Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #4726 > unrolled thread

this cast to const char*

Back to article view | Back to comp.lang.c++

Contents

  this cast to const char* "Gernot Frisch" <me@privacy.net> - 2011-05-05 19:27 +0200
    Re: this cast to const char* Kai-Uwe Bux <jkherciueh@gmx.net> - 2011-05-05 19:39 +0200
      Re: this cast to const char* "Balog Pal" <pasa@lib.hu> - 2011-05-06 01:11 +0200
        Re: this cast to const char* Marcel Müller <news.5.maazl@spamgourmet.org> - 2011-05-06 01:54 +0200
          Re: this cast to const char* m0shbear <andrey.vul@gmail.com> - 2011-05-05 17:59 -0700
            Re: this cast to const char* James Kanze <james.kanze@gmail.com> - 2011-05-08 07:08 -0700
              Re: this cast to const char* m0shbear <andrey.vul@gmail.com> - 2011-05-08 17:03 -0700
          Re: this cast to const char* "Balog Pal" <pasa@lib.hu> - 2011-05-06 20:15 +0200
          Re: this cast to const char* James Kanze <james.kanze@gmail.com> - 2011-05-08 07:05 -0700
      Re: this cast to const char* James Kanze <james.kanze@gmail.com> - 2011-05-08 07:02 -0700
    Re: this cast to const char* Felix Bytow <felix.bytow@informatik.tu-chemnitz.de> - 2011-05-05 19:40 +0200
      Re: this cast to const char* Öö Tiib <ootiib@hot.ee> - 2011-05-05 10:52 -0700
    Re: this cast to const char* Öö Tiib <ootiib@hot.ee> - 2011-05-05 10:44 -0700
    Re: this cast to const char* gwowen <gwowen@gmail.com> - 2011-05-05 10:50 -0700
      Re: this cast to const char* Öö Tiib <ootiib@hot.ee> - 2011-05-05 10:58 -0700
        Re: this cast to const char* "Bo Persson" <bop@gmb.dk> - 2011-05-05 20:21 +0200
        Re: this cast to const char* gwowen <gwowen@gmail.com> - 2011-05-05 11:27 -0700
          Re: this cast to const char* Öö Tiib <ootiib@hot.ee> - 2011-05-05 11:37 -0700
            Re: this cast to const char* gwowen <gwowen@gmail.com> - 2011-05-05 22:28 -0700
              Re: this cast to const char* Öö Tiib <ootiib@hot.ee> - 2011-05-06 03:55 -0700
                Re: this cast to const char* "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-05-06 13:25 +0200
                  Re: this cast to const char* Öö Tiib <ootiib@hot.ee> - 2011-05-06 06:22 -0700
    Re: this cast to const char* Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-05 22:47 -0700
    Re: this cast to const char* Goran <goran.pusic@gmail.com> - 2011-05-06 06:59 -0700
      Re: this cast to const char* Pete Becker <pete@versatilecoding.com> - 2011-05-06 10:17 -0400
        Re: this cast to const char* James Kanze <james.kanze@gmail.com> - 2011-05-08 07:13 -0700
      Re: this cast to const char* "Gernot Frisch" <me@privacy.net> - 2011-05-09 10:38 +0200
        Re: this cast to const char* Leigh Johnston <leigh@i42.co.uk> - 2011-05-09 13:03 +0100
          Re: this cast to const char* Leigh Johnston <leigh@i42.co.uk> - 2011-05-09 17:51 +0100
        Re: this cast to const char* Öö Tiib <ootiib@hot.ee> - 2011-05-09 09:40 -0700

Page 1 of 2  [1] 2  Next page →

#4726 — this cast to const char*

Hi,

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?

Thank you,
-Gernot

[toc] | [next] | [standalone]

#4727

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?


Best,

Kai-Uwe Bux

[toc] | [prev] | [next] | [standalone]

#4742

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

Passing non-pod for a function taking (...) is undefined behavior. If you 
try to compile something like this in gcc, you get a warning telling you're 
on the wrong track and at runtime termonate() will be called.

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

It is more than accident. Not compiler but library magic. At least the 
CString implementations I looked at (up to VS6, MFC4.2)  the implementation 
used a string-holder  struct with some header (having refcount among others) 
and the string data itself at the tail (variable lendth). And CString itself 
had no data elements but a sole pointer.  That was set to point to start of 
the sting data inside the mentioned holder.  Member functions used 
pointer-math to substract offset and get to the full structure.

And compiler implementation for ... works just passing the structure content 
as a whole, as if it were POD, no ctor or dtor calls.  All that together 
leading to "works".

I did not see it specifically documented as a feature of CString, so it is 
unofficial heuristic at best, but the intention to make and keep it work is 
IMO clear.

The visual compiler painfully lacks similar analiser as gcc's 
__attribute__(format) that checks the types and format string components, my 
usual tech s to use format helpers consistently. I.e:

printf("int:%d, long: %ld, str: %s", f_d(i), f_ld(lo), f_s(str));

where f_* are inline functions taking argument of the type proper for the 
format and just returning it. So I can pass either regular string or 
CString, it will be safe and fine. Creating compile time errors for serious 
mistakes too. 

[toc] | [prev] | [next] | [standalone]

#4743

On 06.05.11 01.11, Balog Pal wrote:
[CString binary compatible to const char*]
> It is more than accident. Not compiler but library magic. At least the
> CString implementations I looked at (up to VS6, MFC4.2) the
> implementation used a string-holder struct with some header (having
> refcount among others) and the string data itself at the tail (variable
> lendth). And CString itself had no data elements but a sole pointer.
> That was set to point to start of the sting data inside the mentioned
> holder. Member functions used pointer-math to substract offset and get
> to the full structure.
[...]
> I did not see it specifically documented as a feature of CString, so it
> is unofficial heuristic at best, but the intention to make and keep it
> work is IMO clear.

I made my own string class implementation to work in the same way 
(without knowing the CString implementation at this time). But I did 
this for a completely different reason. It makes the conversion from the 
string class to const char* very cheap. Otherwise the stored pointer 
must always be compared against NULL before adjusting it to the real 
string content. On the other side accessing the string length and the 
ref count at negative offsets does not cause any significant overhead on 
most platforms.

Furthermore, using this memory layout enables array classes in the same 
library to simply cast from CString* to const char** by a reinterpret 
cast, which would necessarily cause an allocation otherwise.

So I would not bet that the implementation is done due to the printf 
compatibility. This is most likely a spin off.


> The visual compiler painfully lacks similar analiser as gcc's
> __attribute__(format) that checks the types and format string
> components, my usual tech s to use format helpers consistently. I.e:
>
> printf("int:%d, long: %ld, str: %s", f_d(i), f_ld(lo), f_s(str));

Well, C++ and printf...
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.


Marcel

[toc] | [prev] | [next] | [standalone]

#4744

On May 5, 7:54 pm, Marcel Müller <news.5.ma...@spamgourmet.org> wrote:
> On 06.05.11 01.11, Balog Pal wrote:
> [CString binary compatible to const char*]
>
> > It is more than accident. Not compiler but library magic. At least the
> > CString implementations I looked at (up to VS6, MFC4.2) the
> > implementation used a string-holder struct with some header (having
> > refcount among others) and the string data itself at the tail (variable
> > lendth). And CString itself had no data elements but a sole pointer.
> > That was set to point to start of the sting data inside the mentioned
> > holder. Member functions used pointer-math to substract offset and get
> > to the full structure.
> [...]
> > I did not see it specifically documented as a feature of CString, so it
> > is unofficial heuristic at best, but the intention to make and keep it
> > work is IMO clear.
>
> I made my own string class implementation to work in the same way
> (without knowing the CString implementation at this time). But I did
> this for a completely different reason. It makes the conversion from the
> string class to const char* very cheap. Otherwise the stored pointer
> must always be compared against NULL before adjusting it to the real
> string content. On the other side accessing the string length and the
> ref count at negative offsets does not cause any significant overhead on
> most platforms.
>
> Furthermore, using this memory layout enables array classes in the same
> library to simply cast from CString* to const char** by a reinterpret
> cast, which would necessarily cause an allocation otherwise.
>
> So I would not bet that the implementation is done due to the printf
> compatibility. This is most likely a spin off.
>
> > The visual compiler painfully lacks similar analiser as gcc's
> > __attribute__(format) that checks the types and format string
> > components, my usual tech s to use format helpers consistently. I.e:
>
> > printf("int:%d, long: %ld, str: %s", f_d(i), f_ld(lo), f_s(str));
>
> Well, C++ and printf...
> 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.
>
> Marcel

Boost has a nice replacement for std::printf, using overloaded '%'
instead of ',' for varargs.

[toc] | [prev] | [next] | [standalone]

#4806

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::printf, 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

[toc] | [prev] | [next] | [standalone]

#4824

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::printf, 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 :p

[toc] | [prev] | [next] | [standalone]

#4786

"Marcel Müller" <news.5.maazl@spamgourmet.org>
[...]
> Furthermore, using this memory layout enables array classes in the same 
> library to simply cast from CString* to const char** by a reinterpret 
> cast, which would necessarily cause an allocation otherwise.
>
> So I would not bet that the implementation is done due to the printf 
> compatibility. This is most likely a spin off.

Makes sense.

>> The visual compiler painfully lacks similar analiser as gcc's
>> __attribute__(format) that checks the types and format string
>> components, my usual tech s to use format helpers consistently. I.e:
>>
>> printf("int:%d, long: %ld, str: %s", f_d(i), f_ld(lo), f_s(str));
>
> Well, C++ and printf...

It was just example. With MFC you certainly use CString::Format. That is IME 
superior to most alternatives in most cases I worked with. And the above 
trick covers the practical problems. (Certainly I'd wish to have gcc-like 
compiler support...)

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

Yeah. :(

[toc] | [prev] | [next] | [standalone]

#4805

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

[toc] | [prev] | [next] | [standalone]

#4804

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

[toc] | [prev] | [next] | [standalone]

#4728

hi,

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

MS provides a casting operator for that.
When writing a class you can define your own casting operators.

e.g.:
class str
{
	char *buff;
	// some stuff

	// here comes the casting operator
	operator const char * (void) const
	{
		return buff;
	}
};

this way an object of "str" will be implicitly casted to const char * if
needed.
you could also declare it "explicit" though

within your own casting operators you can also do some more complex
stuff than simply returning a member of your class.

I hope I helped you :-)

Felix

[toc] | [prev] | [next] | [standalone]

#4732

On May 5, 8:40 pm, Felix Bytow <felix.by...@informatik.tu-chemnitz.de>
wrote:
> hi,
>
> > 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?
>
> MS provides a casting operator for that.
> When writing a class you can define your own casting operators.
>
> e.g.:
> class str
> {
>         char *buff;
>         // some stuff
>
>         // here comes the casting operator
>         operator const char * (void) const
>         {
>                 return buff;
>         }
>
> };
>
> this way an object of "str" will be implicitly casted to const char * if
> needed.
> you could also declare it "explicit" though
>
> within your own casting operators you can also do some more complex
> stuff than simply returning a member of your class.

Nope, you are wrong. To use the casting operator you need to write:

 CString str(_T("test"); printf("%s", (LPCTSTR)str);

It works just by accident, like Kai-Uwe said.

Such implicit casting operators actually make CString dangerous to
use, so if you use MFC for GUI then keep the CString strictly inside
of your GUI classes.

[toc] | [prev] | [next] | [standalone]

#4729

On May 5, 8:27 pm, "Gernot Frisch" <m...@privacy.net> wrote:
> Hi,
>
> with "MFC" I can do:
> CString str(_T("test"); printf("%s", str); // prints "test"

Note that all good compilers and MS own static code analyser "prefast"
complain against using class type object as printf argument.

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

Likely by not having any virtual functions in their CString so it has
no vtable. Who cares? It is wrong anyway.

[toc] | [prev] | [next] | [standalone]

#4730

On May 5, 6:27 pm, "Gernot Frisch" <m...@privacy.net> wrote:
> Hi,
>
> 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.

Passing C++ classes to variable argument functions like printf() is
not advisable ... but if you *MUST* you can have your class inherit
from a POD type with the m_data with its only (or first) member.  This
will force your non-POD class to be layout compatible, and so the
"header" (which will probably be the table of function pointers for
virtual dispatch). This will almost certainly work, as long as the
size of m_data matches the size of argument the compiler expects for
vararg functions...

[toc] | [prev] | [next] | [standalone]

#4733

On May 5, 8:50 pm, gwowen <gwo...@gmail.com> wrote:
> On May 5, 6:27 pm, "Gernot Frisch" <m...@privacy.net> wrote:
>
> > Hi,
>
> > 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.
>
> Passing C++ classes to variable argument functions like printf() is
> not advisable ... but if you *MUST* you can have your class inherit
> from a POD type with the m_data with its only (or first) member.  This
> will force your non-POD class to be layout compatible, and so the
> "header" (which will probably be the table of function pointers for
> virtual dispatch). This will almost certainly work, as long as the
> size of m_data matches the size of argument the compiler expects for
> vararg functions...

It will force only POD base subobject to be layout compatible (and
printf does not cast argument to that base) so if it works then again
by accident.

[toc] | [prev] | [next] | [standalone]

#4734

Öö Tiib wrote:
> On May 5, 8:50 pm, gwowen <gwo...@gmail.com> wrote:
>> On May 5, 6:27 pm, "Gernot Frisch" <m...@privacy.net> wrote:
>>
>>> Hi,
>>
>>> 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.
>>
>> Passing C++ classes to variable argument functions like printf() is
>> not advisable ... but if you *MUST* you can have your class inherit
>> from a POD type with the m_data with its only (or first) member.
>> This will force your non-POD class to be layout compatible, and so
>> the "header" (which will probably be the table of function
>> pointers for virtual dispatch). This will almost certainly work,
>> as long as the size of m_data matches the size of argument the
>> compiler expects for vararg functions...
>
> It will force only POD base subobject to be layout compatible (and
> printf does not cast argument to that base) so if it works then
> again by accident.

It actually isn't by accident (not anymore, at least), MS has 
documented that passing a CString by value gets you the pointer to 
your string. They don't dare to break all the printfs already 
existing!


Bo Persson

[toc] | [prev] | [next] | [standalone]

#4735

On May 5, 6:58 pm, Öö Tiib <oot...@hot.ee> wrote:

> It will force only POD base subobject to be layout compatible

For single inheritance, thats a distinction without a difference.

[toc] | [prev] | [next] | [standalone]

#4736

On May 5, 9:27 pm, gwowen <gwo...@gmail.com> wrote:
> On May 5, 6:58 pm, Öö Tiib <oot...@hot.ee> wrote:
>
> > It will force only POD base subobject to be layout compatible
>
> For single inheritance, thats a distinction without a difference.

Hmm ... really? Where does standard say that POD base sub-object when
used with single inheritance should be located at very start of object
of derived class?

[toc] | [prev] | [next] | [standalone]

#4756

On May 5, 7:37 pm, Öö Tiib <oot...@hot.ee> wrote:

> Hmm ... really? Where does standard say that POD base sub-object when
> used with single inheritance should be located at very start of object
> of derived class?

The standard doesn't.  Every single implementation that is or ever
will be in existence does.

[toc] | [prev] | [next] | [standalone]

#4768

On May 6, 8:28 am, gwowen <gwo...@gmail.com> wrote:
> On May 5, 7:37 pm, Öö Tiib <oot...@hot.ee> wrote:
>
> > Hmm ... really? Where does standard say that POD base sub-object when
> > used with single inheritance should be located at very start of object
> > of derived class?
>
> The standard doesn't.  Every single implementation that is or ever
> will be in existence does.

Uhh. I never dare to be so absolute about C++ compilers. Here i can
even provide evidence of opposite with a compiler manufactured by
CString creators themselves.

<code>
 // WARNING: this is meant as example
 // of really awful coding practices
 #include<iostream>
 #include<cstdio>

 struct Pod { int p; };

 class DerivedFromPod
     : public Pod // single derived
 {
 public:
     DerivedFromPod() { p=42; d=0; };
     virtual ~DerivedFromPod() {};
 private:
     int d;
 };

 int main()
 {
     DerivedFromPod* der = new DerivedFromPod();
     Pod* pod = der; // implicit cast here

     std::cout << "der is at: " << der
               << " pod is at: " << pod << std::endl;
     printf( "ints from der %d, %d \n", *der );
     printf( "ints from pod %d, %d \n", *pod );
     delete der;
 }
</code>

Compiling it for Win32 MS compiler Visual C++ 0.9 (bundled in VS
"CString" 2008 Professional)
Running it produces something like:

der is at: 00356940 pod is at: 00356944
ints from der 4290588, 42
ints from pod 42, -242263521

So there we are with your "Every single implementation that is or ever
will be in existence does".

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web