Adapting software to multiple usage patterns

[jacob navia]

One of the main arguments being advanced by the people that oppose
the standardization of a container library in C is the fact that
there are many different usage patterns for such a library, and it
would be impossible to satisfy them all.

The solution proposed overcomes this problem in an elegant way
by using a function table.

For example, let's see how that would work in lists, one of the
simplest containers.

As it stands now, the list header structure, with free list, pointer
to first, last, a size_t for the count of the items, and several
other fields could be "top heavy", and bring too much overhead if
the list is very small. For instance, if you know in advance
that you will never store more than 5 items at a time in the
list, such a "top heavy" overhead would be too much.

The solution is to write a specialization of the list
software for very small lists, where (for instance)
you just allocate all the 5 items at once when creating the
list, you eliminate the free list and the heap manager.

You write then, all the functions contained in the interface in a
NEW virtual table (say "small_list.c") and you define a
new virtual table, etc. Then, you just add to the API a
function

newSmallList(size_t element_size);

and you are done. All the code that uses

mylist->lpVtbl->Add(mylist, &data);

will STAY as before identical, without the need to change anything
in it. And one day, when you discover that the list you thought
would be small is no longer small at all, NOTHING must be changed
in the code that uses the list container, only the call to the
normal creation function.

Since all virtual tables are binary compatible (the virtual table
is always the first member) the user code doesn't even need to be
recompiled.

 

[Seebs]

The solution proposed overcomes this problem in an elegant way
by using a function table.

No, because the function table IS the failure.

That's the usage pattern that is unsuitable for a whole lot of systems,
very unlike the "spirit of C", and unlikely to get traction.

-s

 

[jacob navia]

Seebs a écrit :

No, because the function table IS the failure.

That's the usage pattern that is unsuitable for a whole lot of systems,

I do not know any. Care to explain?
All systems support function pointers (if not they wouldn't support C!)

very unlike the "spirit of C",

As I understand this "spirit of C", the objective is to keep things simple
and trust the programmer. This is a very simple container library. The code
of the list module doesn't even arrive at 3K.

The code trusts the programmer to customize the interface to his/her own needs,
making possible to change completely the data representation of a container
without changing at all the code that uses it.

Suppose you have a simple minded list package (like there are thousands) and
you see that it is a point where your program is spending a lot of time...

Using this system you can change the representation into a flexible array with
almost NO CHANGES to the user code.

Or, as I explained in the original message, you want to use a "light weight" list.

Etc.

What is important is to see that the user code is made INDEPENDENT of the
actual representation used.

and unlikely to get traction.

That remains to be seen.

 

[Seebs]

I do not know any. Care to explain?
All systems support function pointers (if not they wouldn't support C!)

Again you confuse function pointers and function tables! Your comments
in the other thread about the performance cost of virtual methods were
totally unrelated to the question of the performance cost of function
pointers.

Function tables are certainly possibly part of a well-understood C interface,
but they're usually fairly closely tied to what's being done.
"Containers" is a very unlikely level of abstraction for a lot of use cases.

Fundamentally, embedding a table of function pointers in an object is pretty
unlikely to make it into the standard.

If you did a version that didn't use any camelcase (because you'll never
sell anyone on an interface which rejects the conventions used throughout
the entire rest of the language), you'd still have the issue that, in general,
if you're writing in C, you are not writing at a level of abstraction where
switching from a flexible array to a list would make sense. They tend to
have radically different typical use cases, with different likely interfaces.

I just don't think this is going to go anywhere, because from the start, you
made a decision contrary to the usual type of decision that gets into the
standard. Make a list library and an array library, and you might see some
buy-in. I don't think "containers" have any hope, though, unless the list
and array interfaces work really, really, well.

-s

 

[Tim Rentsch]

No, because the function table IS the failure.

That's the usage pattern that is unsuitable for a whole lot of systems,
very unlike the "spirit of C", and unlikely to get traction.

What makes you say that a table of function pointers
is not in the spirit of C?

 

[jacob navia]

Tim Rentsch a écrit :

What makes you say that a table of function pointers
is not in the spirit of C?

This is the only solution if we want to keep a standard interface
but allow for multiple usage patterns. If not, we would have to
make one API for very big lists, another for not so big lists,
and another for tiny lists. That would be an impossible undertaking.

The function pointer table approach allows for many specialized
implementations within a single common interface. This preserves user code
and is flexible to satisfy many different requirements.

 

[Tim Rentsch]

I do not know any. Care to explain?
All systems support function pointers (if not they wouldn't support C!)

Again you confuse function pointers and function tables! Your comments
in the other thread about the performance cost of virtual methods were
totally unrelated to the question of the performance cost of function
pointers.

Function tables are certainly possibly part of a well-understood C interface,
but they're usually fairly closely tied to what's being done.
"Containers" is a very unlikely level of abstraction for a lot of use cases.

Fundamentally, embedding a table of function pointers in an object is pretty
unlikely to make it into the standard. [snip responses on other aspects]

For me this doesn't answer the question (or maybe the answer is just
circular, "it is the way it is because it is the way it is"). The
function qsort() has a function pointer parameter. Is it so hard to
imagine expanding that to a type that has a struct with several
function pointers in it? I agree with your comment that the interface
needs to be well-worked-out, but assuming that were the case, what
is it about aggregating several function pointers that makes you
think the response to a proposed interface with such a type
would be poor?

 

[Tim Rentsch]

Tim Rentsch a @C3{A9}crit :

This is the only solution if we want to keep a standard interface
but allow for multiple usage patterns. If not, we would have to
make one API for very big lists, another for not so big lists,
and another for tiny lists. That would be an impossible undertaking.

The function pointer table approach allows for many specialized
implementations within a single common interface. This preserves user code
and is flexible to satisfy many different requirements.

I understand the point of proposing an interface that uses
aggregates of function pointers. My question is about
Peter's comment that says (I'm paraphrasing here) such a
technique is not in the spirit of C. I'm curious to
know more exactly what he meant by that and why he said it.

 

[Seebs]

What makes you say that a table of function pointers
is not in the spirit of C?

A table of function pointers embedded in objects and with the contents of
the table specified by the library seems pretty much like C++ to me.

-s

 

[Seebs]

For me this doesn't answer the question (or maybe the answer is just
circular, "it is the way it is because it is the way it is"). The
function qsort() has a function pointer parameter. Is it so hard to
imagine expanding that to a type that has a struct with several
function pointers in it?

The point where you embed a pointer to that in the objects.

Imagine that a "string" had to be a struct with a first member which was
a pointer to the chr, str, dup, cmp, rchr, cspn functions...

That would be unlike the C library. The C library provides simpler
interfaces than that.

I agree with your comment that the interface
needs to be well-worked-out, but assuming that were the case, what
is it about aggregating several function pointers that makes you
think the response to a proposed interface with such a type
would be poor?

It seems likely to be expensive and inefficient compared to more specific
designs, and that's not how the library usually goes.

-s

 

[jacob navia]

Seebs a écrit :

The point where you embed a pointer to that in the objects.

Imagine that a "string" had to be a struct with a first member which was
a pointer to the chr, str, dup, cmp, rchr, cspn functions...

That would be unlike the C library. The C library provides simpler
interfaces than that.


It seems likely to be expensive and inefficient compared to more specific
designs, and that's not how the library usually goes.

-s

The problem with specific designs, is exactly that. They are specific.
In C, if you start with a container like a list for instance, you are
married with that container forever. Changing the container because the
list has grown too long is highly expensive in reprogramming time.
Access and usage of the container are too visible. If you want to replace
the list with a flexible array you have to rewrite all accesses to the
data. An error prone and cumbersome approach.

Exactly that problem is addressed here. A generic interface to containers
makes it easier to change them without changing all the code that uses
them.

It is precisely the lack of abstraction that dooms C to be considered as
a low level, primitive language when in fact it is just a simpler language
than others, but it has enough power to be able to describe a containers
library without any problems.

 

[Seebs]

The problem with specific designs, is exactly that. They are specific.
In C, if you start with a container like a list for instance, you are
married with that container forever. Changing the container because the
list has grown too long is highly expensive in reprogramming time.

Yes, it is.

But that's the thing -- if you don't think a list is the right structure,
you don't use one. And if you need to change it, yes, it takes time, but
the result after the change is (at least in theory) a very good match for
what you're doing, without overhead.

Access and usage of the container are too visible. If you want to replace
the list with a flexible array you have to rewrite all accesses to the
data. An error prone and cumbersome approach.

Often true -- but if a flexible array fit, you probably shouldn't have used
a list in the first place.

It is precisely the lack of abstraction that dooms C to be considered as
a low level, primitive language when in fact it is just a simpler language
than others, but it has enough power to be able to describe a containers
library without any problems.

If the use of the library is any more complex than using a single-purpose
list or array library (and it looks as though it is), then it's not going to
be used because they'll be better fits and simpler to use.

And yes, C is a low-level language these days, and I don't think it is
necessarily a good idea to try to change that. As the man says: If you want
C++, you know where to find it.

-s

 

[jacob navia]

Seebs a écrit :

Yes, it is.

But that's the thing -- if you don't think a list is the right structure,
you don't use one.

A list is the right structure when it doesn't grow too much. But you
know as well as everybody else that requirements change, and data
tends to grow, and that list that was OK for 500 elements it just
doesn't cut it with 5000: you need a better list, with better
heap management that doesn't call malloc for each element to
be added to the list. And then the list is out when you need
50000 elements. You need an array that is flexible, etc.

At each change you need to rewrite all data access!

And if you need to change it, yes, it takes time, but
the result after the change is (at least in theory) a very good match for
what you're doing, without overhead.

Until next change.

Often true -- but if a flexible array fit, you probably shouldn't have used
a list in the first place.

It depends on the application state, and whether that is critical or not.
And those conditions change.

If the use of the library is any more complex than using a single-purpose
list or array library (and it looks as though it is), then it's not going to
be used because they'll be better fits and simpler to use.

And yes, C is a low-level language these days, and I don't think it is
necessarily a good idea to try to change that. As the man says: If you want
C++, you know where to find it.

Well, here we come to the central point in this discussion. Any improvement in
C is considered harmful to C++ that should be the "better C". I do not see why
C should be destroyed because it is a simpler language. In this race to complexity
C remains very easy to learn and use. Contrary to you, I think C++ is not the
solution because precisely of its complexity.

The library I presented (and I am still developing: today I started the bitstrings)
is a proposal for a standard way to use containers what would give C a boost.

It must be understood that C and C++ are two different languages and each one has its
own development and goals. Establishing a common interface for containers is a worthwhile
goal for C.

Anyway, thanks for participating in this discussion. It is a pity that in this
group so much is written about all kinds of beginner's questions or whether "Kiki"
is an insult or not, or many other absolutely irrelevant stuff, rather than
discussing the construction of a container library.

It is an interesting development, it is precisely about C, and we could discuss in
a concrete fashion many things that we never mention but are hugely important for
software construction in C:

o Interface to the allocator: how could we abstract it? (malloc/gc_malloc/alloca)
o Software specialization and subclassing (This was the original theme I wanted to discuss
with "Adapting software to multiple usage patterns")
o Error handling and software interrupts.

Etc. The container library give us an opportunity to discuss all this stuff but
not many people seem interested in C in comp.lang.c

 

[jacob navia]

Gareth Owen a écrit :

All true and valid. My problem with your container libray is that you
are, in essence reinventing a subset of the C++ container library.
Yes.

Only without language support (which may well exist in your compiler)
you are left with an explicit vtable, and comparatively ugly syntax.

Yes. The syntax is ugly (can be better with some macros, but I would prefer
not to).

And, because the vtable is explicit, and users are encouraged to alter
it (to create polymorphic behaviour), the compiler is likely to be
able to make fewer.

I suppose you meant "fewer optimizations". Yes, but it has already
more or less 20-30% more speed than the C++ containers and uses
more or less the same memory for huge lists of 50 million items.

With specialization it can have more speed than C++ can ever attain.

It seems to be (though I'm not terribly familiar with the
standardisation process) that the time for standard C container
library was 20+ years ago, where it might have competed for mindshare
with C++ containers, and the C++ compiler writers were still shaking
bugs out of their template code.

The time is right now, when the C++ people start realizing that
a simpler language is not a mistake but an advantage. Ask any C++
programmer, the complexity of that language is over their heads.

But I do not want at all to start a flame war against C++.
What I want is the C equivalent: simpler, faster, that can be used
widely and make C a better language.

Now, anyone who wants containers and wants to use manipulate using a
language that is close enough to C to leverage their skill, is using
C++ containers.

Obviously since there is no C container library

They're standardised, they're at least as flexible as
your containers (you can replace the default memory allocator, much as
you've proposed), they're on a colossal number of platforms, they're
logical const-ness is supported by the language (as opposed to your
"read-only" toggle) and you get all the things in <algorithm>
(std::transform, max_element etc), well defined copying semantics
(std::swap specialisation) etc etc etc.. for free.

You mention many things:
"They are on a colossal number of platforms".
True, but C too is in a colossal number of platforms.

> they're
> logical const-ness is supported by the language (as opposed to your
> "read-only" toggle)

True, but my toggle can be changed dynamically during the runtime,
i.e. you can take a read/write list, make it read only before
passing it to some other function, and be sure that it wont change.
Then, you eliminate the read only property and you can change it as you
wish. Doing it at runtime has a small cost but it is much more
flexible. And that can't be done in C++.

And yes, "algorithm" part is surely not going to be ported to C...
most people I know using C++ never use that part of the STL and just have
a blank stare when I mention it... Too complex!

Oh, and if you're
willing to use iterators (whose syntax can be, I grant you, also
hideously ugly), you can swap container types with relative ease.

Sure. You see, why then can't we do it in C? Why only in C++?
Let's do it in C because is much SIMPLER since everything is open
for you to examine and modify. The vtable is not a mystery that
only compiler people know about. It is there, open for you to hack
as you wish.

Regardless of the merits of your library, in terms of standardisation,
that ship has long sailed.

That would mean that there is no future for C. And, as I have stated many
times, I do not believe that. A simpler language is better than a complex
one.

Why?

Because, contrary to the exponential growth of hardware, brain hardware
is kind of FIXED, and there is a much smaller limit to the amount of
computer language trivia that your brain is able to swallow without
indigestion.

That ship has long sailed and C++ has grown beyond what a human being
can understand. Not even the creator of the language can introduce a
modification now, because the complexity of C++ is beyond what he
himself can manage. After several years working on "concepts", he was
forced to accept that he can't do it... The "concepts" debacle show
us that complexity grows without limit and eventually it makes the
whole language impossible to use correctly.

What I want is to go on developing C. You can make a positive contribution
here, if you wish. You can propose things, and I am not a zealot that
will start fighting language wars. I have to use C++ at work, and
that is why I am more and more convinced that the future is C and
not C++.

At the same time I see many things in C++ that are very good ideas
and I have tried to bring them to C. Software construction should be
about that: software construction and not "group feelings"...

Thanks for your contribution.

 

[Mark Storkamp]

Regardless of the merits of your library, in terms of standardisation,
that ship has long sailed.

That would mean that there is no future for C. And, as I have stated many
times, I do not believe that. A simpler language is better than a complex
one.[/QUOTE]

I would like to know how Gareth's statement would imply your conclusion.
Do you believe that for C to have a future it must continually evolve
and expand? And if so, for how long. i.e. will it ever be complete, and
if it ever can be, then how do we know that it isn't now? I'm not trying
to be facetious, I think those questions apply in many other areas (e.g.
law).

 

[jacob navia]

Mark Storkamp a écrit :

Regardless of the merits of your library, in terms of standardisation,
that ship has long sailed.

That would mean that there is no future for C. And, as I have stated many
times, I do not believe that. A simpler language is better than a complex
one.

I would like to know how Gareth's statement would imply your conclusion.
Do you believe that for C to have a future it must continually evolve
and expand?[/QUOTE]


To evolve, yes. For instance this proposal about a container library
is an evolution that doesn't add any new complexity to the language.

C remains exactly as it was before but we would have a common interface
for using lists, hash tables, bitstrings and other containers that would
allow that most programmers would not need to reinvent this thing
over and over when they program in C.

Expand?

Careful. I do not want to reinvent C++.

And if so, for how long. i.e. will it ever be complete, and
if it ever can be, then how do we know that it isn't now?

Nothing is ever "complete", unless it is dead. All languages evolve
with time, some parts go obsolete, some other parts are introduced.

That is life. Always changing.

I'm not trying
to be facetious, I think those questions apply in many other areas (e.g.
law).

The answer is the same. When is the body of law finished?

When can we say:

We have all the laws we will ever need?

Here is the same.

Many people have taken the attitude that C is fixed forever frozen in
C 1989. You will find here many people that reject even the C99 standard.

I disagree, and I believe that C is a good all purpose programming language.
It needs to have a better library and one of the most important things
that is missing is a common interface for containers.

Thanks for your contribution.

 

[Tim Rentsch]

The point where you embed a pointer to that in the objects.

Imagine that a "string" had to be a struct with a first member which was
a pointer to the chr, str, dup, cmp, rchr, cspn functions...

That would be unlike the C library. The C library provides simpler
interfaces than that.

I agree that it's unlike the C of K&R times. And to some
extent it's unlike C as it is now (meaning C99), however the
difference now is smaller; for example, type-generic macros
never would have made it into C in earlier times. There's a
good chance that C1X will have language support for threads.
So I'm not sure I'd agree with your assessment if we consider
"the spirit of C" to be a slowly evolving point rather than
a fixed point.

It seems likely to be expensive and inefficient compared to more specific
designs, and that's not how the library usually goes.

Certainly we would expect generic code to be slower than
code specific to a particular data structure. Still,
sometimes it's useful or necessary to provide a generic
interface -- qsort() is much more valuable because it
allows array of any element type to be sorted. And
there's no reason the C library can't support type-generic
interfaces as well as type-specific ones. At some level
it's necessary to parameterize a container-like library
by the functions that access the data structures, because
different people will want to make different decisions
about how the various data structures are represented
(witness the recent thread about null-terminated strings
versus length-prefixed strings). ISTM that a type-generic
container-like interface is valuable or necessary for the
same sort of reasons that a type-generic qsort() interface is;
although, I have to admit that doing a good job for containers
is much harder than it is for qsort.

IMO the most important conclusion to come out of this
discussion is a point you've basically made already,
which is for such a proposal to get some buy-in it
must be well worked out. So I definitely agree on
that aspect of what (I think) you're saying.

 

[Flash Gordon]

Seebs a écrit :

A list is the right structure when it doesn't grow too much.

Only if your access pattern is list like.

But you
know as well as everybody else that requirements change, and data
tends to grow, and that list that was OK for 500 elements it just
doesn't cut it with 5000: you need a better list, with better
heap management that doesn't call malloc for each element to
be added to the list.

It's not necessarily the size, it might be frequency of addition. If the
program runs for a year adding 100 elements to the list per day then the
overhead of malloc might not be significant.

And then the list is out when you need
50000 elements. You need an array that is flexible, etc.

Hmm. Inserting an element half way through could be problematic.

At each change you need to rewrite all data access!

I've not had any data usage change by that much. I would consider it to
be a sign that it was not well specified in the first place.

Until next change.

At which you need maximum possible speed and don't want the overhead of
indirect calls.

It depends on the application state, and whether that is critical or not.
And those conditions change.

I've never had them change that much. If it might happen that I would
possibly design a suitable flexible interface.

Well, here we come to the central point in this discussion. Any
improvement in
C is considered harmful to C++ that should be the "better C".

No it isn't. It just happens that a number of improvements you have
suggested have not been considered appropriate by a lot of people.

I happen to consider the addition of threading support to the C standard
to be interesting.

I do not
see why
C should be destroyed because it is a simpler language.

It isn't.

In this race to
complexity
C remains very easy to learn and use. Contrary to you, I think C++ is
not the
solution because precisely of its complexity.

I'm not fond of what I've seen of C++, so I would probably pick one of
the other many languages out there if I wanted the kinds of features you
are proposing.

The library I presented (and I am still developing: today I started the
bitstrings)
is a proposal for a standard way to use containers what would give C a
boost.

Since it can be implemented in standard C you can release it under a
suitable license and people can use it if they want. However, I don't
like the look of the way your interface is used, so I'm unlikely to use it.

It is an interesting development, it is precisely about C, and we could
discuss in
a concrete fashion many things that we never mention but are hugely
important for
software construction in C:

You seem to think that discussing something means agreeing with you.

o Interface to the allocator: how could we abstract it?
(malloc/gc_malloc/alloca)

For my usage, malloc is abstract enough. I don't need GC, and have never
seen a need for alloca (I don't have a need for flexible arrays either).

o Software specialization and subclassing (This was the original theme I
wanted to discuss
with "Adapting software to multiple usage patterns")

I can't say I've a need for that, not in the was you are doing it. I do
have stuff with indirection through function pointers, but that is not
working in the same was as your interface.

o Error handling and software interrupts.

Those are different topics.

Etc. The container library give us an opportunity to discuss all this
stuff but
not many people seem interested in C in comp.lang.c

Plenty of people are interested in C, just not in your container library.

 

[jacob navia]

Gareth Owen a écrit :

Yes. But most people who use C++ use a a relatively simple subset of
it

This is an interesting point that I hear very often. C++ is of course
too much for a single person so the language is cut by people in
smaller pieces that can be understood.

Well, here is a smaller subset of the STL that is written in C and
that you can use as you wish in C. (Or in C++ for that matter)

I meant "rather than roll their own C containers". The point is a
skilled C programmer can program in "C plus containers" already.
That's one of the viable, relatively simple, almost-subsets of C++ I
refer to above.

But precisely my objective is that once this library is working
you do not need to "roll you own". If you have the interface, and
the source code readily available with no license whatsoever
you can adapt it in thousand ways without a lot of effort to
customize it to do what you want. This is a technologically
simpler approach but, an approach that can work very well.

But your libray will need porting / creating to those platforms.
Past history suggests this will be less trivial than first thought.

Until now I have used ONLY C89. Not even C99. I do not see where
I would need anything else.

But what happens if I pass a readonly container to a routine that
expects a mutable container. In C++ const-ness prevents this
happening.

Yes, and C++ will go on existing, and you will go on using it. In C++
you are protected by a huge and complex compiler from many mistakes.
In C you aren't, you are using a simpler language where many things
are possible but that does NOT protect you in any way from your
own mistakes.

Both languages can coexist, and in C you can do things that in C++ you
can't and in C++ you can do things that C can't.

The dark corners are undeniably complex. I'd argue that

vector<double> vec;
/* ... */
double mean = accumulate(vec.begin(),vec.end(),0.0) / vec.size();

is as clear in intent as its C equivalent.

Sure, that looks nice. But is it very different from

Vector *dv;
// Add elements to the vector
double mean,sum=0; int i;
for (i=0; i<dv->count; i++) {
sum += *(double *)dv->lpVtbl->GetElement(dv,i);
}
mean = sum/i;

Sure, that doesn't look as pretty as C++. But it does the same.
and, let's get real, is as clear as C++.

We can do it in C. Of course we can. But people are *already* doing
it in C++, and that inertia is going to be impossible to shift.

But I do not want to disturb all those programmers that use C++. If they
are happy please go on using C++. I am only proposing that in C we
do not need to reprogram a list package for the THOUSANDTH time!

I don't consider that as great an advantage as you do When doing
things with containers, I consider it a positive boon to have the gory
details hidden from me.

Sure, in that case you can use the macros:
for (i=0; GetCountVector(dv); i++) {
sum += GetElementVector(dv,i,double);
}
Much better, but it uses name space in YOUR name space. If you
do not mind, the library will come with all those macros predefined.

#ifdef __INCLUDE_MACROS__
#define GetElementVector(vec,idx,type) *(type *)vec->lpVtbl->GetElement(vec,idx)
#endif

No. It merely mean the future of C is the present of C. A
widely-available niche language with good facilities for bare metal
programming, wide popularity in embedded software, and a partial,
mediocre standard library that displays many warts (if not outright
deformities) due to lessons learned long after its standardisation.

But why should we keep those warts forever dam it?

Why do the C++ people always start complaining when somebody starts
trying to eliminate those warts?

Why should C be always considered as the land of the warts? All C++
books start with telling people how bad C is and how much better
C++ is. And each time that somebody starts trying to remedy that
situation they tell "C is like that" or "C can't be changed", etc.

So C without containers is better than C with containers. C
programmers (hell, all programmers) want their language to be as
simple as possible but no simpler. The problem is that

But the container library doesn't modify anything in the C language
as such, in the same way that a network library doesn't modify the language
either. And the language is simpler than before because all the
different list/hash tables/whatever are done using the same
uniform interface.

That wasn't the result I saw using gcc on your original postings.

Since then I posted about the new heap manager. This reduced memory
consumption by half, and increased speed by a factor of 30-40%.
And it is just a very simple heap manager. Much better heap managers
can be done. But that is not even important. What is important is
the interface.

And, given that the C++ implementation uses almost an identical
implementation (vtables), I'll need to see some concrete evidence.


With a custom heap manager? But then the C++ mavens will tune their
allocator, and we'll be back to near-equivalence.

Of course. At the end both libraries will have the same speed.
You can buy a Rolls Royce, or you can buy a small car. C is
simpler than C++, easier to learn and to master. C++ is the Rolls,
C is the small car and both go at the same speed in the CPU/RAM
traffic jams.

 

[jacob navia]

Gareth Owen a écrit :

It's interesting you single that out. I use one feature of C99 ever
day in my programming, and its one with a bearing on another interest
of yours. The 'restrict' keyword enables gcc to automatically
vectorise dot and matrix products using x86 SSE/SIMD instructions.

Well, I have spent the last 10 years writing a C99 compilation system.
I am surely not against C99!

I was just telling you about the attitude of some people here.