New address of the C Containers library

[jacobnavia]

https://github.com/jacob-navia/ccl.git

There you will find all the source code and the source code of the
dopcumentation in TeX form (the only word processor of the 80es that is
still running today and will run in 2030)

The C Containers library is a replica of the STL written in plain C.

jacob

[Scott Lurndal]

jacobnavia <ja...@jacob.remcomp.fr> writes:

>There you will find all the source code and the source code of the
>dopcumentation in TeX form (the only word processor of the 80es that is
>still running today and will run in 2030)

troff is a word processor of
the 70's that is still running today, and will continue to
run through 2030, and is still the foundation of manual pages
on unix/linux systems.

If you are documenting source code, then you should at minimum
provide doxygen comments in the source.

[Randy Howard]

On 3/30/16 8:03 AM, jacobnavia wrote:
> https://github.com/jacob-navia/ccl.git
>
> There you will find all the source code and the source code of the
> dopcumentation in TeX form (the only word processor of the 80es that is
> still running today and will run in 2030)

Is "dopcumentation" an artifact of an archaic word processor? ;-)

Btw, I'm completely convinced that other word processors from that era
are still running today and will still be runnable in 2030. But don't
let that get in the way of grinding the axe for your favorite one.

> The C Containers library is a replica of the STL written in plain C.

Thanks for the warning.

Out of curiosity, is it really written in plain C, or that 'almost C'
flavor you like?


--
Randy Howard
(replace the obvious text in the obvious way if you wish to contact me
directly)

[Randy Howard]

On 3/30/16 10:11 AM, Scott Lurndal wrote:
> jacobnavia <ja...@jacob.remcomp.fr> writes:
>
>> There you will find all the source code and the source code of the
>> dopcumentation in TeX form (the only word processor of the 80es that is
>> still running today and will run in 2030)
>
> troff is a word processor of
> the 70's that is still running today, and will continue to
> run through 2030, and is still the foundation of manual pages
> on unix/linux systems.

Or perhaps nroff.

> If you are documenting source code, then you should at minimum
> provide doxygen comments in the source.

Seriously? doxygen is a train wreck.

[jacobnavia]

Le 30/03/2016 17:11, Scott Lurndal a écrit :
> jacobnavia <ja...@jacob.remcomp.fr> writes:
>
>> There you will find all the source code and the source code of the
>> dopcumentation in TeX form (the only word processor of the 80es that is
>> still running today and will run in 2030)
>
> troff is a word processor of
> the 70's that is still running today, and will continue to
> run through 2030, and is still the foundation of manual pages
> on unix/linux systems.
>

You are comparing TeX to troff?

How about mathematical formulae?
How about QUALITY?

Please, there is NO comparison here!

[Scott Lurndal]

Randy Howard <rhowa...@EverybodyUsesIt.com> writes:
>On 3/30/16 10:11 AM, Scott Lurndal wrote:
>> jacobnavia <ja...@jacob.remcomp.fr> writes:
>>
>>> There you will find all the source code and the source code of the
>>> dopcumentation in TeX form (the only word processor of the 80es that is
>>> still running today and will run in 2030)
>>
>> troff is a word processor of
>> the 70's that is still running today, and will continue to
>> run through 2030, and is still the foundation of manual pages
>> on unix/linux systems.
>
>Or perhaps nroff.

It's the same source language - troff generates typesetter output (now postscript)
and nroff generates terminal output.

>
>> If you are documenting source code, then you should at minimum
>> provide doxygen comments in the source.
>
>Seriously? doxygen is a train wreck.

YMMV.

[Scott Lurndal]

man eqn(1) for the small subset of documents requiring math formulae.
man pic(1) for diagrams
man tbl(1) for tables
man dformat(1) for data structure documentation
mqn grap(1) for graphs

>How about QUALITY?

Missing definition noted.

>
>Please, there is NO comparison here!
>

Wrong group for this argument. Suffice it to say
horses for courses.

[Keith Thompson]

(I'm not sure this belongs in comp.lang.c++, but I'll leave the
newsgroups list as it is for now.)

Randy Howard <rhowa...@EverybodyUsesIt.com> writes:
> On 3/30/16 8:03 AM, jacobnavia wrote:
>> https://github.com/jacob-navia/ccl.git
>>
>> There you will find all the source code and the source code of the
>> dopcumentation in TeX form (the only word processor of the 80es that is
>> still running today and will run in 2030)

[...]

>> The C Containers library is a replica of the STL written in plain C.
>
> Thanks for the warning.
>
> Out of curiosity, is it really written in plain C, or that 'almost C'
> flavor you like?

It appears to be plain C. When I modify the Makefile to use
-std=c11 -pedantic -Wall -Wextra -O3
with gcc 5.3.0, I get a number of unused parameter warnings.
(I haven't looked into them, but that's probably to be expected
for this kind of thing.) Adding
-Wno-unused-parameter

leaves two warnings:

hashtable.c: In function 'Clear':
hashtable.c:696:27: warning: 'HashIdx.ht' is used uninitialized in this
function [-Wuninitialized]
if (hi->index > hi->ht->max)
^
hashtable.c:383:15: note: 'HashIdx' was declared here
HashIndex HashIdx,*hi;
^

and:

priorityqueue.c: In function 'checkcons':
priorityqueue.c:418:36: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
if (h->Log2N == -1 || h->count > (1 << h->Log2N)) {

"-std=c99" gives similar results.

One more minor problem: "make clean" doesn't remove "test.o".

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[jacobnavia]

Tex is used in scientific journals like astronomy and astrophysics. It
is the work of D. Knuth, someone I profoundly respect. The independence
of TeX from the machine, and many other things of TeX makes it a unique
creation.

Obviously nroff has the same stuff, and many other text handling
programs (probably, I do not really know nroff that well) but in a
mathematical way, TeX is relly something.

I remember when it appeared, the bugs of Knuth, his analysis of those
bugs, those wonderfully typesetted programming books that Knuth wrote.

Mostly sentimental reasons as you see.

[jacobnavia]

This comes because the code analyzer of gcc fails to realize that this
data is initialized in the call to getfirst in function Clear

> and:
>
> priorityqueue.c: In function 'checkcons':
> priorityqueue.c:418:36: warning: comparison between signed and unsigned
> integer expressions [-Wsign-compare]
> if (h->Log2N == -1 || h->count > (1 << h->Log2N)) {
>
> "-std=c99" gives similar results.
>

OK. Thanks I will look at that one later

> One more minor problem: "make clean" doesn't remove "test.o".
>

OK. Thanks

[Juha Nieminen]

In comp.lang.c++ jacobnavia <ja...@jacob.remcomp.fr> wrote:
> https://github.com/jacob-navia/ccl.git

I think this is a good demonstration of why C++ is, among other things,
more memory-efficient than C. I did a quick test like this:

//--------------------------------------------------------------
#include "ccl/intdlist.h"
#include <list>
#include <iostream>

int main()
{
std::cout << sizeof(std::list<int>) << " "
<< sizeof(std::list<int>::iterator) << "\n"
<< sizeof(INTERFACE_STRUCT_INTERNAL_NAME(int)) << " "
<< sizeof(ITERATOR(int)) << "\n";
}
//--------------------------------------------------------------

And the result was:

24 8
512 112

Of course the C++ version is not only more memory-efficient, it's also
technically speaking faster because every std::list method call is a
direct function call (that can ostensibly be even inlined by the compiler
if it deems it efficient), while in the C version each call has an
additional level of indirection, and the compiler has no possibility
of inlining.

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[jacobnavia]

It would be nice if you told us what are INTERFACE_STRUCT_INTERNAL_NAME
and ITERATOR.

Thanks

[jacobnavia]

Le 04/04/2016 09:13, Juha Nieminen a écrit :

> In comp.lang.c++ jacobnavia <ja...@jacob.remcomp.fr> wrote:
>> https://github.com/jacob-navia/ccl.git
>
> I think this is a good demonstration of why C++ is, among other things,
> more memory-efficient than C. I did a quick test like this:
>
> //--------------------------------------------------------------
> #include "ccl/intdlist.h"
> #include <list>
> #include <iostream>
>
> int main()
> {
> std::cout << sizeof(std::list<int>) << " "
> << sizeof(std::list<int>::iterator) << "\n"
> << sizeof(INTERFACE_STRUCT_INTERNAL_NAME(int)) << " "
> << sizeof(ITERATOR(int)) << "\n";
> }
> //--------------------------------------------------------------
>
> And the result was:
>
> 24 8
> 512 112
>

I compiled this program IN C!!


#include "containers.h"
#include "ccl_internal.h"

int main(void)
{
printf("sizeof(Dlist)=%lu\n",sizeof(Dlist));
}


Result:
~/ccl/test $ ./a.out
sizeof(Dlist)=96

96 is not 512. You have made a mistake: you compiled the program with a
C++ compiler. Use a C compiler instead.

You say:

<<
Of course the C++ version is not only more memory-efficient, it's also
technically speaking faster because every std::list method call is a
direct function call
>>

The difference between a direct and an indirect call is just ONE MEMORY
ACCESS. Does a single memory access make ANY difference at 2.7GB/second?

Of course not.

C offers the added flexibility (that you loose when the call is
hard-wired like in C++) that you can change the call at run time if you
want.

You say:

<<
in the C version each call has an
additional level of indirection, and the compiler has no possibility
of inlining.
>>

Of course the compiler could inline IF THE COMPILER WRITERS WANTED.
But since C is not being developed anymore as a language (only C++
counts) this optimizations aren't offered. You could install a
"freeze" switch in the compiler that would it allow to inline calls
through a known function pointer assuming the function pointer is fixed
at the start of the program.

[Ian Collins]

On 04/04/16 21:57, jacobnavia wrote:
>
> C offers the added flexibility (that you loose when the call is
> hard-wired like in C++) that you can change the call at run time if you
> want.

The interesting question is when would you want to change the call?

--
Ian Collins

[jacobnavia]

This allows a dynamic subclassing of some features of an interface. For
instance a hash table adapted to ALL possible sizes of data is probably
not 100% good at small sizes and also at huge sizes.

According to the dynamic requirements of the program, you can change the
search, or insert functions of an interface to adapt it to a huge/small
container. Obviously if you can do it at compile time is better, but
that is not always possible, specially if it is a library...

[Keith Thompson]

jacobnavia <ja...@jacob.remcomp.fr> writes:
[...]
> printf("sizeof(Dlist)=%lu\n",sizeof(Dlist));
[...]

That should be %zu, not %lu.

[Juha Nieminen]

In comp.lang.c++ jacobnavia <ja...@jacob.remcomp.fr> wrote:
> 96 is not 512. You have made a mistake: you compiled the program with a
> C++ compiler. Use a C compiler instead.

Fine:

//-------------------------------------------------------------------
#include "ccl/intdlist.h"
#include <stdio.h>

int main()
{
printf("%zu %zu\n",
sizeof(struct INTERFACE_STRUCT_INTERNAL_NAME(int)),
sizeof(struct ITERATOR(int)));
return 0;
}
//-------------------------------------------------------------------

Compiled with "clang -O3", output:

512 112

> You say:
>
> <<
> Of course the C++ version is not only more memory-efficient, it's also
> technically speaking faster because every std::list method call is a
> direct function call
> >>
>
> The difference between a direct and an indirect call is just ONE MEMORY
> ACCESS. Does a single memory access make ANY difference at 2.7GB/second?
>
> Of course not.

It can have a difference in tight inner loops that are run millions of times.

C++ doesn't need this kind of indirection, and the optimization comes for
free, without you having to do anything for it.

> C offers the added flexibility (that you loose when the call is
> hard-wired like in C++) that you can change the call at run time if you
> want.

You say it like it's a C feature (rather than a feature of your library),
as if it were impossible in C++. After all, you didn't say "this library
offers the added flexibility". You said "C offers the added flexibility".
As if C++ didn't, if you implemented it like that.

> You say:
> <<
> in the C version each call has an
> additional level of indirection, and the compiler has no possibility
> of inlining.
> >>
>
> Of course the compiler could inline IF THE COMPILER WRITERS WANTED.

You first give the very reason why it can't be inlined (because, as you
said, the pointer could be changed at runtime to point somewhere else,
which effectively precludes inlining), and then you say that it could
be inlined if the compiler writers wanted. I don't think even you know
what you are talking about.

> But since C is not being developed anymore as a language

Oh, that's why the latest C standard is from 2011? That's ancient indeed.
Belongs to a museum.

[jacobnavia]

Le 05/04/2016 08:59, Juha Nieminen a écrit :
> You first give the very reason why it can't be inlined (because, as you
> said, the pointer could be changed at runtime to point somewhere else,
> which effectively precludes inlining), and then you say that it could
> be inlined if the compiler writers wanted. I don't think even you know
> what you are talking about.

I said:

<quote>

You could install a
"freeze" switch in the compiler that would it allow to inline calls
through a known function pointer assuming the function pointer is fixed
at the start of the program.

<end quote>

but you ignored that part of my message. This "selective quoting" is
normal in these polemics in Usenet.

Then, the other stuff:

You get 512 bytes

[jacobnavia]

Le 05/04/2016 08:59, Juha Nieminen a écrit :

> Compiled with "clang -O3", output:
>
> 512 112

This is ridiculous. There is only ONE object of this kind in the whole
program. If it takes more or less bytes is irrelevant.

[Randy Howard]

You must be used to this by now Jacob. :-) Welcome to Usenet.