Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #20601 > unrolled thread

CCL vs STL: a comparison

Back to article view | Back to comp.lang.c

Contents

  CCL vs STL: a comparison jacob navia <jacob@spamsink.net> - 2012-05-11 18:59 +0200
    Re: CCL vs STL: a comparison Ike Naar <ike@sverige.freeshell.org> - 2012-05-11 17:54 +0000
      Re: CCL vs STL: a comparison jacob navia <jacob@spamsink.net> - 2012-05-11 19:59 +0200
    Re: CCL vs STL: a comparison Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-11 20:31 +0100
      Re: CCL vs STL: a comparison jacob navia <jacob@spamsink.net> - 2012-05-11 21:56 +0200
        Re: CCL vs STL: a comparison Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-11 21:02 +0100
          Re: CCL vs STL: a comparison jacob navia <jacob@spamsink.net> - 2012-05-11 22:12 +0200
            Re: CCL vs STL: a comparison Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-11 21:18 +0100
      Re: CCL vs STL: a comparison jacob navia <jacob@spamsink.net> - 2012-05-11 22:01 +0200
        Re: CCL vs STL: a comparison Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-11 21:08 +0100
      Re: CCL vs STL: a comparison jacob navia <jacob@spamsink.net> - 2012-05-11 22:04 +0200
        Re: CCL vs STL: a comparison Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-11 21:11 +0100
          Re: CCL vs STL: a comparison jacob navia <jacob@spamsink.net> - 2012-05-11 22:15 +0200
            Re: CCL vs STL: a comparison cartec69@gmail.com - 2012-05-11 13:17 -0700
      Re: CCL vs STL: a comparison jacob navia <jacob@spamsink.net> - 2012-05-11 22:06 +0200
        Re: CCL vs STL: a comparison Ian Collins <ian-news@hotmail.com> - 2012-05-12 08:41 +1200
          Re: CCL vs STL: a comparison Gareth Owen <gwowen@gmail.com> - 2012-05-12 07:18 +0100
            Re: CCL vs STL: a comparison jacob navia <jacob@spamsink.net> - 2012-05-12 09:48 +0200
              Re: CCL vs STL: a comparison Ian Collins <ian-news@hotmail.com> - 2012-05-12 20:09 +1200
                Re: CCL vs STL: a comparison jacob navia <jacob@spamsink.net> - 2012-05-12 10:30 +0200
                  Re: CCL vs STL: a comparison Ian Collins <ian-news@hotmail.com> - 2012-05-12 21:23 +1200
                    Re: CCL vs STL: a comparison jacob navia <jacob@spamsink.net> - 2012-05-12 11:39 +0200
                      Re: CCL vs STL: a comparison Ian Collins <ian-news@hotmail.com> - 2012-05-12 23:02 +1200
                      Re: CCL vs STL: a comparison "BartC" <bc@freeuk.com> - 2012-05-12 13:14 +0100
                        Re: CCL vs STL: a comparison jacob navia <jacob@spamsink.net> - 2012-05-12 14:35 +0200
              Re: CCL vs STL: a comparison "io_x" <a@b.c.invalid> - 2012-05-13 10:59 +0200
    Re: CCL vs STL: a comparison "BartC" <bc@freeuk.com> - 2012-05-11 23:36 +0100
      Re: CCL vs STL: a comparison Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-12 00:25 +0100
        Re: CCL vs STL: a comparison Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-12 01:58 +0100
          Re: CCL vs STL: a comparison Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-11 19:30 -0700
      Re: CCL vs STL: a comparison jacob navia <jacob@spamsink.net> - 2012-05-12 09:49 +0200
    Re: CCL vs STL: a comparison Jens Gustedt <jens.gustedt@loria.fr> - 2012-05-12 18:31 +0200

Page 2 of 2 — ← Prev page 1 [2]

#20649

On 05/12/12 08:30 PM, jacob navia wrote:
> Le 12/05/12 10:09, Ian Collins a écrit :
>>
>> Kindly explain (I bet you won't) how
>>
>> List *L;
>> int data;
>> L = iList.Create(sizeof(int));
>>
>> data = 0;
>> iList.Add(L,&data);
>> iList.PushFront(L,&data);
>> data = 2;
>> iList.InsertAt(L,1,&data);
>> data = 5;
>> iList.Add(L,&data);
>> data = 6;
>> iList.Add(L,&data);
>> iList.Apply(L,PrintInt,stdout);
>> iList.Finalize(L);
>>
>> gives the user more control and is less error prone than than
>>
>> list<int>  L = {0, 2, 0, 5, 6};
>>
>
> Wait Ian, if I use C99 I can write:
>
> List *L = iList.InitializeWith(sizeof(int),5, (int []){0, 2, 0, 5, 6});
>
> The purpose of my example was to show how Add, InsertAt, etc are used,
> not to build precisely a list of those 5 integers!

That's better, but what would happen if you wrote

List *L = iList.InitializeWith(sizeof(int),4, (int []){0, 2, 0, 5, 6});

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#20650

Le 12/05/12 11:23, Ian Collins a écrit :
> On 05/12/12 08:30 PM, jacob navia wrote:
>> Le 12/05/12 10:09, Ian Collins a écrit :
>>>
>>> Kindly explain (I bet you won't) how
>>>
>>> List *L;
>>> int data;
>>> L = iList.Create(sizeof(int));
>>>
>>> data = 0;
>>> iList.Add(L,&data);
>>> iList.PushFront(L,&data);
>>> data = 2;
>>> iList.InsertAt(L,1,&data);
>>> data = 5;
>>> iList.Add(L,&data);
>>> data = 6;
>>> iList.Add(L,&data);
>>> iList.Apply(L,PrintInt,stdout);
>>> iList.Finalize(L);
>>>
>>> gives the user more control and is less error prone than than
>>>
>>> list<int> L = {0, 2, 0, 5, 6};
>>>
>>
>> Wait Ian, if I use C99 I can write:
>>
>> List *L = iList.InitializeWith(sizeof(int),5, (int []){0, 2, 0, 5, 6});
>>
>> The purpose of my example was to show how Add, InsertAt, etc are used,
>> not to build precisely a list of those 5 integers!
>
> That's better, but what would happen if you wrote
>
> List *L = iList.InitializeWith(sizeof(int),4, (int []){0, 2, 0, 5, 6});
>

As I said before, the better way to write that is:

int tab[] = {0, 2, 0, 5, 6};
#define NB_ELEM(tab) (sizeof(tab)/sizeof(tab[0])
List *L = iList.InitializeWith(sizeof(int),NB_ELEM(tab),tab);

[toc] | [prev] | [next] | [standalone]

#20651

On 05/12/12 09:39 PM, jacob navia wrote:
> Le 12/05/12 11:23, Ian Collins a écrit :
>> On 05/12/12 08:30 PM, jacob navia wrote:
>>> Le 12/05/12 10:09, Ian Collins a écrit :
>>>>
>>>> Kindly explain (I bet you won't) how
>>>>
>>>> List *L;
>>>> int data;
>>>> L = iList.Create(sizeof(int));
>>>>
>>>> data = 0;
>>>> iList.Add(L,&data);
>>>> iList.PushFront(L,&data);
>>>> data = 2;
>>>> iList.InsertAt(L,1,&data);
>>>> data = 5;
>>>> iList.Add(L,&data);
>>>> data = 6;
>>>> iList.Add(L,&data);
>>>> iList.Apply(L,PrintInt,stdout);
>>>> iList.Finalize(L);
>>>>
>>>> gives the user more control and is less error prone than than
>>>>
>>>> list<int>  L = {0, 2, 0, 5, 6};
>>>>
>>>
>>> Wait Ian, if I use C99 I can write:
>>>
>>> List *L = iList.InitializeWith(sizeof(int),5, (int []){0, 2, 0, 5, 6});
>>>
>>> The purpose of my example was to show how Add, InsertAt, etc are used,
>>> not to build precisely a list of those 5 integers!
>>
>> That's better, but what would happen if you wrote
>>
>> List *L = iList.InitializeWith(sizeof(int),4, (int []){0, 2, 0, 5, 6});
>>
>
> As I said before, the better way to write that is:
>
> int tab[] = {0, 2, 0, 5, 6};
> #define NB_ELEM(tab) (sizeof(tab)/sizeof(tab[0])
> List *L = iList.InitializeWith(sizeof(int),NB_ELEM(tab),tab);
>

That's what we have to do in "old" C++ but the updated standard makes 
life easier and safer.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#20652

"jacob navia" <jacob@spamsink.net> wrote in message
news:jolb3p$d62$1@speranza.aioe.org...
> Le 12/05/12 11:23, Ian Collins a écrit :
>> On 05/12/12 08:30 PM, jacob navia wrote:
>>> Le 12/05/12 10:09, Ian Collins a écrit :

>>>> List *L;
>>>> int data;
>>>> L = iList.Create(sizeof(int));
>>>>
>>>> data = 0;
>>>> iList.Add(L,&data);
>>>> iList.PushFront(L,&data);
>>>> data = 2;
>>>> iList.InsertAt(L,1,&data);
>>>> data = 5;
>>>> iList.Add(L,&data);
>>>> data = 6;
>>>> iList.Add(L,&data);
>>>> iList.Apply(L,PrintInt,stdout);
>>>> iList.Finalize(L);


> As I said before, the better way to write that is:
>
> int tab[] = {0, 2, 0, 5, 6};
> #define NB_ELEM(tab) (sizeof(tab)/sizeof(tab[0])
> List *L = iList.InitializeWith(sizeof(int),NB_ELEM(tab),tab);

I've tried hard to like this library but, having to stick within the
limitations of standard C, I think you've got your work cut out trying to
make it not look clunky.

As I understand your original example, you're trying to do something like
this:

L:=()
L.append(0)
L.prepend(0)
L.insert(1,2)
L.concat((5,6))
print (L)

You can probably do pretty much this now, in half-a-dozen different
scripting languages. The above is not typed, so perhaps you can formalise it
by declaring:

List L  or List int L

at the top. Then that will use flex int arrays as the C and C++ fragments
would do (although I understand the CCL doesn't know about type, only size).

Both the examples in your original post have plenty of extra clutter
compared with my minimalist version. Maybe the newer C++ comes closer to
doing this, but probably by having to enhance the language and at a cost of
considerable extra complexity (and the original C++ wasn't exactly simple).

Perhaps you should be comparing your CCL code, with a version in C that
doesn't use CCL, although the latter is likely to be specialised. (You gave
one example of a specialised version, and it did look more streamlined.)

Also, maybe compare performance; whether it's faster than C++ might be of
interest (but I guess that depends on compiler). Both are likely to be a lot
faster than any of those scripting languages.

It's also possible that appearance is not so important, if a library such as
CCL is going to be used behind the scenes. Then users will wrap it with an
interface of their choice, and perhaps with shorter names ('InitializeWith'
looks long-winded). The important thing then are the list-processing
facilities that are provided.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#20653

Le 12/05/12 14:14, BartC a écrit :
> perhaps with shorter names ('InitializeWith'
> looks long-winded)

Yes, you are right. I will change that to
InitWith (6 chars less) that is as explicit but
shorter. I will review other longnames also.

[toc] | [prev] | [next] | [standalone]

#20672

"jacob navia" <jacob@spamsink.net> ha scritto nel messaggio 
news:jol4jh$tpt$1@speranza.aioe.org...
> Le 12/05/12 08:18, Gareth Owen a écrit :
>> Ian Collins<ian-news@hotmail.com>  writes:
>>
>>> On 05/12/12 08:06 AM, jacob navia wrote:
>>>> Le 11/05/12 21:31, Ben Bacarisse a écrit :
>>>>> I am not sure what you are really asking.
>>>>
>>>> Just trying to discuss the two approaches. I am sure
>>>> C++ has more "syntactic sugar" than C, but the
>>>> two approaches lead to similar code.
>>>
>>> Not really.  As Ben demonstrated, the "syntactic sugar" leads to much
>>> more concise and less error prone code.  In this case, 2 lines rather
>>> than 18!
>>
>> Jacob's code contains an explicit cast of a void* to an int*, meaning
>> the programmer has to track the data types and then tell the compiler
>> what they are, rather than have the compiler track and check the types.
>>
>> He doesn't seem to believe this to be a drawback.
>>
>> Describing the C++ as "less error prone" would be something of an
>> understatement.
>
> Yes. C++ is the best thing since sliced bread.

i like asm, and C library; expecially my library because i know
the source code too and i understand better than C++ library ones

> In C, the programmer has to do more work. But he gains more control
> of what is going on, and avoids a complex (and more error prone yes)
> language.
>
> It is my personal view, that is why I insist in developing in C. You
> are entitled to your opinion of course. But I thought that in a C group
> we would discuss how to improve C.
>
> What would you propose? (Besides the obvious "Use C++") 

[toc] | [prev] | [next] | [standalone]

#20632

"jacob navia" <jacob@spamsink.net> wrote in message 
news:jojghh$91l$1@speranza.aioe.org...
> Here is a comparison of two source codes that use the C++ STL and the
> C containers library (ccl).

>     List *L;
>     int data;
>
>     L = iList.Create(sizeof(int));
>
>     data = 0;
>     iList.Add(L,&data);

Shame you can't use immediate data. Then that line becomes:

  ilist.Add(L,0);

Although it might not be much trouble (*in this simple case*) to do:

  ilist.Add(L,imm(0));

where imm is "int* imm(int)".

But perhaps in actual use, immediate data isn't used so much.

-- 
Barts

 

[toc] | [prev] | [next] | [standalone]

#20637

"BartC" <bc@freeuk.com> writes:

> "jacob navia" <jacob@spamsink.net> wrote in message
> news:jojghh$91l$1@speranza.aioe.org...
>> Here is a comparison of two source codes that use the C++ STL and the
>> C containers library (ccl).
>
>>     List *L;
>>     int data;
>>
>>     L = iList.Create(sizeof(int));
>>
>>     data = 0;
>>     iList.Add(L,&data);
>
> Shame you can't use immediate data. Then that line becomes:
>
>  ilist.Add(L,0);

C++ has compound literals which produce lvalues so you can apply & to
the result:

  ilist.Add(L, &(int){0});

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#20638

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> "BartC" <bc@freeuk.com> writes:
>
>> "jacob navia" <jacob@spamsink.net> wrote in message
>> news:jojghh$91l$1@speranza.aioe.org...
>>> Here is a comparison of two source codes that use the C++ STL and the
>>> C containers library (ccl).
>>
>>>     List *L;
>>>     int data;
>>>
>>>     L = iList.Create(sizeof(int));
>>>
>>>     data = 0;
>>>     iList.Add(L,&data);
>>
>> Shame you can't use immediate data. Then that line becomes:
>>
>>  ilist.Add(L,0);
>
> C++ has compound literals which produce lvalues so you can apply & to

<slap!> C99, of course, not C++.

> the result:
>
>   ilist.Add(L, &(int){0});
>
> <snip>

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#20643

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> "BartC" <bc@freeuk.com> writes:
>>
>>> "jacob navia" <jacob@spamsink.net> wrote in message
>>> news:jojghh$91l$1@speranza.aioe.org...
>>>> Here is a comparison of two source codes that use the C++ STL and the
>>>> C containers library (ccl).
>>>
>>>>     List *L;
>>>>     int data;
>>>>
>>>>     L = iList.Create(sizeof(int));
>>>>
>>>>     data = 0;
>>>>     iList.Add(L,&data);
>>>
>>> Shame you can't use immediate data. Then that line becomes:
>>>
>>>  ilist.Add(L,0);
>>
>> C++ has compound literals which produce lvalues so you can apply & to
>
> <slap!> C99, of course, not C++.

C99, C11, C++  -  they're all about the same.  :)

[toc] | [prev] | [next] | [standalone]

#20646

Le 12/05/12 00:36, BartC a écrit :
> "jacob navia" <jacob@spamsink.net> wrote in message
> news:jojghh$91l$1@speranza.aioe.org...
>> Here is a comparison of two source codes that use the C++ STL and the
>> C containers library (ccl).
>
>> List *L;
>> int data;
>>
>> L = iList.Create(sizeof(int));
>>
>> data = 0;
>> iList.Add(L,&data);
>
> Shame you can't use immediate data. Then that line becomes:
>
> ilist.Add(L,0);
>

You can specialize the sample implementation file to an int list.
In that case, you make a new interface automatically called

iIntList

and you use

iIntList.Add(L,0);

[toc] | [prev] | [next] | [standalone]

#20654

Salut,

Am 11.05.2012 18:59, schrieb jacob navia:
> Here is a comparison of two source codes that use the C++ STL and the
> C containers library (ccl).

I think your example is a nice demonstration of the features of your
library, but I also think it would gain a lot if you would put it in
the context of C11, especially when you compare to C++.

C11 has type generic macros and the simplicity of using your library
would gain a lot if the interfaces were type generic. Things like

    data = 0;
    iList.Add(L,&data);

i.e having to assign to a variable, first, before being able to add an
element to a list is a no-go. Additionally, it lacks at least a simple
check for consistency to see if sizeof data is the size that you
initially gave to your list through iList.Create.

I can imagine the reason why it looks like this (probably your
function is just doing a memcpy so you can't do with an rvalue) but
interfaces like that will not be widely used, I think.

For a generic interface I'd do something like

#define getLvalue(X)              \
_Generic((X),                     \
  int: (int){ (X) },              \
   ...etc...                      \
)

#define iListAdd(L, X) iList.Add(L, (dynamic_asser(theSizeOfElements(L)
== sizeof X), &getLvalue(X)))

Or, alternatively I would change the interfaces of your functions that
they all also receive the size of the data element that is to be
stored and then have something simpler like

#define iListAdd(L, X) iList.Add(L, &getLvalue(X), sizeof X)

Your iList.Apply function then also could be encapsulated in a macro
that would make the call side look something like

ILIST_APPLY(L, int, i) {
    fprintf(extraArgs,"%d ",i);
}

no need to distract the programmer by forcing him to define a function
specially for that. (But I am well aware that such constructs would
face much reluctance for inclusion in a C standard.)

Please don't get me wrong, I am just saying that a "naked" type
agnostic interface like you defined and implemented it is not
sufficient. But it could be a first step (or stage) for such a library
if you'd offer a type generic interface on top of it. Modern C gives
you all the tools you need for that.

If the C library were designed today, it would be designed with type
generic interfaces à la tgmath.h I think that any future additions to
the library should follow such a pattern.

Jens

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web