C++ has Boost libraries, C?

[g]

Hello,

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

thanks in advance,

[Richard Heathfield]

g said:

Hello,

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

There are lots of libraries available with C bindings. What functionality
are you after?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Peter Nilsson]

Richard Heathfield wrote:

g said:

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

There are lots of libraries available with C bindings.

True, but that doesn't answer the question.

What Boost is for C++ is clear from the Boost front page...

http://www.boost.org/

There is no such equivalent for C.

--
Peter

[websnarf]

Peter Nilsson wrote:

Richard Heathfield wrote:

g said:

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

There are lots of libraries available with C bindings.

True, but that doesn't answer the question.

What Boost is for C++ is clear from the Boost front page...

http://www.boost.org/

There is no such equivalent for C.

True, but there is this:

http://sglib.sourceforge.net/

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Richard Heathfield]

Peter Nilsson said:

Richard Heathfield wrote:

>g said:

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

There are lots of libraries available with C bindings.

True, but that doesn't answer the question.

That depends on how you read the question. The way I read the question, my
answer answered it (correctly).

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Kenny McCormack]

In article <RJ*********************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>Peter Nilsson said:

>Richard Heathfield wrote:

>>g said:
is there any library for C as Boost is for C++?

There are lots of libraries available with C bindings.

True, but that doesn't answer the question.

That depends on how you read the question. The way I read the question, my
answer answered it (correctly).

Quelle surprise!

[Serve Laurijssen]

<we******@gmail.comwrote in message
news:11**********************@q40g2000cwq.googlegr oups.com...

Peter Nilsson wrote:

>Richard Heathfield wrote:

g said:
is there any library for C as Boost is for C++?
There are lots of libraries available with C bindings.

True, but that doesn't answer the question.

What Boost is for C++ is clear from the Boost front page...

http://www.boost.org/

There is no such equivalent for C.

True, but there is this:

http://sglib.sourceforge.net/

that lib only implements some containers and algorithms on them but that
doesnt even come close. Boost has way more to offer. There really is no such
thing for C and its also impossible to do something like that just because C
misses lots of C++ features.

[jacob navia]

Serve Laurijssen a écrit :

<we******@gmail.comwrote in message
news:11**********************@q40g2000cwq.googlegr oups.com...

>>Peter Nilsson wrote:

>>>Richard Heathfield wrote:

g said:

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

There are lots of libraries available with C bindings.

True, but that doesn't answer the question.

What Boost is for C++ is clear from the Boost front page...

http://www.boost.org/

There is no such equivalent for C.

True, but there is this:

http://sglib.sourceforge.net/

that lib only implements some containers and algorithms on them but that
doesnt even come close. Boost has way more to offer. There really is no such
thing for C and its also impossible to do something like that just because C
misses lots of C++ features.

The only feature that is really needed is operator overloading,
specifically the '[ ']' operator.

In the lcc-win32 compiler system, I have developed an
experimental library with lists, resizable arrays, stacks, and other
containers that are addressed with the indexing operator.

Works quite nice.

http://www.cs.virginia.edu/~lcc-win32

[Serve Laurijssen]

"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:45***********************@news.orange.fr...

The only feature that is really needed is operator overloading,
specifically the '[ ']' operator.

In the lcc-win32 compiler system, I have developed an
experimental library with lists, resizable arrays, stacks, and other
containers that are addressed with the indexing operator.

Works quite nice.

http://www.cs.virginia.edu/~lcc-win32

yeah I made something like that too, but those are all containers.
boost has way more to offer

[Roland Pibinger]

On 6 Jan 2007 12:48:25 -0800, "g" wrote:

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

Boost is a set of experimental C++ template libraries that will never
attract the C++ mass-market due to their inherent complexity,
clumsiness and impracticality.
Why are you looking for something comparable in C? OTOH, if you just
want a C foundation library:
http://developer.gnome.org/doc/API/2.0/glib/index.html

Best wishes,
Roland Pibinger

[santosh]

g wrote:

Hello,

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

thanks in advance,

Not quite, but two useful utility libraries that can be used by C
programmers are GLib and Apache Portable Runtime. Google to find the
links. Also have a look at snippets.org.

[g]

every serious C++ software house use BOOST...

I am wondering if there is anything like that for C....
portable and robust libs...

[g]

yes, I know APR, robust, portable and efficient...

[santosh]

g wrote:

yes, I know APR, robust, portable and efficient...

Please quote the material to which you're replying. Without context,
it's hard for traditional users of Usenet to understand your article.

[Mark McIntyre]

On 6 Jan 2007 16:50:06 -0800, in comp.lang.c , "Peter Nilsson"
<ai***@acay.com.auwrote:

>Richard Heathfield wrote:

>g said:

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

There are lots of libraries available with C bindings.

True, but that doesn't answer the question.

What Boost is for C++ is clear from the Boost front page...

http://www.boost.org/

There is no such equivalent for C.

Sure, because boost does a bunch of stuff that makes no sense in C.
Might as well ask if there's a library for Visual Basic that does
11/780 low-level IO.

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

[Mark McIntyre]

On Sun, 07 Jan 2007 16:27:25 GMT, in comp.lang.c , rp*****@yahoo.com
(Roland Pibinger) wrote:

>On 6 Jan 2007 12:48:25 -0800, "g" wrote:

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

Boost is a set of experimental C++ template libraries that will never
attract the C++ mass-market due to their inherent complexity,

Whoof! I don't know many people these days that /don't'/ use Boost in
C++ development!
--
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

[Richard Heathfield]

Mark McIntyre said:

On Sun, 07 Jan 2007 16:27:25 GMT, in comp.lang.c , rp*****@yahoo.com
(Roland Pibinger) wrote:

>>On 6 Jan 2007 12:48:25 -0800, "g" wrote:

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

Boost is a set of experimental C++ template libraries that will never
attract the C++ mass-market due to their inherent complexity,

Whoof! I don't know many people these days that /don't'/ use Boost in
C++ development!

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

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Keith Thompson]

"g" <ge*******@yahoo.comwrites:

yes, I know APR, robust, portable and efficient...

Please provide context when you post a followup; don't assume your
readers can see the article to which you're replying.

See <http://cfaj.freeshell.org/google/>.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[websnarf]

Serve Laurijssen wrote:

<we******@gmail.comwrote in message

Peter Nilsson wrote:

Richard Heathfield wrote:
g said:
is there any library for C as Boost is for C++?
There are lots of libraries available with C bindings.

True, but that doesn't answer the question.

What Boost is for C++ is clear from the Boost front page...

http://www.boost.org/

There is no such equivalent for C.

True, but there is this:

http://sglib.sourceforge.net/

that lib only implements some containers and algorithms on them but that
doesnt even come close. Boost has way more to offer. There really is no such
thing for C and its also impossible to do something like that just because C
misses lots of C++ features.

You are right. sglib really only dares compete with STL, not boost.
So there is a fair point to be made that C is just a deficient language
from a general library support point of view. You can view C as
basically like assembly language, or COBOL or Fortran from that point
of view.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Richard Heathfield]

we******@gmail.com said:

<snip>

So there is a fair point to be made that C is just a deficient language
from a general library support point of view.

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

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[websnarf]

Richard Heathfield wrote:

we******@gmail.com said:

So there is a fair point to be made that C is just a deficient language
from a general library support point of view.

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.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[jacob navia]

we******@gmail.com a écrit :

Richard Heathfield wrote:

>>we******@gmail.com said:

>>>So there is a fair point to be made that C is just a deficient language
from a general library support point of view.

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.

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]

In article <45**********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:
....

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

we******@gmail.com wrote:

Richard Heathfield wrote:

we******@gmail.com said:

So there is a fair point to be made that C is just a deficient language
from a general library support point of view.

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.

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.

<snip>

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]

"santosh" <sa*********@gmail.comwrote in message
news:11**********************@i15g2000cwa.googlegr oups.com...

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:

<snip>

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:
[...]

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[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]

jacob navia <ja***@jacob.remcomp.frwrites:
[...]

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[jacob navia]

Keith Thompson a écrit :

jacob navia <ja***@jacob.remcomp.frwrites:
[...]

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

jacob navia <ja***@jacob.remcomp.frwrites:

Keith Thompson a écrit :

>jacob navia <ja***@jacob.remcomp.frwrites:

[...]

>>>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"???

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Mark McIntyre]

On Sun, 07 Jan 2007 19:31:56 +0000, in comp.lang.c , Richard
Heathfield <rj*@see.sig.invalidwrote:

>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

[Peter Nilsson]

Richard Heathfield wrote:

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

--
Peter

[CBFalconer]

Keith Thompson wrote:

jacob navia <ja***@jacob.remcomp.frwrites:

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

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Keith Thompson wrote:

>jacob navia <ja***@jacob.remcomp.frwrites:

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

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[user923005]

g wrote:

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]

user923005 wrote:

g wrote:

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

(fx:OT)

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

--
Chris "first on the Underground!" Dollin
"We live for the One, you die for the One." Unsaid /Babylon 5/.

[Jorgen Grahn]

On 8 Jan 2007 06:18:45 -0800, we******@gmail.com <we******@gmail.comwrote:

Richard Heathfield wrote:

>we******@gmail.com said:

So there is a fair point to be made that C is just a deficient language
from a general library support point of view.

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

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

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org R'lyeh wgah'nagl fhtagn!

[Roland Pibinger]

On Mon, 08 Jan 2007 15:11:23 -0800, Keith Thompson wrote:

>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/ta...l/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]

Roland Pibinger wrote:

On Mon, 08 Jan 2007 15:11:23 -0800, Keith Thompson wrote:

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

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/ta...l/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.

--
Ian Collins.

[Roland Pibinger]

On Wed, 10 Jan 2007 08:00:32 +1300, Ian Collins wrote:

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

If you understood the C philosophy you'd see that C needs no 'next
standard'.

[jacob navia]

Roland Pibinger a écrit :

On Wed, 10 Jan 2007 08:00:32 +1300, Ian Collins wrote:

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

If you understood the C philosophy you'd see that C needs no 'next
standard'.

This is wrong. Completely wrong.

Everything evolves. The only things that do not evolve
any more are corpses: dead things.

I am of the opposite view. C needs to evolve to be able to
offer a slimpler interface than now.

In the link provided there was the famous KISS principle in
the first page.

But simple for who?

Simple for the compiler writer or simple for the user?

We know now where the C++ way leads. But this doesn't mean
that everything in that way is bad. It is like milk.

If you dring 10 liters of milk in a few minutes you die.
Does this mean that mil is inherently dangerous?

It is a matter of measure.

I have tried to introduce in the lcc-win32 compiler system
some advances that would have far reaching consequences
without adding any complexity neither to the compiler
(500 lines) nor to the language in general. But they would
simplify enormously the usage of the language.

This extensions are:

o Operator overloading
o generic functions

And that was it. Nothing else.

This allows to write container libraries in a very simple way, and above
all to get rid of the zero terminated strings, one of the big BUGS in C.

[Ian Collins]

Roland Pibinger wrote:

On Wed, 10 Jan 2007 08:00:32 +1300, Ian Collins wrote:

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

If you understood the C philosophy you'd see that C needs no 'next
standard'.

Don't forget the distinction between the language and the standard library.

--
Ian Collins.

[Richard Heathfield]

jacob navia said:

Roland Pibinger a écrit :

>On Wed, 10 Jan 2007 08:00:32 +1300, Ian Collins wrote:

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

If you understood the C philosophy you'd see that C needs no 'next
standard'.

This is wrong. Completely wrong.

Everything evolves.

So you say. Whether or not that is so, it is certainly true that, of those
things that do evolve, some evolve in dead-end directions.

The only things that do not evolve
any more are corpses: dead things.

Wrong. Living things don't evolve. Species evolve. Species are not living
things. They are classes of living things.

I am of the opposite view. C needs to evolve to be able to
offer a slimpler interface than now.

It's already about as simple as it can get, isn't it?

<snip>

I have tried to introduce in the lcc-win32 compiler system
some advances that would have far reaching consequences
without adding any complexity neither to the compiler
(500 lines) nor to the language in general. But they would
simplify enormously the usage of the language.

This extensions are:

o Operator overloading
o generic functions

Operator overloading would enormously complicate the usage of the language.
At the moment, + means + and - means - and that's an end of it. Operator
overloading (other than the very primitive form that is already built into
the arithmetic operators for handling integer, floating-point, and pointer
types) would make it much more difficult to read and maintain programs, as
C++ has demonstrated amply.

>
And that was it. Nothing else.

This allows to write container libraries in a very simple way, and above
all to get rid of the zero terminated strings, one of the big BUGS in C.

No matter how often you call null-terminated strings a bug, the fact remains
that they were a conscious design decision that has, at the very least, the
merit of simplicity.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Ian Collins]

jacob navia wrote:

This extensions are:

o Operator overloading

How can a language without objects support operator overloading?

o generic functions

Which leads to function overloading and breaks compatibility with
standard C linkage.

And that was it. Nothing else.

If you want these features, use C++ which is way more portable.

--
Ian Collins.

[jacob navia]

Ian Collins a écrit :

jacob navia wrote:

>>This extensions are:

o Operator overloading

How can a language without objects support operator overloading?

Very easy:

typedef struct ComplexInteger { int re; int imag; } COMPLEX_INTEGER;

COMPLEX_INTEGER operator+(COMPLEX_INTEGER x, COMPLEX_INTEGER y)
{
COMPLEX_INTEGER result;

result.re = x.re+y.re;
result.im = x.im+y.imm;
return result;
}

Operator overloading has nothing to do with object oriented programming.
C is not object oriented, hence here things are much easier than in C++.

>

>>o generic functions

Which leads to function overloading and breaks compatibility with
standard C linkage.

That could be avoided if there is a standard name mangling schema.

>

>>And that was it. Nothing else.

If you want these features, use C++ which is way more portable.

If you want milk you should drink immediately 10 liters

:-)

[jacob navia]

Richard Heathfield a écrit :

>
Operator overloading would enormously complicate the usage of the language.
At the moment, + means + and - means - and that's an end of it. Operator
overloading (other than the very primitive form that is already built into
the arithmetic operators for handling integer, floating-point, and pointer
types) would make it much more difficult to read and maintain programs, as
C++ has demonstrated amply.

Suppose you have a special numeric data type, say the decimal
data type.

Now, you have to write for

c = ( (a+b)*(d-5) )/(b*a);

c=divide(multiply(add(a,b),subtract(d,NewDecimal(5 ))),multiply(b,a)):

Of course the second form is easier to maintain.
:-)

Operator overloading makes defining new numeric data types
easy.

Besides it allows the construction of generric containers using the
array notation.

[Ian Collins]

jacob navia wrote:

Ian Collins a écrit :

>jacob navia wrote:

>>This extensions are:

o Operator overloading

How can a language without objects support operator overloading?

Very easy:

typedef struct ComplexInteger { int re; int imag; } COMPLEX_INTEGER;

COMPLEX_INTEGER operator+(COMPLEX_INTEGER x, COMPLEX_INTEGER y)
{
COMPLEX_INTEGER result;

result.re = x.re+y.re;
result.im = x.im+y.imm;
return result;
}

Fair enough for a simple example,but what happens when the sruct is more
complex and or contains pointers? You are stuck with C's copy semantics
unless you introduce pass by reference. My main point is you are
starting down the same road C with classes did a couple of decades ago.

>>o generic functions

Which leads to function overloading and breaks compatibility with
standard C linkage.

That could be avoided if there is a standard name mangling schema.

Which would have to be introduced before vendors started to define their
own.

>>And that was it. Nothing else.

If you want these features, use C++ which is way more portable.

If you want milk you should drink immediately 10 liters

Sip, don't gulp!

--
Ian Collins.

[Mark McIntyre]

On Tue, 09 Jan 2007 23:49:50 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>Ian Collins a écrit :

>>
How can a language without objects support operator overloading?

typedef struct ComplexInteger { int re; int imag; } COMPLEX_INTEGER;

For reference, what you've done here is create an object. A simple
one, but still an object.

>Operator overloading has nothing to do with object oriented programming.

Indeed. However Ian didn't say "without object oriented programming".
Its commonplace to confuse the two, I admit.

The point is that C does support the creation of objects (eg 6.2.4).
What it doesn't support is operator overloading, so what lcc-win32
does is extend the language by allowing you to define an operator for
an object. I have no problem with this, but of course its offtopic
here.
--
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

[jacob navia]

Ian Collins a écrit :

Fair enough for a simple example,but what happens when the sruct is more
complex and or contains pointers?

Who cares? Pointers are pointers. What's wrong with that?

You are stuck with C's copy semantics
unless you introduce pass by reference.

This is not absolutely necessary. It is slightly less
"efficient" but it works well for small structures.

There are operations that are defined for pointers.
For instance if you wanted to define:

COMPLEX_INTEGER operator+(COMPLEX_INTEGER *x, int y);

This will not work since addition of pointer + integer is
already defined. That is why is better to abstain from
using pointers in this context.

Yes. It is not C++. You can't do EVERYTHING.

My main point is you are
starting down the same road C with classes did a couple of decades ago.

When you drink one cup of milk this doesn't mean you
will not stop until you drink 10 liters and you die!

But yes, when you drink a cup of milk you are starting
a road that *could* lead you to drink 10 liters and die.

You have to know when to stop.

The basic error of C++ is that they did not see when it is
the time to STOP!