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

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

The C Containers library

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

Contents

  The C Containers library jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-01 10:24 +0100
    Re: The C Containers library Ian Collins <ian-news@hotmail.com> - 2015-11-01 22:43 +1300
      Re: The C Containers library jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-01 12:08 +0100
        Re: The C Containers library Ian Collins <ian-news@hotmail.com> - 2015-11-02 10:46 +1300
          Re: The C Containers library jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-01 23:10 +0100
    Re: The C Containers library gazelle@shell.xmission.com (Kenny McCormack) - 2015-11-01 10:57 +0000
    Re: The C Containers library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-01 10:57 +0000
      Re: The C Containers library Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-01 03:30 -0800
        Re: The C Containers library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-01 16:36 +0000
          Re: The C Containers library Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-01 10:04 -0800
            Re: The C Containers library Ian Collins <ian-news@hotmail.com> - 2015-11-02 07:23 +1300
              Re: The C Containers library Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-01 13:25 -0800
              Re: The C Containers library supercat@casperkitty.com - 2015-11-01 15:44 -0800
            Re: The C Containers library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-01 23:50 +0000
              Re: The C Containers library Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-02 01:19 -0800
                Re: The C Containers library Ian Collins <ian-news@hotmail.com> - 2015-11-02 22:33 +1300
                  Re: The C Containers library Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-02 02:04 -0800
    Re: The C Containers library Keith Thompson <kst-u@mib.org> - 2015-11-01 12:04 -0800
      Re: The C Containers library Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-11-01 15:41 -0500
        Re: The C Containers library Keith Thompson <kst-u@mib.org> - 2015-11-01 13:26 -0800
          Re: The C Containers library Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-11-01 16:50 -0500

Page 1 of 2  [1] 2  Next page →

#74528 — The C Containers library

I posted  yesterday a pointer to a pure C package, that allows any C 
programmer to enjoy the samelevel of abstraction than C++. In the post 
there were two small errors that allowed some people to just say "It 
doesn't compile" and leave it there, even if the errors are VERY easy to 
fix.

I post again the two examples and ask for a real discussion here, 
instead of pointing to details.

The task
--------
You have a file with an unknown number of text lines of variable
lengths. Read the lines and write them out sorted in another file.

The C++ solution
------------------------------------------------------
#include <vector>
#include <fstream>
#include <algorithm>
#include <iterator>
#include <string>

using namespace std;

int main(int argc,char* argv[])
{
     char* file = argv[2];    // input file name
     char* ofile = argv[3];   // output file name

     vector<string> buf;

     fstream fin(file, ios::in);
     string d;
     while(getline(fin, d)) buf.push_back(d);  //add line to buf
     sort(buf.begin(), buf.end());
     fstream fout(ofile, ios::out);
     copy(buf.begin(), buf.end(), ostream_iterator<string>(fout,"\n"));

}
--------------------------------------------------

The C solution

-------------------------------------------------
#include <containers.h>

int main(void)
{
     strCollection *myData =
         istrCollection.CreateFromFile("mydata.txt");
     istrCollection.Sort(myData);
     istrCollection.WriteToFile(myData,"mySortedData.txt");
     return 0;
}
-------------------------------------------------

URL:
https://code.google.com/p/ccl/

The code is completely free, no strings attached.

[toc] | [next] | [standalone]

#74531

jacobnavia wrote:
> I posted  yesterday a pointer to a pure C package, that allows any C
> programmer to enjoy the samelevel of abstraction than C++. In the post
> there were two small errors that allowed some people to just say "It
> doesn't compile" and leave it there, even if the errors are VERY easy to
> fix.

While your library is sound, to justify your same level of abstraction 
as C++ claim, you would have to show how easy it is to repeat the 
process with something other than strings.  Start with something simple 
like a file of Foo records, where Foo is:

struct Foo
{
   int a;
   int b;
   int c;
};

Being able to work with generic types is where the flexibility of the 
C++ containers lies.

-- 
Ian Collins

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

#74537

Le 01/11/2015 10:43, Ian Collins a écrit :
> jacobnavia wrote:
>> I posted  yesterday a pointer to a pure C package, that allows any C
>> programmer to enjoy the samelevel of abstraction than C++. In the post
>> there were two small errors that allowed some people to just say "It
>> doesn't compile" and leave it there, even if the errors are VERY easy to
>> fix.
>
> While your library is sound, to justify your same level of abstraction
> as C++ claim, you would have to show how easy it is to repeat the
> process with something other than strings.  Start with something simple
> like a file of Foo records, where Foo is:
>
> struct Foo
> {
>    int a;
>    int b;
>    int c;
> };
>
> Being able to work with generic types is where the flexibility of the
> C++ containers lies.
>

Yes, that is why the C containers library provides a "template" file 
with all the code for some containers like lists, vectors, strings, so 
that they are generic.

You define a small parameter file, and the C preprocessor will do the rest.

Let's suppose that you want to define a vector for the "size_t" type.


   1 #include "containers.h"
   2 #undef DATA_TYPE
   3 #define DATA_TYPE size_t
   4 #include "vectorgen.c"


You will get a bunch of functions defined that you can put in a library.
The interface function table will be iDATA_TYPEVectorInterface, where 
"DATA_TYPE" is the name of your data type, in this case size_t.

So, you call the interface with

isize_tVectorInterface.Add(...)

Since you have all the source code you can use other naming conventions.

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

#74588

jacobnavia wrote:
> Le 01/11/2015 10:43, Ian Collins a écrit :
>> jacobnavia wrote:
>>> I posted  yesterday a pointer to a pure C package, that allows any C
>>> programmer to enjoy the samelevel of abstraction than C++. In the post
>>> there were two small errors that allowed some people to just say "It
>>> doesn't compile" and leave it there, even if the errors are VERY easy to
>>> fix.
>>
>> While your library is sound, to justify your same level of abstraction
>> as C++ claim, you would have to show how easy it is to repeat the
>> process with something other than strings.  Start with something simple
>> like a file of Foo records, where Foo is:
>>
>> struct Foo
>> {
>>     int a;
>>     int b;
>>     int c;
>> };
>>
>> Being able to work with generic types is where the flexibility of the
>> C++ containers lies.
>>
>
> Yes, that is why the C containers library provides a "template" file
> with all the code for some containers like lists, vectors, strings, so
> that they are generic.
>
> You define a small parameter file, and the C preprocessor will do the rest.
>
> Let's suppose that you want to define a vector for the "size_t" type.
>
>
>     1 #include "containers.h"
>     2 #undef DATA_TYPE
>     3 #define DATA_TYPE size_t
>     4 #include "vectorgen.c"
>
>
> You will get a bunch of functions defined that you can put in a library.
> The interface function table will be iDATA_TYPEVectorInterface, where
> "DATA_TYPE" is the name of your data type, in this case size_t.
>
> So, you call the interface with
>
> isize_tVectorInterface.Add(...)
>
> Since you have all the source code you can use other naming conventions.

That makes sense.

Can you define ordering and I/O functions for user defined types with 
this mechanism?

-- 
Ian Collins

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

#74590

Le 01/11/2015 22:46, Ian Collins a écrit :
> Can you define ordering and I/O functions for user defined types with
> this mechanism?

The library defaults to memcmp for ordering. It is up to you to override 
that default if you want, and provide a comparison function that will be 
used if present.


Concerning I/O it offers also a save/restore utility that calls your 
Output and Input routines. If you do not override the default it will 
just use fwrite.

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

#74534

In article <n14lk4$hmh$1@dont-email.me>,
jacobnavia  <jacob@jacob.remcomp.fr> wrote:
>I posted  yesterday a pointer to a pure C package, that allows any C 
>programmer to enjoy the samelevel of abstraction than C++. In the post 
>there were two small errors that allowed some people to just say "It 
>doesn't compile" and leave it there, even if the errors are VERY easy to 
>fix.

Par for the course in CLC.

>I post again the two examples and ask for a real discussion here, 
>instead of pointing to details.

Par for the course in CLC.

How long have you been reading/posting here?  You (of all people) should be
well aware that that's all their tiny little brains are capable of.

-- 
BigBusiness types (aka,
    Republicans/Conservatives/Independents/Liberatarians/whatevers)
don't hate big government.  They *love* big government as a means for
them to get rich, sucking off the public teat.  What they don't like is
*democracy* - little people actually having the right to vote and stuff
like that.

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

#74535

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

> I posted  yesterday a pointer to a pure C package, that allows any C
> programmer to enjoy the samelevel of abstraction than C++.
<snip>
> I post again the two examples and ask for a real discussion here,
> instead of pointing to details.
<snip>
> ------------------------------------------------------
> #include <vector>
> #include <fstream>
> #include <algorithm>
> #include <iterator>
> #include <string>
>
> using namespace std;
>
> int main(int argc,char* argv[])
> {
>     char* file = argv[2];    // input file name
>     char* ofile = argv[3];   // output file name

(Odd numbers.  I changed this 1 and 2 to make testing more obvious.)

>     vector<string> buf;
>
>     fstream fin(file, ios::in);
>     string d;
>     while(getline(fin, d)) buf.push_back(d);  //add line to buf
>     sort(buf.begin(), buf.end());
>     fstream fout(ofile, ios::out);
>     copy(buf.begin(), buf.end(), ostream_iterator<string>(fout,"\n"));
>
> }
> --------------------------------------------------
>
> The C solution
>
> -------------------------------------------------
> #include <containers.h>
>
> int main(void)
> {
>     strCollection *myData =
>         istrCollection.CreateFromFile("mydata.txt");
>     istrCollection.Sort(myData);
>     istrCollection.WriteToFile(myData,"mySortedData.txt");

(and I replaced the the wired in names by argv[1] and argv[2] to make
the testing simpler.)

>     return 0;
> }
> -------------------------------------------------

These don't show the same level of abstraction.  The C++ uses a more
abstract collection (vector) than the C code does -- the C version has
the type of the elements wired into to the code.  The same level of
abstraction would need a string type, and a generic collection type that
can use it.

That's very hard in C which is, I think, why you introduced the specific
generalisation of a strCollection.

The C++ also makes use of the very general abstraction of iterators.  I
doubt that your collection library permits a copy function to be
implemented that can copy any ordered collection to anything that has a
suitable output iterator.  It's not used to much effect here, but it
does illustrate the possibility of some very abstract algorithms.

<snip>
-- 
Ben.

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

#74538

On Sunday, November 1, 2015 at 10:57:51 AM UTC, Ben Bacarisse wrote:
>
> These don't show the same level of abstraction.  The C++ uses a more
> abstract collection (vector) than the C code does -- the C version has
> the type of the elements wired into to the code.  The same level of
> abstraction would need a string type, and a generic collection type that
> can use it.
> 
> That's very hard in C which is, I think, why you introduced the specific
> generalisation of a strCollection.
> 
Not really.
However in C you approach the problem differently. You pass in an object's
bit pattern and its size, and you make sure you get the same bit pattern
back.
You pass an ordered list by passing an array, if you want to do it generically.
If you want to pass a linked list or a more complex graph, you need a bit
of boilerplate code (you can call it a "design pattern" if you like buzz words),
which is usually simply for(ptr = head; ptr != 0; ptr = ptr->next). Proposals
for standard containers (Like Jacob's) have generally failed - it would only
take five minutes to design a stdlinkedlist header, but in fact everyone prefers
to roll their own. Whether that says something good or bad about C is a good
question.

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

#74568

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Sunday, November 1, 2015 at 10:57:51 AM UTC, Ben Bacarisse wrote:
>>
>> These don't show the same level of abstraction.  The C++ uses a more
>> abstract collection (vector) than the C code does -- the C version has
>> the type of the elements wired into to the code.  The same level of
>> abstraction would need a string type, and a generic collection type that
>> can use it.
>> 
>> That's very hard in C which is, I think, why you introduced the specific
>> generalisation of a strCollection.
>> 
> Not really.

Yes really.  Nothing I said is wrong.

> However in C you approach the problem differently. You pass in an object's
> bit pattern and its size, and you make sure you get the same bit pattern
> back.

Jacob's collection use that approach but it does not work for strings,
hence the specialised interface.

> You pass an ordered list by passing an array, if you want to do it generically.
> If you want to pass a linked list or a more complex graph, you need a bit
> of boilerplate code (you can call it a "design pattern" if you like buzz words),
> which is usually simply for(ptr = head; ptr != 0; ptr = ptr->next). Proposals
> for standard containers (Like Jacob's) have generally failed - it would only
> take five minutes to design a stdlinkedlist header, but in fact everyone prefers
> to roll their own. Whether that says something good or bad about C is a good
> question.

Yes, I mostly agree with this -- the C way it to roll your own non-abstract
container interfaces.  Often again and again.  Sometimes with new bugs.

-- 
Ben.

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

#74574

On Sunday, November 1, 2015 at 4:37:09 PM UTC, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 
> Yes really.  Nothing I said is wrong.
> 
Robotics is hard, and most people start by trying to simplify the#
environment the robot works in.
However I've been told, by people I believe, that the insight you
need is to simplify the robot. If the robot is simple enough, it
can cope with pretty much anything the environment throws at it.

There's an analogy with containers. Simplify the language, and many
of the problems and issues just disappear. It's not that it's hard 
to write an abstract container in C, it's that the problems simply
don't arise, there's no complexity to abstract over.

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

#74575

Malcolm McLean wrote:
> On Sunday, November 1, 2015 at 4:37:09 PM UTC, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> Yes really.  Nothing I said is wrong.
>>
> Robotics is hard, and most people start by trying to simplify the#
> environment the robot works in.
> However I've been told, by people I believe, that the insight you
> need is to simplify the robot. If the robot is simple enough, it
> can cope with pretty much anything the environment throws at it.
>
> There's an analogy with containers. Simplify the language, and many
> of the problems and issues just disappear. It's not that it's hard
> to write an abstract container in C, it's that the problems simply
> don't arise, there's no complexity to abstract over.

If you simplify the language, you move the problems from the language to 
the programmer.  Otherwise we would all be writing our code in binary.

-- 
Ian Collins

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

#74583

On Sunday, November 1, 2015 at 6:23:36 PM UTC, Ian Collins wrote:
> Malcolm McLean wrote:
>
> If you simplify the language, you move the problems from the language to 
> the programmer.  Otherwise we would all be writing our code in binary.
> 
It's certainly very easy to produce something which is Turing equivalent,
but unusable for anything other than a few demo programs written to
prove the point.
The insight you need is that most data is real values, strings, or
indexes into arrays. Not in a mathematically rigourous, proveable
sense. Just that's what most programs deal with - things we measure
are usually continuous, things we count tend to have measurements
attached to them, and humans communicate with humans, in a computer
context,using text. 
So you can start by reducing your data types to three.

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

#74598

On Sunday, November 1, 2015 at 12:23:36 PM UTC-6, Ian Collins wrote:
> If you simplify the language, you move the problems from the language to 
> the programmer.  Otherwise we would all be writing our code in binary.

While I like the idea of having a C library include some features to support
data structures beyond the qsort and bsearch methods that predate C89, there
are so many different requirements that it's hard to know what features would
offer particular benefits if added to the Standard.

A principle I do think is important, however, is to recognize that it's
often important to let programmers not only control corner-case behaviors but
indicate whether or not they're important.  A function to return a range of
items from a collection may sometimes be used in cases where it should return
as much data is available if the whole request can't be satisfied, and may
sometimes be used in cases where it should either satisfy the request
completely or refuse it altogether.  Great debates may ensue about which
approach is right, when the answer is that because each approach is right in
some circumstances and wrong in others, a good library should provide methods
with both kinds of semantics.

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

#74601

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Sunday, November 1, 2015 at 4:37:09 PM UTC, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> 
>> Yes really.  Nothing I said is wrong.
>> 
> Robotics is hard, and most people start by trying to simplify the#
> environment the robot works in.
> However I've been told, by people I believe, that the insight you
> need is to simplify the robot. If the robot is simple enough, it
> can cope with pretty much anything the environment throws at it.
>
> There's an analogy with containers. Simplify the language, and many
> of the problems and issues just disappear. It's not that it's hard 
> to write an abstract container in C, it's that the problems simply
> don't arise, there's no complexity to abstract over.

I suspect another language issue, because I can't force this remark to
be true with any of the meanings available to me for the terms it uses.

I can see how to simplify the language by removing the type-checking
(you use void * and sizes) but then it's not true that problems simply
don't arise.  If you keep the idea of types (with all the safety that
brings with it) then there is complexity that C can't abstract over.

-- 
Ben.

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

#74623

On Sunday, November 1, 2015 at 11:50:35 PM UTC, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 
> I can see how to simplify the language by removing the type-checking
> (you use void * and sizes) but then it's not true that problems simply
> don't arise.  If you keep the idea of types (with all the safety that
> brings with it) then there is complexity that C can't abstract over.
> 
It's not all or nothing - "types" or "binary bits". You can allow
very rich types, like C++.
But then that means that "memcpy(&dest, &src, sizeof(type)) is no
longer adequate. So you need a "copy constructor". Which means that
containers need some way of automatically linking to the copy 
constructor. Then you find that, for efficiency, you need a "move
constructor". You also need a "default constructor" to create
null objects, which gives rise to the concept of the "null object"
as well as the "null pointer - all the methods have to react 
appropriately to being passed a null object. The complexities grow.

A C "vector", however, is simply

struct C_vector
{
   unsigned char *base;
   int N; // number of elements
   int size; // buffer size
   size_t elsize; // size of element
}

then you use memmove and memcpy to keep the contents in an array.
There's no complexity of constructor calls.

You can object that it's possible to create a struct with a pointer
to itself, which will break when moved. Fair enough. But we can live
with that. 

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

#74625

Malcolm McLean wrote:
> On Sunday, November 1, 2015 at 11:50:35 PM UTC, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> I can see how to simplify the language by removing the type-checking
>> (you use void * and sizes) but then it's not true that problems simply
>> don't arise.  If you keep the idea of types (with all the safety that
>> brings with it) then there is complexity that C can't abstract over.
>>
> It's not all or nothing - "types" or "binary bits". You can allow
> very rich types, like C++.

Or C.

> But then that means that "memcpy(&dest, &src, sizeof(type)) is no
> longer adequate.

Which happens as soon as you have a struct with pointer members and you 
want to maintain some degree of sanity regarding ownership of the 
dynamic memory.

> So you need a "copy constructor". Which means that
> containers need some way of automatically linking to the copy
> constructor. Then you find that, for efficiency, you need a "move
> constructor". You also need a "default constructor" to create
> null objects, which gives rise to the concept of the "null object"
> as well as the "null pointer - all the methods have to react
> appropriately to being passed a null object. The complexities grow.

That's something I've very rarely seen in C++ or C.  If a default 
constructor isn't appropriate, block it.

> A C "vector", however, is simply
>
> struct C_vector
> {
>     unsigned char *base;
>     int N; // number of elements
>     int size; // buffer size
>     size_t elsize; // size of element
> }
>
> then you use memmove and memcpy to keep the contents in an array.
> There's no complexity of constructor calls.

For trivial data types, maybe.  For most real world ones, things will 
get more complicated.

-- 
Ian Collins

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

#74630

On Monday, November 2, 2015 at 9:33:19 AM UTC, Ian Collins wrote:
> Malcolm McLean wrote:
> 
> > But then that means that "memcpy(&dest, &src, sizeof(type)) is no
> > longer adequate.
> 
> Which happens as soon as you have a struct with pointer members and you 
> want to maintain some degree of sanity regarding ownership of the 
> dynamic memory.
> 
You pass in pointers to the structs. As soon as you've got a rich set of pointer
members, such that it's hard to keep track of ownership, it's easiest to keep
everything dynamically allocated on the heap and not try to support stack
objects.
>
> > You also need a "default constructor" to create
> > null objects, which gives rise to the concept of the "null object"
> > as well as the "null pointer - all the methods have to react
> > appropriately to being passed a null object. The complexities grow.
> 
> That's something I've very rarely seen in C++ or C.  If a default 
> constructor isn't appropriate, block it.
>
I've seen null objects recommended. There's also a boost::optional to allow
nothing to be passed. In C, of course, you just use null pointers. 
 >
> For trivial data types, maybe.  For most real world ones, things will 
> get more complicated.
> 
Firstly, you often do need arrays of trivial data types. Its very common to need
an array of 2D points to describe something, for example. As programs gain 
complexity, those arrays don't usually grow in complexity with them, they
become more numerous and get embedded in higher-level structures.

Then once you've got a web of pointers pointing to each other, the structure has
become a graph. it's unlikely that most data is on the stack. Just put everything
on the heap, including the root. 

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

#74578

jacobnavia <jacob@jacob.remcomp.fr> writes:
> I posted  yesterday a pointer to a pure C package, that allows any C 
> programmer to enjoy the samelevel of abstraction than C++. In the post 
> there were two small errors that allowed some people to just say "It 
> doesn't compile" and leave it there, even if the errors are VERY easy to 
> fix.
>
> I post again the two examples and ask for a real discussion here, 
> instead of pointing to details.
>
> The task
> --------
> You have a file with an unknown number of text lines of variable
> lengths. Read the lines and write them out sorted in another file.
>
> The C++ solution
> ------------------------------------------------------
[snip]
> int main(int argc,char* argv[])
> {
>      char* file = argv[2];    // input file name
>      char* ofile = argv[3];   // output file name
[snip]
> }
> --------------------------------------------------
>
> The C solution
>
> -------------------------------------------------
> #include <containers.h>
>
> int main(void)
> {
>      strCollection *myData =
>          istrCollection.CreateFromFile("mydata.txt");
>      istrCollection.Sort(myData);
>      istrCollection.WriteToFile(myData,"mySortedData.txt");
>      return 0;
> }
> -------------------------------------------------

Discussion would be easier if you would at least make the C++
and C solutions equivalent.

The C++ version takes the input and output file names from command
line arguments (and doesn't check whether those arguments exist).
The C version uses hardwired file names.

Yes, this is a minor detail, easily fixed, and no, I'm not commenting
on the collections library itself.  I might consider doing so if I
thought there was any chance you'd be receptive to anything I have
to say.  History suggests you would not.

> URL:
> https://code.google.com/p/ccl/
>
> The code is completely free, no strings attached.

Not true.  The code is licensed under the BSD 3-Clause License.
It is a free software license, but it does attach some strings,
including a requirement to retain the copyright notice.  A minor
detail, but IMHO an important one.

-- 
Keith Thompson (The_Other_Keith) kst-u@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"

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

#74582

On Sunday November 1 2015 15:04, in comp.lang.c, "Keith Thompson"
<kst-u@mib.org> wrote:

> jacobnavia <jacob@jacob.remcomp.fr> writes:
>> I posted  yesterday a pointer to a pure C package, that allows any C
>> programmer to enjoy the samelevel of abstraction than C++.
[snip]
>> URL:
>> https://code.google.com/p/ccl/
>>
>> The code is completely free, no strings attached.
> 
> Not true.  The code is licensed under the BSD 3-Clause License.
> It is a free software license, but it does attach some strings,
> including a requirement to retain the copyright notice.  A minor
> detail, but IMHO an important one.

As a "third-party library", I must say that Jacob's Container Library seems
both comprehensive and (relatively) easy to use. I don't find Jacob's use of
the BSD 3-clause licence any more restrictive than any other 3rd-party
library I use.

I note that Jacob seems to have taken the initiative to submit his library's
documentation to the C language committee (Pre-Portland mailings, 2012, 
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1625.pdf ), something that
very few third-party library authors do. Jacob's efforts to advance the C
language should be applauded, whether we agree with his approach or not.

I don't particularly care whether any new revision of the C standard includes
a "standard container library". But, then again, I don't care that the recent
revisions of the language standard now include a "standard threading model"
either.

The deciding question, to me, is one of utility: "Can I write better (for a
loose definition of "better") code to do this than I can get from the
standard libraries or from some third-party?" If I can answer "Yes" to the
question, then I write the code, otherwise I go looking for something to ease
my efforts.

So, Thank you, Jacob, for the fine code and your efforts to establish some
sort of standard.
 
-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

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

#74584

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
> On Sunday November 1 2015 15:04, in comp.lang.c, "Keith Thompson"
> <kst-u@mib.org> wrote:
>
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>> I posted  yesterday a pointer to a pure C package, that allows any C
>>> programmer to enjoy the samelevel of abstraction than C++.
> [snip]
>>> URL:
>>> https://code.google.com/p/ccl/
>>>
>>> The code is completely free, no strings attached.
>> 
>> Not true.  The code is licensed under the BSD 3-Clause License.
>> It is a free software license, but it does attach some strings,
>> including a requirement to retain the copyright notice.  A minor
>> detail, but IMHO an important one.
>
> As a "third-party library", I must say that Jacob's Container Library seems
> both comprehensive and (relatively) easy to use. I don't find Jacob's use of
> the BSD 3-clause licence any more restrictive than any other 3rd-party
> library I use.

To be clear, I have no objection to jacob's choice of license.
I was merely pointing out that his "no strings attached" claim
is not entirely accurate.  I mention this again only because you
replied to my followup rather than to jacob's original article.

-- 
Keith Thompson (The_Other_Keith) kst-u@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"

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web