www.digitalmars.com         C & C++   DMDScript  

c++ - feature request: type_info

reply Larry Brasfield <larry_brasfield snotmail.com> writes:
It would be a convenience if the typeid operator
returned a type_info & rather than a Type_info &.

-- 
-Larry Brasfield
(address munged, s/sn/h/ to reply)
Aug 19 2002
parent reply Jan Knepper <jan smartsoft.cc> writes:
Why?
Just...
typedef Type_info        typeinfo;
and you should be done.
Jan



Larry Brasfield wrote:


 It would be a convenience if the typeid operator
 returned a type_info & rather than a Type_info &.

 --
 -Larry Brasfield
 (address munged, s/sn/h/ to reply)
Aug 19 2002
parent reply Larry Brasfield <larry_brasfield snotmail.com> writes:
In article <3D616AB7.B0CEF6D7 smartsoft.cc>, 
Jan Knepper (jan smartsoft.cc) says...

 Why?
 Just...
 typedef Type_info        typeinfo;
 and you should be done.


I beg to differ.

Here is a C++ program:
#include <typeinfo>

// typedef Type_info type_info;

class foo {};
class bar : foo {};

const type_info & its_real_type(foo & r) { return typeid(r); }

If I remove the comment delimiter on the typedef, it will
no longer compile with a compiler that follows the
standard with respect to the name of what typeid() yields.

Of course I can ..just.. put the typedef into a conditional
compilation, but this is more clutter and leads to
  #include "DMC_fixups.h"
or
  #include "CPP_fixups.h"
everywhere.

Truly, it would be a convenience if the typeid operator
returned a type_info & rather than a Type_info &.

The <typeinfo> header can have something like
  typedef type_info Type_info;
for the benefit of backward (source) compatibility.

There is a reason for having a C++ standard, and little
issues like this do not deserve to rise to the level
of making people write little globally used fixups.

-- 
-Larry Brasfield
(address munged, s/sn/h/ to reply)
Aug 19 2002
parent reply Jan Knepper <jan smartsoft.cc> writes:
I merely showed a way to solve the problem for now.

I have a file Target.h which I include when compiling ANY file. It
basically does a number of #define's necessary to make my code
compile with different compilers. I think the standard return for
typeid actually is type_info &. In Target.h I use a define,
something like:

#if defined(__DMC__)

#define type_info        Type_info;

#elif defined(__BORLANDC__)

#define type_info        type_info;

#elif ...

Target.h contains quite a few more of such things to make code
work between different compilers...
Attached...

Jan



Larry Brasfield wrote:


 In article <3D616AB7.B0CEF6D7 smartsoft.cc>,
 Jan Knepper (jan smartsoft.cc) says...

 Why?
 Just...
 typedef Type_info        typeinfo;
 and you should be done.


 I beg to differ.

 Here is a C++ program:
 #include <typeinfo>

 // typedef Type_info type_info;

 class foo {};
 class bar : foo {};

 const type_info & its_real_type(foo & r) { return typeid(r); }

 If I remove the comment delimiter on the typedef, it will
 no longer compile with a compiler that follows the
 standard with respect to the name of what typeid() yields.

 Of course I can ..just.. put the typedef into a conditional
 compilation, but this is more clutter and leads to
   #include "DMC_fixups.h"
 or
   #include "CPP_fixups.h"
 everywhere.

 Truly, it would be a convenience if the typeid operator
 returned a type_info & rather than a Type_info &.

 The <typeinfo> header can have something like
   typedef type_info Type_info;
 for the benefit of backward (source) compatibility.

 There is a reason for having a C++ standard, and little
 issues like this do not deserve to rise to the level
 of making people write little globally used fixups.

 --
 -Larry Brasfield
 (address munged, s/sn/h/ to reply)
Aug 19 2002
parent reply Larry Brasfield <larry_brasfield snotmail.com> writes:
In article <3D61AB3D.F4A31364 smartsoft.cc>, 
Jan Knepper (jan smartsoft.cc) says...

 I merely showed a way to solve the problem for now.


I appreciate your effort.  My request is motivated
by the desire to not need "include this everywhere"
fixup headers.  The closer our tools get to actually
conforming to the C++ standard, the more avoiding
such solutions seems in reach and desirable.


 I have a file Target.h which I include when compiling ANY file. 


I've seen such in many projects.  They seem to
grow without bound.  I've updated them myself on
several occasions and hope to never have to bring
such conglomerations into my editor again.  (A
vain hope, I know, but less vain as time passes.)

I did save your attachment in the hope that it
will help me stumble thru other issues with DMC.

Thanks.

-- 
-Larry Brasfield
(address munged, s/sn/h/ to reply)
Aug 19 2002
parent Jan Knepper <jan smartsoft.cc> writes:
Larry Brasfield wrote:


 In article <3D61AB3D.F4A31364 smartsoft.cc>,
 Jan Knepper (jan smartsoft.cc) says...

 I merely showed a way to solve the problem for now.


 I appreciate your effort.  My request is motivated
 by the desire to not need "include this everywhere"
 fixup headers.  The closer our tools get to actually
 conforming to the C++ standard, the more avoiding
 such solutions seems in reach and desirable.


Agreed.


 I have a file Target.h which I include when compiling ANY file.


 I've seen such in many projects.  They seem to
 grow without bound.  I've updated them myself on
 several occasions and hope to never have to bring
 such conglomerations into my editor again.  (A
 vain hope, I know, but less vain as time passes.)


<g> I was hoping so too... Hope in vain indeed I guess... I have had
this file for YEARS, it changes little in time, but it does...


 I did save your attachment in the hope that it
 will help me stumble thru other issues with DMC.


Have used DMC++ ever since Zortech C++ V1.x...
I should be aware of most of the quirks... <g>

Jan
Aug 19 2002