why this if statements fails??!?

[indiocolifa]

Look at the following code which compares for an argument string in the command line:


if (argc <= 1 || argc >= 3)
DisplayHelp();

// interpretar la linea de comandos

char* param = new char[strlen(argv[1])+1];
strcpy (param, argv[1]);

if (param == "-s")
{
cout << "SAVeonly" << endl;
}
exit(1);


I enter -s to test in the command line and the if statement fails!!!
Where I can't compare param == "-s"?? There is anything related to the way i create char*param=new... etc... ???

Thank you!

[PaulWendt]

param is a char*; that's basically just an integer as far as the
computer is concerned. Basically, what's happening is that the
compiler is comparing the addresses of the two pointers. To
compare char*'s, you must use the function strcmp():

char* str1 = "hi";
char* str2 = "hi2";

if (strcmp(str1, str2) == 0)
{
// strings are equal in here
}
else if (strcmp(str1, str2) < 0)
{
// str1 is less than str2 in h ere
}
else
{
// str2 is less than str1 in here
}



--Paul

[PaulWendt]

Oh, and as an aside, is there any reason why you're not using
std::string in lieu of using those char*'s? You've already run into
memory management problems [I don't see any exception
handling so if an exception is thrown, param will never be
delete'd]. Obviously, you've also run into the operator== dilemma
... where you can't use an interface which is intuitive.

std::string solves all of these problems [and more]:

if (argc <= 1 || argc >= 3)
DisplayHelp();

// interpretar la linea de comandos

std::string param(argv[1]);
if (param == "-s")
{
cout << "SAVeonly" << endl;
}


If an exception is thrown, now you won't have to worry about a
memory leak; also, you get the syntactic sugar of the operator==
comparison.

--Paul

[indiocolifa]

Yeah, thanks, i fixed it...

Im so stupid, I dont know why Im still stick with the char* types instead of std::string type.

Aynway, there is any advantage in C++ for using char* instead of string????

[Graham]

Originally posted by indiocolifa
Aynway, there is any advantage in C++ for using char* instead of string????
No.

[indiocolifa]

My next (easy.. :) ) question is how to convert to uppercase a string.

The following code (of course) wont do it:

string pm = "hello";
strupr(pm);


i tried the following and failed (because STRUPR expects a char* not a const char*)

strupr (pm.c_str() );

[Philip Nicoletti]

#include <algorithm>


std::transform(pm.begin(),pm.end(),pm.begin(),toupper);

[PaulWendt]

There are many, many ways to achieve this. One of the easiest
to understand might be:

#include <algorithm>
#include <iostream>
#include <string>

void convertToUpper(char& toConvert)
{
toConvert = toupper(toConvert);
}

int main(int argc, char* argv[])
{
string temp("this is a test string");
for_each(temp.begin(), temp.end(), convertToUpper);

cout << temp << endl;
}


--Paul

[indiocolifa]

I found in DEVX.com the following code snippet that will do the trick.
std::transform(pm.begin(), pm.end(), pm.begin(), (int(*)(int)) toupper);

I think its more compact...

Thank you Paul for your help!

(also, i dont know if this is good technique, I ve made the following macro to easier use)


#define STRTOUPPER(x) (std::transform((x).begin(), (x).end(),\
(x).begin(), (int(*)(int)) toupper));

Is this good technique? or bad programming practice? Many sites tell that C Macros are a bad technique in C++.

[PaulWendt]

I wouldn't bother with the macro; I'd just use std::transform. If
the idea of algorithms bothers you [as I thought it would] you
should wrap the entire thing in an inline function: you'd get all of
the benefits of the macro, but would still retain the type safety
of the compiler.

--Paul

[Graham]

Don't use macros. Macros are evil. Use an inline if you must, but I would say: keep the original as it is. Anyone who knows their way around STL will immediately recognise the transform call and know what's happening. And if they don't know their way around STL...... there's still time to learn.

For one thing, if you keep the original form in your code then, should you do something slightly different nearby (say, only transform part of the string), then the correspondance between the two bits of code will be apparent. Of course, you could modify the inline function to do partial strings, but then it starts to look like the original, so what's the point?

string::iterator si1 = s.begin(), si2 = s.end();
transform(si1, si2, si1, MakeUpper());
//...
// Modify si1 and si2 so that they mark out a substring....
transform(si1, si2, si1, MakeUpper());

compared to:

UppercaseWholeString(s);
//...
string::iterator si1, si2; // a subrange of the string
transform(si1, si2, si1, MakeUpper());

and, of course, then you find you need MakeLower.

[Ajay Vijay]

What about performance measurements with these STD 'string's. They could'nt serve you any better than core str... counterparts.

[Graham]

Originally posted by Ajay Vijay
What about performance measurements with these STD 'string's. They could'nt serve you any better than core str... counterparts.
Are you sure about that?

[Paul McKenzie]

Originally posted by Ajay Vijay
What about performance measurements with these STD 'string's. They could'nt serve you any better than core str... counterparts. Why not write code to test this? Take concatenation for example:

Make sure that when you write the equivalent of concatenation for the string.h functions you:

a) determine if the source is large enough to hold the destination.

b) If not large enough, call malloc() or new[] to allocate the memory.

c) Copy the source to the destination

d) Make sure that you call free() or delete[] to clean up the memory when done.

Now time the above steps with doing an operator += with a std::string. Of course, to do these steps, it would be wise to write a class that wraps the str... functions. But wait a minute -- that's already been done with std::string. So all you would be doing is reinventing the wheel -- a wheel that has been written by some of the best C++ programmers in the business.

edit :[I also forgot to add that old string.h functions and char * leads to more bugs, especially if that char * is a class member. You have to write a copy constructor and assignment statement for the class to make sure the char * is copied correctly. The std::string can be used safely in a class without writing a copy ctor or assignment functions to take care of the copy.]

Regards,

Paul McKenzie

[Paul McKenzie]

Originally posted by Graham

Are you sure about that? Personally, I believe the old <string.h> functions should be relegated to a small section in the appendix of every C++ programming book.

Regards,

Paul McKenzie

[Graham]

... and that appendix then torn out by the bookseller.

[Ajay Vijay]

What about CString of MFC.
Dont it will cause a performance bottleneck. You may like just because it has pretty of member to solve variety of string problems.

MFC drawback is documented but std::string may not be (I didnt try to see that).

I think you(all) should test the performance with copying, comparing, concatenating and so on on about 1000 strings within a loop!!!

[Bassman]

I think you(all) should test the performance with copying, comparing, concatenating and so on on about 1000 strings within a loop!!!

Rather than make vague claims and tell everyone else to do some research, do you have some hard results you would like to share with us?

Some hard conclusions you've reached that aren't generally obvious like less instructions usually equals higher performance?

And those findings are of course offset with an analysis of the long-term costs of using code of greater complexity in the name of saving a few CPU cycles?

Or is it dependent on situation to situation? And if that's the case, then why not go with the tools that are easier to code initially so you can spend more time worrying about keeping to the implementation design and less time worrying about deleting[] all those bloody new char[]? Or buffer overruns? Or not allocating enough memory? Or leaking memory? Etc, etc, etc.

Regards,
Bassman

[indiocolifa]

I think we should find the mix between good code maintenance (less errors and wasting debugging hours) and acceptable speed.

I would try MFCs CString, but ... this means VC will link all the bloated MFC code into my program?

This is done with

#include <stdafx.h>

im right?

[Paul McKenzie]

Originally posted by indiocolifa
I think we should find the mix between good code maintenance (less errors and wasting debugging hours) and acceptable speed.Get the program to work first, then find where there are probable slow spots by properly profiling the code.

I still hold that trying to do what std::string does using <string.h> functions is a waste of time, especially when you discover you've spent all the time coding something that has very minimal speedup, no speed up at all, and in many cases a degradation of speed (can you write code that is more optimal than the library writer?)I would try MFCs CString, but ... this means VC will link all the bloated MFC code into my program?Just use std::string and you don't worry about MFC.

Regards,

Paul McKenzie

[indiocolifa]

But there are advantages in using MFC's CString over std::string?
thank you.

[Paul McKenzie]

Originally posted by indiocolifa
But there are advantages in using MFC's CString over std::string?
thank you. What if I'm not using MFC, or VC++, or even running Windows? This is not only the case for std::string, but for all the container classes. You don't need MFC for container and string classes, period. Everything that the MFC container classes and string classes support, the standard library IMO does a much better job. You will also get the same reply from practically every expert who has dealt with MFC classes and the standard classes.

In all the coding that I've done that had used CString (this was years ago), I quickly and easily replaced all of it with std::string. Therefore, I see no advantages, and a whole lot of disadvantages of CString over std::string.

a) CString is proprietary to MFC. The std::strng is an ANSI standard C++ class and is supported by all ANSI compliant C++ compilers, regardless of operating system.

b) To use CString, you must either link in gobs of MFC code in your application or add the MFC DLL's to your application. With std::string, this is not necessary.

Too many programmers who are not using MFC in their apps automatically try to include MFC when they need a string or container class. I don't know if it's Microsoft brainwashing, or not having learned C++ from a good textbook as to why this phenomenon occurs, but it does happen (check out the VC++ Forum -- you'll find more than a dozen messages from people trying to include MFC in their non-MFC apps when they need a string, map, dynamic array, etc.)

Regards,

Paul McKenzie

[indiocolifa]

all right... i will stick to ansi c++

recommend me please a good c++ book
bruce eckel´s "Thinking in C++" ??? this is a good book to buy?

[Paul McKenzie]

Originally posted by indiocolifa
all right... i will stick to ansi c++

recommend me please a good c++ book
bruce eckel´s "Thinking in C++" ??? this is a good book to buy? http://www.codeguru.com/forum/showthread.php?s=&threadid=231039

Add to that list "The C++ Standard Library" by Nicolai Josuttis.

Regards,

Paul McKenzie