"Walter" <walter@digitalmars.com> wrote in message news:bpet6l$1r31$1@digitaldaemon.com...
>
> "Andy Friesen" <andy@ikagames.com> wrote in message news:bp88h1$15ja$1@digitaldaemon.com...
> > Ben Hinkle wrote:
> > > speaking of which, is there a standard Dism for "C++ long" when
writing
> the
> > > interface to a C/C++ library? I made a typdef gmp_long when
translating
> > > gmp.h to gmp.d
> > Personally, I would just call it an int and be done with it. :)
>
> So would I <g>.

I'm dipping in here without having read the previous postings in the thread (newsreader "issues"), but I think this is a bad move.

When porting from an external API, you centralise all the type translations in one place if you define and use the requisite types in the D form.

For example, in the D mapping of recls - which will be in D std lib from 0.76 onwards - I use the type recls_rc_t (the return type), rather than int, since it may conceivably change in recls at some point, and I don't want to have to go around the D mapping guessing which int is a return code, and which is just an int.

Frankly, I'm surprised to hear counter opinions. This is integration lesson 1. Or am I missing something?

"Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> wrote in message news:bpf1c5$21id$1@digitaldaemon.com...
> Frankly, I'm surprised to hear counter opinions. This is integration
lesson
> 1. Or am I missing something?

I'm not a very orthodox programmer. I tend to use far fewer typedefs than others, usually only for either 1) documentation purposes or if 2) I *know* it will change, rather than worry that it might. The reason for (2) is my experience migrating from the 16 bit world to 32 bits. 16 bit programmers would really load up their code with typedef's for portability reasons, and yet when the code was ported to 32 bits it still broke all over the place and was just as much trouble to fix as code with no typedefs at all. The trouble comes from subtle dependencies on the type of a typedef creeping in from all sides.

Another part of my reluctance to use typedefs is I have spent too many hours tracing through too many layers of typedefs, macros, #include's, #if's, etc., trying to figure out just what type foo_x_t_bar_abc__t_my_x_t actually is.

Some things I know are going to change? For 64 bits, size_t and ptrdiff_t are not going to be int-sized any more. File sizes and file offsets are going to 64 bits. time_t is going to change. The size of a pointer is going to change.

Things that I am sure won't change? sizeof(char) is going to stay 1. The number of bits in a byte is going to stay at 8 (10 bit bytes and 18 bit half-words are machines of the past, and are not going to be resurrected). Ones-complement isn't coming back. IEEE 754 floating point is here to stay. Worrying about these things changing is fruitless because (aside from those changes not happening) despite one's best efforts, one will get it wrong anyway trying to be portable to such architectures without actually testing it on such. I think the 16 to 32 bit conversion proved that <g>.

In article <bsgv5n$11m4$1@digitaldaemon.com>, Walter says...
>I'm not a very orthodox programmer. I tend to use far fewer typedefs than others, usually only for either 1) documentation purposes or if 2) I *know* it will change, rather than worry that it might. The reason for (2) is my experience migrating from the 16 bit world to 32 bits. 16 bit programmers would really load up their code with typedef's for portability reasons, and yet when the code was ported to 32 bits it still broke all over the place and was just as much trouble to fix as code with no typedefs at all. The trouble comes from subtle dependencies on the type of a typedef creeping in from all sides.

Of course poorly done typedefs are always a problem partly because C/C++ does not actually create a new type. A few years of Ada programming makes you appreciate what types can be.

"Mark T" <Mark_member@pathlink.com> wrote in message news:bshlgj$25mu$1@digitaldaemon.com...
> In article <bsgv5n$11m4$1@digitaldaemon.com>, Walter says...
> >I'm not a very orthodox programmer. I tend to use far fewer typedefs than others, usually only for either 1) documentation purposes or if 2) I
*know*
> >it will change, rather than worry that it might. The reason for (2) is my experience migrating from the 16 bit world to 32 bits. 16 bit programmers would really load up their code with typedef's for portability reasons,
and
> >yet when the code was ported to 32 bits it still broke all over the place and was just as much trouble to fix as code with no typedefs at all. The trouble comes from subtle dependencies on the type of a typedef creeping
in
> >from all sides.
>
> Of course poorly done typedefs are always a problem partly because C/C++
does
> not actually create a new type. A few years of Ada programming makes you appreciate what types can be.

I've never programmed in Ada so I'll take your word for it. BTW, D does have strong typedef's unlike C/C++.

"Walter" <walter@digitalmars.com> wrote in message news:bsicou$cjv$1@digitaldaemon.com...
>
> "Mark T" <Mark_member@pathlink.com> wrote in message news:bshlgj$25mu$1@digitaldaemon.com...
> > In article <bsgv5n$11m4$1@digitaldaemon.com>, Walter says...
> > >I'm not a very orthodox programmer. I tend to use far fewer typedefs
than
> > >others, usually only for either 1) documentation purposes or if 2) I
> *know*
> > >it will change, rather than worry that it might. The reason for (2) is
my
> > >experience migrating from the 16 bit world to 32 bits. 16 bit
programmers
> > >would really load up their code with typedef's for portability reasons,
> and
> > >yet when the code was ported to 32 bits it still broke all over the
place
> > >and was just as much trouble to fix as code with no typedefs at all.
The
> > >trouble comes from subtle dependencies on the type of a typedef
creeping
> in
> > >from all sides.
> >
> > Of course poorly done typedefs are always a problem partly because C/C++
> does
> > not actually create a new type. A few years of Ada programming makes you appreciate what types can be.
>
> I've never programmed in Ada so I'll take your word for it. BTW, D does
have
> strong typedef's unlike C/C++.

STLSoft does provide strong typedefs, called "True Typedefs". See the file stlsoft_true_typedef.h