C can be very literal.

[DSF]

Yes. But there are lots of platforms where pointers cast to uint will
have lost some of their bits, and where you might occasionally see
strange behavior.

Assume ints are 32-bit, and pointers 64-bit, and consider what you
get from (uint) 0x100000010 - (uint) 0x0FFFFFFF0.

I'm well aware of that. At the time, speed (of finishing the
project, not execution time) was of a priority. I don't recall right
now what that code was part of, but I believe it's still a work in
progress. (I was sick for over a month.)

In that case, I think it's a safe bet that you would spend an order
of magnitude less time converting to a modern compiler than you are
spending writing code that's less maintainable and more likely to
have subtle bugs than what a modern compiler would do.

True. But that is bound to be a major undertaking and I have
several projects in progress that I need yesterday! The time
learning/getting used to a new compiler plus some code conversion
would set me back months.

Which sort of renders the entire exercise a little silly, no?

No. Because it wasn't an exercise. I needed 16-bit character
support and converting the 16-bit code to an 8-bit counterpart for
each of the string functions I wrote was a simple matter.

#define TONGUE_IN_CHEEK

Who knows? It might still be incredibly faster than a current
compiler. When I get the two remaining projects done and have some
time to look into finding/learning a new compiler, I'll let you know.

#undef TONGUE_IN_CHEEK

-s

DSF
"'Later' is the beginning of what's not to be."
D.S. Fiscus

 

[DSF]

On Wed, 13 Nov 2013 08:57:21 -0500, James Kuyper

{much snipped}

There may be legitimate reasons for worrying about and complaining about
the inadequacies of 20-year old compilers, though those reasons don't
apply to me. However, those inadequacies should be attributed to the age
of the compiler, not to the language it compiles. You Subject: header
should have been "Borland C++ can be very literal".

It should have, but I didn't want all of the responses to be flames
for being off-topic.

There are times when I *WANT* the compiler to be literal. Some
practical reasons: There are some optimizations in BC++ that cannot
be turned of and make debugging difficult. There are occasions where
I want the resulting code to be exactly how I wrote it. They're rare,
but I've heard complaints of errant optimizations altering the intent
of the code under certain conditions.

DSF
"'Later' is the beginning of what's not to be."
D.S. Fiscus

 

[James Kuyper]

On Wed, 13 Nov 2013 08:57:21 -0500, James Kuyper


It should have, but I didn't want all of the responses to be flames
for being off-topic.

The best way to avoid getting flamed for an off-topic post is to post it
to a forum where it isn't off-topic (a Borland C++ forum would be such a
one for this issue). Using a misleading "Subject:" header won't help
much, most people pay more attention to the body of the message than to
the "Subject:" header.

There are times when I *WANT* the compiler to be literal. Some

Then, at those times, you should be using assembler, not C. C was never
intended to specify precisely the generated machine code. It was
intended to specify the resulting behavior, leaving implementations free
to choose how they achieve that behavior.