«

On May 5, 6:39 pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
> Gernot Frisch wrote:
> > with "MFC" I can do:
> > CString str(_T("test"); printf("%s", str); // prints "test"

> > With my own string class, however, there seems to be a 4 byte "header"
> > before the string data.

> > I have the member >const TCHAR* m_data;< as the first member of my string
> > class.

> > How does MS doe this?

> 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 May 6, 12:54 am, Marcel Müller <news.5.ma...@spamgourmet.org>
wrote:
> 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

On May 6, 1:59 am, m0shbear <andrey....@gmail.com> wrote:
> On May 5, 7:54 pm, Marcel Müller <news.5.ma...@spamgourmet.org> 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.)

--
James Kanze

On May 6, 3:17 pm, Pete Becker <p...@versatilecoding.com> wrote:
> On 2011-05-06 09:59:31 -0400, Goran said:
> >> I have the member >const TCHAR* m_data;< as the first member of my string
> >> class.

> >> How does MS doe this?

> > Luck (well, cheating). First of all, as said, passing non-pod is UB.
> > What actually happens is that your string is passed to printf as a
> > POD. But CString class is made in such a way that "this" is also a
> > pointer to the first character (there's more to CString than a
> > pointer, and you don't want to know that .

> > So... Your code has an error,

> 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.

--
James Kanze

On May 8, 10:08*am, James Kanze <james.ka...@gmail.com> wrote:
> On May 6, 1:59 am, m0shbear <andrey....@gmail.com> wrote:
>
> > On May 5, 7:54 pm, Marcel Müller <news.5.ma...@spamgourmet.org> 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

> 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

On May 9, 11:38*am, "Gernot Frisch" <m...@privacy.net> wrote:
> > 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.

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.