[MUD-Dev] TECH: non-integral integral types

[Nathan F.Yospe]

shren <shren at io.com> said:
> On Fri, 4 May 2001, Caliban Tiresias Darklock wrote:
>> On Wed, 2 May 2001 20:12:03 -0400, "Jon Lambert"
>> <tychomud at ix.netcom.com> wrote:
>>> Caliban Tiresias Darklock wrote:

>>>> True, but not under Windows. The Winsock concern is that an
>>>> FD_SET is actually an array of structures, which is a GREAT deal
>>>> larger than a bit vector.

>>> No it's an array of unsigned ints.

>> Hmm, I was of the impression that the SOCKET datatype was actually
>> a type of structure pointer... not that I've really delved into the
>> internals. I shouldn't have to. :P
 
> The whole reason that things like SOCKET are defined is for a)
> readibility and b) so these things can change in the underlying
> implementation without breaking old code.  I think you know that but
> I thought I'd make it clear to anyone who might not.  If you know
> that time_t is a long, *forget* that fact and declare it as time_t
> and not long, or pay the karmic price.

My real job is programming.  For the last four months, I've worked on
an assortment of platform and architecture ports of a huge server
platform.  I've learned more doing this than I expected.  In spite of
knowledge of, and experience in, programming on many platforms,
architectures, pointer sizes, operating systems, and development
environments, I've run into an unbelievable number of issues.  Byte
swapping on a binary stream, with a number of things *not* being
byte-swapped.  Word size and implicit types being assumed equivalant
to other types.  Rampant casting to be fixed by rampant rewriting...
but above all, not breaking the source tree.  This has to become a
pure, realtime, effective parallel build.  It has to get served by the
same source code control (MS VSS) to several platforms (It wouldn't be
a good idea for me to get into detail... for now, assume the basics of
UNIX and related) with several compilers, commercial or other, and
communicate with the same assortment of clients, databases, and even
stored formats.

Abstraction without killing performance is vital.  I have to trust
sizes of types... which means typedefs... and the behaviors of threads
and I/O and everything else.  And I have to do it with the same code,
minus some tiny amount of platform specific stuff.  Which means I have
types which, in a pinch, can act exactly the same as Win32 threads,
under pthreads or Solaris threads or whatever.  Which means I have
types that can act just the same when cast to a pointer, on any word
length.  Which means I must be able to know that my longs aren't going
to become ints.  Which means, frankly, the rest of the developers need
to be retrained *never* to use, or consider using, native C/C++ types,
because the language was designed in the days when 6, 7, 18, and 36
bit words were common on certain CPUs, and people thought portability
meant *hiding* that detail.  Which is why we now have to hide the
short/int/long/long long (or hyper) types behind types that show their
true colors... plus ones that declare other things instead, like "I'm
as big as a pointer on this machine".

Which is why I think C should allow a typedef supplement that has no
way to cast to the original type implicitly.  I think there should be
a type that is type-identical to *any* enumeration, but isn't an int.
I think, frankly, that C makes it too impossible to forcibly disallow
use of type knowledge on a type that shouldn't know what it casts to.

Many platforms have ints the size of longs.  Some have longs the size
of long longs.  Many have time_t cast to long, and pthread_t to int,
and if you use those assumptions, there's never a conflict.

And of course, people still use fprintf, with its implicit
need-to-know, which can print thread handles, cause they're ints.
Unless they aren't.

--
Nathan F. Yospe  email: yospe at kanga.nu nyospe at a2i.com nyospe at pacbell.net
Don't mind me, I'm just insane - there's someone else here, in my brain. 


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev