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 1 of 2  [1] 2  Next page →

#20601 — CCL vs STL: a comparison

Here is a comparison of two source codes that use the C++ STL and the
C containers library (ccl).

First, the C++ example:

// Standard Template Library example

#include <iostream>
#include <list>
using namespace std;

// Simple example uses type int

int main(void)
{
    list<int> L;
    L.push_back(0);         // Insert a new element at the end
    L.push_front(0);        // Insert a new element at the beginning
    L.insert(++L.begin(),2);// Insert "2" before position of first argument
                            // (Place before second argument)
    L.push_back(5);
    L.push_back(6);

    list<int>::iterator i;

    for(i=L.begin(); i != L.end(); ++i) cout << *i << " ";
    cout << endl;
    return 0;
}

/* OUTPUT: 0 2 0 5 6 */
---------------------------------------------------------------------------
Here is the C example
#include "containers.h"
static int PrintInt(void *pdata,void *extraArgs)
{
     int i = *(int *)pdata;
     fprintf(extraArgs,"%d ",i);
}
int main(void)
{
     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);
}
----------------------------------------------------------------------------

I could have used iterators to print the list but I think using "Apply"
looks better ...

What do you think?

[toc] | [next] | [standalone]

#20606

On 2012-05-11, jacob navia <jacob@spamsink.net> wrote:
> #include "containers.h"
> static int PrintInt(void *pdata,void *extraArgs)
> {
>      int i = *(int *)pdata;
>      fprintf(extraArgs,"%d ",i);
> }

PrintInt promises to return an int, but it doesn't.

> int main(void)
> {
>      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);

No terminating newline is printed?

>      iList.Finalize(L);
> }

This

  int data = 5;
  iList.Add(L, &data);

looks clumsier than

  L.push_back(5);

and it's more prone to errors,
for instance, the compiler will accept

  long data = 5;
  iList.Add(L, &data);

but this may lead to unexpected run-time behaviour on
a machine on which sizeof(int) != sizeof(long)..

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

#20607

Le 11/05/12 19:54, Ike Naar a écrit :
> On 2012-05-11, jacob navia<jacob@spamsink.net>  wrote:
>> #include "containers.h"
>> static int PrintInt(void *pdata,void *extraArgs)
>> {
>>       int i = *(int *)pdata;
>>       fprintf(extraArgs,"%d ",i);
>> }
>
> PrintInt promises to return an int, but it doesn't.
>


Yes, this is an error. Should return one or other value.

>> int main(void)
>> {
>>       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);
>
> No terminating newline is printed?
>

No. But it is easy to add one.

>>       iList.Finalize(L);
>> }
>
> This
>
>    int data = 5;
>    iList.Add(L,&data);
>
> looks clumsier than
>
>    L.push_back(5);
>
> and it's more prone to errors,
> for instance, the compiler will accept
>
>    long data = 5;
>    iList.Add(L,&data);
>
> but this may lead to unexpected run-time behaviour on
> a machine on which sizeof(int) != sizeof(long)..

Yes, you can put any value, and you have to keep track of what you are 
doing.

A specific interface for a specific data type can be obtained by using
the template file furnished with the sample implementation.

If you do that you obtain compiler checking at compile time.

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

#20615

jacob navia <jacob@spamsink.net> writes:

> Here is a comparison of two source codes that use the C++ STL and the
> C containers library (ccl).

It's not clear what the point is.  In terms of code clarity and
simplicity, C++ is likely to come out on top in simple comparisons like
this.

> First, the C++ example:
>
> // Standard Template Library example
>
> #include <iostream>
> #include <list>
> using namespace std;
>
> // Simple example uses type int
>
> int main(void)
> {
>    list<int> L;

You can also just initialise the list:

  list<int> L = {0, 2, 0, 5, 6};

C libraries will always have live withing C's core language limitations.

>    L.push_back(0);         // Insert a new element at the end
>    L.push_front(0);        // Insert a new element at the beginning
>    L.insert(++L.begin(),2);// Insert "2" before position of first argument
>                            // (Place before second argument)
>    L.push_back(5);
>    L.push_back(6);
>
>    list<int>::iterator i;
>
>    for(i=L.begin(); i != L.end(); ++i) cout << *i << " ";

Modern C++ has this:

  for (int i: L) cout << i << " ";

Nice, yes?

>    cout << endl;
>    return 0;
> }
>
> /* OUTPUT: 0 2 0 5 6 */
> ---------------------------------------------------------------------------
> Here is the C example
> #include "containers.h"
> static int PrintInt(void *pdata,void *extraArgs)
> {
>     int i = *(int *)pdata;
>     fprintf(extraArgs,"%d ",i);
> }
> int main(void)
> {
>     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);
> }
> ----------------------------------------------------------------------------
>
> I could have used iterators to print the list but I think using "Apply"
> looks better ...

C++ also has an "apply" and, what's more, it doesn't need a top-level
function definition:

  for_each(L.begin(), L.end(), [](int i){ cout << i << " "; });

> What do you think?

I am not sure what you are really asking.

-- 
Ben.

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

#20617

Le 11/05/12 21:31, Ben Bacarisse a écrit :
>
> You can also just initialise the list:
>
>    list<int>  L = {0, 2, 0, 5, 6};


In the C library you can do the equivalent with


     int tab[]={0, 2, 0, 5, 6};

     iList.InitializeWith(sizeof(int),5,tab);

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

#20619

jacob navia <jacob@spamsink.net> writes:

> Le 11/05/12 21:31, Ben Bacarisse a écrit :
>>
>> You can also just initialise the list:
>>
>>    list<int>  L = {0, 2, 0, 5, 6};
>
>
> In the C library you can do the equivalent with
>
>
>     int tab[]={0, 2, 0, 5, 6};
>
>     iList.InitializeWith(sizeof(int),5,tab);

The 5 is unfortunate.  Did you consider

  iList.InitializeWith(sizeof *tab, sizeof tab, tab);

?

-- 
Ben.

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

#20624

Le 11/05/12 22:02, Ben Bacarisse a écrit :
> jacob navia<jacob@spamsink.net>  writes:
>
>> Le 11/05/12 21:31, Ben Bacarisse a écrit :
>>>
>>> You can also just initialise the list:
>>>
>>>     list<int>   L = {0, 2, 0, 5, 6};
>>
>>
>> In the C library you can do the equivalent with
>>
>>
>>      int tab[]={0, 2, 0, 5, 6};
>>
>>      iList.InitializeWith(sizeof(int),5,tab);
>
> The 5 is unfortunate.  Did you consider
>
>    iList.InitializeWith(sizeof *tab, sizeof tab, tab);
>
> ?
>

The prototype is:
  List    *InitializeWith(size_t elementSize, size_t n, const void *Data);

You would propose then:
  List    *InitializeWith(size_t elementSize, size_t datasize, const 
void *Data);

where datasize would be the total size of the table, that should be a
multiple of elementSize?

I wote the 5 to be short. Normally I have a
#define SIZEOF(tab) (sizeof(tab)/sizeof(tab[0])
macro somewhere

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

#20626

jacob navia <jacob@spamsink.net> writes:

> Le 11/05/12 22:02, Ben Bacarisse a écrit :
>> jacob navia<jacob@spamsink.net>  writes:
>>
>>> Le 11/05/12 21:31, Ben Bacarisse a écrit :
>>>>
>>>> You can also just initialise the list:
>>>>
>>>>     list<int>   L = {0, 2, 0, 5, 6};
>>>
>>>
>>> In the C library you can do the equivalent with
>>>
>>>
>>>      int tab[]={0, 2, 0, 5, 6};
>>>
>>>      iList.InitializeWith(sizeof(int),5,tab);
>>
>> The 5 is unfortunate.  Did you consider
>>
>>    iList.InitializeWith(sizeof *tab, sizeof tab, tab);
>>
>> ?
>>
>
> The prototype is:
>  List    *InitializeWith(size_t elementSize, size_t n, const void *Data);
>
> You would propose then:
>  List    *InitializeWith(size_t elementSize, size_t datasize, const
> void *Data);
>
> where datasize would be the total size of the table, that should be a
> multiple of elementSize?

Yes.

> I wote the 5 to be short. Normally I have a
> #define SIZEOF(tab) (sizeof(tab)/sizeof(tab[0])
> macro somewhere

It all depends on how you think InitializeWith will be used.  How often
will the number of elements be more easily available than the number of
bytes?  Even if the answer is "almost always", n * sizeof *tab is
simpler that sizeof(tab)/sizeof(tab[0]).

-- 
Ben.

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

#20618

Le 11/05/12 21:31, Ben Bacarisse a écrit :
> for (int i: L) cout<<  i<<  " ";

I added this:

#if 0
    for(i=L.begin(); i != L.end(); ++i) cout << *i << " ";
    cout << endl;
#else
    for (int i: L) cout << i << " ";
#endif

and obtained:

~ $ g++ list.cpp
list.cpp: In function ‘int main()’:
list.cpp:25: error: a function-definition is not allowed here before ‘:’ 
token
list.cpp:27: error: expected primary-expression before ‘return’
list.cpp:27: error: expected `;' before ‘return’
list.cpp:27: error: expected primary-expression before ‘return’
list.cpp:27: error: expected `)' before ‘return’

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

#20622

jacob navia <jacob@spamsink.net> writes:

> Le 11/05/12 21:31, Ben Bacarisse a écrit :
>> for (int i: L) cout<<  i<<  " ";
>
> I added this:
>
> #if 0
>    for(i=L.begin(); i != L.end(); ++i) cout << *i << " ";
>    cout << endl;
> #else
>    for (int i: L) cout << i << " ";
> #endif
>
> and obtained:
>
> ~ $ g++ list.cpp
> list.cpp: In function ‘int main()’:
> list.cpp:25: error: a function-definition is not allowed here before
> ‘:’ token
> list.cpp:27: error: expected primary-expression before ‘return’
> list.cpp:27: error: expected `;' before ‘return’
> list.cpp:27: error: expected primary-expression before ‘return’
> list.cpp:27: error: expected `)' before ‘return’

Surely that's a question (if it is a question) for comp.lang.c++?  But
since I "opened the door" as they say in cheap TV legal dramas -- it's a
new feature, but recent g++ compilers have it (-std=c++0x).

-- 
Ben.

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

#20620

Le 11/05/12 21:31, Ben Bacarisse a écrit :
> for_each(L.begin(), L.end(), [](int i){ cout<<  i<<  " "; });

I added this:
    for_each(L.begin(), L.end(), [](int i){ cout << i << " "; });

as you wrote and obtained:

list.cpp:26: error: expected primary-expression before ‘[’ token
list.cpp:26: error: expected primary-expression before ‘]’ token
list.cpp:26: error: expected primary-expression before ‘int’

~$ g++ -v
Using built-in specs.
Target: i686-apple-darwin11
Configured with: 
/private/var/tmp/llvmgcc42/llvmgcc42-2336.9~22/src/configure 
--disable-checking --enable-werror 
--prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 
--mandir=/share/man --enable-languages=c,objc,c++,obj-c++ 
--program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ 
--with-slibdir=/usr/lib --build=i686-apple-darwin11 
--enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.9~22/dst-llvmCore/Developer/usr/local 
--program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 
--target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)

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

#20623

jacob navia <jacob@spamsink.net> writes:

> Le 11/05/12 21:31, Ben Bacarisse a écrit :
>> for_each(L.begin(), L.end(), [](int i){ cout<<  i<<  " "; });
>
> I added this:
>    for_each(L.begin(), L.end(), [](int i){ cout << i << " "; });
>
> as you wrote and obtained:

<snip errors>

It's valid C++, but surely this is not the place to discuss C++ errors?

-- 
Ben.

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

#20625

Le 11/05/12 22:11, Ben Bacarisse a écrit :
> It's valid C++, but surely this is not the place to discuss C++ errors?

Why not? If we are comparing C with C++ code it is ok.

Or did I made a transcription error?

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

#20752

On Friday, May 11, 2012 3:15:15 PM UTC-5, jacob navia wrote:
> Le 11/05/12 22:11, Ben Bacarisse a écrit :
> > It's valid C++, but surely this is not the place to discuss C++ errors?
> 
> Why not? If we are comparing C with C++ code it is ok.
> 
> Or did I made a transcription error?

The code is valid C++, but makes use of C++11 features which your compiler does not support.

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

#20621

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.

I was just asking from feedback about that, maybe improvements
proposals.

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

#20627

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!

> I was just asking from feedback about that, maybe improvements
> proposals.

What you have is probably the best that can be done within the confines 
of C.

-- 
Ian Collins

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

#20644

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.

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

#20645

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.

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]

#20647

On 05/12/12 07:48 PM, jacob navia wrote:
> 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.

Did anyone here make that claim?

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

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};

As I've said many times, the complexity in a given problem is fixed, 
where it occurs (in the language or in the code) is variable.

It's worth noting that most of the C++ improvements Ben introduced use 
new C++ features.  This is because a large proportion of the new 
features in C++11 were added to make the programmer's job easier.  It's 
a pity C11 didn't set out with the same objective.

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

Well that's a bit rich considering it was you who introduced the comparison!

> What would you propose? (Besides the obvious "Use C++")

Use the best tool for the job, which doesn't have to be C or C++.

-- 
Ian Collins

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

#20648

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!

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web