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:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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.

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.

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