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

Discussion in 'C++' started by avasilev, Jan 3, 2012.

  1. avasilev

    avasilev Guest

    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
     
    avasilev, Jan 3, 2012
    #1
    1. Advertising

  2. Re: char* to literal return from static in-class method definition- will the pointer always be the same?

    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
     
    Victor Bazarov, Jan 3, 2012
    #2
    1. Advertising

  3. avasilev

    avasilev Guest

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

    > 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,
     
    avasilev, Jan 3, 2012
    #3
  4. avasilev

    avasilev Guest

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

    >
    > 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
     
    avasilev, Jan 3, 2012
    #4
  5. avasilev

    avasilev Guest

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

    > 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
     
    avasilev, Jan 3, 2012
    #5
  6. avasilev

    Ian Collins Guest

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

    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
     
    Ian Collins, Jan 3, 2012
    #6
  7. avasilev

    Goran Guest

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

    On Jan 3, 7:00 pm, avasilev <> 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.
     
    Goran, Jan 4, 2012
    #7
  8. avasilev

    avasilev Guest

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

    On Jan 4, 9:47 am, Goran <> wrote:
    > On Jan 3, 7:00 pm, avasilev <> 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 :)
     
    avasilev, Jan 4, 2012
    #8
  9. Re: char* to literal return from static in-class method definition- will the pointer always be the same?

    On 1/4/2012 2:47 AM, Goran wrote:
    > On Jan 3, 7:00 pm, avasilev<> 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
     
    Victor Bazarov, Jan 4, 2012
    #9
  10. avasilev

    Goran Guest

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

    On Jan 4, 1:15 pm, avasilev <> wrote:
    > On Jan 4, 9:47 am, Goran <> wrote:
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > On Jan 3, 7:00 pm, avasilev <> 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.
     
    Goran, Jan 5, 2012
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Sam
    Replies:
    4
    Views:
    475
    The Directive
    Jan 13, 2004
  2. Jianli Shen
    Replies:
    1
    Views:
    594
    Victor Bazarov
    Mar 13, 2005
  3. lovecreatesbeauty
    Replies:
    1
    Views:
    1,062
    Ian Collins
    May 9, 2006
  4. Pawel_Iks
    Replies:
    3
    Views:
    536
    terminator
    Jul 31, 2007
  5. Anonieko Ramos

    What's wrong with rpc-literal? Why use doc-literal?

    Anonieko Ramos, Sep 27, 2004, in forum: ASP .Net Web Services
    Replies:
    0
    Views:
    381
    Anonieko Ramos
    Sep 27, 2004
Loading...

Share This Page