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