The C Containers Library

[jacob navia]

Le 04/08/12 21:17, Ike Naar a écrit :

If the type of the header structure were known to the program,
there would be a simpler solution:

Yes, but that would break the complete separation between the
implementation and the specifications. As it is now, a complete change
in the inner structure of the containers doesn't need even a
recompilation in user code since all the data types are completely
hidden. This is a very strong requirement of the libray and I have done
everything to ensure that all containers data types are compeletly
opaque to user code.

This is much stronger "private" definition than in C++ where you have
the possibility of accessing the inner structure of the container
because they are specified in the stl headers. Here you do not have
any information about the internals.

I will provide with the library a small program that prints all those
sizes building a header file:

#include <containers.h>
int main (void)
{
printf("#define CCL_iList_SIZE\t%d\n",iList.Sizeof(NULL));
printf("#define CCL_iDictionary_SIZE\t%d\n",
iDictionary.Sizeof(NULL));
printf("#define CCL_iVector_SIZE\t%d\n",iVector.Sizeof(NULL));
// ...
}

This file is stable between releases of the library but must be rebuilt
at each release and client code that uses it must be rebuilt.

 

[Ike Naar]

Le 04/08/12 21:17, Ike Naar a ?crit :

Yes, but that would break the complete separation between the
implementation and the specifications. As it is now, a complete change
in the inner structure of the containers doesn't need even a
recompilation in user code since all the data types are completely
hidden. This is a very strong requirement of the libray and I have done
everything to ensure that all containers data types are compeletly
opaque to user code.

The data types are not *completely* hidden. For instance, the trick
with the pointer-to-void exposes the knowledge that the alignment of the
header structure is not stricter that the alignment of a pointer to void.

"Hidden" assumption like these make the code fragile. The user may
think it is safe not to recompile, when it may in fact be dangerous.

If there are any compile-time dependencies between user code and
the library, it is safer to make them explicit than to pretend
they're not there. Doing unnecessary compilations may be bad, but
not doing necessary compilations is far worse.

 

[Ansel]

he's probably unhappy they didn't accept the proposal to add Klingon.
I'm with you I think he's just randomly moaning and can't actually
point out any serious problem.

Wow. I half-jokingly admonished RM for childish goading and then what do you
two do? That very thing!

Seriously, search the web for deficiencies of Unicode and you will find
some. I don't see how Unicode is "on-topic" in this NG, and I *know* y'all
have "topic police" in here.

 

[Ansel]

In all my life as a programmer I have tried to keep things SIMPLE.
That is why I like (and use) the C language. C is a language that
can be understood in full by a person.

C: such utter simplicity, that it is simply incorrect (i.e., violates the
principle of KISS-but-not-simpler-than-required).
C++: such utter complexity that it leads to incorrect code.

Pick your poison I guess.

 

[Ansel]

In informal contexts like this I'd say it's perfectly acceptable to
say "Bjarne Stroustrup", but if you're going to give him a title,
give him the right one. He has a PhD from Cambridge, and holds the
College of Engineering Chair in Computer Science at Texas A&M
University. Using "Mr" could be misconstrued.

Credentials vs. substance. PhD: one who followed the path of knowing more
and more about less and less? I do not accept credentials as proof of
ability. How could one escape the awful "mind think" by being sheltered in
institutional processes all the time?

Food for thought.

 

[Ansel]

The data types are not *completely* hidden. For instance, the trick
with the pointer-to-void exposes the knowledge that the alignment of
the header structure is not stricter that the alignment of a pointer
to void.

"Hidden" assumption like these make the code fragile. The user may
think it is safe not to recompile, when it may in fact be dangerous.

If there are any compile-time dependencies between user code and
the library, it is safer to make them explicit than to pretend
they're not there. Doing unnecessary compilations may be bad, but
not doing necessary compilations is far worse.

I skim the gurus' comments and say to myself, "well, if the gurus have a
hard time with it, or if it requires a guru to use it, then what has been
accomplished?". (That, to you JN. Rebuttle please.)

 

[Anders Wegge Keller]

Seriously, search the web for deficiencies of Unicode and you will
find some. I don't see how Unicode is "on-topic" in this NG, and I
*know* y'all have "topic police" in here.

I fail to find anyone claiming that the unicode specification is
ambigous. UC is on-topic in the sense that you brought it up as an
example of an incomplete specification document, that you for some
reason found timely to compare to the C standard. I'm trying to figure
out why that is.

You made a bogus claim in the first place. The easiest way out for
you, is to admit that it was totallty baseless. The other way out, is
to actually prove that you claim had merit. Your feeble excuses are
void, since we would never had this debate in the first place, hadn't
you started it.

 

[Ansel]

I fail to find anyone claiming that the unicode specification is
ambigous.

OK. Maybe I just don't like it then and your *cause* of warring for it,
disinterests me.

UC
"UC"?

is on-topic in the sense that you brought it up as an
example of an incomplete specification document,

I did not say that. If you want to be a lawyer, you need to get the facts
right.

that you for some
reason found timely to compare to the C standard. I'm trying to figure
out why that is.

I "find" you defensive. What are you accusing me of exactly?

You made a bogus claim in the first place.

Do tell. Are you calling me a liar?

The easiest way out for
you

Did you really type that?

is to admit

Or else the rubber hose? Are you planning?

that it was totallty baseless. The other way out, is
to actually prove that you claim had merit.

What is your name, that you give me ultimatum? (rhetorical, I don't care to
know).

Your feeble excuses are
void, since we would never had this debate in the first place, hadn't
you started it.

You are testing my convictions?

 

[Anders Wegge Keller]

Anders Wegge Keller wrote:

OK. Maybe I just don't like it then and your *cause* of warring for
it, disinterests me.

That's entirely up to you.

"UC"?

Make an educated guess.

I did not say that. If you want to be a lawyer, you need to get the
facts right.

The standard is intended to supply an unambiguous defintion of
the language.

You mean, like the Unicode specification does? And the USA laws
do? You kinda lost me on "intent". Please expound.

The unquoted text is yours.

I "find" you defensive. What are you accusing me of exactly?

Stating fiction as fact, and when called, trying to weasel out of it.

Do tell. Are you calling me a liar?

No, your attempts to talk yourself out what you said earlier are.

What is your name, that you give me ultimatum? (rhetorical, I don't
care to know).

You are totally free to ignore me, if you don't like what I
write. Likewise, I'm totally free to continue questioning the quality
of your opinions, if I feel like doing so.

You are testing my convictions?

No, I'm just stating a fact. Someone has to do, and since you
declined on that part, that onus falls upon me.

 

[Ansel]

That's entirely up to you.


Make an educated guess.

Oh, a wanker. Your mom is interested?

You mean, like the Unicode specification does? And the USA laws
do? You kinda lost me on "intent". Please expound.

The unquoted text is yours.

I reject your war.

Stating fiction as fact, and when called, trying to weasel out of it.

And wars are armed by adolescent males why? What is "war"?

No, your attempts to talk yourself out what you said earlier are.

So go to Canada? I cannot help you with personal dillema.

You are totally free to ignore me,

That is a lie.

if you don't like what I
write.

Isn't that the rub.

Likewise, I'm totally free to continue questioning the quality
of your opinions, if I feel like doing so.

Not good. Freedom to rape is bad. Freedom is good. But "America" is still an
abstraction.

No, I'm just stating a fact.

State that "fact" please,

Someone has to do, and since you
declined on that part, that onus falls upon me.

I assure you that I have nothing to do with your "onus".

 

[Rui Maciel]

Le 03/08/12 23:31, Rui Maciel a écrit :

I would not say that c++ is in "the decline" but there are some
developments that are noteworthy.

1) After several YEARS of work, the creator of the language declares
that he is unable to add a new feature to the language.

This means that C++ has become such a complex software construct that
it is impossible for its creator (Mr Bjarne Stroustrup) to fully
understand the consequences of a language enhancement. This shows
us the level of complexity reached by C++.

Could you provide a source for that quote? Stroustrup, in his FAQ, doesn't
refer to that. In fact, there is a section that covers the addition of new
features to C++, and the only criticism that he makes is that it isn't a
good idea to add "every feature that someone considers a good idea", and
that it isn't easy to remove older features from C++.

http://www.stroustrup.com/C++11FAQ.html#what-features

2) Undeterred by this fact, the new standard piles up yet another thick
software layer into the already brittle edifice. Lambdas, and other
esoteric constructs add more complexity as if increasing the
number of language constructs and their unforeseen interactions
was a good thing!

What's wrong with lambdas? All they do is essentially provide syntactic
sugar to either define a function object or a simple function.

http://www.stroustrup.com/C++11FAQ.html#lambda

Personally, I find lambdas to be an invaluable addition to the language
just for a single reason: they'll replace function-like macros in a
significant number of applications.

4) All C++ programmers (besides Bjarne) use a portion of the huge
language since it is not possible to fit every detail of that into a
human brain.

This means that only the overlapping portions of the language can be
understood by all of them, and a proliferation of "C++ subsets" starts
that makes communication between programmers more difficult.

I don't see how this can be seen as a problem. For example, just because we
have a set of tools in our toolbelt it doesn't mean we should be forced to
use every single one of them whenever we need to pick up a screw driver.

In addition, I don't see there is a problem if we don't need to use a
feature provided by the language. For example, function pointers aren't
necessarily present in every C program, and not using them isn't exactly a
problem. So, why should it be a problem if, with some other programming
language, a project doesn't use a specific language feature?

In all my life as a programmer I have tried to keep things SIMPLE.
That is why I like (and use) the C language. C is a language that
can be understood in full by a person.

Yes, I know. You will tell me that the complexity is in the language
instead of in every program that uses the language and that a complex
language simplifies programs. Yes, I do KNOW that.

But there is a point of diminishing returns where you add complexity to
the language trying to be all things to everyone and you end up with
being a complexity monster for everyone.

I know that you like C++ Rui, and I hope you do not feel personally
attacked since I am talking about a computer (machine) language.

We tend to get attached to languages because of other philosophical
reasons. For instance the fact that I like small and simple computer
languages comes from my beliefs that "small is beautiful" from my youth,
and many other things that are more or less completely irrelevant here.

Let's try to put all that baggage aside and discuss in a rational
manner.

I didn't felt personally attacked. Far from it. And if, for some reason, I
was forced to choose which language, between C and C++, would be removed
from the world, I would gladly keep C around instead of C++.

Yet, just because someone prefers to use C instead of some other language it
doesn't grant them the right to throw around absurd claims, even if those
claims are posted to comp.lang.c. No matter how someone prefers C over C++,
claims such as "the STL made the syntax for just declaring an array and
stepping through it too cumbersome" are just blatantly wrong and completely
detached from reality. There are plenty of issues that affect each
language, and we don't help anyone or anything if the only criticism we are
able to muster comes in the form of made up nonsense.


Rui Maciel

 

[jacob navia]

Le 07/08/12 11:24, Rui Maciel a écrit :

What's wrong with lambdas? All they do is essentially provide syntactic
sugar to either define a function object or a simple function.

There is nothing wrong with lambdas as such. What is wrong is trying to
add yet a layer of sugar to a cake that is 80% sugar already!

Lambdas can be replaced by function pointers or classes. Classes retain
also state during calls (using some private variable) and they are
already well tested. Function pointers also.

Yes, lambdas (anonymous functions) are handy, but the problem is that
they add MORE complexity to an already extremely complex product.

Each feature in isolation looks reasonable and justified. When you
add them up, however, problems arise.

 

[Ben Bacarisse]

Le 07/08/12 11:24, Rui Maciel a écrit :

There is nothing wrong with lambdas as such. What is wrong is trying
to add yet a layer of sugar to a cake that is 80% sugar already!

That's a catchy phrase, but adding one metaphor to another does not
always make sense. Syntax is called "sugar" when it improves things --
in this case by making a construct simpler. It not obviously true that
adding simplifying syntax is wrong, even when you have a lot of it. I
think the case needs be made, feature by feature, not by saying "we've
got too much sugar already".

Lambdas can be replaced by function pointers or classes. Classes
retain also state during calls (using some private variable) and they
are
already well tested. Function pointers also.

Yes, lambdas (anonymous functions) are handy, but the problem is that
they add MORE complexity to an already extremely complex product.

C++'s lambdas are not closures (I am sure you know this) so they don't
add any new concepts. They do, however, greatly simplify what you'd
have to write in their place. In my view, they pay their way.

Each feature in isolation looks reasonable and justified. When you
add them up, however, problems arise.

That depends on how they are organised. When language features are
piled on top of each other, you can get great complexity. Mathematics
is an example of this. Many, many, layers are needed to understand
something like "a Hamel basis of an infinite-dimensional Banach space is
uncountable" because the notions involved all build on top of other
notions that are themselves far from basic. C++ is not like that. The
features don't, in general, build one on top of one another. It is
broad and shallow rather than narrow and deep. Yes, there is a lot to
learn, but you don't really need to learn it all. Just as I'd use a
broad library like Java's with a reference manual next to me, I would
not commit to memory every aspect of C++. You need to know what's
there, but you don't need to know all the details.

I'm not denying that C is much simpler than C++; it is; much, much,
simpler, but that simplicity comes at a price which is not always worth
paying. It would be, if C++ were unmanageable, but I don't feel it is.

I would be great to be able to start again. Inside modern C++ there is
a great programming language struggling to get out, but that language
would never have become popular, and the C++ we have now can't be
trimmed back without breaking it.

 

[Nick Keighley]

Could you provide a source for that quote?

I assume Jacob is referring to "Concepts". And it isn't really
a quote but an interpretation of what happened. This is
Bjarne Stroustrup on the subject

http://www.devx.com/cplus/Article/42448/0/page/1

it appear they *did* underestimate the difficulty of the task.
But design's like that; you don't know how how hard it
is until you've done it.

Stroustrup, in his FAQ, doesn't
refer to that.  In fact, there is a section that covers the addition ofnew
features to C++, and the only criticism that he makes is that it isn't a
good idea to add "every feature that someone considers a good idea", and
that it isn't easy to remove older features from C++.

http://www.stroustrup.com/C++11FAQ.html#what-features

that's a list of what they added. Not what they declined to add.

I don't see how this can be seen as a problem.  For example, just because we
have a set of tools in our toolbelt it doesn't mean we should be forced to
use every single one of them whenever we need to pick up a screw driver.

yes but if I read someone else's code I have to understand all the
features they use. And their subset may not match my subset. (actually
it's usually the other way around I have to be careful with certain
features to avoid baffling other people)

In addition, I don't see there is a problem if we don't need to use a
feature provided by the language.  For example, function pointers aren't
necessarily present in every C program, and not using them isn't exactly a
problem.  So, why should it be a problem if, with some other programming
language, a project doesn't use a specific language feature?

C++ is a much larger language. I think most people agree on what the
commonly used core of C is. Function pointers are good example of
something that some people may find esoteric.

With C++ some people avoid exceptions or templates or the STL.
You may not consider it sane but it happens.

[...] just because someone prefers to use C instead of some other language it
doesn't grant them the right to throw around absurd claims, even if those
claims are posted to comp.lang.c.  No matter how someone prefers C overC++,
claims such as "the STL made the syntax for just declaring an array and
stepping through it too cumbersome" are just blatantly wrong and completely
detached from reality.

I was wondering where that came from. Because if you really love
arrays
C++ lets you use them. Does he mean the initialisation of a
std::vector?

Stepping through an array (or a vector) doesn't have to be cumbersome.
In fact in C++11 (or whatever) I believe its quit elegant.

 There are plenty of issues that affect each
language, and we don't help anyone or anything if the only criticism we are
able to muster comes in the form of made up nonsense.

the Concepts thing was a bit of a disaster and template Meta
Programming
scares the crap out of me.

I love RAII (automatic cleanup) and the STL containers. If I have to
debug one more half-arsed implementaion of a linked list...

 

[jacob navia]

Le 08/08/12 11:26, Nick Keighley a écrit :

I assume Jacob is referring to "Concepts". And it isn't really
a quote but an interpretation of what happened. This is
Bjarne Stroustrup on the subject

You are right. Concepts are needed in C++, because if not there is no
way to build templates with argument checking. There was a discussion
about that in the C++ standardization committee in France, and people
agreed that concepts were needed. Because if they don't exist things are
proposed like "static if" that try to test template arguments for validity.

But after years of work by brilliant people they couldn't. And I am not
blaming them. The complexities of adding such a feature are just staggering.

Personally I think that there is another way. Compile time functions
should replace templates. But that is another discussion.

 

[Tim Rentsch]

Le 07/08/12 11:24, Rui Maciel a @C3{A9}crit :

Lambdas can be replaced by function pointers or classes.
Classes retain also state during calls (using some private
variable) and they are already well tested. Function pointers
also.

Lambdas have another important property, specifically being able
to reference variables outside of the lambda but local to the
calling environment (ie, function/method body) where the lambda
is defined/created. Neither classes nor function pointers do
this. It can be simulated, clumsily, with classes, and still
more clumsily using function pointers. But, why stop there? All
this can be simulated without lambdas, classes, or even function
pointers, using just regular pointers, structs, and functions.
Personally, I prefer the convenience of closures (which I have
used in various different contexts) or (probably) lambdas, which
I can only speculate about since I haven't used C++ lambdas
specifically.

Incidentally, for C-like languages, it is possible to implement a
lambda-like construct in such a way that they are interchangeable
with function pointers. That is, a function being called couldn't
tell whether it is getting a pointer-to-function or a closure (or
lambda) instance as one of its pointer-to-function parameters (and
ditto for variables). The D language does this. So rather than
complexifying a language, this unification results (to my way of
thinking, anyway) in a simplification. Granted, the language has
gotten somewhat bigger, but programs get smaller - there is a
significant power in being able to put together easily a local
function body and send the function off somewhere to get some
work done in a generalized context.

 

[Tim Rentsch]

C++'s lambdas are not closures (I am sure you know this) so
they don't add any new concepts.

Forgive my ignorance - how are lambdas different from closures?
I know a lot about closures, but only a little about C++ lambdas.

They do, however, greatly simplify what you'd have to write in
their place. In my view, they pay their way.

Based on the little I already know about them, I'm inclined
to agree.

 

[Ben Bacarisse]

Forgive my ignorance - how are lambdas different from closures?
I know a lot about closures, but only a little about C++ lambdas.

Then I'm sure the difference is just one of interpreting the term.

The main point, for me, is that C++ lambdas are not simply a piece of
code that can refer to the environment being "closed over". They don't
treat the environment in a uniform way as a closure would. For example:

struct S { int i; };
enum { name = 42; };
int i;
auto l = []{ S s = {name}; };

The lambda body can refer to 'S' and 'name' (and, incidentally, all
'global' names like functions and file-scope object names) but it can't
refer to 'i' unless we specify either a default or an explicit capture
mode (by reference or by copy).

C++'s "capture by copying" is very useful, but it's not at all what a
"plain" closure does (thought you can get the same effect easily enough
using closures). Capture by reference is very close, except for two
things: the non-uniform treatment of the environment I've already
mentioned, and the fact that the capture has no effect on the lifetime
of the object referenced.

Now this last point could be argued because C++ is simply not that sort
of language. It has no garbage collection, so there is no solution but
to treat captured references like any other, but it limits what you can
do in non-trivial ways.

<snip>

 

[Tim Rentsch]

Forgive my ignorance - how are lambdas different from closures?
I know a lot about closures, but only a little about C++ lambdas.

Then I'm sure the difference is just one of interpreting the term.

The main point, for me, is that C++ lambdas are not simply a piece of
code that can refer to the environment being "closed over". They don't
treat the environment in a uniform way as a closure would. For example:

struct S { int i; };
enum { name = 42; };
int i;
auto l = []{ S s = {name}; };

The lambda body can refer to 'S' and 'name' (and, incidentally, all
'global' names like functions and file-scope object names) but it can't
refer to 'i' unless we specify either a default or an explicit capture
mode (by reference or by copy).

C++'s "capture by copying" is very useful, but it's not at all what a
"plain" closure does (thought you can get the same effect easily enough
using closures). Capture by reference is very close, except for two
things: the non-uniform treatment of the environment I've already
mentioned,

This part is what I'm confused about. If there's a default
by-reference capture mode, how is the treatment of the
environment non-uniform? My assumption is that giving
a default capture mode of reference affects all variables
in the outer environment the same way (obviously types and
enum's are different, but that doesn't matter since they
can't change).

and the fact that the capture has no effect on the lifetime
of the object referenced. [snip elaboration]

I get that, this difference is the one I was expecting,
and was wondering what other differences there might be.

 

[Ben Bacarisse]

C++'s lambdas are not closures (I am sure you know this) so
they don't add any new concepts.

Forgive my ignorance - how are lambdas different from closures?
I know a lot about closures, but only a little about C++ lambdas.

Then I'm sure the difference is just one of interpreting the term.

The main point, for me, is that C++ lambdas are not simply a piece of
code that can refer to the environment being "closed over". They don't
treat the environment in a uniform way as a closure would. For example:

struct S { int i; };
enum { name = 42; };
int i;
auto l = []{ S s = {name}; };

The lambda body can refer to 'S' and 'name' (and, incidentally, all
'global' names like functions and file-scope object names) but it can't
refer to 'i' unless we specify either a default or an explicit capture
mode (by reference or by copy).

C++'s "capture by copying" is very useful, but it's not at all what a
"plain" closure does (thought you can get the same effect easily enough
using closures). Capture by reference is very close, except for two
things: the non-uniform treatment of the environment I've already
mentioned,

This part is what I'm confused about. If there's a default
by-reference capture mode, how is the treatment of the
environment non-uniform? My assumption is that giving
a default capture mode of reference affects all variables
in the outer environment the same way (obviously types and
enum's are different, but that doesn't matter since they
can't change).

The term "the outer environment" needs some clarification. A lambda has
access to (and can change) a variable declared at file scope even when
you have no capturing specified:

int i = 0;
void f()
{
int j; // for later...
auto l = []{i = 42;};
l();
}

Calling f() changes i. The capturing only applies to automatic objects.

When you say "if there's a default by-reference capture mode" do you
mean that you are only really asking about lambdas that use that mode
because it's not a default mode for all lambdas? The one above, for
example, can't access j. Changing [] to [&] allows it access to j, but
has no effect on it's access to i (so far as I know). Using [=] has the
effect of making a read-only copy of j, but leaves i writable.

If you know what's going on under the hood, it all makes a reasonable
amount of sense, but it's probably a little odd-looking if you don't.
I'd find it fiddly to explain to someone, whereas the idea of a closure
is really very straight forward.

and the fact that the capture has no effect on the lifetime
of the object referenced. [snip elaboration]

I get that, this difference is the one I was expecting,
and was wondering what other differences there might be.

It's a mixed bag, really. The form [](args){body} is not really a
closure at all (it's just an anonymous function pointer) but
[&](args}{body} is pretty much indistinguishable from a closure. The
[=](args){body} form is a curious thing that's, well, curious (but
useful).