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

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%cgl%ssic%ccom%c", "ma", 58, 'g', 64, "ba", 46, 10);}

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

Gernot Frisch <Me@Privacy.netwrote:Provide a function c_str (or whatever you want to call it), which
returns the char*. Then call printf like:

printf ("Here is: %s", ms.c_str ());

You cannot pass non-PODs thru the ellipsis, afaik.
Removing the virtual keyword may work in your case, but it is still
invalid, as you are still passing a non-POD thru an ellipsis.

hth
--
jb

(reply address in rot13, unscramble first)

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

Gernot Frisch schrieb:You really don't want this. This will result, sooner or later, in an
access violation. What happens if c is nullptr? What happens if c does
not point to a null terminated C-style-string? What happens if c is is
1025 characters long?
printf
No. &ms will always point to the address of the instance ms. BTW, you
provided ms, not &ms to print(f). You'll save your own time if you use
copy'n'paste instead of typing source in your newsreader all the time,
including typing errors or whatever.
No, it will not do. You just have been lucky that your program didn't
crash.

Summarized:
* you want std::string, or
* you want to implement a MyString::c_str() method, or
* you want to use <iostream>s and implement a custom
operator<< for ostream and MyString.

Just i.e.:

const char* MyString::c_str()
{
return m_data;
}

and:

printf("%s", ms.c_str());

or:

cout << ms.c_str() << endl;

or (given that you implemented operator<< for ostreams):

cout << ms << endl;

This is, btw, more or less (omitting some details) what std::string
does. You probably do want to use std::string, it is not the worlds
best design of a string class, but its quite much better than anything
you and me will ever invent.


Best regards,
-- Markus

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

Markus Grueneis wrote:c being null or not pointing to a nul-terminated string are a problem
with std::string too though.

It is true that 1024 is arbitrary and I don't see the reason for it.
Apart from that the class above is flawed in:

1. No defined copy-constructor or assignment, nor are they disabled in
a case where the default ones are not valid.

2. No means to access the string.

although perhaps he intended to add more methods (after all why have a
virtual destructor with no other virtual methods?)
You missed a const. Or put in one too many. Actually you can do this:

char* MyString::c_str() const
{
return m_data;
}

but probably wouldn't want to as you'd probably want a const access
function to return a non-writable string (deep const).
But possibly not the same semantics, and therefore there may be reasons
to write a string class.

For example, with std::string:

1. No method to get a writable buffer.
2. No methods for locking
3. Not immutable
4. Not safely portable between libraries.

For any number of those reasons you might wish to write a string class.
For the purpose of locking you'd possibly implement it in terms of
std::string (i.e. your class has a nested std::string and wraps it).

That's not saying that std::string should have all those features, just
that there doesn't have to be only one string class.

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

> MyString(const char* c)It's just for demonstration and giving you a working example of my
problem.

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.
That's exaclty what I wanted _not_. I wanted to write "ms" to an
printf ellipsis. Thank you for showing the options to newbies, though.

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

Gernot Frisch wrote:
[snip]If CString can print via printf it is because Microsoft relies on some
specific behaviour from its C++ compiler. This is more than a quick
hack in my opinion.
Perhaps you are the newbie? In any case you can not in standard C++
create a class that prints via the printf family. If you want to ask
compiler specific questions go to the appropriate newsgroup.

/Peter

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

I just wanted to ask if there is a standard way of making my class's
object's address default the address of its first member. I know - and
have done - overloading of (const char*) operator, so I can use
printf. I just wanted to know if the very convenient way MS takes is
std.
As you said - it's not. That would suffice as an answer to me.
Regards,
-Gernot

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

peter koch wrote: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;
I'm sure I read somewhere that CString is designed specifically to
allow people to pass CStrings to printf in this broken way and have it
work, so I'd guess that this is how MS have done it.
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.

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

Earl Purple schrieb:That's correct, but you can initialize a std::string with a specified
length, and therefore have strings with \0 chars in it, etc. etc. It
does not deal with the problems I listed above, though.
;-)
Thanks for the additions. I'm still to sloppy very often.
That's correct too. But I was extrapolation from the OP's use of
printf() that this should not be the case. I was shown wrong on this.


Best regards,
-- Markus

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

"Gernot Frisch" <Me@Privacy.netwrites:
A conversion operator will not be invoked if you pass something to an
ellipsis (what should be converted to?).

As standard C++ is concerned, you can't pass non-POD types to an
ellipsis, as others have said.

printf belongs to the C language; in C++ std::string and iostreams
are usually preferable.
It wouldn't be MS if it was, would it?

Regards,

Jens

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

"tragomaskhalos" <dave.du.vergier@logicacmg.comwrites:
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.
It's embrace and extend, and that may be a good commercial decision,
and such is drug trafficking at whiles.

Regards,

Jens

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

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!

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

Gernot Frisch wrote:
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.

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

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

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

Pete Becker wrote:
I thought the word was "unspecified" if the standard offered any
liberties to the implementation.

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

Eberhard Schefold wrote: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.

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

Eberhard Schefold wrote: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
possiblebehaviors is delineated by this International Standard. ]

Gavin Deane