OK! I''m trying to implement a console menu in my Win32 App. So, I made a ''char input[128]'' to store the characters the user types in, and an ''unsigned int currentno'' to track how many characters are already in the buffer. When a user inputs a char (tracked by using the wParam from a WM_CHAR message), I add the character in the current location of the buffer, increment the counter and add a NULL as the next characters input[currentno] = wParam; currentno++; input[currentno] = NULL; When I detect a backspace pressed, I do the opposite, place a NULL at the current location and decrease the currentno. All is fine, and when I output the text onto the screen, it works fine. However, when I start to do comparisons like (input == "XYZ"), it always fails even though it shows that the input is currently "XYZ" on the screen. I''ve tried (input == "XYZ\0") as well just to test, but it still fails. Anyone can clear this up a little?

Your comparing pointers, not strings. Try the c standard library function strcmp instead. Also remember that the strings will be case sensitive.

Thanx! Never saw it that way.. strcmp works fine now.

I have another (yet untested, more theoretical) solution!You could try to overload the ==-operator
It may use the standard string functions of c inside, but using these method would be easier

B.o.t.G.
--------

Writer of the VQAtoAVI conversation utility for CC

quote: Original post by B.o.t.G.

I have another (yet untested, more theoretical) solution!You could try to overload the ==-operator
It may use the standard string functions of c inside, but using these method would be easier

Isn''t this exactly what the CString class has? A quick look in the help shows that most of the comparison operators ( == != ... ) are supported as well as usfull things like +.

------------
Andrew

Actually, the CString class is different, because it is a dynamic string class, which uses dynamically allocated arrays, as is the STL basic_string. You wouldn''t want to override the + operator for a static array, that would produce... er... interesting results. == is a nice thing to overload, however, though it would probably just involve using a strcmp anyway. One thing you have to watch is your interpretation versus your user''s interpretation of what''s happening. Personally, when I see "==" applied to a character array, I think of it in terms of pointers... if it were overloaded and I didn''t know about it, I wouldn''t think to use it or would find it rather confusing.

An interesting thing about basic_string (I''m not sure about CString, I haven''t tested this on it yet) is that a copy of a string isn''t actually allocated new space until either the copy or the original is changed, at which point whichever was changed is moved. This can cause a serious debugging headache when you''re trying to watch addresses for errors, but it''s really a very cool thing, because it helps to lower memory usage and fragmentation (usage by not using more memory until you really need it, and fragmentation reduction due to the fact that the original string fit perfectly in that slot, so you move the one that no longer fits perfectly.)

I''m rambling aren''t I. *smile* (/ramble)

-fel

Overloading the == operator sounds like a good idea at first, but once you''ve done that you''ll no longer be able to simply compare two pointers.

Using or implementing a string class as acraig suggested is the way I''d go if the need to do more than simply compare two strings arose.

This gets a little off topic, but my only problem with the CString class is that if you try to do any type of heap management to decrease memory fragmentation for lists of structures containing CStrings, you inevitably can''t do it. The dynamic nature of CString is nice for command buffers and such, but for large lists that are maintained in a heap they tend to cause fragmentation regardless of the memory sharing algorithm in the code. I would like to find a capable string class that has a fixed length. Fixed length strings are easier to control for memory usage. I almost suspect that the allocation deallocation occuring in the CString class is one of the reasons poor performance over time happens with NT, 98, 95, ...

Just my rant on CStrings.
Kressilac

quote: Original post by felisandria
An interesting thing about basic_string (I''m not sure about CString, I haven''t tested this on it yet) is that a copy of a string isn''t actually allocated new space until either the copy or the original is changed, at which point whichever was changed is moved.

It''s true for CString too. Also for the Borland AnsiString class. I''m not certain about the Borland WideString class, but it most likely has the same behavior.

Interesting tidbit: the internal memory allocated inside the the CString object keeps a pointer to the beginning of the dynamically allocated string, but that isn''t the beginning of the dynamically allocated memory. Reference count values are stored in front of the string proper. This can really louse up automatic garbage collectors. Actually, the only member variable for CString is this pointer to dynamic memory, which is why you can push and pop CStrings on the stack so freely. Well that, and the reference counting that CStrings do.