S
Steven T. Hatton
I've been working a lot with OpenSceneGraph lately. Overall it is very much
in the spirit of C++. One feature OSG has which is, IMO, an eyesore, is
the presence of a couple of #MACROs to assist in the creation of classes
derived from osg::Object, or osg::Node. The main reason these #MACROS are
useful is because the cpp provides stringification of tokens in the source
file. Here is what the META_Object #MACRO looks like:
http://openscenegraph.org/viewcvs/include/osg/Object?view=markup
/** META_Object macro define the standard clone, isSameKindAs and className
methods.
* Use when subclassing from Object to make it more convenient to define
* the standard pure virtual clone, isSameKindAs and className methods
* which are required for all Object subclasses.*/
#define META_Object(library,name) \
virtual osg::Object* cloneType() const { return new name (); } \
virtual osg::Object* clone(const osg::CopyOp& copyop) const { return
new name (*this,copyop); } \
virtual bool isSameKindAs(const osg::Object* obj) const { return
dynamic_cast<const name *>(obj)!=NULL; } \
virtual const char* libraryName() const { return #library; }\
virtual const char* className() const { return #name; }
It seems natural that std::type_info should support much of this
functionality. Here's the class declaration:
namespace std {
class type_info {
public:
virtual ~type_info();
bool operator==(const type_info& rhs) const;
bool operator!=(const type_info& rhs) const;
bool before(const type_info& rhs) const;
const char* name() const;
private:
type_info(const type_info& rhs);
type_info& operator=(const type_info& rhs);
};
Unfortunately, the standard does not specify the format of the ntbs returned
by std::type_info::name(). GCC on SuSE Linux produces the following output
from the code listed below:
o=N2ti6ObjectE
d=N2ti7DerivedE
#include <iostream>
#include <typeinfo>
namespace ti{
class Object{
public:
const char* name() const { return typeid(*this).name(); }
virtual ~Object(){}
};
class Derived: public Object{
};
}
int main(){
ti::Object o;
ti:
erived d;
std::cout << "o=" << o.name() << std::endl;
std::cout << "d=" << d.name() << std::endl;
}
I could read the documentation for GCC and come up with a way to parse that
string to extract the ntbs returned from osg::Object::className() and
osg::Object::libraryName(), but that would not be portable. Of course I
could put the declarations in a header, and conditionally include platfrom
specific implementaitons - assuming all target platforms will provide
parseable return values from std::type_info::name(). That of course is a
less than ideal solution.
On page 416 of TC++PL(SE), Dr. Stroustrup tells us "the likelyhood is zero
that someone can come up with a single set of information that satisfies
every user". I believe that position may have been taken to a harmful
extreme. It seems to me that specifying a "source form" function that
returns the fully qualified class name in the form it would appear in the
source code would be both useful and reasonable. Does anybody else agree
with this?
I understand that having the ntbs representation of the class name at
runtime does not address the problem of creating osg::Object* cloneType()
const { return new name (); }. That would certainly take a lot more design
change in the C++ library and/or core language. The functionality provided
by the osg::Object class seems rather fundamental. I am sure this kind of
functionality is native to Java, and feel confident it exists in C#. That
doesn't mean it is essential to C++. Obviously, OSG is doing it with
fairly simple CPP #MACROs. But the fact that OSG does have this feature,
and the fact that it is provided externally to the core language suggest to
me that there may be a use for such support in C++. I say this because OSG
is a C++ graphics toolkit. It is not C++ trying to be Java, C#, Pascal, C,
SmallTalk, nor Lisp. This is the only place where (AFAIK) OSG resorts to
#MACROs (other than #include and header guards).
Is there any desire for, or movement for such support in standard C++?
--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell
in the spirit of C++. One feature OSG has which is, IMO, an eyesore, is
the presence of a couple of #MACROs to assist in the creation of classes
derived from osg::Object, or osg::Node. The main reason these #MACROS are
useful is because the cpp provides stringification of tokens in the source
file. Here is what the META_Object #MACRO looks like:
http://openscenegraph.org/viewcvs/include/osg/Object?view=markup
/** META_Object macro define the standard clone, isSameKindAs and className
methods.
* Use when subclassing from Object to make it more convenient to define
* the standard pure virtual clone, isSameKindAs and className methods
* which are required for all Object subclasses.*/
#define META_Object(library,name) \
virtual osg::Object* cloneType() const { return new name (); } \
virtual osg::Object* clone(const osg::CopyOp& copyop) const { return
new name (*this,copyop); } \
virtual bool isSameKindAs(const osg::Object* obj) const { return
dynamic_cast<const name *>(obj)!=NULL; } \
virtual const char* libraryName() const { return #library; }\
virtual const char* className() const { return #name; }
It seems natural that std::type_info should support much of this
functionality. Here's the class declaration:
namespace std {
class type_info {
public:
virtual ~type_info();
bool operator==(const type_info& rhs) const;
bool operator!=(const type_info& rhs) const;
bool before(const type_info& rhs) const;
const char* name() const;
private:
type_info(const type_info& rhs);
type_info& operator=(const type_info& rhs);
};
Unfortunately, the standard does not specify the format of the ntbs returned
by std::type_info::name(). GCC on SuSE Linux produces the following output
from the code listed below:
o=N2ti6ObjectE
d=N2ti7DerivedE
#include <iostream>
#include <typeinfo>
namespace ti{
class Object{
public:
const char* name() const { return typeid(*this).name(); }
virtual ~Object(){}
};
class Derived: public Object{
};
}
int main(){
ti::Object o;
ti:
erived d;std::cout << "o=" << o.name() << std::endl;
std::cout << "d=" << d.name() << std::endl;
}
I could read the documentation for GCC and come up with a way to parse that
string to extract the ntbs returned from osg::Object::className() and
osg::Object::libraryName(), but that would not be portable. Of course I
could put the declarations in a header, and conditionally include platfrom
specific implementaitons - assuming all target platforms will provide
parseable return values from std::type_info::name(). That of course is a
less than ideal solution.
On page 416 of TC++PL(SE), Dr. Stroustrup tells us "the likelyhood is zero
that someone can come up with a single set of information that satisfies
every user". I believe that position may have been taken to a harmful
extreme. It seems to me that specifying a "source form" function that
returns the fully qualified class name in the form it would appear in the
source code would be both useful and reasonable. Does anybody else agree
with this?
I understand that having the ntbs representation of the class name at
runtime does not address the problem of creating osg::Object* cloneType()
const { return new name (); }. That would certainly take a lot more design
change in the C++ library and/or core language. The functionality provided
by the osg::Object class seems rather fundamental. I am sure this kind of
functionality is native to Java, and feel confident it exists in C#. That
doesn't mean it is essential to C++. Obviously, OSG is doing it with
fairly simple CPP #MACROs. But the fact that OSG does have this feature,
and the fact that it is provided externally to the core language suggest to
me that there may be a use for such support in C++. I say this because OSG
is a C++ graphics toolkit. It is not C++ trying to be Java, C#, Pascal, C,
SmallTalk, nor Lisp. This is the only place where (AFAIK) OSG resorts to
#MACROs (other than #include and header guards).
Is there any desire for, or movement for such support in standard C++?
--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell