Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > char* to literal return from static in-class method definition - willthe pointer always be the same?

Reply
Thread Tools

char* to literal return from static in-class method definition - willthe pointer always be the same?

 
 
avasilev
Guest
Posts: n/a
 
      01-03-2012
Hi all, and Happy new Year!

I have the following class method:

class MyClass
{
public:
static const char* typeName() { return "myClass";}
};
The pointer that this method returns serves as an unique identifier of
the class. Thus, it must not only point to the class name string, but
also the value of the pointer itself serfes as an UID.

My question is: Since this method is defined inside the class
declaration, in a header file, is it guaranteed that the same
'version' of the method will be called in all compilation units in my
application, and any call to the method will return exactly the same
pointer, or will there be different 'copies' of the method and string
literal in each compilation unit, and they will return a different
char* ?

Thanks in advance
Alex
 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      01-03-2012
On 1/3/2012 1:00 PM, avasilev wrote:
> I have the following class method:
>
> class MyClass
> {
> public:
> static const char* typeName() { return "myClass";}
> };
> The pointer that this method returns serves as an unique identifier of
> the class. Thus, it must not only point to the class name string, but
> also the value of the pointer itself serfes as an UID.
>
> My question is: Since this method is defined inside the class
> declaration, in a header file, is it guaranteed that the same
> 'version' of the method will be called in all compilation units in my
> application, and any call to the method will return exactly the same
> pointer, or will there be different 'copies' of the method and string
> literal in each compilation unit, and they will return a different
> char* ?


Don't compare pointers. Compare the string contents. If you want to
ensure that the pointers are always the same, create an object and
return its address. There is no guarantee that two literals have the
same address if their contents match. It's *usually* the case since the
linker merges those. The language doesn't require it, though.

Probably better to do

class MyClass
{
public:
static char const* typeName() {
static const char name[] = "myClass"; return name; }
};

V
--
I do not respond to top-posted replies, please don't ask
 
Reply With Quote
 
 
 
 
avasilev
Guest
Posts: n/a
 
      01-03-2012
> Don't compare pointers. *Compare the string contents. *If you want to
> ensure that the pointers are always the same, create an object and
> return its address. *There is no guarantee that two literals have the
> same address if their contents match. *It's *usually* the case since the
> linker merges those. *The language doesn't require it, though.
>
> Probably better to do
>
> * * class MyClass
> * * {
> * * public:
> * * * *static char const* typeName() {
> * * * * * static const char name[] = "myClass"; return name; }
> * * };
>


Thanks, Vadim. Doesn't the same instance of a literal (as it appears
in code) map to a single instance of this literal embeded in the data
section of the executable? I.e. if there is only one place in code
where this literal is defined, shouldn't be there only one copy of it
in the data section of the executable, hence only one possible pointer
to it?
My worry is that if the method is defined in a header, then there may
exist multiple local copies of the method, hence multiple literals.
Wouldn't this hold true even if I use a static local variable, as you
propose? OTOH, a static local is defined by the language to be
singleton, and I should not care about how this is implemented... I
guess I am missing some knowledge about how in-class defined methods
are linked. Can you please shed some light on this?

Alex

I was considering what you proposed,
 
Reply With Quote
 
avasilev
Guest
Posts: n/a
 
      01-03-2012
>
> Don't compare pointers. *Compare the string contents. *If you want to
> ensure that the pointers are always the same, create an object and
> return its address. *There is no guarantee that two literals have the
> same address if their contents match. *It's *usually* the case since the
> linker merges those. *The language doesn't require it, though.
>
> Probably better to do
>
> * * class MyClass
> * * {
> * * public:
> * * * *static char const* typeName() {
> * * * * * static const char name[] = "myClass"; return name; }
> * * };
>


Thanks, Victor. Doesn't the same instance of a literal (as it appears
in code) map to a single instance of this literal embeded in the data
section of the executable? I.e. if there is only one place in code
where this literal is defined, shouldn't be there only one copy of it
in the data section of the executable, hence only one possible pointer
to it?
My worry is that if the method is defined in a header, then there may
exist multiple local copies of the method, hence multiple literals.
Wouldn't this hold true even if I use a static local variable, as you
propose? OTOH, a static local is defined by the language to be
singleton, and I should not care about how this is implemented... I
guess I am missing some knowledge about how in-class defined methods
are linked. Can you please shed some light on this?

As for comparing the strings, not the pointers, there is a performance
penalty that is unacceptable in my case - this is a type checking
mechanism that is executed every time an object is passed, so the
comparison is done quite frequently.
Alex



 
Reply With Quote
 
avasilev
Guest
Posts: n/a
 
      01-03-2012
> Don't compare pointers. *Compare the string contents. *If you want to
> ensure that the pointers are always the same, create an object and
> return its address. *There is no guarantee that two literals have the
> same address if their contents match. *It's *usually* the case since the
> linker merges those. *The language doesn't require it, though.
>
> Probably better to do
>
> * * class MyClass
> * * {
> * * public:
> * * * *static char const* typeName() {
> * * * * * static const char name[] = "myClass"; return name; }
> * * };
>


Let me clarify a bit more on the use case. I actually have only one
place in code where the literal is - namely the typeName()method. The
class can be regarded as a factory, which creates objects, which have
a char pointer field, which the factory assigns to the return value of
typeName(). Later, when a function is called, taking such an object as
argument, it does type checking by calling typeName() of the factory,
and comparing the returned pointer to the object's field.

Alex
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      01-03-2012
On 01/ 4/12 08:17 AM, avasilev wrote:

Please don't snip attributions.

>> Don't compare pointers. Compare the string contents. If you want to
>> ensure that the pointers are always the same, create an object and
>> return its address. There is no guarantee that two literals have the
>> same address if their contents match. It's *usually* the case since the
>> linker merges those. The language doesn't require it, though.
>>
>> Probably better to do
>>
>> class MyClass
>> {
>> public:
>> static char const* typeName() {
>> static const char name[] = "myClass"; return name; }
>> };
>>

>
> Let me clarify a bit more on the use case. I actually have only one
> place in code where the literal is - namely the typeName()method. The
> class can be regarded as a factory, which creates objects, which have
> a char pointer field, which the factory assigns to the return value of
> typeName(). Later, when a function is called, taking such an object as
> argument, it does type checking by calling typeName() of the factory,
> and comparing the returned pointer to the object's field.


That's why Victor suggested a local static object: the address will be
unique.

--
Ian Collins
 
Reply With Quote
 
Goran
Guest
Posts: n/a
 
      01-04-2012
On Jan 3, 7:00*pm, avasilev <(E-Mail Removed)> wrote:
> Hi all, and Happy new Year!
>
> I have the following class method:
>
> class MyClass
> {
> public:
> * static const char* typeName() { return "myClass";}};
>
> The pointer that this method returns serves as an unique identifier of
> the class. Thus, it must not only point to the class name string, but
> also the value of the pointer itself serfes as an UID.
>
> My question is: Since this method is defined inside the class
> declaration, in a header file, is it guaranteed that the same
> 'version' of the method will be called in all compilation units in my
> application, and any call to the method will return exactly the same
> pointer, or will there be different 'copies' of the method and string
> literal in each compilation unit, and they will return a different
> char* ?


I just came in to mention the elephant in the room: typeid and
type_info. If you are in some sort of (extremely, I would say)
constrained environment, and you want to compile without RTTI, then
why a string? Wouldn't an enum be better then, or, if you don't want a
compile-time dependency, an integral?

Goran.
 
Reply With Quote
 
avasilev
Guest
Posts: n/a
 
      01-04-2012
On Jan 4, 9:47*am, Goran <(E-Mail Removed)> wrote:
> On Jan 3, 7:00*pm, avasilev <(E-Mail Removed)> wrote:
>
>
>
>
>
>
>
>
>
> > Hi all, and Happy new Year!

>
> > I have the following class method:

>
> > class MyClass
> > {
> > public:
> > * static const char* typeName() { return "myClass";}};

>
> > The pointer that this method returns serves as an unique identifier of
> > the class. Thus, it must not only point to the class name string, but
> > also the value of the pointer itself serfes as an UID.

>
> > My question is: Since this method is defined inside the class
> > declaration, in a header file, is it guaranteed that the same
> > 'version' of the method will be called in all compilation units in my
> > application, and any call to the method will return exactly the same
> > pointer, or will there be different 'copies' of the method and string
> > literal in each compilation unit, and they will return a different
> > char* ?

>
> I just came in to mention the elephant in the room: typeid and
> type_info. If you are in some sort of (extremely, I would say)
> constrained environment, and you want to compile without RTTI, then
> why a string? Wouldn't an enum be better then, or, if you don't want a
> compile-time dependency, an integral?
>
> Goran.


Two reasons - for int or enum, i would need to define them manually,
and take care for them to be unique (i will need to add types later).
A pointer is automatically unique. And second - easier for debugging -
I can always print the class id as a string, if needed. I avoided
using RTTI for the reason you mentioned - I dint want to depend on C+
+'s RTTI. Not until they make it more useful
 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      01-04-2012
On 1/4/2012 2:47 AM, Goran wrote:
> On Jan 3, 7:00 pm, avasilev<(E-Mail Removed)> wrote:
>> Hi all, and Happy new Year!
>>
>> I have the following class method:
>>
>> class MyClass
>> {
>> public:
>> static const char* typeName() { return "myClass";}};
>>
>> The pointer that this method returns serves as an unique identifier of
>> the class. Thus, it must not only point to the class name string, but
>> also the value of the pointer itself serfes as an UID.
>>
>> My question is: Since this method is defined inside the class
>> declaration, in a header file, is it guaranteed that the same
>> 'version' of the method will be called in all compilation units in my
>> application, and any call to the method will return exactly the same
>> pointer, or will there be different 'copies' of the method and string
>> literal in each compilation unit, and they will return a different
>> char* ?

>
> I just came in to mention the elephant in the room: typeid and
> type_info. If you are in some sort of (extremely, I would say)
> constrained environment, and you want to compile without RTTI, then
> why a string? Wouldn't an enum be better then, or, if you don't want a
> compile-time dependency, an integral?


<shrug> I think that strings are more attractive because they carry that
"humanly readable" trait... But the OP can have a different reason, of
course.

V
--
I do not respond to top-posted replies, please don't ask
 
Reply With Quote
 
Goran
Guest
Posts: n/a
 
      01-05-2012
On Jan 4, 1:15*pm, avasilev <(E-Mail Removed)> wrote:
> On Jan 4, 9:47*am, Goran <(E-Mail Removed)> wrote:
>
>
>
>
>
>
>
>
>
> > On Jan 3, 7:00*pm, avasilev <(E-Mail Removed)> wrote:

>
> > > Hi all, and Happy new Year!

>
> > > I have the following class method:

>
> > > class MyClass
> > > {
> > > public:
> > > * static const char* typeName() { return "myClass";}};

>
> > > The pointer that this method returns serves as an unique identifier of
> > > the class. Thus, it must not only point to the class name string, but
> > > also the value of the pointer itself serfes as an UID.

>
> > > My question is: Since this method is defined inside the class
> > > declaration, in a header file, is it guaranteed that the same
> > > 'version' of the method will be called in all compilation units in my
> > > application, and any call to the method will return exactly the same
> > > pointer, or will there be different 'copies' of the method and string
> > > literal in each compilation unit, and they will return a different
> > > char* ?

>
> > I just came in to mention the elephant in the room: typeid and
> > type_info. If you are in some sort of (extremely, I would say)
> > constrained environment, and you want to compile without RTTI, then
> > why a string? Wouldn't an enum be better then, or, if you don't want a
> > compile-time dependency, an integral?

>
> > Goran.

>
> Two reasons - for int or enum, i would need to define them manually,
> and take care for them to be unique (i will need to add types later).
> A pointer is automatically unique. And second - easier for debugging -
> I can always print the class id as a string, if needed. I avoided
> using RTTI for the reason you mentioned - I dint want to depend on C+
> +'s RTTI. Not until they make it more useful


Key question is __why__ are you avoiding RTTI? If for size/speed, it's
already pretty tight. I don't believe it's implementation is much
bigger than your class name: it __is__ class name and a couple of
pointers (e.g. guess vtable and possibly nothing else). Further, I
would guess that any type_info instances that aren't used in code
itself would not be linked in. If that's the case, if you are in a
very constrained environment, then, (aside of class name being
wasteful), you're losing automatic elimination of unused type_info-s.

Finally, typeName(), the way you made it, is akin to following errors:

1.
class whatever_refactored_name { static const char* typeName()
{ return "whatever" } };

2.
class base { static const char* typeName() { return "base" } };
class derived : public base { /*Whoops, I forgot typeName*/ };

3.
struct base { static const char* typeName() { return "base"; } virtual
~base() };
struct derived : public base { static const char* typeName() { return
"derived"; } };
void f(const base& b, const derived& d)
{
if (b.typeName()==d.typeName())
{ /* Should get here, right? */ }
}
void g()
{
f(derived(), derived());
}

I believe that what you should rather be doing is either tightest
possible solution (int, or a char, even), either existing RTTI. And if/
when it's not enough, add your own bits.

Goran.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
RPC/literal definition dave Java 2 09-04-2008 11:16 PM
Definition of floating literal in C++ standard murali.desikan@gmail.com C++ 5 02-04-2008 07:18 PM
State definition and display: literal vs. symbolic in ModelSim Paul Urbanus VHDL 4 01-12-2005 03:40 AM
What's wrong with rpc-literal? Why use doc-literal? Anonieko Ramos ASP .Net Web Services 0 09-27-2004 09:06 AM
Does a static variable in a class's member fn always remain static? Sam C++ 4 01-13-2004 11:05 PM



Advertisments