what do c developers do without the stl?

[Marian]

You should quote enough from whatever you are replying to to
establish at least context. Each article should stand on its own.
The links below (in my sig) will help. Top-posting means placing
your answer before the quoted material, it should follow it (or be
interspersed) with non-germane matter snipped out.

The google reply system is seriously broken. To have at least a
reasonable chance of generating a sane reply, see below:

"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

I am sorry for this. I have got it in between.

Marian

 

[Randy Howard]

There are at least two counterexamples in last two days on
this forum. There are two threads asking for such library in C.
Why they do not simply switch to C++ at this stage of development?

Very good question. I've not seen either of them answer it.

It is probably not as easy as this. C an C++ are two different
languages.

True, but the differences are easy enough to overcome, especially
if you really need STL and can't bear to live without it. Surely
moving most projects from C to C++ would be easier than implementing
your own homegrown "STLfoo" for C.

I have to pay invoices

Then perhaps you shouldn't be giving it away. Just a hint.

It's just a header file. It must be open source and it is.

You can copyright the contents of header files and charge
for their use, provided you can find someone willing to
pay to do so.

If not, then it's probably not worth paying for, so why should you
get grant money for it?

I am starting here

Oh, I thought you were serious.

 

[Arthur J. O'Dwyer]

The google reply system is seriously broken. To have at least a
reasonable chance of generating a sane reply, see below:

"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

True. But I strongly encourage you, and every Google Groups Beta user,
to switch interfaces. If you can't use a real newsreader, at least
move to Canada --- groups.google.ca, that is! Their interface is still
relatively un-broken, though it may not last long.

And send e-mail to (e-mail address removed) (that's
groups-support\@google.com, for you Google Groups BETA users). I've
cc'ed this message to them, for example.

HTH,
-Arthur

 

[Default User]

It translates as "google is the bain of Usenet's existence".
Hint: Use the reply button at the TOP of the page when
using google, instead of the broken one at the bottom.
Also, add you text below, or interleaved with that you
are replying to, as I am doing here.

This advice is inaccurate. What the user needs to do is click "show
options" at the top of the message (not the page) then select the Reply
shown in the expanded message header.

However, that doesn't have anything to do with top-posting, but rather
the all too prevalent Google "no quotes at all" problem.



Brian (sadly still using Google to post, but not read, news)

 

[websnarf]

(e-mail address removed) says...

Probably not, unless you guarantee it will work on about a dozen
different platforms and compilers.

A dozen compilers is doable. After you get past 3 compilers, it
usually gets pretty easy from there unless you are doing hard core
numerics.

Multiple platforms is different. If you want to cover what ANSI C
supposedly says it covers -- I would say I have barely ever heard of a
completely cross-platform application. I guess "Hello World" would be
the only case that springs to mind. But obviously install base is far
easier. If you do Windows/DOS, *nix, and MacOSX (which really just
*nix now) then you are well above 99.99% install base of
PCs/workstations. As for other devices, VxWorks and QNX will cover
most of the rest.

[...] Even then, I don't think I have a need for it.

Interesting. Do you use any prewritten source at all?

[...] What I'd much
rather see is a Grand Unified Multithreading interface for C, that
works regardless of platform. Have one of those on the back burner?

First of all, there is basically no serious application written in C
that works regardless of platform.

Depending on what you want from multithreading -- it can be a
complicated low-level interface to OS/platform specific features that
are not universal. Certainly, pre-emption is a non-universal platform
feature.

However, if you poke your head out of the sand and look at the work
being done in other scripting languages (Python, LUA, Perl and ErLang
specifically) you will see that they are *all* moving towards
multitasking solutions. Its been their one collective big "missing
feature". I'm not an expert at ErLang, but the other guys have
primarily focused on co-routines as their avenue to multithreading.
Lua probably has the best implementation of coroutines (although I
don't know about the details of ErLang.)

C's closest approximation to coroutine functionality is the
setjmp/longjmp, but I have looked into this, and its simply not
possible to duplicate the expected full functionality of "one-shot
continuation" style coroutines with it.

Running off to inline assembly, personally, I have implemented basic
coroutine functionality -- but the platform details are pretty
daunting. Even for *one* compiler, I have to supply multiple different
interfaces depending on which "ABI/calling convention" is being used.

Coroutines are a particularly good sweet spot, because it dramatically
increases programming capabilities without introducing, mutexes,
semaphores and race conditions. The implementation details also are
just generalizations of setjmp/longjmp with some call stack
manipulation capabilities. Coroutines can also be fairly fast, while
sync primitive multitasking objects can be very slow.

That's going to be big.

Well I don't know what you mean by this -- its not likely to ever come.
There are relatively few who understand the problem well enough to
even attempt it, and the ANSI C standard committee is not of any help.

The best chance would be to get the VxWorks or OSE guys to open source
their solutions, but they currently still make money off them, so I
don't know what you are expecting from them. By the time they might
consider open sourcing their solutions, the mindshare for C will have
eroded to the point where nobody cares anymore.

Probably could even get some grant money for it.

Yeah, the problem is, how do you get someone interested in giving you
grant money for such a thing? The effort required is fairly high, and
there will be no returns unless you sell the solution (which means not
making it an open standard).

 

[websnarf]

There are at least two counterexamples in last two days on
this forum. There are two threads asking for such library in C.
Why they do not simply switch to C++ at this stage of development?
It is probably not as easy as this. C an C++ are two different
languages.

Yes, but paradoxically, this is the wrong newsgroup to discuss
something like a "standard generic library for C". There simply is no
audience for your ideas here. People may come here periodically with
such questions, but the loiterers here are more interested in the
standard of C than the practice of C. You'll notice you got a lot of
arrows slung at you, but not a lot of useful feedback.

There is a sentiment amonst some programmers that the only real value
of C++ is, in fact, STL. But as you correctly point out, C++ also
introduces many semantic language differences from C that may prevent
it from being adopted (not the least of which being that the C++
standard is something like 10 times larger) by programmers for various
reasons.

So the obvious conclusion is that if a good enough library of generics
(whether via macros, or whatever mechanism) were made available that,
there would be amongst those programmers I just referred to who would
probably be very interested in them. Then of course there are people
like me, who just sees the value of generics in general.

Ok, but that isn't exactly what you've provided. Instead, you've taken
a position that you will never dynamically allocate any memory or
create/declare your own fresh data structures. And what you are really
supplying is a set of algorithms which can be applied to data
structures that are user generated. That's fine, and an interesting
take on the problem, but then what you are doing is not exactly
comparable to what STL does.

For example, the primary value of STL that *I* personally saw, is the
inclusion of the vector<> template. A vector is like a dynamically
sized array -- it can be indexed directly, trivially iterated, sorted,
rotated, etc. Since you restrict yourself from use of malloc(), your
library doesn't implement any container abtraction for things such as
vectors or deques, etc -- you require an array based implementation by
the user, if you want to sort it, for example.

So in the end you will find yourself restricted, and certainly not able
to duplicate the entire functionality of STL. Your hash table, for
example, implements only the chaining-style hash tables, which are
generally somewhat slower than the open-address style.

I would also posit, that one of the main problems in C programming, is
that memory/buffer management is a common place for errors, many of
which have become quite famous bugs.

So I guess I would wonder if you would be willing to consider,
possibly, adding perhaps a "level 2 API" for building real ADT which
include their own memory management? That, I think, is where the real
holy grail for this kind of mechanism for C is.

But in generally, I highly endorse your mechanism for implementation.
Where C is very weak in many ways, one of its bizarre strengths is the
source-level macro concatenation feature. And its an interestingly
natural way of trying to implement generic programming in C.

 

[Conrad Weyns]

There are at least two counterexamples in last two days on
this forum. There are two threads asking for such library in C.
Why they do not simply switch to C++ at this stage of development?
It is probably not as easy as this. C an C++ are two different
languages.

I was having to do some work on a many years old c project. I was not going
back to using c by choice.
It would certainly be feasable to move it over to c++ but with any sizeable
project, this is never a cheap undertaking.
Years ago, when using only c, I'd simply get on with it and write whatever
it is that I needed to get the job done.
I was surprised now to find myself not quite willing to consider that!
So, after wasting at least half a day in a total void, I ended up writing a
few pages of uggly fixes that I hope no one else will ever get to review...

I certainly agree with Randy Howard:

Surely moving most projects from C to C++ would be easier than implementing
your own homegrown "STLfoo" for C.

Absolutely!
Were I to envisage a future using c, I'd certainly support your efforts to
make a good c stl alternative.
I'd have no problem paying for a license. Good, bug-free, third party
libraries are worth their weight in gold.
In my working world, I am seeing many years investment in c++ comming to an
end, in favour of .net and c#.
Cheers,
Conrad Weyns.

 

[Malcolm]

There are at least two counterexamples in last two days on
this forum. There are two threads asking for such library in C.
Why they do not simply switch to C++ at this stage of development?
It is probably not as easy as this. C an C++ are two different
languages.

When the stl came out I seriously considered switching to C++ for most of my
development.
However I decided against it. One reason was that the syntax is horrible.
The more important reason is that interfaces become complex.

For instance if you want to calculate a standard deviation in C you will
write something like

double stdev(const double *x, int N)

in stl the first reaction may be to pass in a vector of doubles.

double stddev( vector<double> x)

However to really get into the spirit of stl, the algorithm should work on a
controlled sequence of any numeric type. So you end up with something like

template <numeric>
numeric stdev( numeric::iterator start, numeric::iterator end)

This is a nice idea, but too hard to use. I'm not sure I've even got the
syntax right.

However it is very difficult to provide useful generic macros / functions in
C. It is easy enough to write an expandable vector, for instance, but if
most objects are small then the generic call to memcpy() is prohibitive.
Also, you must handle out-of-memory somehow, and C has no exception
mechanism. By the time you've finished you might as well just call
realloc(), with its annoying requirement for a temporary to handle failure
properly.

 

[Russell Shaw]

When the stl came out I seriously considered switching to C++ for most of my
development.
However I decided against it. One reason was that the syntax is horrible.
The more important reason is that interfaces become complex.

For instance if you want to calculate a standard deviation in C you will
write something like

double stdev(const double *x, int N)

in stl the first reaction may be to pass in a vector of doubles.

double stddev( vector<double> x)

However to really get into the spirit of stl, the algorithm should work on a
controlled sequence of any numeric type. So you end up with something like

template <numeric>
numeric stdev( numeric::iterator start, numeric::iterator end)

This is a nice idea, but too hard to use. I'm not sure I've even got the
syntax right.

However it is very difficult to provide useful generic macros / functions in
C. It is easy enough to write an expandable vector, for instance, but if
most objects are small then the generic call to memcpy() is prohibitive.
Also, you must handle out-of-memory somehow, and C has no exception
mechanism.

Use longjmp macros and wrap your malloc().

http://ldeniau.home.cern.ch/ldeniau/html/exception/exception.html

I have a different way of doing the cleanup handlers for freeing malloced
memory during an exception.

 

[Russell Shaw]

When the stl came out I seriously considered switching to C++ for most of my
development.
However I decided against it. One reason was that the syntax is horrible.
The more important reason is that interfaces become complex.

For instance if you want to calculate a standard deviation in C you will
write something like

double stdev(const double *x, int N)

in stl the first reaction may be to pass in a vector of doubles.

double stddev( vector<double> x)

However to really get into the spirit of stl, the algorithm should work on a
controlled sequence of any numeric type. So you end up with something like

template <numeric>
numeric stdev( numeric::iterator start, numeric::iterator end)

This is a nice idea, but too hard to use. I'm not sure I've even got the
syntax right.

However it is very difficult to provide useful generic macros / functions in
C. It is easy enough to write an expandable vector, for instance, but if
most objects are small then the generic call to memcpy() is prohibitive.
Also, you must handle out-of-memory somehow, and C has no exception
mechanism.

Use longjmp macros and wrap your malloc().

http://ldeniau.home.cern.ch/ldeniau/html/exception/exception.html

I have a different way of doing the cleanup handlers for freeing malloced
memory during an exception.

Some real C code that does exception handling and cleanups is in gnu gdb.

 

[Marian Vittek]

So the obvious conclusion is that if a good enough library of generics
(whether via macros, or whatever mechanism) were made available that,
there would be amongst those programmers I just referred to who would
probably be very interested in them. Then of course there are people
like me, who just sees the value of generics in general.

Ok, but that isn't exactly what you've provided. Instead, you've taken
a position that you will never dynamically allocate any memory or
create/declare your own fresh data structures. And what you are really
supplying is a set of algorithms which can be applied to data
structures that are user generated. That's fine, and an interesting
take on the problem, but then what you are doing is not exactly
comparable to what STL does.

Yes, I do not want to implement an exact copy of STL. Rather something
simpler and closer to the C philosophy. Something not as heavy as STL,
but taking most of useful things.

The reason to not allocate/free objects at the moment is that each
project has its own memory management strategy. I do not want to
interfere with it.

For example, the primary value of STL that *I* personally saw, is the
inclusion of the vector<> template. A vector is like a dynamically
sized array -- it can be indexed directly, trivially iterated, sorted,
rotated, etc. Since you restrict yourself from use of malloc(), your
library doesn't implement any container abtraction for things such as
vectors or deques, etc -- you require an array based implementation by
the user, if you want to sort it, for example.

Right, also in C++ you can overload the [] indexing operators. It
is much more natural to use vector when you can simply write a
rather than stl_index(a,i).

So in the end you will find yourself restricted, and certainly not able
to duplicate the entire functionality of STL. Your hash table, for
example, implements only the chaining-style hash tables, which are
generally somewhat slower than the open-address style.

I would also posit, that one of the main problems in C programming, is
that memory/buffer management is a common place for errors, many of
which have become quite famous bugs.

I don't think that there is a fundamental difference between C
and C++ memory management models. It must be the same source of
bugs (if not larger) for C++ programmers, I guess.

So I guess I would wonder if you would be willing to consider,
possibly, adding perhaps a "level 2 API" for building real ADT which
include their own memory management? That, I think, is where the real
holy grail for this kind of mechanism for C is.

The intention is to build a library with several levels. As the
current version defines: a level-0 as a simple collection of macros
providing algorithms, level-1 a collection of functions as level-0 plus

allowing recursive implementations. In the future, there can be
level-2 interface making (and forcing in some sens) its own memory
allocation mechanism and own data structures like vectors.

However, making a good implementation requires a lot of work and
energy and enthousiasm and money, of course. It covers also writting
of testing programs, the documentation ...

But in generally, I highly endorse your mechanism for implementation.
Where C is very weak in many ways, one of its bizarre strengths is the
source-level macro concatenation feature. And its an interestingly
natural way of trying to implement generic programming in C.

Thanks for the first possitive reaction on my postings .

 

[Marian Vittek]

Absolutely!
Were I to envisage a future using c, I'd certainly support your efforts to
make a good c stl alternative.
I'd have no problem paying for a license. Good, bug-free, third party

libraries are worth their weight in gold.
In my working world, I am seeing many years investment in c++ comming to an
end, in favour of .net and c#.

This was in some sens the main question I asked here. Is it
useful to invest time and money into such project? Until now,
I have worked on the library just for myself, implementing only
things I needed. If it should be a general purpose library,
it should cover much more. I hoped that there are still a lot of C
programmers. I hoped that they are using C (as me, I do) because they
consider it as the best solution.

People investing money only in NEW technologies may not be
favorable to any evolution in C area, certainly.


Marian

 

[Gregory Pietsch]

Wondered how long that would take.



Wonder how you knew about that?


Oh, that's how.

So, I prosthelytize a little. Still, it's best to stick with something
that works. Why reinvent the wheel? ;-)

Gregory Pietsch
Gregory Pietsch

 

[Friedrich Dominicus]

Do you have considered using libapr?

Regards
Friedrich

 

[Michael Mair]

This was in some sens the main question I asked here. Is it
useful to invest time and money into such project? Until now,
I have worked on the library just for myself, implementing only
things I needed. If it should be a general purpose library,
it should cover much more. I hoped that there are still a lot of C
programmers. I hoped that they are using C (as me, I do) because they
consider it as the best solution.

FWIW: For many things, C IMO still is the best solution. In some
areas, it is the only solution (see embedded systems; writing
compilers for more complex languages than C89 just will not
pay. However, the C code for the embedded device may well be
partially created by other software _not_ written in C...)
Some established STL-like library for C might ease the
decision for C in some but certainly not all cases.
I certainly followed the discussion with some interest and
had a quick look at the SGLIB documentation.

People investing money only in NEW technologies may not be
favorable to any evolution in C area, certainly.

People investing money in new technologies only because they
are new technologies, are almost certainly wasting their money.
However, if there is a better technology for something and the
ROI (as much as I hate thinking in these terms) cries "yesss",
then it is no mean act of treason to turn your back on an old
solution. In fact, a clean cut from time to time may be the
only way to keep something alive and not only in some state
of suspended animation respawning for a couple of moments
every now and then.


Apart from that: C is my favourite programming language


Cheers
Michael