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);}

[Jakob Bieling]

Gernot Frisch <[e-mail] wrote:

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] writes:

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