printf("%s", myclass) prints vtable instead of m_data

[Gernot Frisch]

Hi,

class MyString
{
char* m_data;
public:
MyString(const char* c)
{
m_data = new char[1024];
strcpy(m_data, c);
}
virtual ~MyString()
{
delete[] m_data;
}
};

int main()
{
MyString ms("KungFoo");
print("Here is: %s", ms);
}
this prints the address of the vtable pointer (VC++7.1) instead of
m_data. Is there any way of getting this to work, so that &ms points
to ms.m_data?

I know - removing the virtual keyword will do, but any other way?
--
-Gernot
int main(int argc, char** argv) {printf
("%silto%c%cf%c gl%ssic%ccom%c" , "ma", 58, 'g', 64, "ba", 46, 10);}

[Jens Theisen]

"tragomaskhalos " <da************ *@logicacmg.com writes:

If your string class contains a single pointer into a null-terminated
buffer of chars, with length, reference count or whatever housekeeping
stuff you want in memory *before* the chars [so eg bytes0-3 ref count,
bytes4-7 length, bytes8ff the chars, pointer points at byte 8, pace
alignmnent issues], and if the class has no virtual functions, then one
can see how printf("%s")ing such a thing would "just work". Is this
relying on specific compiler behaviour? Well I guess technically it
is;

And it's in practice. If you try that in gcc, gcc will warn you at
compile time that it's about to abort at runtime - and then it will
abort at runtime.

If you relied on this M$ hack, you have a harder time migrating away
from their toolchain, which is why they introduced this hack.

Now just because they *could* have done it this way, doesn't mean they
*should* have done it this way, but making CString behave just like a
char* wrt printf is a good commercial decision even if we cringe at it
from a technical/purist perspective.

It's embrace and extend, and that may be a good commercial decision,
and such is drug trafficking at whiles.

Regards,

Jens

[Gernot Frisch]

And it's in practice. If you try that in gcc, gcc will warn you at
compile time that it's about to abort at runtime - and then it will
abort at runtime.

Problem is: The MS compiler will not warn you, nor will it yield an
error. So, when you port to gcc at least you get warned about it.
Why can't they stick with the #~*$%& standard!

[Eberhard Schefold]

Gernot Frisch wrote:

I provided "ms" because I wanted "ms". The Microsoft CString is
designed to work in a printf ellisis, so I wanted a safe way of doing
the same.

No MS documentation states that CString was "designed" that way, or that
you should take advantage of an undefined behaviour which happens to
"work" as intended. Here's the respective part in the CSimpleString
documentation (the CString base class that provides the built-in const
char * operator):

// If the prototype isn't known or is a va_arg prototype,
// you must invoke the cast operator explicitly. For example,
// the va_arg part of a call to sprintf( ) needs the cast:

sprintf( sz, "I think that %s!\n", ( PCXSTR ) strSports );

Everybody (including MS) knows today that the built-in const char *
operator probably shouldn't have been there in the first place, but we
should not entirely forget that the CString design is 14 years old.

[Pete Becker]

Gernot Frisch wrote:

>And it's in practice. If you try that in gcc, gcc will warn you at
compile time that it's about to abort at runtime - and then it will
abort at runtime.

Problem is: The MS compiler will not warn you, nor will it yield an
error. So, when you port to gcc at least you get warned about it.
Why can't they stick with the #~*$%& standard!

They do. The standard says that passing a non-POD to an ellipsis
produces undefined behavior, which means simply that the standard does
not impose any requirement. It's up to the implementor to decide whether
to do something sensible with that.

--

-- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.

[Eberhard Schefold]

Pete Becker wrote:

They do. The standard says that passing a non-POD to an ellipsis
produces undefined behavior, which means simply that the standard does
not impose any requirement.

I thought the word was "unspecifie d" if the standard offered any
liberties to the implementation.

[Pete Becker]

Eberhard Schefold wrote:

Pete Becker wrote:

>They do. The standard says that passing a non-POD to an ellipsis
produces undefined behavior, which means simply that the standard does
not impose any requirement.

I thought the word was "unspecifie d" if the standard offered any
liberties to the implementation.

That is also one of the terms that the standard uses. It doesn't give as
much liberty as undefined does. For example, the order of evaluation of
the arguments to a function is unspecified:

int f();
int g();
void h(int,int);

h(f(), g());

The standard doesn't require that f() be called before g(), nor does it
require that g() be called before f(). Nevertheless, the program is
valid, and you have to be aware that you can't count on any particular
order.

void *p = 0;
*p = 3;

The program is invalid under the standard. Its behavior is undefined.
The standard doesn't say what it does.

For more details, see the preface to my book, "The Standard C++ Library
Extensions."

--

-- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.

[Gavin Deane]

Eberhard Schefold wrote:

Pete Becker wrote:

They do. The standard says that passing a non-POD to an ellipsis
produces undefined behavior, which means simply that the standard does
not impose any requirement.

I thought the word was "unspecifie d" if the standard offered any
liberties to the implementation.

It's not a violation of the standard if an implementor chooses to have
their implementation behave in a predictable and documented way in one
particular case of formally undefined behaviour.

1.3.13 unspecified behavior
behavior, for a well-formed program construct and correct data, that
depends on the implementation. The implementation is not required to
document which behavior occurs. [Note: usually, the range of
possiblebehavio rs is delineated by this International Standard. ]

Gavin Deane