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

[Jakob Bieling]

Gernot Frisch <[e-mail]:

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?

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.

I know - removing the virtual keyword will do, but any other way?

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)

[Markus Grueneis]

Gernot Frisch schrieb:

Hi,

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

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?

}
virtual ~MyString()
{
delete[] m_data;
}
};

int main()
{
MyString ms("KungFoo");
print("Here is: %s", ms);

printf

}
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?

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.

I know - removing the virtual keyword will do, but any other way?

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

>

[Earl Purple]

Markus Grueneis wrote:

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

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?

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?)

Just i.e.:

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

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

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.

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.

[Gernot Frisch]

> MyString(const char* c)

> {
m_data = new char[1024];
strcpy(m_data, c);

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?

It's just for demonstration and giving you a working example of my
problem.

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.

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.

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

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.

[peter koch]

Gernot Frisch wrote:
[snip]

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

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.

>

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

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.

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

[Gernot Frisch]

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.

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

[tragomaskhalos]

peter koch wrote:

Gernot Frisch wrote:
[snip]

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.

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.

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.

[Markus Grueneis]

Earl Purple schrieb:

Markus Grueneis wrote:

>>[OP code]

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?

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

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.

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?)

>Just i.e.:

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

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

Thanks for the additions. I'm still to sloppy very often.

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

But possibly not the same semantics, and therefore there may be reasons
to write a string class.

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

For example, with std::string:

[real reasons to write a string class]

[Jens Theisen]

"Gernot Frisch" <[e-mail]:

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.

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.

I just wanted to know if the very convenient way MS takes is
std.

It wouldn't be MS if it was, would it?

Regards,

Jens

[Jens Theisen]

"tragomaskhalos" <da*************@logicacmg.comwrites:

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 "unspecified" 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 "unspecified" 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 "unspecified" 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
possiblebehaviors is delineated by this International Standard. ]

Gavin Deane