C++ has Boost libraries, C?

[websnarf]

(e-mail address removed) said:


And yet there are probably more libraries written in and for C than in or
for any other language.

Yes, but look at these libraries very carefully. *I* have written a
library for strings. CBFalconer has wriiten a library for hash tables.
Then there is this SGLib thing, and even Boost for C++. There are
things like the PCRE library for regexes as well. The GMP
multiprecision library is also a library that has been made available
for C. These sort of represent the general state of the art for C (and
C++).

Now look at a language like Python. There are of course no libraries
for strings, hash tables, or other ridiculously trivial data types or
any of the examples I cited above at all. Those are all encoded
basically as a handful of keystrokes. Python has bindings to Tk,
telnet, ftp, and other things. Not particular installations of Python
-- *ALL* Pythons have these things.

The very *concept* of what is meant by a library in each of these
languages are completely different. C and C++'s best and most useful
libraries are usually 1) trying to bring C and C++ up to the level of
where other languages are already without special libraries or 2) some
extremely specialized library for dealing with a platform specific
feature or device interface (driver.) In the first case, the large
numbers of C libraries are in a sense a *burden* to the C language
(since those features are not standard, or built in) and in the second,
those are not really *C* libraries, but rather specific
platform-specific and even usually compiler specific libraries.

The latest library that I personally have been looking is a library for
performing screen captures of my desktop (called "vnc2swf"). It
basically connects to VNC, and translates its output to a flash player
format. Now the author originally wrote the thing in C (or C++, I
don't remember) and basically gave up on it in favor of using Python.
Now why would he do that? Could it be that maintaining a cross
platform C library (and a seperate bug database for each operating
system, of course) is a bit of a pain in the ass? As hard as it is to
believe, he has written a screen capture utility that ends up being
cross platform, and which is trivial to extend and maintain precisely
because its written in Python.

Things like boost can be seen almost as a last grasp to keep C++
attractive to HLL programmers while languages like Python and Java
actually concern themselves will truly advanced functionality. And C
cannot even keep up with where C++ is.

So this claim that C has more libraries, maybe true, that doesn't
translate to being necessarily a good thing.

 

[jacob navia]

(e-mail address removed) a écrit :

Yes, but look at these libraries very carefully. *I* have written a
library for strings. CBFalconer has wriiten a library for hash tables.
Then there is this SGLib thing, and even Boost for C++. There are
things like the PCRE library for regexes as well. The GMP
multiprecision library is also a library that has been made available
for C. These sort of represent the general state of the art for C (and
C++).

Now look at a language like Python. There are of course no libraries
for strings, hash tables, or other ridiculously trivial data types or
any of the examples I cited above at all. Those are all encoded
basically as a handful of keystrokes. Python has bindings to Tk,
telnet, ftp, and other things. Not particular installations of Python
-- *ALL* Pythons have these things.

The very *concept* of what is meant by a library in each of these
languages are completely different. C and C++'s best and most useful
libraries are usually 1) trying to bring C and C++ up to the level of
where other languages are already without special libraries or 2) some
extremely specialized library for dealing with a platform specific
feature or device interface (driver.) In the first case, the large
numbers of C libraries are in a sense a *burden* to the C language
(since those features are not standard, or built in) and in the second,
those are not really *C* libraries, but rather specific
platform-specific and even usually compiler specific libraries.

The latest library that I personally have been looking is a library for
performing screen captures of my desktop (called "vnc2swf"). It
basically connects to VNC, and translates its output to a flash player
format. Now the author originally wrote the thing in C (or C++, I
don't remember) and basically gave up on it in favor of using Python.
Now why would he do that? Could it be that maintaining a cross
platform C library (and a seperate bug database for each operating
system, of course) is a bit of a pain in the ass? As hard as it is to
believe, he has written a screen capture utility that ends up being
cross platform, and which is trivial to extend and maintain precisely
because its written in Python.

Things like boost can be seen almost as a last grasp to keep C++
attractive to HLL programmers while languages like Python and Java
actually concern themselves will truly advanced functionality. And C
cannot even keep up with where C++ is.

So this claim that C has more libraries, maybe true, that doesn't
translate to being necessarily a good thing.

I would say the same thing. The mindset of many people here is
against any improvement of the expressivness of the language
itself. Not even basic things like a counted string data type
(that would kill many of the buffer overflow bugs) is deemed
necessary. C is basically seen by these people as a fixed
thing, unable to evolve or to correct its bugs.

The most conspicuous representant of this point of view is precisely
mr heathfield, that asked about "any bugs in C" and then...
went on to deny that any bug exist because "the standard specifies
it so".
Obvious, there isn't any bug when they all are "features" of the language.

The many string libraries around (even if they are correctly built)
just add to the confusion of having to choose and port a string
library, and having a computer language in 2006 that is unable
to provide such a basic data type.

The same thing applies to the containers, where C is more backward than
C++ that at least tries to provide that functionality albeit with
too much unnecessary complexity.

This doesn't HAVE to be like this, but it is like this. The C standards
comitee doesn't help either by freezing any developments until
probably 2020.

jacob

 

[Kenny McCormack]

The most conspicuous representant of this point of view is precisely
mr heathfield, that asked about "any bugs in C" and then...
went on to deny that any bug exist because "the standard specifies
it so".
Obvious, there isn't any bug when they all are "features" of the language.

That is just the way it is - in the context of this (hilariously named)
newsgroup.

The many string libraries around (even if they are correctly built)
just add to the confusion of having to choose and port a string
library, and having a computer language in 2006 that is unable
to provide such a basic data type.

Or 2007.

The real point is, as I've stated many times previously, that this
newsgroup is just misnamed. No sane person expects that a
generically-named/top-level newsgroup would be the kind of
anal-retentive place that this is. It'd be perfectly OK if this group
were renamed to something like: comp.lang.c.ansi-only, or
comp.lang.anal_c, or the like, leaving the top-level name available for
a group dedicated to general discussions of C (as sane people interpret
the term).

 

[santosh]

Yes, but look at these libraries very carefully. *I* have written a
library for strings. CBFalconer has wriiten a library for hash tables.
Then there is this SGLib thing, and even Boost for C++. There are
things like the PCRE library for regexes as well. The GMP
multiprecision library is also a library that has been made available
for C. These sort of represent the general state of the art for C (and
C++).

Now look at a language like Python. There are of course no libraries
for strings, hash tables, or other ridiculously trivial data types or
any of the examples I cited above at all. Those are all encoded
basically as a handful of keystrokes. Python has bindings to Tk,
telnet, ftp, and other things. Not particular installations of Python
-- *ALL* Pythons have these things.

I don't think it's quite fair to compare Python and C. Their origins
are seperated by more than a decade and, from the beginning, they've
targeted different programming domains, as you well know.


That said there're also C bindings to TCL/Tk, ftp etc. They're perhaps
trickier to use, but as far as I can tell, there're libraries available
for C programming, for virtually every aspect of computing.

But you're right. Python collects, integrates and presents them in a
far more homogeneous and simpler manner than C.

Things like boost can be seen almost as a last grasp to keep C++
attractive to HLL programmers while languages like Python and Java
actually concern themselves will truly advanced functionality. And C
cannot even keep up with where C++ is.

So this claim that C has more libraries, maybe true, that doesn't
translate to being necessarily a good thing.

Well since C was developed nearly two decades before Java and Python,
and primarily for systems programming, it's understandable that as
processor and memory capacity increases, the kind of programming style
required for C becomes ever more unpopular or restricted.

I think this is a natural consequence of dramatic increase in processor
speed and memory capacity combined with the near monopolisation of the
x86 architechture.

Unlike Jacob Navia, I don't see it as a disaster for C, rather it has
adapted to use in places where it's still relevant, even valuble.

 

[Serve Laurijssen]

Well since C was developed primarily for systems programming,

I think this is exactly why you dont see C evolve so much in the libraries
field. C doesnt pretend to be a high level application language. If you want
to create high level desktop stuff fast then surely another language is
better suited.
It's impossible to create a generic library for lets say containers when you
want to run on embedded systems too. It works fine on bigger operating
systems, but definately not on smaller systems. Instead, C gives you all the
basic building blocks you need to make your own higher level stuff. If you
want to make a string which knows its own length, by all means create one,
you have char *, you have integers to store the length and if you know you
wont get into memory problems because you have a GB to spare then sure make
one, but it just isnt possible to make such a library for *every* platform
that C promises to run on.
C++ competes with high level application languages like python so they
better make sure to add containers and regular expression and what not, but
I dont recall anybody saying that C competes with languages like python or
perl.

 

[Richard Heathfield]

Serve Laurijssen said:

I dont recall anybody saying that C competes with languages like
python or perl.

That's because it would be like saying an airliner competes with an
air-hostess's drinks trolley.

 

[Keith Thompson]

I would say the same thing. The mindset of many people here is
against any improvement of the expressivness of the language
itself.

This is just more of your usual nonsense.

[...]

This doesn't HAVE to be like this, but it is like this. The C standards
comitee doesn't help either by freezing any developments until
probably 2020.

C, which is what we discuss in this newsgroup, is defined by the
standard. We here in this newsgroup are not able to change the
standard; only the committee can do that. If you want the language to
be "improved", take it up with the committee, or at least discuss your
improvements in comp.std.c. See, for example, the recent discussion
there about overflow detection, in which you've participated.

 

[jacob navia]

Serve Laurijssen a écrit :

It's impossible to create a generic library for lets say containers when you
want to run on embedded systems too.

This is a fallacy. Embedded systems, precisely because of
the feeble hardware ressources, need MORE the good algorithms
than workstations, where with enough horsepower you can
afford a bubble sort for instance and get by with it.


A generic container library using operator overloading
does NOT introduce any higher costs than what is existent
NOW since you have to call a library function anyway, so
a function call does not incur in any extra overhead.

Specifically if you access a list with

List s,s1;

...
s1 = s[4];

or you use

List s,s1;

...
s1 = GetNthFromList(s,4);

It is the SAME overhead.

BUT, the first approach allows you to change your list into
a flexible array without touching the access method (that's why
it is generic).

If we get a standard container library with the same access method
it would work in all compilers and would save countless hours
where you code again and again the dammed list handling procedures.

 

[Keith Thompson]

A generic container library using operator overloading
does NOT introduce any higher costs than what is existent
NOW since you have to call a library function anyway, so
a function call does not incur in any extra overhead.

Operator overloading doesn't impose any performance overhead, but it
imposes the tremendous cost of making the code non-portable to any
implementation that doesn't support that particular extension in that
particular way.

Specifically if you access a list with

List s,s1;

...
s1 = s[4];

or you use

List s,s1;

...
s1 = GetNthFromList(s,4);

It is the SAME overhead.

BUT, the first approach allows you to change your list into
a flexible array without touching the access method (that's why
it is generic).

If we get a standard container library with the same access method
it would work in all compilers and would save countless hours
where you code again and again the dammed list handling procedures.

Yes, but you can't do that in C.

Do not, I repeat, *DO NOT*, interpret this as opposition to the idea
of adding operator overloading to some future version of the C
standard. It is simply a statement of fact about the C language as it
currently exists. I applaud you for implementing this extension in
your own compiler, and I encourage you to discuss it *in your own
newsgroup*.

 

[jacob navia]

Keith Thompson a écrit :

A generic container library using operator overloading
does NOT introduce any higher costs than what is existent
NOW since you have to call a library function anyway, so
a function call does not incur in any extra overhead.

Operator overloading doesn't impose any performance overhead, but it
imposes the tremendous cost of making the code non-portable to any
implementation that doesn't support that particular extension in that
particular way.

Specifically if you access a list with

List s,s1;

...
s1 = s[4];

or you use

List s,s1;

...
s1 = GetNthFromList(s,4);

It is the SAME overhead.

BUT, the first approach allows you to change your list into
a flexible array without touching the access method (that's why
it is generic).

If we get a standard container library with the same access method
it would work in all compilers and would save countless hours
where you code again and again the dammed list handling procedures.

Yes, but you can't do that in C.

Please, the topic of this thread is "Boost libraries". Nowhere the
C standard mentions boost libraries so we could stop any discussion
dead with:

"Boost libraries are not part of the C standard".

How can we follow the topic of this thread and still speak only
about the "C standard"???

 

[Keith Thompson]

Keith Thompson a écrit :

Please, the topic of this thread is "Boost libraries". Nowhere the
C standard mentions boost libraries so we could stop any discussion
dead with:

"Boost libraries are not part of the C standard".

How can we follow the topic of this thread and still speak only
about the "C standard"???

Please, the topic of this newsgroup is C.

The question was whether there are libaries for C similar to the Boost
library for C++. There's been a great deal of (mostly topical)
discussion of that question, some of which has pointed out the
difficulty of implementing something like Boost without the use of
some features that exist in C++ but not in C. The conclusion seems to
be that there are C libraries that provide some subset of Boost, but
not all of it. (I'm not an expert in either C++ or Boost, so I might
be misunderstanding some of this.)

Consider that the language implemented by lcc-win32, including its
extensions such as operator overloading, has much the same
relationship to standard C that C++ has to C. Both are closely based
on C, but provide a number of extra features that C lacks. (Yes,
lcc-win32's language is closer to C than C++ is.) I presume that you
wouldn't answer a question about C here with "You can do this using
C++ templates" (or exception handling, or whatever). Please consider
applying the same restraint when you consider discussion *your*
C-based language here.

 

[Mark McIntyre]

You can mark me down on the "don't" side.

Duly noted.
I meant, of course, /commercial/ developers....

gd&ravfi
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[CBFalconer]

.... snip ...

Do not, I repeat, *DO NOT*, interpret this as opposition to the
idea of adding operator overloading to some future version of the
C standard. It is simply a statement of fact about the C language
as it currently exists. I applaud you for implementing this
extension in your own compiler, and I encourage you to discuss it
*in your own newsgroup*.

However the implementation should have easy provisions to disable
ALL the extensions, or at least to detect and warn about them.

 

[Peter Nilsson]

And yet there are probably more libraries written in and for C than in or
for any other language.

Yup. If you want to build a railway, there's no shortage of different
track
gauges to choose from. :-b

 

[Keith Thompson]

However the implementation should have easy provisions to disable
ALL the extensions, or at least to detect and warn about them.

Yes, lcc-win32's "-ansic" option has already been mentioned here
recently. (I don't know how well it works, but at least it's there.)

 

[user923005]

Hello,

is there any library for C as Boost is for C++?

thanks in advance,

Boost is a template library.

C does not have anything like templates.

An Ada generic package is the closest other-language approximation I
can think of.

So the answer is 'no.' There is nothing like Boost (or the STL either)
in the C language. If someone says that there is something like it in
C, that means that they do not understand what a template does.

Of course, you can accomplish the same things in C that you can
accomplish in C++ and there are lots of prebuilt libraries for C to do
similar things to the things accomplished in Boost.

If your real question was "Are there enough available C tools to get my
work done?" then the answer is almost surely 'yes.'

 

[Chris Dollin]

Boost is a template library.

C does not have anything like templates.

An Ada generic package is the closest other-language approximation I
can think of.

(fx:OT)

Not Java generics or ML-style polymorphism (add modules to taste)?

 

[Jorgen Grahn]

Not to mention that if you want to make your library useful for anyone,
using any language, you expose a C API.

....

Now look at a language like Python. [...] Python has bindings to Tk,
telnet, ftp, and other things. Not particular installations of Python
-- *ALL* Pythons have these things.

And many or most of them are really based on C interfaces -- modules os,
posix, socket, zlib, ... for many things, they have just been able to say
"lots of people seem to use libfoo -- let's package it as module foo and
make it standard".

But I have to admit that there is a lot of useful stuff in Python, Perl,
Ruby etc by default, and the interfaces to them are made convenient by the
expressiveness of the language.

The very *concept* of what is meant by a library in each of these
languages are completely different. C and C++'s best and most useful
libraries are usually 1) trying to bring C and C++ up to the level of
where other languages are already without special libraries or 2) some
extremely specialized library for dealing with a platform specific
feature or device interface (driver.)

Take a look at the hundreds of libraries installed or available on any *BSD
or Linux system. Almost none of them fit into either category.

Things like boost can be seen almost as a last grasp to keep C++
attractive to HLL programmers while languages like Python and Java
actually concern themselves will truly advanced functionality. And C
cannot even keep up with where C++ is.

If you choose to interpret it that way. I choose to see things like Boost as
a serious attempt to make programs better and easier to write.

/Jorgen

 

[Roland Pibinger]

The conclusion seems to
be that there are C libraries that provide some subset of Boost, but
not all of it. (I'm not an expert in either C++ or Boost, so I might
be misunderstanding some of this.)

The least thing C 'needs' is a Boost-like library. Boost represents
the polar opposite of the C programming style as popularized by K&R.
It would be interesting to historically analyze how and why the 'C
philosophy' (which also is the Unix philosphy, aptly summarized by
Raymond in http://www.catb.org/~esr/writings/taoup/html/ch01s07.html)
finally ended in something that is the opposite of the inventors'
intentions. But probably programming languages are not interesting
enough to write books about their evolution (and decline).

Best regards,
Roland Pibinger

 

[Ian Collins]

The least thing C 'needs' is a Boost-like library. Boost represents
the polar opposite of the C programming style as popularized by K&R.

Surely Boos is the embodiment of what is often suggested here for
language extensions - implement it, make it available and if the
interest is there it will find its way into the next standard.

It would be interesting to historically analyze how and why the 'C
philosophy' (which also is the Unix philosphy, aptly summarized by
Raymond in http://www.catb.org/~esr/writings/taoup/html/ch01s07.html)
finally ended in something that is the opposite of the inventors'
intentions. But probably programming languages are not interesting
enough to write books about their evolution (and decline).

The Design an Evolution of C++ is still in print after 12 years.