Stupid g++ compiler, how can you be so self-inconsistent in handling std::string???

xuancong · 02-22-2011, 11:24 PM

Quote:

Originally Posted by dwhitney67

See answer below:

Code:

void toupper(std::string& s)
{
   for (size_t i = 0; i < s.length(); ++i)
   {
      s[i] = ::toupper(s[i]);
   }

#ifdef CRAP
   char *p = (char*)s.c_str();
   while(*p){*p=toupper(*p);p++;}
#endif
}

Thanks a lot! That works! -

But I am always worried that using s[i] for string and vector is slow and inefficient because it calls the string::[] operator function every time to retrieve the address of the corresponding character in the string. I'm not sure how fast g++ implements this. Perhaps someone can come out with a speed test to compare the exec speed of modifying s[i] for {char*s} and {string/vector s}. That would fully settle my perhaps unnecessary worry which results in my casting const char* to char*!

Quote:

@johnsfines: xuancong has very bad track record of this. Hopefully he'll take a more appropriate tone in future posts.

I'm really sorry for that, I always gets too agitated upon encountering these kinds of problems, I'll be more careful in the future.

SigTerm · 02-22-2011, 11:58 PM

Quote:

Originally Posted by xuancong

But I just heard of that using s[i] for string and vector is slow and inefficient

That's called "premature optimization".

Instead of believing that something is slow, you should measure actual performance using profilers (linux has gprof for that). Code needs to be optimized for speed only if you identified it as a bottleneck using a profiler. With modern CPU speeds, unless your APP processes billions of strings per second, difference between [] version and pointer version will not be noticeable, and it is possible that (depending on compiler) pointer version will be slower than []-based or iterator-based version.

Before "optimizing" something, you should profile (with gprof or another software) application and find real bottleneck. Without measurements it is easy to spend hours optimizing routine that is never called. Typically slowest operations are memory allocation (calling new/delete millions of times per second), not [] operators. However, your app currently is too small (only two routines), it doesn't run for hours, so there is nothing to optimize yet.

dugan · 02-23-2011, 12:43 AM

Quote:

Originally Posted by SigTerm

With C++ casting you'll get same behavior.... IMO const_cast should be used as a last resort, and preferably only somewhere within a class.

Not the point. Xuancong had failed to RTFM and therefore had no idea that he was casting a const pointer to non-const. Therefore, if he were using C++-style casting, then he would not have used a const_cast. He would instead have tried to use a static_cast, and its failure would have made him realize what he was doing wrong. If he had used a const cast, he would have known what he was doing and therefore would not have started this thread.

Quote:

Originally Posted by SigTerm

With modern CPU speeds, unless your APP processes billions of strings per second, difference between [] version and pointer version will not be noticeable, and it is possible that (depending on compiler) pointer version will be slower than []-based or iterator-based version.

In addition to this and your other very good points, I would add that:

a) the code for the indexing operator may well be inlined by the compiler
b) if you actually were calling the indexing operator billions of times per second, the instructions would almost certainly be cached by the CPU

In both cases, using the indexer would be as fast as the pointer version.

EDIT: the explanation for xuancong's follow-up post is that an earlier version of this one mentioned using std::transform to convert strings to uppercase.

xuancong · 02-23-2011, 01:29 AM

Code:

void toupper(std::string &s) {
std::transform(s.begin(), s.end(), s.begin(), (int (*)(int))std::toupper);}

Thanks! I found it. How come C++ language specification does not include a function for convert strings to upper or lowercase, this is very often used, right?

graemef · 02-23-2011, 07:12 AM

Quote:

Originally Posted by xuancong

How come C++ language specification does not include a function for convert strings to upper or lowercase, this is very often used, right?

I guess that it is not include is because it is a complicated algorithm best suited to specialised libraries.

If you are only considering ACSII then it is simple, but UNICODE means that the requirements are much more extensive than that, if it is to be done properly.

dugan · 02-23-2011, 08:32 AM

Quote:

Originally Posted by xuancong

How come C++ language specification does not include a function for convert strings to upper or lowercase

The Boost string algorithm library, which includes to_upper() and to_lower(), has been proposed for C++0x.