Boost process and C

[Herbert Rosenau]

About libclc - how is that doing? It seems to have just dried up
without notice. Also, I seem

If a C programmer is writing a reasonably large program these days,
what are the first libraries that are commonly used for collections of
data structures, better strings, etc?

stdlib
string.h
sometimes but not regulary:
- curses ones when his job requires curses
- database ones when his job requires database

and the ones he needs to get his program to work. That means
- system specific ones holding the system APIs he needs.
- the ones he has used to write his own libraries
when he have a need for.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Herbert Rosenau]

(e-mail address removed) a écrit :

Twitsdale, who has proven already that he does not even know what C is
quacks:

Nowhere. Since the C standard comitee refuses to improve the language,
there are a lot of libraries but all of them incompatible.

Basically, the opinion here is that data structures are too much of an
intellectual effort for C programmers...

Leave this group and go to FORTRAN and use its operator overloading
that you says it owns instead to babble senseless crap.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Ian Collins]

jacob navia said:







Well, okay, let's just say for the sake of argument that we're going to add
standard data structure APIs to C.

First step - decide what's in and what's out. Let battle commence.

When you eventually get the blood out of the carpet, the second step is to
agree on an interface. That will take forever and a day.

Third step - get people to use your shiny new standard container library.
Except that they won't, of course, because they will all just carry on
using whatever it is that they're using right now.

The C++ committee did it, is it too hard for C to do the same?

 

[Richard Heathfield]

Ian Collins said:

The C++ committee did it, is it too hard for C to do the same?

Let's find out. First, the wishlist. See if you can get everyone here to
agree what's in and what's out.

 

[Ian Collins]

No surprise here either, if you do not use this feature. Contrary to C++
all this is completely optional. The behavior of old programs and of
programs written not using this features is not affected.

You appear unable of understanding the simple fact that "all this" is
optional in C++ as well.

 

[Chris Hills]

The C++ committee did it, is it too hard for C to do the same?

Most users of C want a compact and efficient language. Many have
complained that they don't want all the "new" features in C99 hence the
reason why 7 years on there have been very few implementations of 99

I can't understand why people want to add a lot of C++ features to C. If
you really need those features use C++

 

[Chris Hills]

CBFalconer a écrit :

Not even that. I told him that I would not even look into it without a
fair payment. Why should I work for him for free? He was the only one
using a 486 that I have ever heard of.

The 486's I know that are still used tend to use the Caduel compiler.
However I think there is more use of the 386 than the 486.

 

[CBFalconer]

jacob navia said:

Mine ports just fine, thanks. You know why? Because I am careful to write
portable code that isn't full of silly use-me-and-lock-yourself-in
extensions such as are to be found in, say, lcc.

Now you are being unfair to lcc, which AFAIK is an accurate and
portable C compiler. It's the lcc-win32 version that is far behind
(I think by about 10 versions) and that sports the anti-portability
execrations and lack of reliability.

 

[CBFalconer]

CBFalconer a écrit :
.... snip ...


Mr Falconer insisted that I keep lcc-win32 compatible with his 486
system. I refused without a maintenance contract, and he did not
forgive me that to this day.

Don't lie. I never insisted on anything. You were totally unaware
of a problem, due to lack of testing. I simply abandoned the
system, and have never recommended it since.

You will note that M.Navia does not want to hear about bugs.

 

[Ian Collins]

Most users of C want a compact and efficient language. Many have
complained that they don't want all the "new" features in C99 hence the
reason why 7 years on there have been very few implementations of 99

I can't understand why people want to add a lot of C++ features to C. If
you really need those features use C++

Agreed, that's why a draw the distinction between new language features
and a new library.

The former can be found in other languages, the latter will make
reliable, portable code easier to produce. The C++ standard library
certainly has, no more roll your own and vendor specific containers.

 

[Richard Heathfield]

jacob navia said:

Ian Collins a écrit :

Apparently yes.

I'd be delighted to be proved wrong - but nobody seems terribly interested
in providing concrete proposals (possibly because they know that nobody
will agree about which containers should be included or what their APIs
should look like).

 

[Flash Gordon]

Keith Thompson a écrit :

We had this discussion already. I started yet another discussion about
the need for a portable standard container library several times and the
answers were:

Mr Flash Gordon, a "regular" here said: (11 Oct 2004)

"Not only can a lot of programing be done without using hash tables,
list, queues etc, but as I said a lot of programming *is* done without
using such things. Also the natural solution for a lot of problems does
not use such things.

In reply to you saying:
| Since the first message in this thread (admitted, polemic)
| I wanted to take a critical look at remarks like "I never use any
| data structures", and such, implying that C (or programming) can
| be done without using containers like hash tables, lists,
| queues, etc.

Is there anything wrong with pointing out that there are large problem
domains which

Our dear Dan Pop, another "regular" said... (21 March 2004)

"It's been 12 years since I've used a binary tree the last time. In the
meantime, the most complex data structure I *needed* to use was an array
of structures. And I suspect that many programmers use linked lists
only in their homework assignments. "

They fact that people have spent years on serious projects without the
needs of such things proves that you implication that they are required
for serious programming is false.

And everyone accepted those things in silence. Nobody complained.

Obviously they could see the point that there is a lot of serious
programming that does not require such things.

Oh, I just noticed, you appear not to have complained about my comment
either as far as I can see in Google.

The standards comitee doesn't even accept simple data structures like
strings. Lists, flexible arrays, stacks, queues, etc etc must be done
over and over, and are kept OUTSIDE the standard library.

They don't have to be done over and over again. Just pick an
implementation and keep using it.

Why?

Because everyone should use the STL damm it!
Why?

I repeat that such an attitude towards data structures means that indeed
C is the past and C++ the dreaded future.

You (or others) can implement those things in standard reusable C if you
require then. In fact, since October 2004 my job has moved on and I've
done some work using a linked list library written by someone else in
standard C and I'm now using an XML library written in C (the bits I've
looked at are all standard C). I didn't have to write these libraries,
nor did I need them to be part of the C language to use them.

Just because you are unable to write a reusable linked list
implementation in standard C doesn't mean that others can't. To quote you:
| OK. That is what I wanted. I think that the language is making too
| difficult to do that. Each time I need a list, I have to rewrite
| a new set of:
| DATA_LIST *AddToList(DATA *item);
| FindInList(DATA_LIST *list,DATA *item);
| etc

Strangely enough you didn't respond (as far as I can see in Google) to
my suggested alternative interface that would not require rewriting each
time.

I am not inventing this Keith, you should know. You participated to
those discussions.

And you know perfectly well that when I say:


I am not insulting anyone but precisely arguing AGAINST that frame of mind.

We use complex data structures when we need them often just reusing
existing code. We don't use them when we don't need them.

Personally I would have no problem if some of the things you suggest
were added to standard C, but that is a discussion for comp.std.c as has
already been pointed out. Or for the standards committee if you want to
join it.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php

 

[Ian Collins]

Ian Collins a écrit :


In another subthread we had this argument already. It is impossible to
dissociate operator overloading from the object oriented framework in
C++. Some operators need a class to be defined, and the implementation
in C++ of operator overloading lacks essential features like
multi-dimensional array indexing, differentiation between read/write
array access and others.

It has been pointed out elsethread that C would require the same baggage
to implement operator overloading. You have to have an object to
operate on! How would yo implement a = b+c on a plain struct without
the means of constructing a temporary object?

The simple point I'm trying to make is you can write C style procedural
code in C++ without any run time support or object related baggage. All
'advanced' features have a cost, paying that cost is the programmer's
choice.

 

[Ian Collins]

Ian Collins a écrit :



In standard C when lcc finds a function that returns a structure by
value like:

STRUCT fn(int arg1);

actually it passes a destination address to fn1 making it:

void fn(STRUCT *__invisiblearg,int arg1);

This allows fn to return its result in an invisible passed in pointer.

I could do with some effort make lcc-win32 recognize the pattern
a = b+c and pass the address of a instead of a temporary.

I will do it this summer when I can work in that part of lcc-win32 again.

That's OK to avoid a temporary, but a typical implementation of operator
+ is

T operator+( const T& a, const T& b )
{
T tmp = a;
a += b;
return tmp;
}

The problems I see are the new requirement for references and the
creation of tmp when a shallow copy of a T is inappropriate (say it
contains pointer members).

Yes, true. Both languages have a common subset.

Besides, I would like to point out that I am by no means saying that
people that use C++ are bad, or that I do not respect their views. I
have another point of view, that's all.

Good, that ends that silly argument!

 

[Richard Heathfield]

CBFalconer said:

Now you are being unfair to lcc, which AFAIK is an accurate and
portable C compiler.

I have no wish to be unfair to lcc. What I am talking about is the use of
extensions such as Jacob Navia frequently mentions here in clc. Such
extensions render unportable any code that uses them. It is interesting
that Jacob is here arguing that portability is a significant issue, whereas
he has so often argued that it is not.

It's the lcc-win32 version that is far behind
(I think by about 10 versions) and that sports the anti-portability
execrations and lack of reliability.

I shan't comment on reliability aspects, because I don't use lcc-win32
myself. As for extensions, I think they're a Good Thing, in that they add
power to the programmer's elbow. But I also think that discussion of them
should be restricted to newsgroups where they are topical. This newsgroup
isn't one of those.

 

[jacob navia]

Ben C a écrit :

[...]

The problem with ultra FAT languages like C++ is their incredible
complexity!

Constructors and destructors?

Who needs them?

YOU, because you needs operator overloading, that requires constuctors
to define the operators to overload and destructors to undefine them.

Not at all. Operator overloading is (or can be) nothing more than
syntactic sugar, allowing an operator symbol to be used as a function
name.

This is true, but you do need to predefine what's I suppose a template
for the prototype of the function it's syntactic sugar for. Probably:

struct T operator+(struct T a, struct T b);
struct T operator=(struct T a);

For something like struct Complex this would be fine, but for a large or
complex T, or one which is subject to some specialized kind of
memory-management, you might not choose to define your functions like
this, but more likely like this:

void operator+(struct T *result,
const struct T* a, const struct T *b);

lcc-win32 does this automatically already. It converts all functions
that return a sructure by value from:
TYPE fn(...)

to

void fn(TYPE *result,...);

The only thing is that the user has no access to "result", the first
argument that is automatically supplied by the system. Workarounds
exists but they are not pretty (in the existing implementation)

With operator overloading supported in the language you lose the ability
to distinguish... until you put that ability back by letting you
redefine constructors and destructors, and adding references to the
language.




I'm not familiar with Ada, but I think the key point is whether the
language has explicit or implicit memory management.

In C, builtin types are passed around by value and space for them
doesn't need to be allocated or freed. Operators work well with such
types.

The easiest way to "bolt on" operator overloading is to stick with C's
current system in which values of variables of user-defined types are
entire instances that are implicitly "memcpy"d.

lcc-win32 ofers a second alternative: the garbage collector, where all
this problems of allocation/deallocation are solved automatically. This
may or may be not a good solution, depends on your memory usage. In any
case it should be considered when speaking about memory allocation issues.

But often C programmers implement their own reference-counting systems,
garbage collectors, specialized allocators, etc., and manage pointers to
objects using functions into these explicit memory managers. How do you
fit this under the very strict interface of overloaded operators? The
same way you fit anything under a strict interface-- with callbacks,
i.e. "constructors". Suddenly you're reinventing C++.

No, we do not need constructors if overloaded operators receive an
already built object, and receive a pointer to the result.

Note that operator overloading is needed for two main applications:

1) Defining a new kind of numeric types.
2) Defining access for a new kind of array.

Period. Other usage is possible, but it is not the main thrust of the
implementation.

In languages with automatic memory management in which the values of
variables are consistently references to automatically allocated and
de-allocated objects, user-defined types already behave a lot more like
builtin types, and so operator overloading fits in much more easily.

lcc-win32 does not allow operator overloading for operations that are
already "taken" by the language. For instance pointer subtraction is
well defined in C, so it is not possible to define:

TYPE operator-(TYPE *a,TYPE *b);

You have to either define:

TYPE operator-(TYPE a,TYPE b);

or

TYPE operator-(TYPE &a,TYPE &b);

if you accept references into the lanuage.

You are right, it could, but it would be of limited utility. The most
common use I've ever found for operator overloading is for matrix
arithmetic, where the matrices are potentially very large, or may be
stored in unusual ways (storing two triangular matrices in one square
array is common for example). For this the code that adds and multiplies
the matrices has to be dovetailed in with the code that knows how to
allocate, deallocate, and find the data. You need a similar level of
automation for both kinds of activity for operator overloading to be
really useful.

There is a work around for this problem that is also used in C++:

All operators for the elementary operators return a dummy result that
just records the type of operation and the arguments in a list.

The overloaded operator assignment then, parses the whole expression and
directs the operations to be realized.

But those are very sophisticated usages. Much simpler is the ability to
add numeric types into the language without so much pain as in C right now.

And, above all, keeping the whole stuff SIMPLE.

jacob

 

[jacob navia]

Richard Bos a écrit :

Operator overloading... yeurgh. What does random_struct_x *=
random_union_y + random_integer_z; _do_ in the first place?

int128 operator*=(int128 a,int128 b);

Well that should multiply a*b and assign the result to a, returning a,
I suppose. What is so weird about that?

References... yikes! When I want my object to change behind my back
without me even being aware of it, I'll use first-generation FORTRAN and
change the value of 3, thank you very much.

References precisely do NOT change at all. They always point to the same
object! It is NOW That pointers can be changed behind your back to point
to something else. References avoid that!

References in the lcc-win32 implementation are exactly equivalent to
pointers with two restrictions:
1) they can't be NULL
2) They are assigned immediately after their definition and point always
to the same object.
3) When using them, they are always immediately dereferenced.

MYSTRUCT Lstruct // a global structure

void fn(void)
{
MSTRUCT &a = Lstruct;

Now, "a" is a pointer that will always point to Lstruct and always
be dereferenced when it is used:

a.one_field = 23;

instead of
a->one_field = 23; // Not needed since "a" is
// always dereferenced.

Not very difficult to understand. Besides those two properties they are
exactly like any other pointer and keep the advantage of passing things
around with a pointer and not by value.

STL... bah. When I want to use a linked list, I want to use _this_
linked list which is tailored to _this_ application, not some Extruded
Datatype Product which may be "good enough" for most applications and
has precisely the wrong properties for mine.

Well, then GO ON USING _that_ list tailored to _that_ application.

Other people that recognize that a single linked list will be always a
single linked list in all cases will be HAPPY TO LEAVE THAT CODING to
some library function that is portable across all implementations.

C is simple, clean and efficient. Let's keep it that way.

Nobody is changing that, as I have stressed over and over. But it is
impossible to define new numeric types and new kind of arrays in C, so,
sorry, this hole should be closed, that is all.

We need length prefixed strings, and the ability to define new numeric
types and operations for them.

 

[jacob navia]

Richard Bos a écrit :
[snip]

Functions which take a reference can change _my_ object behind my back,
and the only way I'd know about it is if I dug up the prototype. You
cannot tell from a single call. With pointers, the difference is always
clear. To illustrate:

With or without references, you know that
function1(*object);
might well change object, because it takes a pointer.
Without references, you can rest assured that
function2(object);
will never change object, because it does not take a pointer.
_With_ references, though, you always have to assume that
function3(object);
could change object, because you just cannot tell from that call whether
it takes a normal parameter or a reference.

This could be a valid concern Richard of course. But at least in
lcc-win32's implementation this does NOT apply.

If a function takes a structure by value as argument and you pass it a
reference, the reference will be COPIED into the stack and if you change
that it will change the COPY and not the original object as it should
be. Maybe this is not what C++ does, I do not know.

To allow passing references as a pointer you have to write
function3(TYPE &object);

In that case the object can be changed.

Three restrictions. And bright red uniforms. But those are not
references as it is generally understood. They're also mostly useless. I
cannot imagine wanting such a type when I already have normal pointers.
OTOH, they're also - being toothless - not harmful, the way a real
reference is.

For enlightenment on what is generally meant by "reference" in
programming, see the C++ Standard.

I do not really care, I am not trying to copy C++. The only advantage of
references is that they are never NULL in my implementation, and they
are (maybe) not as powerful as the C++ ones.

Why?

Avoiding changing objects behind the back of the programmer.

So I do - but if my implementation had to come with a shitload of
baggage, and I would have to understand all that shitload just to read
other people's code - instead of just understanding _that_ code - it
would make that implementation a chore to use.

Excuse me but this arguments AGAINST having to learn over and over again
the zig different list implementations you see? There would be only one!

...are idiots, much as the people who recognise that an apple will
always be an apple (and happily bite an unripe one).

C'mon Richard

Yet you want to add three metric tonnes of baggage to this language. How
is that simple, clean and efficient?




...like we need a hole in the head.

What is wrong with length prefixed strings Richard?

Can you put forward your *arguments* instead of just sending polemic to
the discussion?

WHY are length prefixed strings wrong?

I am waiting for an argument Richard.

jacob

 

[Keith Thompson]

[...]

The problem with ultra FAT languages like C++ is their incredible
complexity!

Constructors and destructors?

Who needs them?

YOU, because you needs operator overloading, that requires constuctors
to define the operators to overload and destructors to undefine them.

Not at all. Operator overloading is (or can be) nothing more than
syntactic sugar, allowing an operator symbol to be used as a function
name. There no necessary connection to constructors and destructors.
(The 1983 version of Ada had operator overloading but did not directly
support object orientation.)

I believe that, theoretically, a form of operator overloading could be
added to C without bringing in any of the other baggage of C++.

(I'm not commenting on whether it would be a good idea.)

 

[Keith Thompson]

CBFalconer a écrit : [...]

His recent citing of Trollsdale as an authority goes beyond any
pale.

Maybe you should cite the context too?

I did not cite him as an authority but as a representative of a view
that is always repeated here:

C++ is the future, C is the past. If you want any improvement to C
just use C++.

If the only example of that attitude you can think of is a quotation
from Tisdale, you should consider the possibility that this attitude
is not as common here as you claim it is.

There are programmers who need (or think they need) features that are
provided by C++, but not by C. Those programmers are better advised
to use C++ than to wait however many decades it might take to get
those features standardized and implemented in C. Most of the rest of
us here in comp.lang.c are content to use and discuss C as it
currently exists.