468,462 Members | 1,858 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,462 developers. It's quick & easy.

C++ more efficient than C?

In "Learning Standard C++ as a New Language" Bjarne Stroustrup claims that
properly written C++ outperforms C code. I will just copy his first example
here, which is supposed to demonstrate how C++ abstractions do not only make
code easier to understand but also make it more efficient:
===
The simplest specific example I can think of is a program to find the mean
and median of a sequence of double precision floating-point numbers read
from input. A conventional C-style solution would be:

#include <stdlib.h>
#include <stdio.h>

int compare(const void *p, const void *q)
{
register double p0 = * (double *)p;
register double q0 = * (double *)q;
if (p0 q0) return 1;
if (p0 < q0) return -1;
return 0;
}

void quit()
{
fprintf(stder, "memory exhausted\n");
exit(1);
}

int main(int argc, char *argv[])
{
int res = 1000;
char * file = argv[2];

double *buf = (double *) malloc(sizeof (double) *res);
if (buf==0) quit();

double median = 0;
double mean = 0;
int n = 0;

FILE *fin = fopen(file, "r");
double d;
while (fscanf(fin, "%lg", &d) == 1) {
if (n==res) {
res += res;
buf = (double *)realloc(buf, sizeof(double) *res);
if (buf==0) quit();
}
buf[n++] = d;
mean = (n == 1) ? d : mean + (d - mean) / n;
}

qsort(buf, n, sizeof(double), compare);

if (n) {
int mid = n/2;
median = (n%2) ? buf[mid] : (buf[mid - 1] + buf[mid]) / 2;
}

printf("number of elements = %d, median = %g, mean = %g\n", n, median,
mean);
free(buf);
}

To compare, here is an idiomatic C++ solution:

#include<vector>
#include<fstream>
#include<algorithm>

using namespace std;

int main(int argc, char * argv[])
{
char *file = argv[2];
vector<double>buf;

double median = 0;
double mean = 0;

fstream fin(file, ios::in);
double d;
while (fin >d) {
buf.push_back(d);
mean = (buf.size() == 1) ? d : mean + (d - mean) / buf.size();
}

sort(buf.begin(), buf.end());

if (buf.size()) {
int mid = buf.size() / 2;
median = (buf.size() %2) ? buf[mid] : (buf[mid - 1] + buf[mid]) / 2;
}

cout << "number of elements = " << buf.size()
<< " , median = " << median << ", mean = " << mean << '\n';
}
======================

He goes on to claim that, using a sample set of 5,000,000 elements, the C++
code is more than 4 times faster than the C code. Further examples follow to
prove the superiority of C++ even in the realm of efficiency.

So C coders who care about efficiency should switch to C++?

Are their any counter-arguments against Stroustroups claim?

Apr 6 '08
74 4203
On Apr 9, 1:23 pm, Paul Hsieh <websn...@gmail.comwrote:
...
The main thing BjarneStroustrupis trying to prove with all this is
that template code inlining is faster than eating indirect function
call overhead.
...
In this case, its not a question of counter-argument, its a question
of debunking. If this is *truly* an example cited by BjarneStroustrup, he deserves to be tarred and feathered on at least 3
grounds:
...
Before you (all of you) start channeling me (saying what I "really"
was trying to do"), accuse me of intellectual dishonesty, stupidity,
bad C code, etc. and proceed to tar and feather me, you might like to
read the paper first. In it, I make no outrageous claims, properly
qualify the results (despite conjectures in this thread I don't make
silly claims such as "C++ is always faster than C"), and explain why
the particular examples were chosen. I have of course known C well for
longer than most posters here have been alive (and I am a major
contributor to modern C), but just in case I had overlooked something
major, I did have my C code in that paper looked at by C experts of a
magnitude or two larger than most people who hang out here (remember,
I was in Bell Labs Computer Science Research Center at the time - look
it up if you don't know what that is relative to C and C++).

Read the paper, you might be surprised and you might actually learn
something.

-- Bjarne Stroustrup; http://www.research.att.com/~bs

PS My home pages contain much more information about C++ and many more
papers.
Apr 10 '08 #51
Morris Dovey wrote:
> Because the programmer shouldn't be required to manually free the
memory. This is a task for the compiler, not the programmer. If the
language requires that the programmer frees the memory, then it's the
fault of the language.

Eh? If an automobile driver doesn't apply the brakes to avoid an
accident, do you blame the car?
You are comparing apples and oranges here.

There are some things which are clearly a task for the compiler (or
some library provided by the compiler).

For example, memory allocation is a task for the compiler. Imagine
that you would have no malloc() function at all, but instead you could
only call brk() (which simply asks the OS to increase the heap size and
does nothing else) and everything else is up to you. It would be quite
unreasonable for a decent programming language to expect that the user
writes his own memory allocation routines every time he writes a small
program. Memory allocation is clearly a task for the compiler, not the
programmer.
In the exact same way memory deallocation should be.
The language doesn't _require_ the programmer to allocate the
memory in the first place. I the programmer then fails to
properly manage the resource he requested and received, then
that's a simple case of irresponsible behavior.
Imagine that each time you wrote, for example "int i = 5;" you would
have to somewhere explicitly say "free this int, I'm not using it
anymore". Would that be reasonable?
Why should dynamic memory allocation be any different?
Apr 10 '08 #52
lb*******@yahoo.com wrote:
One man's fault is another man's feature. Some people like fine
grained control over memory allocation, and don't want garbage
collectors firing up at unpredictable times.
Garbage collection is not the only possible memory management system.
Many programming languages get away without it (such as, AFAIK, PHP and
Objective C).
Apr 10 '08 #53
Alf P. Steinbach said:
* Richard:
<snip>
>Well said, but remember in c.l.c people don't leak memory because they
do things "properly" .... rumour has it that some can debug 50,000 lines
of foreign code 5 hours into a system run by merely glancing at a print
out of the code. Thats the kind of guys you are dealing with
here. Because Kernighan doesn't use a debugger, they don't either.

Heh, I hope that rumour isn't about me.
No, it's just a clc troll, playing the Exaggeration Game as usual.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Apr 10 '08 #54
On Thu, 10 Apr 2008 13:39:19 +0200, Lloyd Bonafide wrote:
Kelsey Bjarnason <kb********@gmail.comwrote in news:r311d5-hbb.ln1
@spanky.localhost.net:
>[snips]

On Wed, 09 Apr 2008 03:11:14 +0000, ozbear wrote:
>>There are a myriad of C functions

"myriad C functions".

Myriad can be used as a noun or an adjective. And correcting grammar in
a technical discussion is bad form, especially when you're wrong.

http://dictionary.reference.com/browse/myriad

"Usage Note: Throughout most of its history in English myriad was used
as a noun, as in a myriad of men. In the 19th century it began to be
used in poetry as an adjective, as in myriad men. Both usages in English
are acceptable, as in Samuel Taylor Coleridge's "Myriad myriads of
lives.""
One might point out that the usage note is inconsistent with the entire
rest of the page. "Myriad", when used in a noun form, is said by the
usage note to be acceptable in usage such as "a myriad of men".

Yet, in direct contradiction to this, not a single offered definition
allows this particular construct. For example, "myriad" can mean "a very
great number", meaning that as used, the phrase reads "a a very great
number of me", with a redundant "a" at the front. No, that doesn't work.

How about "an indefinitely great number"? Then it becomes "a an
indefinitely great number of men", which doesn't work. Nor does "a ten
thousand of men" work. Nor does *any* noun form defined or described.

The sole exception to this is Wordnet's offering of the noun form, which
contradicts the cited page's offering of the noun form, except for the
usage not which also contradicts the cited page's offering of the noun
form.

Or, in short, while a noun form may in fact be acceptable, the noun form
actually used is directly contraindicated by the very page used to
support such usage.

Not sure what the point there was, but if it was not to show that my
correction was both proper and consistent with the proper usage of
myriad, where the original usage was inconsistent with such use, then the
point has failed to be made.

Apr 10 '08 #55
jacob navia <ja***@nospam.comwrites:
[...]
Excuse me but you forgot the discussion a few weeks ago when
the "regulars" in comp.lang.c said the "C has no stack"?
[...]

And you seem to have forgotten, or never to have been aware, that the
"regulars" were right.

There is a difference between a language and an imlementation of a
language. C does not have a stack. Most C implementations do. You
insist on ignoring that distinction.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Apr 10 '08 #56
Kelsey Bjarnason <kb********@gmail.comwrites:
[snips]
On Tue, 08 Apr 2008 13:38:21 -0700, Keith Thompson wrote:
>I'll just point out that there are plenty of programming languages in
which functions (procedures, subprograms, whatever) can modify their
arguments, and programmers who use those languages generally manage to
cope with the pain.

Sure. C's one such language,
[snip]

No, it isn't.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Apr 10 '08 #57
lb*******@yahoo.com wrote:
On Apr 10, 7:01?am, Juha Nieminen <nos...@thanks.invalidwrote:
>>
? But you can invent a language which doesn't leak memory.

Such as?
Pascal. FORTRAN. COBOL.

If you don't have dynamic allocation, you can't leak memory.

-Larry Jones

Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us. -- Calvin
Apr 10 '08 #58
In article <l0************@spanky.localhost.net>,
Kelsey Bjarnason <kb********@gmail.comwrote:
>It's not? Okay, so explain to me, when you see this:

string a = someval;
func(a);

how you tell, without hunting for the prototype or definition of func,
whether a will be modified.
How do you tell in C? You might find

#define func(x) ((x)=someotherval)

-- Richard
--
:wq
Apr 10 '08 #59
In article <ft**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:
>If you hold a reference to an unneeded object NO garbage
collector will collect it. You will have to find it.
That's not true. I wrote a garbage collector which examined
yet-to-be-executed code to see whether the value of a variable
was used. (It wasn't for C.)

-- Richard

--
:wq
Apr 10 '08 #60
In article <2e**********************************@t54g2000hsg. googlegroups.com>,
bjarne <bj****@gmail.comwrote:
>I have of course known C well for
longer than most posters here have been alive
I fear you underestimate the age of most of us.

-- Richard
--
:wq
Apr 10 '08 #61
ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
In article <ft**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:
>>If you hold a reference to an unneeded object NO garbage
collector will collect it. You will have to find it.

That's not true. I wrote a garbage collector which examined
yet-to-be-executed code to see whether the value of a variable
was used. (It wasn't for C.)

-- Richard
Did you build a tardis at the same time?
Apr 10 '08 #62
In article <ft**********@registered.motzarella.org>,
Richard <de***@gmail.comwrote:
>Did you build a tardis at the same time?
What's the hurry? I'll build one later and send it back.

-- Richard

--
:wq
Apr 10 '08 #63
ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
In article <ft**********@registered.motzarella.org>,
Richard <de***@gmail.comwrote:
>>Did you build a tardis at the same time?

What's the hurry? I'll build one later and send it back.

-- Richard
Too late. I just picked it up, went forward in time and invented it
before you.
Apr 10 '08 #64
On 2008-04-10 17:00, Kelsey Bjarnason wrote:
On Thu, 10 Apr 2008 13:39:19 +0200, Lloyd Bonafide wrote:
>Kelsey Bjarnason <kb********@gmail.comwrote in news:r311d5-hbb.ln1
@spanky.localhost.net:
>>[snips]

On Wed, 09 Apr 2008 03:11:14 +0000, ozbear wrote:

There are a myriad of C functions

"myriad C functions".

Myriad can be used as a noun or an adjective. And correcting grammar in
a technical discussion is bad form, especially when you're wrong.

http://dictionary.reference.com/browse/myriad

"Usage Note: Throughout most of its history in English myriad was used
as a noun, as in a myriad of men. In the 19th century it began to be
used in poetry as an adjective, as in myriad men. Both usages in English
are acceptable, as in Samuel Taylor Coleridge's "Myriad myriads of
lives.""

One might point out that the usage note is inconsistent with the entire
rest of the page. "Myriad", when used in a noun form, is said by the
usage note to be acceptable in usage such as "a myriad of men".

Yet, in direct contradiction to this, not a single offered definition
allows this particular construct. For example, "myriad" can mean "a very
great number", meaning that as used, the phrase reads "a a very great
number of me", with a redundant "a" at the front. No, that doesn't work.

How about "an indefinitely great number"? Then it becomes "a an
indefinitely great number of men", which doesn't work. Nor does "a ten
thousand of men" work. Nor does *any* noun form defined or described.

The sole exception to this is Wordnet's offering of the noun form, which
contradicts the cited page's offering of the noun form, except for the
usage not which also contradicts the cited page's offering of the noun
form.

Or, in short, while a noun form may in fact be acceptable, the noun form
actually used is directly contraindicated by the very page used to
support such usage.

Not sure what the point there was, but if it was not to show that my
correction was both proper and consistent with the proper usage of
myriad, where the original usage was inconsistent with such use, then the
point has failed to be made.
Seriously, you've been programming for too long when you can't tell the
difference between English and macro expansions.

--
Erik Wikström
Apr 10 '08 #65
la************@siemens.com writes:
lb*******@yahoo.com wrote:
>On Apr 10, 7:01?am, Juha Nieminen <nos...@thanks.invalidwrote:
>>>
? But you can invent a language which doesn't leak memory.

Such as?

Pascal. FORTRAN. COBOL.

If you don't have dynamic allocation, you can't leak memory.
Pascal has dynamic allocation, at least in every version I've used.

(I think modern Fortrans do as well, but I suppose all-caps FORTRAN
refers to an older version that doesn't.)

But you can certainly *implement* a memory leak even in a language
that doesn't support the feature directly.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Apr 10 '08 #66
On Apr 10, 1:26*am, user923005 <dcor...@connx.comwrote:
NaN != NaN
That was the first thing that I wrote, which you snipped. I am not
sure whether you meant to say "in an IEEE implementation, two NaNs
will compare not equal" or if you meant "all NaNs are not the same; if
an array is sorted with a double value as the key, then there might be
a requirement that certain NaNs are sorted in a certain way relative
to others".
But now lets consider a hash table. When you use a hash table, any two
keys that compare equal must have the same hash value. Your comparison
function considers any two consecutive double numbers to be equal
unless they are very small. So any two consecutive double precision
numbers must have the same hash value. That means that all positive
double numbers that are not very small must have the same hash value.
Which makes a hash table unusable.

There are no comparisons in a hash table. *Hash tables cannot be used
for range searches, only equality searches.
Of course there are comparisons in a hash table. You first find an
element with a matching hash value, and _then_ you do a comparison for
equality.
Apr 10 '08 #67
jacob navia wrote:
>
The C compiler lcc-win offers a GC since 2004 in the standard
distribution.

This allows a simplification of programming and makes most of the need
for destructors superfluous.
GC frees memory which is only one role of destructors. It does not free
other resources.

--
Ian Collins.
Apr 10 '08 #68
On Apr 10, 2:33*pm, "christian.bau" <christian....@cbau.wanadoo.co.uk>
wrote:
On Apr 10, 1:26*am, user923005 <dcor...@connx.comwrote:
NaN != NaN

That was the first thing that I wrote, which you snipped. I am not
sure whether you meant to say "in an IEEE implementation, two NaNs
will compare not equal" or if you meant "all NaNs are not the same; if
an array is sorted with a double value as the key, then there might be
a requirement that certain NaNs are sorted in a certain way relative
to others".
If your sort routine is expecting comparisons to operate normally, I
suggest that sorting NaNs is unreliable unless you do something
special with compare.
But now lets consider a hash table. When you use a hash table, any two
keys that compare equal must have the same hash value. Your comparison
function considers any two consecutive double numbers to be equal
unless they are very small. So any two consecutive double precision
numbers must have the same hash value. That means that all positive
double numbers that are not very small must have the same hash value.
Which makes a hash table unusable.
There are no comparisons in a hash table. *Hash tables cannot be used
for range searches, only equality searches.

Of course there are comparisons in a hash table. You first find an
element with a matching hash value, and _then_ you do a comparison for
equality.
In that case I have no idea what you are talking about here.
I guess it isn't you but me. I can be incredibly thick at times.
Apr 11 '08 #69
On Apr 11, 7:14*am, user923005 <dcor...@connx.comwrote:
On Apr 10, 2:33*pm, "christian.bau" <christian....@cbau.wanadoo.co.uk>
wrote:
On Apr 10, 1:26*am, user923005 <dcor...@connx.comwrote:
NaN != NaN
That was the first thing that I wrote, which you snipped. I am not
sure whether you meant to say "in an IEEE implementation, two NaNs
will compare not equal" or if you meant "all NaNs are not the same; if
an array is sorted with a double value as the key, then there might be
a requirement that certain NaNs are sorted in a certain way relative
to others".

If your sort routine is expecting comparisons to operate normally, I
suggest that sorting NaNs is unreliable unless you do something
special with compare.
In my original post the first part that you snipped start with "when
sorting floating point numbers, you have to take care of NaNs" or
something similar, which you snipped. Now maybe you are not aware of
this, but on some implementations operations like sqrt (-1), acos
(+2), inf-inf, 0/0 all produce _different_ NaNs, that is NaNs with
different representations. That makes it obvious to ask whether you
want all NaNs to be sorted as if they were the same or if you want
different kinds of NaNs to be sorted differently.
But now lets consider a hash table. When you use a hash table, any two
keys that compare equal must have the same hash value. Your comparison
function considers any two consecutive double numbers to be equal
unless they are very small. So any two consecutive double precision
numbers must have the same hash value. That means that all positive
double numbers that are not very small must have the same hash value..
Which makes a hash table unusable.
There are no comparisons in a hash table. *Hash tables cannot be used
for range searches, only equality searches.
Of course there are comparisons in a hash table. You first find an
element with a matching hash value, and _then_ you do a comparison for
equality.

In that case I have no idea what you are talking about here.
I guess it isn't you but me. *I can be incredibly thick at times.
Dann Corbit suggested a compare function for floating point numbers
that considers a and b to be equal if they are very close together. If
that makes sense for sorted arrays, then it makes sense for hash
tables. In a hash table, items are not sorted, but they are still
compared for equality. And any two items that compare equal must have
the same hash code, otherwise the hash table won't work.
Apr 11 '08 #70
On Apr 11, 2:52*pm, "christian.bau" <christian....@cbau.wanadoo.co.uk>
wrote:
On Apr 11, 7:14*am, user923005 <dcor...@connx.comwrote:
On Apr 10, 2:33*pm, "christian.bau" <christian....@cbau.wanadoo.co.uk>
wrote:
On Apr 10, 1:26*am, user923005 <dcor...@connx.comwrote:
NaN != NaN
That was the first thing that I wrote, which you snipped. I am not
sure whether you meant to say "in an IEEE implementation, two NaNs
will compare not equal" or if you meant "all NaNs are not the same; if
an array is sorted with a double value as the key, then there might be
a requirement that certain NaNs are sorted in a certain way relative
to others".
I guess that both things are true because it is possible to have QNAN
and SNAN and there are often even multiple different interal values
that all map to QNAN, for instance. I was testing a sorting routine
on perverse data and it went poof when it got a vector with NaNs in
it. So I know that it can cause real problems if you use a simplistic
comparison routine. I must not have noticed your original stuff about
NaNs.
If your sort routine is expecting comparisons to operate normally, I
suggest that sorting NaNs is unreliable unless you do something
special with compare.

In my original post the first part that you snipped start with "when
sorting floating point numbers, you have to take care of NaNs" or
something similar, which you snipped. Now maybe you are not aware of
this, but on some implementations operations like sqrt (-1), acos
(+2), inf-inf, 0/0 all produce _different_ NaNs, that is NaNs with
different representations. That makes it obvious to ask whether you
want all NaNs to be sorted as if they were the same or if you want
different kinds of NaNs to be sorted differently.
Another question is "Are NaNs large or small?"
But now lets consider a hash table. When you use a hash table, anytwo
keys that compare equal must have the same hash value. Your comparison
function considers any two consecutive double numbers to be equal
unless they are very small. So any two consecutive double precision
numbers must have the same hash value. That means that all positive
double numbers that are not very small must have the same hash value.
Which makes a hash table unusable.
There are no comparisons in a hash table. *Hash tables cannot be used
for range searches, only equality searches.
Of course there are comparisons in a hash table. You first find an
element with a matching hash value, and _then_ you do a comparison for
equality.
In that case I have no idea what you are talking about here.
I guess it isn't you but me. *I can be incredibly thick at times.

Dann Corbit suggested a compare function for floating point numbers
that considers a and b to be equal if they are very close together. If
that makes sense for sorted arrays, then it makes sense for hash
tables. In a hash table, items are not sorted, but they are still
compared for equality. And any two items that compare equal must have
the same hash code, otherwise the hash table won't work.
That's wrong.
If I have 1 and 1+epsilon, and I store them in a hash table they
*will* go into different slots (quite likely separated by a great
distance).
However, my floating point comparison routine will recognize both
correctly as the proper values (or at least the ones that I am
searching for).
It is very likely (however) that a simplistic comparison routine that
is looking for exact values *will* fail to find them.
This is a very well known problem.

Notice that this AVL tree does fuzzy comparisons for floating point:
http://home.comcast.net/~kmbtib/scaled2g.f90

Here we have an interesting note. From http://www.cs.umb.edu/~eoneil/introPLSQL/02_funds.htm
we have this:
"Guidelines for PL/SQL Boolean Expressions
In general, do not compare real numbers for exact equality or
inequality. Real numbers are stored as approximate values. So, for
example, the following IF condition might not yield TRUE:
· count := 1;
· IF count = 1.0 THEN
· ...
· END IF;"

See also:
D.E. Knuth in Section 4.2.2 of Seminumerical Algorithms (3rd
edition).
and:
http://bugs.mysql.com/bug.php?id=27869
Apr 12 '08 #71
On Thu, 10 Apr 2008 13:29:27 -0700, Keith Thompson <ks***@mib.org>
wrote:
la************@siemens.com writes:
lb*******@yahoo.com wrote:
On Apr 10, 7:01?am, Juha Nieminen <nos...@thanks.invalidwrote:

? But you can invent a language which doesn't leak memory.

Such as?
Pascal. FORTRAN. COBOL.

If you don't have dynamic allocation, you can't leak memory.

Pascal has dynamic allocation, at least in every version I've used.
And all the way back to J&W, I'm pretty sure.
(I think modern Fortrans do as well, but I suppose all-caps FORTRAN
refers to an older version that doesn't.)
Fortran does since '90. Actually two kinds: user managed, and easily
leakable, POINTER; and dynamic but auto managed ALLOCATABLE, which
(used alone) after minor fixes in '95 cannot leak, but had limitations
to ensure quick-enough implementation that were relaxed only in a
subsequent Technical Report, and now in '03. (Namely passed to
routines and as ~structure components.)

COBOL (and I believe RPG) had no in-language dynamic. COBOL did have
interlanguage call, allowing you to access other (e.g. assembler)
alloc, with some cheating because it also didn't have overt pointers.

BASICs tended to vary on whether DIM statements were executable (and
dynamic) or not. Some had something like REDIM() executable.

- formerly david.thompson1 || achar(64) || worldnet.att.net
Jun 27 '08 #72
On Wed, 9 Apr 2008 12:33:26 -0400, la************@siemens.com wrote:
Keith Thompson <ks***@mib.orgwrote:

Inlining qsort's comparison function should be straightforward *if*
the compiler is able to inline (a call to) the qsort() function
itself. That would require either the ability to inline across
separately compiled translation units, or an implementation that in
effect delays compilation until link time.

Or an inline definition of qsort() in <stdlib.h>. A conforming
implementation can't do that directly, but it can define the inline
function with a reserved name and then define a qsort() macro that
invokes the inline function.
I don't see that a different reserved name is needed. All std-lib
routine names are already reserved with external linkage, and an
implementation can special case them, as gcc does for e.g. memcpy and
sqrt. OTOH using macro -__magic would allow you to inline plain
invocations but still do a macro-suppressed real call if you want.

- formerly david.thompson1 || achar(64) || worldnet.att.net
Jun 27 '08 #73
On Apr 21, 3:33 am, David Thompson <dave.thomps...@verizon.netwrote:
On Thu, 10 Apr 2008 13:29:27 -0700, Keith Thompson <ks...@mib.org>
wrote:
lawrence.jo...@siemens.com writes:
lbonaf...@yahoo.com wrote:
>On Apr 10, 7:01?am, Juha Nieminen <nos...@thanks.invalidwrote:
>>? But you can invent a language which doesn't leak memory.
>Such as?
Pascal. FORTRAN. COBOL.
If you don't have dynamic allocation, you can't leak memory.
Pascal has dynamic allocation, at least in every version I've used.
And all the way back to J&W, I'm pretty sure.
It was in the J&W, yes. Supposedly, however, the reason why
Knuth didn't use it in TeX was because it didn't work on all
implementations, and I seem to recall ones without it
(admittedly, targetting small, embedded platforms where dynamic
allocation didn't make sense).

[...]
BASICs tended to vary on whether DIM statements were
executable (and dynamic) or not. Some had something like
REDIM() executable.
Every BASIC I've seen had variable length strings, which meant
dynamic allocation (and some form of garbage collection) behind
the scenes.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jun 27 '08 #74
David Thompson <da************@verizon.netwrote:
>
I don't see that a different reserved name is needed. All std-lib
routine names are already reserved with external linkage, and an
implementation can special case them, as gcc does for e.g. memcpy and
sqrt. OTOH using macro -__magic would allow you to inline plain
invocations but still do a macro-suppressed real call if you want.
If an implementation just includes an inline definition of qsort() in
<stdlib.h>, the user is allowed to redeclare qsort() in such a way that
the definition would no longer be an inline definition resulting in a
multiple definition of qsort(). Redirecting to a reserved name avoids
that problem, as does using compiler magic instead.

-Larry Jones

I stand FIRM in my belief of what's right! I REFUSE to
compromise my principles! -- Calvin
Jun 27 '08 #75

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by Narendra C. Tulpule | last post: by
6 posts views Thread by Mike O. | last post: by
3 posts views Thread by sandeep | last post: by
2 posts views Thread by Vance M. Allen | last post: by
3 posts views Thread by Brian Wotherspoon | last post: by
5 posts views Thread by Alan Little | last post: by
1 post views Thread by =?Utf-8?B?UVNJRGV2ZWxvcGVy?= | last post: by
25 posts views Thread by Abubakar | last post: by
reply views Thread by NPC403 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.