this cast to const char*

[James Kanze]

First, MS could use compiler magic to define the UB of the first line. With
your own (homegrown) string class, any use of printf would be UB (the specs
of printf simply won't know about your string class).

Second, I doubt that MS actually does use compiler magic and the first line
could just "work" by accident. Question: does your string class have a
virtual method (e.g., the destructor)? does the CString class?

I don't think it's just "by accident". The authors of the
library knew what the compiler did, and designed their string
class so that it works (and the compiler intentionally doesn't
do anything which would make such a design particularly
difficult).

In the case of VC++, when passing a non-POD to a ..., the
compiler simply copies the object to where it would be on the
stack, much as if it was a POD. The library ensures that
CString contains just a single pointer, which points to the
actual string data (and it also ensures that there is always a
trailing '\0'); g++ has a fairly similar implementation (except
that I don't think they guarantee the '\0'), but the compiler
doesn't handle passage of a non-POD to ... in quite the same
manner.

 

[James Kanze]

On 06.05.11 01.11, Balog Pal wrote:
[...]
There is still no reasonable replacement in the standard. One must be
stoned to use the iostream output operators, because besides being type
safe they create completely unreadable code, at least if you use
different formatting (like hex and decimal) concurrently.

Actually, the reverse is true. The iostream are about the only
output system which allows logical markup, which in turn greatly
increases readability and maintainability.

 

[James Kanze]

[...]
Boost has a nice replacement for std:rintf, using overloaded '%'
instead of ',' for varargs.

The choice of '%' is really what makes it unusable, because the
operator doesn't "stand out" like '<<', so the resulting
expressions become unreadable. For the rest, the boost
implementation is very good, as it allows you to continue to use
manipulators, which are essential if you want readable and
maintainable code. (Embedding the "6.2" or whatever in the
language dependent string is another serious flaw in printf.)

 

[James Kanze]

No, it doesn't. "Undefined behavior" means only that the C++ standard
doesn't tell you what the code does. There's nothing preventing a
compiler from defining the behavior, and there's nothing inherently
wrong with relying on implementation-specific behavior.

And if you're using CString (instead of std::string), you're
already very implementation specific, so you might as well take
the good (assuming you consider being able to use printf good)
with the bad.

 

[m0shbear]

On May 5, 7:54 pm, Marcel Müller <[email protected]> wrote:

    [...]

Boost has a nice replacement for std:rintf, using overloaded '%'
instead of ',' for varargs.

The choice of '%' is really what makes it unusable, because the
operator doesn't "stand out" like '<<', so the resulting
expressions become unreadable.  For the rest, the boost
implementation is very good, as it allows you to continue to use
manipulators, which are essential if you want readable and
maintainable code.  (Embedding the "6.2" or whatever in the
language dependent string is another serious flaw in printf.)

'%' is indeed idosyncratic, but it's still more useful than printf and
its questionable type safety.
It does take quite a while to be able to read what was written though,
kind of like perl code

 

[Gernot Frisch]

with "MFC" I can do:
CString str(_T("test"); printf("%s", str); // prints "test"

Hi,

problem is: We want to replace CString in an existing project, and there are
lots of the above situations.

Now, My string class does not have any virtual member functions. What else
could it be? I can't find how MS did that trick.

Bye,
-Gernot

 

[Öö Tiib]

Hi,

problem is: We want to replace CString in an existing project, and there are
lots of the above situations.

Can't you just add member 'char const* c_str()' to your string?
Then

CString str(_T("test")); printf("%s", str);

becomes

YourString str("test"); printf("%s", str.c_str());

If it is hard to find the places where to add that '.c_str()' then
download g++ and try to compile , it will warn such places.

Now, My string class does not have any virtual member functions. What else
could it be? I can't find how MS did that trick.

MS CString is seemingly header-only. How can it be that you can not
find it? If you can't understand the trick then ... do not use evil
magic you can't understand.