Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > The C Containers Library

Reply
Thread Tools

The C Containers Library

 
 
jacob navia
Guest
Posts: n/a
 
      08-04-2012
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.




 
Reply With Quote
 
 
 
 
Ike Naar
Guest
Posts: n/a
 
      08-04-2012
On 2012-08-04, jacob navia <(E-Mail Removed)> wrote:
> 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.


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.
 
Reply With Quote
 
 
 
 
Ansel
Guest
Posts: n/a
 
      08-05-2012
Nick Keighley wrote:
> On Aug 4, 5:32 am, Anders Wegge Keller <(E-Mail Removed)> wrote:
>> Ansel <(E-Mail Removed)> writes:

>
>>> So, next time, before you start making childish assertions, and
>>> playing childish goading games, you should do a little research on
>>> your own first so that you don't look so foolish and immature.

>>
>> So actually, you cannot point out a single place where the unicode
>> specification is ambigous (which is what you implied in the start of
>> this subthread). Another thing I noted, is that you play the offtopic
>> card, only after you have been unable to play the childish defence of
>> "Find the answer yourself".

>
> 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.


 
Reply With Quote
 
Ansel
Guest
Posts: n/a
 
      08-05-2012
jacob navia wrote:

> 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.


 
Reply With Quote
 
Ansel
Guest
Posts: n/a
 
      08-05-2012
Ben Bacarisse wrote:
> jacob navia <(E-Mail Removed)> writes:
> <snip>
>> 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.

>
> 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.


 
Reply With Quote
 
Ansel
Guest
Posts: n/a
 
      08-05-2012
Ike Naar wrote:
> On 2012-08-04, jacob navia <(E-Mail Removed)> wrote:
>> 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.

>
> 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.)


 
Reply With Quote
 
Anders Wegge Keller
Guest
Posts: n/a
 
      08-05-2012
"Ansel" <(E-Mail Removed)> writes:

> 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.


--
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*
 
Reply With Quote
 
Ansel
Guest
Posts: n/a
 
      08-05-2012
Anders Wegge Keller wrote:
> "Ansel" <(E-Mail Removed)> writes:
>
>> 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.


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?


 
Reply With Quote
 
Anders Wegge Keller
Guest
Posts: n/a
 
      08-05-2012
"Ansel" <(E-Mail Removed)> writes:

> Anders Wegge Keller wrote:


>> 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.


That's entirely up to you.

> "UC"?


Make an educated guess.


>> 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.



From <news:jv59g7$co8$(E-Mail Removed)>

> 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.

>> 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?


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

>> You made a bogus claim in the first place.


> Do tell. Are you calling me a liar?


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

>> 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).


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 started it.


> 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.

--
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*
 
Reply With Quote
 
Ansel
Guest
Posts: n/a
 
      08-05-2012
Anders Wegge Keller wrote:
> "Ansel" <(E-Mail Removed)> writes:
>
>> Anders Wegge Keller wrote:

>
>>> 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.

>
> That's entirely up to you.
>
>> "UC"?

>
> Make an educated guess.
>
>

Oh, a wanker. Your mom is interested?

>>> 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.

>
>
> From <news:jv59g7$co8$(E-Mail Removed)>
>
> > 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 reject your war.

>
>>> 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?

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


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

>
>>> You made a bogus claim in the first place.

>
>> Do tell. Are you calling me a liar?

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


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

>
>>> 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).

>
> 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.

>
>>> you started it.

>
>> You are testing my convictions?

>
> 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".


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Are sequence containers not a subset of general containers? Sebastian Mach C++ 5 10-06-2012 07:54 PM
C library containing implementations of associative containers. Morten C Programming 3 05-07-2008 02:24 PM
Containers of iterators vs. containers of references clark.coleman@att.net C++ 7 01-25-2008 01:37 PM
Library exposing STL containers Bob C++ 2 07-26-2006 02:04 AM
Questions about destructors on std library containers Ross Boylan C++ 12 02-13-2004 03:03 AM



Advertisments