global typedefs and #define /\ global inheritance base

Discussion in 'C++' started by eiji, Dec 5, 2005.

  1. eiji

    eiji Guest

    Hi folks,

    I hope this is not "off topic"! :)

    Consider the next code:

    /* Declarations of types that could become platform-dependent */

    #define MyChar char
    #define MyInt int
    #define MyUnsLong unsigned long
    #define MyShort short
    #define MyCharPtr MyChar *
    #define MyBoolean int

    class Base
    {
    public:
    inline Base() {};
    inline ~Base() {};

    #ifdef DEBUG_MODE
    inline void* operator new(size_t size, char* aFile, int aLine);
    inline void* operator new[](size_t size, char* aFile, int aLine);
    #else
    inline void* operator new(size_t size);
    inline void* operator new[](size_t size);
    #endif
    inline void operator delete(void* object);
    inline void operator delete[](void* object);

    };

    Most of you know java quit good, so there is "java.lang.Object" and
    classes are inheriant to this one.
    So when and how would this become interessting for my c++-design? Why
    should I design my classes in that way?
    Another thing are the #define (for cross-plattform-stuff).
    Code becomes worse dealing with these MyChar's but could it be
    necessary to build cross-platform code in that way?

    Any advice in dealing with such designes?
    Today I'm a win-developer(scientific education stuff), so there is not
    so much cross-plattform knowledge.
     
    eiji, Dec 5, 2005
    #1
    1. Advertising

  2. eiji wrote:
    > I hope this is not "off topic"! :)
    >
    > Consider the next code:
    >
    > /* Declarations of types that could become platform-dependent */
    >
    > #define MyChar char
    > #define MyInt int
    > #define MyUnsLong unsigned long
    > #define MyShort short
    > #define MyCharPtr MyChar *
    > #define MyBoolean int
    >
    > class Base
    > {
    > public:
    > inline Base() {};
    > inline ~Base() {};


    Drop the semicolons after }s and the words "inline". They are totally
    superfluous, and make code harder to read.

    >
    > #ifdef DEBUG_MODE
    > inline void* operator new(size_t size, char* aFile, int aLine);
    > inline void* operator new[](size_t size, char* aFile, int aLine);
    > #else
    > inline void* operator new(size_t size);
    > inline void* operator new[](size_t size);
    > #endif
    > inline void operator delete(void* object);
    > inline void operator delete[](void* object);
    >
    > };
    >
    > Most of you know java quit good


    Yep. It quit good, quit all over the place... Oh, did you mean "quite
    well"?

    >, so there is "java.lang.Object" and
    > classes are inheriant to this one.


    You mean, all non-built-in types derive from 'java.lang.Object' class?
    OK. Yes, they do. And all functions are virtual.

    > So when and how would this become interessting for my c++-design?


    Is that a question you want _us_ to answer? It's _your_ design. How
    should *we* know anything about it?

    > Why
    > should I design my classes in that way?


    I don't think you should, actually. Are you trying to figure out how to
    use Java's approaches to modeling worlds in C++? It's generally A BAD
    IDEA(tm). Java has its advantages, C++ has its own. Applying designs
    from one to the other is not always beneficial.

    > Another thing are the #define (for cross-plattform-stuff).
    > Code becomes worse dealing with these MyChar's but could it be
    > necessary to build cross-platform code in that way?


    Yes, it could, I suppose.

    > Any advice in dealing with such designes?


    Put them in a separate file. How else could you "deal" with them?

    > Today I'm a win-developer(scientific education stuff), so there is not
    > so much cross-plattform knowledge.


    Do you really need it? Are you planning on moving on to some "greener
    pastures"? Cross-platform development is a bitch, you know.

    V
     
    Victor Bazarov, Dec 5, 2005
    #2
    1. Advertising

  3. eiji

    eiji Guest

    Re: global typedefs and #define /\ global inheritance base

    The "Base"-class is just a guess. (not implemented that way)

    I often see c++ design where everything is derived from one base, but I
    could not find out when there is a real benefit or even where are
    possible disadvantages(speed?, space?).

    So the question would be:
    Is there known use case for that? ( And I mean where everything is
    derived from "Base")
     
    eiji, Dec 5, 2005
    #3
  4. Re: global typedefs and #define /\ global inheritance base

    eiji wrote:
    > Hi folks,
    >
    > I hope this is not "off topic"! :)


    It is not really, but it is hard to answer because it is not specific.

    > Consider the next code:
    >
    > /* Declarations of types that could become platform-dependent */
    >
    > #define MyChar char
    > #define MyInt int
    > #define MyUnsLong unsigned long
    > #define MyShort short
    > #define MyCharPtr MyChar *
    > #define MyBoolean int


    I would use typedefs here, especially if this is in a header, and I
    would put it in a namespace. #defines are best avoided.

    > class Base
    > {
    > public:
    > inline Base() {};
    > inline ~Base() {};


    These are already inline by defining them in the class and the
    semicolumns are superflous.

    > #ifdef DEBUG_MODE
    > inline void* operator new(size_t size, char* aFile, int aLine);
    > inline void* operator new[](size_t size, char* aFile, int aLine);
    > #else
    > inline void* operator new(size_t size);
    > inline void* operator new[](size_t size);
    > #endif
    > inline void operator delete(void* object);
    > inline void operator delete[](void* object);
    >
    > };
    >
    > Most of you know java quit good, so there is "java.lang.Object" and
    > classes are inheriant to this one.
    > So when and how would this become interessting for my c++-design?


    Only when it is necessary. The Object class is a worst-case of
    inheritance, when all the classes share a common base class. Usually,
    you will want to have seperate hierarchies in your program.

    The problem with a universal base class (UBC) is that it prevents
    static type-safety, much as void pointers do in C++. It also makes no
    sense in many circumstances. Most of the time, you will work with more
    specific base classes (such as Fruit, Vehicle or Animal).

    It also brings the problem of "what should I put in a UBC"? What
    functionnalities are universal to all your classes in your program? A
    ToString() member function? Are you sure all the classes must have a
    conversion to string? Serialization? Clone? Does it makes sense to call
    Wait() to pause a thread on a Banana object?

    It is much better to provide exactly what you need, instead of
    providing too much.

    > Why
    > should I design my classes in that way?


    If some classes share a common subset and you want to access them by
    that subset (a banana is a fruit), derive them from a class containing
    only that subset. If you can find a common subset for all the classes
    in your program and you want to access them by that subset, derive them
    all from a UBC.

    > Another thing are the #define (for cross-plattform-stuff).
    > Code becomes worse dealing with these MyChar's but could it be
    > necessary to build cross-platform code in that way?


    There will be sometimes when your code will have to be ported, but you
    may never have to. A good balance between genericity and specificity is
    vital.


    Jonathan
     
    Jonathan Mcdougall, Dec 5, 2005
    #4
  5. Re: global typedefs and #define /\ global inheritance base

    eiji wrote:
    > The "Base"-class is just a guess. (not implemented that way)
    >
    > I often see c++ design where everything is derived from one base, but I
    > could not find out when there is a real benefit or even where are
    > possible disadvantages(speed?, space?).


    The disadvantage is confusion that such "model" creates. When you model
    your "world" where everything is derived from the same class, what kind
    of functionality do you give that class? A virtual destructor, and that's
    about it? Base classes are only needed when there is some commonality
    between _ALL_ the types deriving from it. What kind of commonality do you
    see between _literally_ all elements of your design? I don't see any.
    Not even the need in polymorphic deletion. So, none of my designs have
    the common base class.

    > So the question would be:
    > Is there known use case for that? ( And I mean where everything is
    > derived from "Base")


    Java. Beyond that, I don't know of any. But wait, didn't you just say
    that you "often see c++ design where everything is derived from one base"?
    So, there must be a known use case for that, right? I mean, since you
    "often see" it...

    V
     
    Victor Bazarov, Dec 5, 2005
    #5
  6. eiji

    Rolf Magnus Guest

    Victor Bazarov wrote:

    > eiji wrote:
    >> I hope this is not "off topic"! :)
    >>
    >> Consider the next code:
    >>
    >> /* Declarations of types that could become platform-dependent */
    >>
    >> #define MyChar char
    >> #define MyInt int
    >> #define MyUnsLong unsigned long
    >> #define MyShort short
    >> #define MyCharPtr MyChar *
    >> #define MyBoolean int


    To the OP: use typedef instead of #define.

    typedef char MyChar;
    //...

    >> class Base
    >> {
    >> public:
    >> inline Base() {};
    >> inline ~Base() {};

    >
    > Drop the semicolons after }s and the words "inline". They are totally
    > superfluous, and make code harder to read.


    Actaully, I would drop the whole thing. In this case, the compiler will just
    create the same thing automatically.

    >> #ifdef DEBUG_MODE
    >> inline void* operator new(size_t size, char* aFile, int aLine);
    >> inline void* operator new[](size_t size, char* aFile, int aLine);
    >> #else
    >> inline void* operator new(size_t size);
    >> inline void* operator new[](size_t size);
    >> #endif
    >> inline void operator delete(void* object);
    >> inline void operator delete[](void* object);
    >>
    >> };
    >>
    >> Most of you know java quit good

    >
    > Yep. It quit good, quit all over the place... Oh, did you mean "quite
    > well"?


    Don't make fun of people just because their english is not as good as yours,
    even if that gives you a feeling of superiority.

    >>, so there is "java.lang.Object" and
    >> classes are inheriant to this one.

    >
    > You mean, all non-built-in types derive from 'java.lang.Object' class?
    > OK. Yes, they do. And all functions are virtual.
    >
    >> So when and how would this become interessting for my c++-design?

    >
    > Is that a question you want _us_ to answer? It's _your_ design. How
    > should *we* know anything about it?
    >
    > > Why
    >> should I design my classes in that way?

    >
    > I don't think you should, actually. Are you trying to figure out how to
    > use Java's approaches to modeling worlds in C++? It's generally A BAD
    > IDEA(tm). Java has its advantages, C++ has its own. Applying designs
    > from one to the other is not always beneficial.




    >
    >> Another thing are the #define (for cross-plattform-stuff).
    >> Code becomes worse dealing with these MyChar's but could it be
    >> necessary to build cross-platform code in that way?

    >
    > Yes, it could, I suppose.
    >
    >> Any advice in dealing with such designes?

    >
    > Put them in a separate file. How else could you "deal" with them?
    >
    >> Today I'm a win-developer(scientific education stuff), so there is not
    >> so much cross-plattform knowledge.

    >
    > Do you really need it? Are you planning on moving on to some "greener
    > pastures"? Cross-platform development is a bitch, you know.


    It's actually a lot easier if you consider it from the beginning. Making an
    large program that was not written with portability in mind portable is "a
    bitch", as you say it.
     
    Rolf Magnus, Dec 6, 2005
    #6
    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. emerth
    Replies:
    3
    Views:
    380
    emerth
    Aug 8, 2003
  2. cppsks
    Replies:
    0
    Views:
    827
    cppsks
    Oct 27, 2004
  3. lutorm
    Replies:
    1
    Views:
    2,195
    Rapscallion
    May 21, 2005
  4. Grizlyk
    Replies:
    4
    Views:
    369
    Grizlyk
    Jan 15, 2007
  5. Brian Takita

    #define _ and #define __

    Brian Takita, Jan 23, 2006, in forum: Ruby
    Replies:
    0
    Views:
    468
    Brian Takita
    Jan 23, 2006
Loading...

Share This Page