C needs a BOOST

[James Dennett]

[...] and gcc and Microsoft decided
to just drop C. Gcc hasn't still 8 years later finished the
C99 implementation, they do not participate into any standard
body (even if they could).

Jacob, you do your argument no favours with falsehoods like this.
It just shows you don't know what you're talking about.

Of course "I do not know what I am talking about".

You do. Please tell us then, some proposition that gcc has done
since C99 for standardization. Or proposal. Or whatever in this
direction.

He's trying to tell you that GCC developers *do* participate
in standards bodies. You said they do not, and that was wrong.
It's OK, we're all wrong sometimes. It's a chance to learn.

-- James

 

[jacob navia]

jacob navia wrote:

[...] and gcc and Microsoft decided
to just drop C. Gcc hasn't still 8 years later finished the
C99 implementation, they do not participate into any standard
body (even if they could).
Jacob, you do your argument no favours with falsehoods like this.
It just shows you don't know what you're talking about.

Of course "I do not know what I am talking about".

You do. Please tell us then, some proposition that gcc has done
since C99 for standardization. Or proposal. Or whatever in this
direction.

He's trying to tell you that GCC developers *do* participate
in standards bodies. You said they do not, and that was wrong.
It's OK, we're all wrong sometimes. It's a chance to learn.

-- James

OK. I see. They participate but they do not say that they are from
GNU or I do not know that fact and I think that nobody from
GNU is there.

A misunderstanding then.

 

[Douglas A. Gwyn]

This is an error. Keeping the language in this state makes the language
impossible to use for any serious software development
unless your project is big enough to warrant rewriting the
C library and adding stacks, lists, etc etc at each project!

That's certainly not true. A large number of applications,
especially for embedded systems, are coded nearly entirely in C.

Why would you not maintain your programming support library
for reuse across multiple projects? Unless, perhaps, you
don't know how to design it well enough for reuse.

 

[Douglas A. Gwyn]

gets() is still there and will stay with us at least till 2019.

gets() was part of the Base Library. Generally the C Standard
bearers are cautious about changing previously supported
standardized features in incompatible ways, such as removing
them. The two main examples of removing features were both in
response to proposals I championed (one in a DR): implicit int
and gets. (Yes, gets has been officially deprecated.)

I don't know where "2019" comes from.

 

[Douglas A. Gwyn]

My conclusion has to be that the demand isn't there.

The very age of C might be partly responsible, in that the vast
amount of existing C applications already embed some solutions
to the requirements for lists, etc. The maintenance programmer
(a)is unlikely to rework the existing app just to use some new
standardized interface for the same thing; and (b) has to
continue to maintain whatever libraries he has been using.

The only real use for such a library would be for new program
development, once the learning hurdle has been overcome. Much
new development really ought to use higher-level languages in
the first place.

By the way, does the C standard committee have an active library group?

Not as a separate entity.

 

[Douglas A. Gwyn]

The C community reacted with a tendency to look into the past,
and it "enshrined" their language resisting any change
of it at all.

Your history and rationale were entirely wrong.

C99 did not radically change the existing standard interfaces
because that would not have been in the best interest of our
"customers". Even as a highly compatible upgrade, it took
a long time for C99 to become widely implemented. As an
incompatible product, it very likely would never have been
accepted at all.

The advantage of having a committee of experience experts
deciding on Standard C's direction is that there is balance
so that more relevant factors get considered before changes
are made. The net newsgroups have seen many people who think
that obviously they know best how things should be done and
that any other ideas are wrong-headed. Fortunately that is
not how C has evolved.

 

[jxh]

Opinions? Is keeping the language tiny worth the cost of C
programmers having to constantly reinvent the wheel?

It would be a nice experiment to add template support to C and see
what kinds of generic solutions would fall out from it. OTOH, there
are plenty of C shops that are using C++ compilers, and cherry pick
features they want to use (such as STL).

Nice troll, BTW.

-- James

 

[jacob navia]

That's certainly not true. A large number of applications,
especially for embedded systems, are coded nearly entirely in C.

Why would you not maintain your programming support library
for reuse across multiple projects? Unless, perhaps, you
don't know how to design it well enough for reuse.

Because in customer xyz the list library used is such and such
that conflicts with mine in *some* areas but not in others. Then
I have to use the customer's library until I discover that it
has a bug in a few not well tested routines. Then I debug them,
but I can't test all of them. With the next project is the same,
they *have* too several routines for list handling, each
serious C project has, and all of them not well tested and full
of problems!

What you do not want to understand is that EACH project has its
list library and ALL of them will not be well tested ones, with
more or less problems. Why do we have to REPEAT this work at
each project?

If we follow your reasoning we would all have a strcmp routine
because we would not have a standard LIBRARY!

Why calculating the gamma function is deemed worth of
standardization and not a common place routine like the handling of
a single linked list?

How many MILLIONS of lines of C code have followed your reasoning
above and ended with not well tested libraries that produce always
problems?

The task of a standard is to avoid needless repetition of effort
by providing a common interface for this library routines. Then,
vendors would all be compatible with libraries of different quality
and different prices and each one stressing different parts of
the implementation.

Look at Mr Plaugher for instance, and his high quality C library.
A user of my compiler system can throw away my library and buy
Mr Plaugher's without rewriting a single line of his code
because the interface is fixed you understand?


You say:
"... unless, perhaps, you don't know how to design it well enough
for reuse".

This attitude is unwarranted Mr Gwyn.

 

[user923005]

It would be a nice experiment to add template support to C and see
what kinds of generic solutions would fall out from it. OTOH, there
are plenty of C shops that are using C++ compilers, and cherry pick
features they want to use (such as STL).

The problem I see with template support is that it requires operator
overloading.
The problem with operator overloading is tht it requires references.
Now, if you introduce references into C, it becomes a lot less "C-
like".
So I guess that monumental collections of generic programs requires a
language like C++.

Nice troll, BTW.

It turned out that way, but it wasn't my intention. I was just
wondering aloud why the C++ side of the fence has this wonderful bag
of 1001 tricks and C has an itty-bitty one. I was thinking it would
be nice to have more pre-built tools for problem solving ready to go.
It turns out it was more difficult than I thought to produce it.

 

[santosh]

The problem I see with template support is that it requires operator
overloading.
The problem with operator overloading is tht it requires references.
Now, if you introduce references into C, it becomes a lot less "C-
like".
So I guess that monumental collections of generic programs requires a
language like C++.


It turned out that way, but it wasn't my intention. I was just
wondering aloud why the C++ side of the fence has this wonderful bag
of 1001 tricks and C has an itty-bitty one. I was thinking it would
be nice to have more pre-built tools for problem solving ready to go.
It turns out it was more difficult than I thought to produce it.

Well if you take into account non-Standard code, then the amount of reusable
code in C, for C, is *massive*

It's just that the Standardised library is quite small, but many of the
reasons Doug Gywn has listed seem very plausible to me.

 

[André Gillibert]

Well, lcc-win32 *can* use the libc from the system, the libc from the
Microsoft compiler and probably the libc of GNU...

There are many reasons to use a different compiler.

No. If they are shared objects they just have a copy of the C runtime
with them anyway.

Maybe for lcc-win32.
That it works for *one* compiler is insufficient.

I said:

Link with another library

I did not said:

Use two libraries for lists at the same time!

Which isn't possible with Borland C, for example, because non-standard
functions of the default library are implicitly linked even for very
simple pieces of code.

Moreover, if one function is inlined, it may be recognized BY NAME.
e.g. A call to memset, even if it's imported in a third party library may
be replaced by raw assembly code.
Redefining a library function is undefined behavior, and is likely to
behave badly on many implementations.

Maybe *your* compiler wouldn't make it that way, but that doesn't mean
other compilers won't.

Note:
I used only ONE exclamation mark.

Good.


No. The list module I wrote makes fir 2380 bytes of code
and 204 bytes of data. Maybe adding some overhead it *could* grow to
4-5K.

I think that's small enough to be a perfectly acceptable proposal.
If you add the modules for a few other common containers, it should still
be acceptable...
If possible, you should write a proposal that doesn't require extra
features (e.g. OOL), then, it has some chance of being accepted.
However, I highly doubt you can do something as full-featured as the
STL+BOOST as the OP wishes, in less than several hundred of kilobytes.

 

[André Gillibert]

And yet the field of generic programming has been built for
years on a foundation of abstraction *not* costing performance,
which is to a large extent realized with C++'s STL and real
current compilers.

Not to a so large extent.
Maybe the string append function of std::string is as fast as, or faster
than, I could ever write, but, when using std::string, anybody tends to
make much much more copies and costy operations than when manually
managing pointers.
I remember than, when I refactored a lexical parser using the STL, to use
lower level features, I got a x20 speed up, keeping the same algorithmic
complexity.

 

[jacob navia]

The very age of C might be partly responsible, in that the vast
amount of existing C applications already embed some solutions
to the requirements for lists, etc. The maintenance programmer
(a)is unlikely to rework the existing app just to use some new
standardized interface for the same thing; and (b) has to
continue to maintain whatever libraries he has been using.

The only real use for such a library would be for new program
development, once the learning hurdle has been overcome. Much
new development really ought to use higher-level languages in
the first place.

Excuse me but did I understand you correctly?

That library would be of no use but in new code you say.

Then,

"Much new development really ought to use higher level
languages in the first place".

So, you say that new development shouldn't be done in C but in
"higher level" languages.

Actually then, you say it is better not to develop anything new in C.

OK. I understand better now, what do you think about C, and
why our viewpoints differ completely. Until now I thought that
you (like people in a news group about the C language) would
agree that C is a language that is worth developing code
in.

I would like that you claify this of course. Did I understand you
correctly?

 

[André Gillibert]

jacob navia wrote:

P.S. I will look at the glib again.

Yes, in particular, even if the GNU implementation may be of low quality,
and to big, it may be possible to keep the SAME interface, and get a
lightweight library.

If GLib is too big, it may be possible to take a meaningful subset of
GLib, of course.

 

[André Gillibert]

The only real use for such a library would be for new program
development, once the learning hurdle has been overcome. Much
new development really ought to use higher-level languages in
the first place.

C can still be a good choice for many new projects.

 

[André Gillibert]

jacob navia wrote:

C is then seen as an old and obsolete language by most
programmers. Its main use should be in small circuit
boards where there is no space for a language like
C++.

I see more C as an UNIVERSAL language that had the advantage of not
changing every two years.
That's wonderful how PORTABLE C90 is. Much more portable than C++98.
(C99 broke the portability dream, which explains why C90 is still much
more popular than C99)
That's wonderful how reliable are the ports of C90 programs. You don't
have version conflicts.
C90 is ONE language.
Not changing is the strength of C90.

NOTE: I don't think that the container library would "break" the C
language. It wouldn't be a big change. It wouldn't create any
incompatibility. It may not increase too much the size of the library.

When those circuit boards disappear, C will disappear
with them. It will remain (like COBOL) in a frozen state
for the biggest part of this century as the software
written in C is slowly rewritten in other, more
modern languages.

If that happens, would you die?
That's not as if there had to be an affectional relation to a language.
Sometimes it's better to use an entirely different new language, instead
of cheating in transforming the first language in the latter and creating
thousands of painful compatibility issues.

What is crucial is that the library has a small memory footprint.
Not in RAM of course, but in HUMAN memory footprint. This means that
the library is easy to remember and use, that it has a consistent
naming, and that it is kept as simple as possible.

It would equally be good if it had a small RAM footprint.

Software has a tendency to bloat forever.

As languages have. Compare C99 to K&R C. Compare Fotran 2003 to Fotran 66.

 

[André Gillibert]

[...] and gcc and Microsoft decided
to just drop C. Gcc hasn't still 8 years later finished the
C99 implementation, they do not participate into any standard
body (even if they could).

Jacob, you do your argument no favours with falsehoods like this.
It just shows you don't know what you're talking about.

Of course "I do not know what I am talking about".

You do. Please tell us then, some proposition that gcc has done
since C99 for standardization. Or proposal. Or whatever in this
direction.

If possible I would like to know if the C99 support
is finished in gcc. Even if it is very good, the last thing I
know is a web page where VLAs and other features are marked missing
or broken.

GCC TRIES to support C99, but hasn't yet got it.
Similarly, GCC TRIES to support C++98, but hasn't yet got it.
Well, actually, it doesn't try to get full C++98 conformance, while it
does, for C99!
(GCC doesn't try to implement the C++ export feature).

The fact that C99 is already to big and requires YEARS to be implemented
correctly (unlike C90 which is much simplier)

Implementing standards requires time. Especially when they're big.

 

[André Gillibert]

But even if I use the same syntax, the simplicity of the language
is preserved. That's why I was completely opposed to introducing
constructors for instance, remember?

And of course, it's obvious to everybody that OOL is much easier to
implement than constructors. Maybe it's possible to implement constructors
in 2000 LOC as you did for OOL.

Did you know that C++ had slowly evolved from C?
"C with objects" was very small.
Then, it became C++ as new features were added.

Similarly C evolved continuously from B... But, C99 clearly is much bigger
than B.

 

[Ben Pfaff]

Since I am not a member of GNU I have just to believe the
public information that GNU itself publishes. Sorry.

I don't think that there is such a thing as a "member of GNU".

 

[André Gillibert]

The problem I see with template support is that it requires operator
overloading.

It's simply huge, very complex, and causes linking issues.
It's also quite weak without function overloading support with complex
resolution rules.
Classes support, with constructors and destructors, also greatly help to
the functionality of C++ templates.