global typedefs and #define /\ global inheritance base

[eiji]

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.

[Victor Bazarov]

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

[eiji]

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")

[Jonathan Mcdougall]

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

[Victor Bazarov]

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

[Rolf Magnus]

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.