Is overriding a function of a library in accordance with C++ standard?

If you didn't include , then the compiler doesn't know anything about strlen().

Edit:
Nevermind, I was barking up the wrong tree. And apparently you DON'T have to include for strlen.

Edit2:
I think you don't run into any compilation errors because you never try to use the function.

It's not in accordance with good programming or software engineering practices at least. If you're going to do something like that, have a wrapper class or library.

Quote:

Original post by skulldrudgery If you didn't include , then the compiler doesn't know anything about strlen().

I'm sure that what you said is incorrect. If you comment the function definition of strlen provided by the user, you can see that the compiler calls the default version of the function.

Quote:

Original post by skulldrudgery Edit: Nevermind, I was barking up the wrong tree. And apparently you DON'T have to include for strlen.

This is unrelated to inclusion.

Quote:

Original post by skulldrudgery Edit2: I think you don't run into any compilation errors because you never try to use the function.

Even if I use strlen("Hello"); in main() body, the compiler still doesn't give me any complaint.

It's actually amusing.. Seems like a compiler bug to me.. I have tried compiling the bellow program with visual studio 2005 and got 1 error during first try of compilation.. But when tried compiling the same program a second time it passed with 0 warnings and 0 errors.

I don't know if there's anything special with standard libraries. I have always treaten them as ordinary additional libraries. To my current knowledge they should obey the ODR (One Definition Rule). Meaning that a non-static function can defined only once per program.

For my best knowledge it's uncommon practice to override standard functions. Personally I would probably curse the programmer who would override standard functions and caused a bug on the way. Hunting such bugs can be very time concuming, especially when you expect something to work because it was made by the experts and was tested by huge amount of programmers(people that use standard libraries). Other than that, I advise you to stop working with C functions and move on to CPP, such as std::string class. Even though it's bit bloated, it has more advantages over C functions.







HTH,
Shimon

Quote:

Original post by Anonymous Poster anyways! it's really not a good idea, because if anyone else uses it, they would assume that they're calling the library function and not the overloaded one.

In some cases it wouldn't matter as much. Such as if you just wanted to deal with null pointers as though they are empty strings in functions like strcmp(). I'm pretty sure most of the standard string functions throw an error or access violation.

But I still agree that a wrapper would be better.

I'm a bit confused here - surely if you include with a properly standards-compliant C++ compiler, the library strlen would be in the std namespace so you would be free to declare another strlen in the global or your own namespace without a conflict?

Or does this not apply if it is included via ?

Don't forget about namespaces! :-)

Yeah, I suppose it would really. That never occured to me before.

Regardless of what the C++ standard says, the microsoft C standard libaries headers for C++ headers(, etc) place their contents into both the global namespace AND namepsace std. I believe they simply include the old style .h file then issue a number of using directives in the std namespace.

I don't have my copy of the standard available at work, so I don't know if that's correct.

EDIT: That's for the 2003 version. The draft version of the standard on the internet indicates that this behaviour is incorrect.

Surprisingly, that would seem to be true for VS 2005 as well. The following code compiles and runs from the VS 2005 IDE:



I can only guess this is an extension (hopefully that can somehow be disabled) for compatibility with legacy code, but then surely any legacy code that was pre namespace std would include ?

I notice that requires std::string s="hello"; and fails on string s="hello";, so it is inconsistent to say the least.

Even Borland's BCC55 implements and correctly and that has been available free for a number of years.

Quote:

Original post by EasilyConfused I notice that requires std::string s="hello"; and fails on string s="hello";, so it is inconsistent to say the least.

std::string is not part of the C Standard Library, so there is no inconsistancy.

CM

Following the standard for everything would be consistent. Following the standard for nothing would be consistent. Following the standard for the C++ SL and not the C SL is, IMHO, inconsistent, hence my comment.

I am aware that std::string is not part of the C standard library.

In g++ it gives 0, in gcc this gives 5, which is weird aswell.
Check out this for the output.

I think I can probably explain GCC's behaviour: the strlen() routine is in libc not libstdc++, i.e. it is exported as a C function. Your version when compiled with C++ will have a different name because it will be mangled to include the return type and parameter types, so it appears to be a different function to the linker.

Other than that - I'm not quite sure why the C version behaves as it does on GCC. You can overload library functions, but it's usually done from a library for debugging purposes (e.g. Electric Fence), and I think that depends on the order in which libraries are loaded to work. In any case I think this is pretty conclusively nonportable. Even if a compiler implented the standard correctly (as I understand it), so that strlen was only in the std namespace your code would not work because your strlen is not in the standard namespace, and I'm pretty sure the C++ standard prohibits putting your own functions into the standard namespace.

Yes, it is compliant to be able to supply a function with any name you choose, as long as it is not a reserved word.

If a compler barfs when you supply your own definition for strlen(), that compiler is either non-compliant or you have not found the switch to disable that behaviour (such as -fno-builtins or its equivalent).

It is necessary to be able to supply a definition for a standard function so that you can use alternate implementations of libraries for whatever reason. Even the basic libraries that come supplied with your compiler are just regular libraries.

The standard does not talk about linkage or dictate implementation.

If you supply your own definition of, say, strlen(), it should compile just fine. The linker will pick it up and use it, and not try to resolve the symbol further by searching any additional libraries. Your definition will replace the one from the standard library. No magic, that's the way seprate compilation is intended to work.

In terms of C++, if you attempt to replace a name in the std:: namespace you will not have written a fully compliant program, but that's more a sort of "you break it, you're on your own" kinda thing. I've spent a lot of time replacing such functions as a part of implementing libstdc++, so I know the compiler isn't going to stop you. You just really need to know the internals of that particular version of the library and compiler to be safe.