C needs a BOOST

[André Gillibert]

jacob navia wrote:

Why is this not a good idea?

Constructors and destructors look great in principle, but
they are
o difficult to implement correctly. It took the C++ people 5-6
years to get it right.
o They add too much implicit code to the language. And this is
a very important point.

3] Don't mix well with traditional error codes.
As an example, read Gripe #4 at:
http://blogs.msdn.com/ericlippert/archive/2004/03/23/94651.aspx

4] Are hard to use *correctly* without exceptions.
Whenever a constructor allocates a resource whose creation mail fail, it
must signals that.
There're several ways to get it right without exceptions.
1) A zoombie flag that has to be checked explicitly just after explicit
(or implicit) object creation.
2) Making the constructor do nothing except initialize some state bits to
indicate that the object is uninitialized and then, providing a
AllocateResource() function that does the real work and returns an error
code.

 

[Chris Thomasson]

I'd advise you to start off with a red black tree or a hash table.

Well, I am very curious to find out if we are even able to agree on a simple
LIFO interface... Let's get a simple/trivial API out of the way, then we can
increase the complexity by adding more and more advanced data-structures.

Everyone can write their own linked list routines or stacks, and the
benefits of yours aren't obvious.

I guess a possible benefit would be a pseudo-standardization of common
data-structures within the context of this newsgroup. How useful that would
be is up for debate indeed...

However a more complex structure takes non-trivial effort to code, so
you've got a much better chance of acceptance. After the complex
structures have some sort of following, people might accept linked lists
or dynamic arrays that operate with the same conventions.

Perhaps. Although, if we can't flesh out a LIFO API, then how can we
possibly do something more "advanced"?

But they are not going to rewrite their code tomorrow just because CT says
"we should have a function called clc_llunlink() to remove a node from a
linked list".

I am not advocating that we should change our code to use an API that is
defined by this newsgroup. Anyway, IMHO, the CLC Standard API itself, along
with its various implementations, would be a good resource for any C
newbie's.

Hummm... Thinking on this one.

 

[santosh]

That's not true in games.
What typically happens in a games company is that a product is released. If
it is successful, the graphics will be changed and a few tweaks and twiddles
made to the code, to get something that plays rather differently and looks
new to the user but costs less to develop. After about the third time round
the whole thing is getting creaky, the programmers are getting bored, and
technology has moved on. So management decide to invest in a new version,
"starting with a clean sheet".

All the code from the old version will be rigorously thrown away, and every
single line rewritten from scratch, for a brand new project. It is largely
psychological, to do something new rather than rehash the old game.

As far as I'm concerned game programmers can play around all they
want.

 

[Chris Hills]

It would be really nice if C could adopt a really nice algorithms
library like C++'s STL + BOOST.

The recent "reverse the words in this sentence" problem posted made me
think about it.
It's like 5 lines to do it in C++ because of all the nifty algorithms
that come with the language (I think BOOST is going to get bolted on
to the C++ language like STL did).

It's a lot more work in C than C++. Why doesn't C have stacks,
dequeues, and other common, simple tool sets already in its standard
library?

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

Actually in the last ISO C meeting the ISO C panel finally realised that
the major use of C is in the embedded field and C99 is already too big.

In fact any changes to C are likely to include reducing it rather than
enlarging it by much.

 

[Chris Hills]

jacob navia wrote On 10/03/07 16:31,:

Since C is impossible to use for serious software
development,

Actually C is used for a LOT of seriously safety critical work. Much of
the time your life depends on C programs.

 

[André Gillibert]

Yes, but it has the class hierarchy rules, that C doesn't have.

In C the rules can't be the same.

Yes, they can. It wouldn't be possible if C had MORE types than C++, but
it has FEWER.

We would need a new set of rules,
and some years of testing of those rules in the field, etc.

Maybe you would create simplier rules, but it would be very harmful, in my
opinion, to reinvent something by doing it differently.
Incompatibilities between C and C++ would become numerous and harmful.
It's hard enough to live with the existing incompatibilities. Please,
don't add any new.
You may not feel concerned if you don't use C++, but if you did, you would
see that making C projects/libs cooperate with C++ projects/libs is
something that would be eased by a better compatibility.

BTW: I don't find the C++ standard harder to read than the C standard.

 

[André Gillibert]

Some things can't be done by committee. For instance I don't think there
is a single example of a famous poem written by a committee of people.

Yes, you're most probably right for poems.

Language design is another of those things that don't seem to respond
well to committee treament.

The law of jungle is MUCH MUCH worse than committee treatment.
e.g. The "state" of C++ before standardization was really awful. After
standardization, it became consistent, understandable, though complex.
C was awful too, before standardization. Less than C++, but it was too.

I judge that C90 had been one of the best standardization success of the
the twentieth century in IT.
Moreover, I think that C90 didn't sacrificied simplicity.

The mentality of a brilliant software designer and a good committee
member seem to be opposed.

The problem is not: Committee member vs software designer.
The problems are: More than one brain for a design, more than one
implementation and more than one platform for a language.

A language designed by a single person will be consistent, relatively
simple, won't have obvious flaws, but will have many non-obvious ones.
Moreover, if there're more than one implementation, they all will be
incompatible because informal specifications are always full of corner
cases.

A language designed by many non-cooperating persons, will be incredibely
inconsistent, go into all directions, and be a real nightmare to use,
since every implementation would be incompatible and have zounds of
absolutely useless extensions. That's the state of BASIC.
Personally, I wouldn't be able to *define* what BASIC is! All
implementations are so different and incompatible that I cannot find much
common.
Note: There has been a standard, but, most implementations don't follow
it, either because they don't care, or because they've been written before
the standardization.

A language designed by a committee (a set of people who try to build
something coherent from a mess) from an existing language having many
incompatible implementations, will please most members, without bloating
too much the language (unless it's already bloated), and keeping some
internal consistency.
Moreover, portability flaws (e.g. platform, technology or human language
dependence) will be removed, so that it becomes possible to implement it
everywhere it makes sense.

Many languages follow the three steps:
Design by one creator (it may "look" good, but be either unusable or too
platform dependent... Sometimes, it's right from the start), cahotic
evolution by implementors, and final standardization.

 

[jacob navia]

Actually in the last ISO C meeting the ISO C panel finally realised that
the major use of C is in the embedded field and C99 is already too big.

In fact any changes to C are likely to include reducing it rather than
enlarging it by much.

Great!

I would vote for getting rid of
gets()
asctime()
trigraphs
strtok()

If we introduce operator overloading we can get rid of complex numbers
*in the language*. They would become another numeric data type that can
be used with that feature. The same for fixed point numbers, decimal
numbers, and several other proposals like bignums, extended precision
floats etc. All those packages wouldn't be part of the language itself
but would be in libraries that can be added on an "as needed " basis.

Actually, if we add the proposed changes the language becomes richer and
smaller. We can use hash_tables and other containers transparently
using the [ ] operator, and extending the basic types becomes
much easier.

 

[Chris Hills]

Sure, and I haven't said otherwise. I use it myself.

I maintain that C is not a good choice for most "modern" major
applications.

So what language would you suggest?

However, if you already have access to a good
C programming support environment (libraries, disciplines) then
that could influence the decision. Also, C still has an edge
over any of the alternatives when it comes to breadth of
portability.

Agreed.

 

[Chris Hills]

It would be really nice if C could adopt a really nice algorithms
library like C++'s STL + BOOST.

The recent "reverse the words in this sentence" problem posted made me
think about it.
It's like 5 lines to do it in C++ because of all the nifty algorithms
that come with the language (I think BOOST is going to get bolted on
to the C++ language like STL did).

It's a lot more work in C than C++. Why doesn't C have stacks,
dequeues, and other common, simple tool sets already in its standard
library?

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

Yes.

Why shouldn't C be more like C++?
Because there is C++.[/QUOTE]

Absolutely!

The other thing to bear in mind is that on platforms where there is a C
compiler but no C++ compiler it is usually for a very good reason. Even
if these things were added to C (like many things were added to C90 to
get C99) I doubt they would be implemented.

 

[Chris Hills]

Neil Booth wrote:
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.

I know of at least one GCC maintainer who is on a C standards panel

 

[Chris Hills]

C99 didn't *require* years to implement. In fact, there was at least
one C99 front end (from Edison) not very long after C99 was published.

C99 has required years to implement. A parser is not a compiler. It is
part of a compiler.

There are very few (if any) compilers that do a full implementation of
C99

The rate at which C99 conformance is being attained by GCC could be
explained by a combination of low customer demand (C90 being adequate
for most C programmers) and relative lack of interest by implementors.

I think the came is true for ALL C compiler makes not just GCC

 

[Chris Hills]

Default User said:


No. In fact, we're not even used to being called Brits.

Well quite often it is common to drop the honorific ( suppose it
depends where you went to school) and we are quite often called Brits.

 

[Chris Hills]

Beats "Yanks" or "Seppos".

Er Septics not Seppos

We like to call everybody by their first name. Do you prefer Ricky or
Richie?

Bub or Mac?

 

[Chris Hills]

[csc snipped]

Default User said:

We like to call everybody by their first name. Do you prefer Ricky or
Richie?

No.

Dick or Dicky?

(Ducky even )))

 

[Chris Hills]

I hereby declare this subthread terminated, by virtue of my authority
-- oh, wait, I don't have any. Well, I declare this subthread
terminated anyway.

Come on, guys, play nice.

Ok Mr Kenneth Thompson

Its a Saturday afternoon and we need a little fun before the Aussies
beat us at rugby :-(

 

[Malcolm McLean]

So what language would you suggest?

Major applications are notorious for cost overruns, if not outright failure.
A lot of them are written in C, or least were until a few years ago. That
tells us that use of C doesn't guarantee success, and it suggests that a
better language should be found.

Unfortunately there isn't one. Projects written in competing languages such
as C sharp, C++, Java, or in mixtures of various scripting lanauges and
database interfaces, also regularly fail. There might be a slight
improvement or deterioration with respect to C, but it is so slight that it
is hard to measure.

 

[jacob navia]

Major applications are notorious for cost overruns, if not outright
failure. A lot of them are written in C, or least were until a few years
ago. That tells us that use of C doesn't guarantee success, and it
suggests that a better language should be found.

Unfortunately there isn't one. Projects written in competing languages
such as C sharp, C++, Java, or in mixtures of various scripting lanauges
and database interfaces, also regularly fail. There might be a slight
improvement or deterioration with respect to C, but it is so slight that
it is hard to measure.

Result:

Programming languages do not affect really the outcome of large
projects.

 

[santosh]

Actually in the last ISO C meeting the ISO C panel finally realised that
the major use of C is in the embedded field and C99 is already too big.

In fact any changes to C are likely to include reducing it rather than
enlarging it by much.

In your estimation which parts of C99 are most likely to be dropped if
a new
Standard does come out? The least used parts perhaps? Like VLAs,
tgmath.h,
standard pragmas?

 

[Chris Hills]

In your estimation which parts of C99 are most likely to be dropped if
a new
Standard does come out? The least used parts perhaps? Like VLAs,
tgmath.h,
standard pragmas?

No idea. It was just a preliminary discussion. There is a long way to go
yet.

I think the suggestion was anything not implemented by more than 2
mainstream (in their market) compilers.