c / c++ : is it end of era ?

[Richard Heathfield]

Chris Hills said:

C++ started evolving before 1990 but it fixed on the C90 standard as a
basis .

I guess it depends on what you mean by "came from", then. Yes, you can argue
that C++ "came from" C90, in much the same sense that Doctor Foster "came
from" Gloucester - but first he had to go there!

C++ came from K&R C, headed off on its own for some adventure, excitement,
and really wild things, and then went to C90 for a 10,000 mile service
before heading off into the sunset again.

 

[Jean-Marc Bourguet]

C++ came from C90.

Not really. C90 is K&R C with influence from C++ (prototypes, which is the
most visible difference between K&R C and C90, is directly imported from
C++).

Yours,

 

[Stephen Sprunk]

Aren't ENTER and LEAVE slower because they implement a function call
protocol more complicated than that usually required, rather than for
the reasons you listed? In particular, they can handle "displays" as
used for nested procedures, and provide a frame pointer which can
often be omitted.

The standard calling convention on x86 is what ENTER/LEAVE do. However,
emitting separate instructions allows some bits to be omitted,
rearranged, removed, etc. as the optimizer sees fit. Note that when
optimizing for size, ENTER/LEAVE _are_ used; they couldn't be if they
didn't have the same net effect.

Dropping the frame pointer requires a specific, extra command line flag
to the compiler because it breaks debuggers; it's generally a bad idea,
so it's off by default even at the highest optimization levels. You
typically only turn it on for particular functions or libraries that
need the extra speed from having another register, and there's few
things that need such so badly that people are willing to give up
debugging capability.

I don't know what "displays" for nested procedures are.

S

 

[Richard Tobin]

I don't know what "displays" for nested procedures are.

According to the Intel manual I have, "The second operand [of ENTER]
(nesting level operand) gives the lexical nesting level (0 to 31) of
the procedure. The nesting level determnines the number of stack frame
pointers that are copied to the 'display area' of the new stack frame
from the prededing frame".

In a language where you can nest procedures, something like:

int foo(void)
{
int a;

int bar(int x)
{
... reference to a ...;
if(x > 0)
bar(x-1);
...;
}

bar(10);

...;
}

then a procedure may need be able to access variables which are in an
enclosing procedure's stack frame, and which may not be in a fixed
position on the stack relative to its own frame (as in the recursive
call to bar above). A display is a structure that makes this work by
recording the stack frame pointers of the visible activations of
enclosing procedures.

C doesn't need this, but the implementation of ENTER has to test for
it. Of course, CPU designers may nowadays be able to optimise this
away without overhead.

-- Richard

 

[Richard Tobin]

Dropping the frame pointer requires a specific, extra command line flag
to the compiler because it breaks debuggers;

By the way, it's quite possible to debug without a frame pointer. The
frame pointer will always be "close" to the stack pointer, and its
offset will be fixed at a given point in the code. The compiler can
record the necesary information in the executable file so that a
debugger can construct a "virtual" frame pointer. Of course this
requires a little more cooperation between compiler and debugger.

Even more off-topic: this is reminiscent of the way the Java VM
provides exception-catching without any run-time overhead.

-- Richard

 

[Richard]

Au contaire, cheri.


You've demonstrated your experience in this newsgroup on numerous
occasions. If you have different experience to that which you display
here, then show it.


I'm not the one making sweeping statements claiming that it is
essential to know the length of a string.


With correct design, you don't need to .

Ridiculous. If the example of padding all strings to be FIXEDBUFF in
length or whatever is your idea of correct design then either something
is wrong or you are purposely rising Jacob.

Strings are frequently copied into correctly sized memory blocks to
avoid multiple program objects holding pointers to single string
resources.

Having said that, it would be rare in this case than a simple strlen
wouldnt be better than keeping the length as an attribute.

Having said that, many languages do do this so there must be something
to be said for it.

Gosh! You are clever. And how can I know if the given string
is bigger than the buffer without at least trying to measure
the length?

By knowing its length already, of course.

int fn(char *str)
{
char tmpbuf[512];
/* Here I have to start scanning the string.
At least 511 bytes must be scanned before
I realize that the length of the string is bigger
than tmpbuf. For bigger buffers a bigger WASTE
*/
}

Is it /my/ fault if you have a badly designed programme? Where did
"str" come from? How did you create it? Did you define its length when
you did so?

To put you out of your misery, the app in question read strings into
fixed length buffers, padded them with blanks and null-terminated
them. Thus the strings were /always/ exactly N characters long, no
more and no less. This removed any need at all anywhere to calculate
how long the strings were, because we already knew.

Because you never know when software will change and a constant
becomes a variable...

Two points here
a) constants have nothing to do with it.
b) designing an application for a series of unknown future changes for
unguessable purposes by maintenance droids of unknown quality is both
inefficient and foolish.
I also strongly suspect you're not a follower of XP. They'd shoot you
for doing that sort of thing.

Ahh and it was slower because of the division by zero tests?

Yes. How do I know? I measured it. Next question.

I would like to see the data that supports that hypothesis.

Sure. Get yourself employed by my former employer, and you can look at
my project post-implementation report. Its in the files of the
Technology Dept somewhere.

With today's machines, a test for zero is so fast

And you've proved this beyond all doubt on Vax/VMS, Vax/OSF,
Sun/Solaris, Windows NT/PIII, all of which were targets.

that to slow
down a calculator so that a human being notices the tests must have
been done in an incredible fashion,

Or incredibly often. You apparently have no experience of numerical
pricing techniques either. Ever heard of monte-carlo simulation?

Obvious coming from you.

The point you miss is that security and efficiency are not mutually
exclusive, nor is one axiomatically more important than the other.
Again you generalise unacceptably.

This finishes it. You, you are not AN IDIOT!

I'm glad we agree I'm not an idiot. I know that of course.

--

 

[Richard]

But it isn't C. Do you understand that?

In what language has he implemented these mongrel extensions?

 

[Richard Heathfield]

Richard said:

In what language has he implemented these mongrel extensions?

The implementation language is irrelevant. A C compiler could be written in
Fortran 77 or SNOBOL for all the C Standard cares.