Need a better way to valid Computer name using C++ code - winapi

I am not trying to set the local hostname. In my app using a edit control need to accept a host name (fully qualified with DNS / without).
We do know we cannot use chars a (\ / ! # # $ % ^). Is there a better way than programmatically parsing the user input.
Code needs to work in all languages (multi byte char set)
Thanks
AnilG

Not that I could think of. The effort to do this yourself is pretty slim, though. See _mbschr and _mbscspn for good examples on how to search for a single character and multiple characters.
There is also a good overview over string functions supported by Visual Studio here.
char string[] = "xyzabc";
int pos;
pos = strcspn( string, "abc" );
printf( "First a, b or c in %s is at character %d\n", string, pos );

You can use the PCRE library to match the string against a regular expression.

Related

Godot: too few arguments

every now and then I stumble over an error-message like the one in this case:
if "," in text.erase():
print ("comma erased")
error(109,1): Too few arguments for "erase()" call. Expected at least
2.
Whatever I try to put into those (), nothing seems to work. How can I find out what arguments I need in such a case?
At least some basic programming knowledge provided, the editor's Search Help offers some useful info in such a case:
void erase ( int position, int chars )
Erases chars characters from the string starting from position.

Significance of an ampersand in VB6 function name?

I just got a bunch of legacy VB6 (!) code dumped on me and I keep seeing functions declared with an ampersand at the end of the name, for example, Private Declare Function ShellExecute& . . ..
I've been unable to find an answer to the significance of this, nor have I been able to detect any pattern in use or signature of the functions that have been named thusly.
Anyone know if those trailing ampersands mean anything to the compiler, or at least if there's some convention that I'm missing? So far, I'm writing it off as a strange programmer, but I'd like to know for sure if there's any meaning behind it.
It means that the function returns a Long (i.e. 32-bit integer) value.
It is equivalent to
Declare Function ShellExecute(...) As Long
The full list of suffixes is as follows:
Integer %
Long &
Single !
Double #
Currency #
String $
As Philip Sheard has said it is an indentifier type for a Long. They are still present in .Net, see this MSDN link and this VB6 article
From the second article:
The rules for forming a valid VB variable name are as follows:
(1) The first character must be a letter A through Z (uppercase or
lowercase letters may be used). Succeeding characters can be letters,
digits, or the underscore (_) character (no spaces or other characters
allowed).
(2) The final character can be a "type-declaration character". Only
some of the variable types can use them, as shown below:
Data Type Type Declaration Character
String $
Integer %
Long &
Single !
Double #
Currency #
Use of type-declaration
characters in VB is not encouraged; the modern style is to use the
"As" clause in a data declaration statement.

What's the most reliable way to parse a piece of text out into paragraphs in RealBasic that will work on Windows, Mac, and Linux?

I'm writing a piece of software using RealBASIC 2011r3 and need a reliable, cross-platform way to break a string out into paragraphs. I've been using the following but it only seems to work on Linux:
dim pTemp() as string
pTemp = Split(txtOriginalArticle.Text, EndOfLine + EndOfLine)
When I try this on my Mac it returns it all as a single paragraph. What's the best way to make this work reliably on all three build targets that RB supports?
EndofLine changes depending upon platform and depending upon the platform that created the string. You'll need to check for the type of EndOfLine in the string. I believe it's sMyString.EndOfLineType. Once you know what it is you can then split on it.
There are further properties for the EndOfLine. It can be EndOfLine.Macintosh/Windows/Unix.
EndOfLine docs: http://docs.realsoftware.com/index.php/EndOfLine
I almost always search for and replace the combinations of line break characters before continuing. I'll usually do a few lines of:
yourString = replaceAll(yourString,chr(10)+chr(13),"<someLineBreakHolderString>")
yourString = replaceAll(yourString,chr(13)+chr(10),"<someLineBreakHolderString>")
yourString = replaceAll(yourString,chr(10),"<someLineBreakHolderString>")
yourString = replaceAll(yourString,chr(13),"<someLineBreakHolderString>")
The order here matters (do 10+13 before an individual 10) because you don't want to end up replacing a line break that contains a 10 and a 13 with two of your line break holders.
It's a bit cumbersome and I wouldn't recommend using it to actually modify the original string, but it definitely helps to convert all of the line breaks to the same item before attempting to further parse the string.

User-defined Literals suffix, with *_digit..."?

A user-defined literal suffix in C++0x should be an identifier that
starts with _ (underscore) (17.6.4.3.5)
should not begin with _ followed by uppercase letter (17.6.4.3.2)
Each name that [...] begins with an underscore followed by an uppercase letter is reserved to the implementation for any use.
Is there any reason, why such a suffix may not start _ followed by a digit? I.E. _4 or _3musketeers?
Musketeer dartagnan = "d'Artagnan"_3musketeers;
int num = 123123_4; // to be interpreted in base4 system?
string s = "gdDadndJdOhsl2"_64; // base64decoder
The precedent for identifiers of the form _<number> is the function argument placeholder object mechanism in std::placeholders (§20.8.9.1.3), which defines an implementation-defined number of such symbols.
This is a good thing, because it means the user cannot #define any identifier of that form. §17.6.4.3.1/1:
A translation unit that includes a standard library header shall not #define or #undef names declared in any standard library header.
The name of the user-defined literal function is operator "" _123, not simply _123, so there is no direct conflict between your name and the library name if presence of the using namespace std::placeholders;.
My 2¢, though, is that you would be better off with an operator "" _baseconv and encoding the base within the literal, "123123_4"_baseconv.
Edit: Looking at Johannes' (deleted) answer, there is There may be concern that _123 could be used as a macro by the implementation. This is certainly the realm of theory, as the implementation would have little to gain by such preprocessor use. Furthermore, if I'm not mistaken, the reason for hiding these symbols in std::placeholders, not std itself, is that such names are more likely to be used by the user, such as by inclusion of Boost Bind (which does not hide them inside a named namespace).
The tokens are not reserved for use by the implementation globally (17.6.4.3.2), and there is precedent for their use, so they are at least as safe as, say, forward.
"can" vs "may".
can denotes ability where may denotes permission.
Is there a reason why you would not have permission to the start a user-defined literal suffix with _ followed by a digit?
Permission implies coding standards or best-practices. The examples you provides seem to show that _\d would fine suffixes if used correctly (to denote numeric base). Unfortunately your question can't have a well thought out answer as no one has experience with this new language feature yet.
Just to be clear user-defined literal suffixes can start with _\d.
An underscore followed by a digit is a legal user-defined literal suffix.
The function signature would be:
operator"" _4();
so it couldn;t get eaten by a placeholder.
The literal would be a single preprocessor token:
123123_4;
so the _4 would not get clobbered by a placeholder or a preprocessor symbol.
My reading of 17.6.4.3.5 is that suffixes not containing a leading underscore risk collision with the implementation or future library additions. They also collide with existing suffixes: F, L, ULL, etc. One of the rationales for user-defined literals is that a new type (such as decimals for example) could be defined as a pure library extension including literals with suffuxes d, df, dl.
Then there's the question of style and readability. Personally, I think I would loose sight of the suffix 1234_3; Maybe, maybe not.
Finally, there was some idea that didn't make it into the standard (but I kind of like) to have _ be a literal separator for numbers like in Ada and Ruby. So you could have 123_456_789 to visually separate thousands for example. Your suffix would break if that ever went through.
I knew I had some papers on this subject:
Digital Separators describes a proposal to use _ as a digit separator in numeric literals
Ambiguity and Insecurity with User-Defined literals Describes the evolution of ideas about literal suffix naming and namespace reservation and efforts to deconflict user-defined literals against a future digit separator.
It just doesn't look that good for the _ digit separator.
I had an idea though: how about either a backslash or a backtick for digit separator? It isn't as nice as _ but I don't think there would be any collision as long as the backslash was inside the stream of digits. The backtick has no lexical use currently that I know of.
i = 123\456\789;
j = 0xface\beef;
or
i = 123`456`789;
j = 0xface`beef;
This would leave _123 as a literal suffix.

Visual basic handle decimal comma

I'm trying to save variables into text files and the Czech typographic rules drives me crazy.
The program I'm tuning is dedicated to work on Czech localized computers where decimal comma is used but the VB is working with normal, standard decimal dot.
When loading files "US" decimals are loaded correctly and showed as Czech decimals. In TextBoxes "Czech" decimals are required. My problem is that program generates Czech decimals and require the "US" ones.
How can I force VB program to read comma as decimal sign instead of delimiter or how to export data with dots instead of commas?
Yes I can load 123,456 as a=123 and b=456 and then return value as a + b/1000 but is there more elegant solution?
Pick the right function.
Val, Str will always use US settings (dot as decimal)
CDbl, Format will take account of the regional settings.
It's all in the manual section on international programming.
Your trouble might be due to use of the Val function; that isn't international. The help text recommends the use of CDbl when converting from strings to numbers.
Thanks for your advices, I'm not sure if I did something wrong, but I've obtained only errors (ie. type mismatch) or "Czech" decimal comma.
I've tried 'Got slapped? Slap him harder!' aproach with this code:
Dim PpP As String, SaveFile As Integer
PpP = Form1.TxtA10.Text & " " & Form1.TxtA11.Text
PpP = Replace(PpP, ",", ".")
Print #SaveFile, PpP
edit:
something means trying those functions at the output, not at the input. (like trying Double as String parameter).
This code:
Input #1,TempString
Form1.TxtA10.Text = CDbl(TempString)
works aswell.
Try,
Format$(CDbl(Text1.Text), "#,##0.00")

Resources