Thread: Just say NO to strlen.

because you aren't allowed to create user defined functions with those names.

Why not? Just change the parameter type to char* and return type to int, and you're all good - no ambiguity. Besides, the library functions are supposed to be in the std:: namespace.

Code:

#include <iostream>
#include <string>
#include <cstring>
#include <cstdlib>

int strlen(char* x)
{  return 200;  }

int main()
{
    char* y = "1234";
    for(int i = 0; i < strlen(y); ++i)
        std::cout << y[i];

    std::cin.get();
    return 0;
}

Output:

1234 4³I úÚB l³I OåB @´I þÑB T €´I ÖÖB ð´I ’ãB ÍÚB [èB ÆÒB àB IÒB ØB ÓB ‹ÑB dßB oèB 3ÞB {æB $µI láB ©àB ˜ÝB ÆÒB jèB èB ØB ÓB ¼æB íÓB ûèB ÞçB åB

Code:

std::string

Problem solved!

Spoilsport.

Originally Posted by Thantos

Maybe because toupper() and strlen() are defined by the implentation.

But they aren't built into the compiler, are they? And even if they are, are their specific characteristics built-in too? In some implementations (GNU libc is an example, I think), it is in fact impossible for the compiler to deduce the behaviour of toupper from the code, because the lookup tables are loaded at locale setting time from files on the disk. In other words, the exact behaviour of toupper is not known at compile time.

Which means that the knowledge, "toupper only returns 0 when passed 0" must be built into the compiler.
(On a side note, the _toupper macro that appears in the MS CRT ctype.h header doesn't fulfill this guarantee.)

In other words:

1) The compiler must have been explicitely told that toupper returns 0 only when being passed 0.
2) The compiler must either have been explicitely told, or able to deduce from the (suddenly available) code of strlen (which very often is implemented in assembly), that a loop over a sequence passed to strlen and controlled by its return value can never hit a 0 character in its body.
3) The compiler must either have been explicitely told, or able to deduce from strlen's source, that its return value only changes if a change to the sequence results in a new location of the first 0 character.
4) The compiler must either have been explicitely told, or able to deduce from strlen's source, that strlen has no additional side effects.

Given these three pieces of information, the compiler must follow this line of logic:
Since the loop is controlled by strlen, only non-0 characters will appear in it. The only change to the sequence is the assignment of a value that comes from the same position in the sequence and has been passed through toupper. toupper will only ever return 0 if 0 was passed in, which means that it will never return 0 in this loop, and thus no new 0 characters are introduced inside the loop. Since strlen's return value can never change under these circumstances, strlen can be considered a loop-time constant and can safely be fetched only once.

I think you're asking a lot, even from modern compilers.

Changing the parameter char * instead of const char * will cause ambiguity for the user. They might expect to get your function but instead will get the standard function if they use a const pointer or const array.

Indeed, but it's a possibility that the compiler must take into account.

Ok, well I just ran a test (MSVC 2005 release build):

Code:

#include <iostream>
#include <cstring>
#include <cctype>
#include <windows.h>

int main()
{
    char a_str[1000];
    for(int i = 0; i < 1000; ++i)
        a_str[i] = 'x';
    a_str[999] = '\0';

    DWORD j = GetTickCount();
    for(int p = 0; p < 10000; ++p)
    {
        for ( int ix = 0; ix < strlen(a_str); ix++)
        {
            a_str[ix] = tolower( (unsigned char) a_str[ix] );
        }
    }
    DWORD end = GetTickCount() - j;
    std::cout << end << std::endl;

    j = GetTickCount();
    for(int p = 0; p < 10000; ++p)
    {
        int n = strlen(a_str);
        for ( int ix = 0; ix < n; ix++)
        {
            a_str[ix] = tolower( (unsigned char) a_str[ix] );
        }
    }
    end = GetTickCount() - j;
    std::cout << end << std::endl;

    std::cin.get();
    return 0;
}

Output on my machine:

7031
47

Strangely enough, under Debug build:

3235
93

Apparently, the compiler anti-optimized the strlen version for Release build, and optimized the 'proper' version. However, either way the Release build of the strlen version took 149.6 times as long, and the Debug build took 34.8 times as long.

Yeah, I always see strlen hanging around in back alleys in the shady parts of town.