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)

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)

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)

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)

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)

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