C needs a BOOST

[Keith Thompson]

This one's funnier:
All men are mortal. All women are mortal. Therefore, all men are
women.

All men are mortal.
Socrates is a man.
Therefore, all men are Socrates.
(Woody Allen used this in one of his movies.)

All syllogisms have three parts.
Therefore, this is not a syllogism.

 

[jxh]

Compatibility with C++ may not be desirable at the syntax
level, if the semantics differ. Syntactic choices have little
impact on compiler complexity. Introducing templates in C by
transplanting a C++ implementation is hopeless.

As much as possible the semantics should not change. I wouldn't
know how hopeless it would be to try. I am certain vendors that
provide C and C++ implementations would want to try to reuse as
much code as possible. I am certain that if C had templates,
then programmers that visit both languages frequently would
appreciate it if the template syntax was the same.

-- James

 

[André Gillibert]

As much as possible the semantics should not change. I wouldn't
know how hopeless it would be to try.

I agree.

It's funny to see that all the distinctive C++ features (+ GC) have
recently been proposed on comp.std.c: OOL, classes with MI, constructors &
destructors, templates, STL, exceptions and GC.

Everytime, the poster proposed to implement things *differently*
(typically, to get something less powerful but "simplier").

I wonder how many incompatibilities we'll have to deal with, daily, if C
contains all of C++ but implemented differently.

Moreover, I don't believe that adding all the features of C++ will keep C
small. I don't see why C + templates + classes + constructors &
destructors + templates + exceptions + STL + GC would be smaller than C++.

 

[¬a\\/b]

In data Sun, 07 Oct 2007 12:23:46 +0200, ¬a\/b scrisse:

In data Sun, 7 Oct 2007 09:15:04 +0100, Malcolm McLean scrisse:

in how i see the thing (don't know if compiler follow me)
in ("123"+"457") + ("123"+"456")

first there is
tm1=("123"+"457") , tm1=("123"+"456")
than
return tm1+tm1

so if there is only one golbal variable "tm1" for doing the sum
at the end there will be a wrong result

but with one only variable tm1 all is ok with
"123"+"457" + "123" + "456";
because it is ((("123"+"457") + "123") + "456");
tm1=("123"+"457");
tm1+="123";
tm1+="456";
return tm1;

for handle all this i use a queue of static objets with a global index
someting like

obj array[16];
int index=0;

obj * function(char *a)
{obj* tmp= & (array[ index++ % 16 ]);
*tmp+=a;
return tmp;
}

and limit the level of parentesis (or number of returned function) to
15 level max
don't remember if i add code for resize the 16 global array objects
in somewhere

 

[Richard Bos]

This is where templates could have a positive impact. Most of the
limitations of generic containers and algorithms in C now are the
void * basis, which requires an extra allocation to use, or a mess
of macros, which are difficult to maintain. The availability of
templates would provide a mechanism to write near optimal general
containers, and used in more optimal ways (for example, ADTs that
can be allocated from the stack instead of dynamically).

By which time you might as well switch to an object-orientated language
and be done with it.

Richard

 

[Giorgos Keramidas]

Humm... I will post an example LIFO linked collection API (e.g. stack)
in a day or two. We should be able to tear it apart into something
usable. A simple standardized API wrt this newsgroup could be
beneficial. Well, any question that deals with common/trivial
collection abstractions can be directed at the various implementations
of this newsgroups standardized API.

There's already a BSD-licensed implementation of various 'collections'
of objects, including:

* Singly-linked lists.

* Doubly-linked lists.

* Tail queues.

* Singly-linked tail queues.

Maybe you could start with something like this, and extend it a bit?

The supported data structures are not really great in number, but they
are still quite useful in many cases.

The source for the macros I'm referring to is part of the source tree of
the various BSDs out there, and parts of it have already made their
way into the Linux kernel too. See for example:

http://cvsweb.freebsd.org/src/sys/sys/queue.h

The documentation of the existing macros, in groff_mdoc(7) format, is
also available at:

http://cvsweb.freebsd.org/src/share/man/man3/queue.3

With the small exception of the STAILQ_LAST() macro -- which depends on
a call to__offsetof() to work properly -- the rest of the macros are
fairly easy to port/reuse in at least the following systems:

* FreeBSD, using various GCC versions
* FreeBSD, using the Intel C compiler
* OpenBSD, using GCC
* NetBSD, using GCC
* Solaris 8, 9 and 10, using either GCC or Sun Studio
* Linux, using various GCC versions

This list is not exhaustive, but it only includes the systems I have
used so far.

I'm not sure if macros are the appropriate way to go, but they may be
useful as you try to come up with a set of 'collection' structures for
standard C. I know that they have been very useful for me during the
last few years, but YMMV

- Giorgos

 

[Douglas A. Gwyn]

There's already a BSD-licensed implementation of various 'collections'
of objects, ...

I don't think the problem is the existence of candidates,
but rather that there are many of them and everybody has a
different opinion about what the best interfaces should be.

 

[Giorgos Keramidas]

I don't think the problem is the existence of candidates,
but rather that there are many of them and everybody has a
different opinion about what the best interfaces should be.

You are right, of course.

I haven't been watching the c.l.c thread about this sort of things very
closely, but I'm sure there are at least as many opinions about the
``best interface'' as the people involved

 

[Szabolcs Nagy]

The source for the macros I'm referring to is part of the source tree of
the various BSDs out there, and parts of it have already made their
way into the Linux kernel too. See for example:

http://cvsweb.freebsd.org/src/sys/sys/queue.h

those are extremely ugly and dangerous macros

i'd rather use a code generator that generates clean typesafe code for
my containers.

cpp has many problems: hard to maintain, hard to debug (a lenghty
macro is expanded in one line), it can trick the users since a macro
looks like a function, etc

of course it's difficul to create a nice maintainable syntax for the
code generator with the right level of abstraction (a container
usually has many parameters, not just the data type, which can
influence the implementation)


when it's ready i could say:
'hello i need a char*->int open addressing hashtable with ht_ prefix,
75% fill threshold, strdupping/freeing keys, simple hashfunction,
asserts on invalid parameters and other errors'

which would give me a nice clean hashtable implementation, with
apropriate api.

cpp macros will never be able to do this
and i don't think c++ templates are the right way either

 

[Richard Heathfield]

Giorgos Keramidas said:

You are right, of course.

I haven't been watching the c.l.c thread about this sort of things very
closely, but I'm sure there are at least as many opinions about the
``best interface'' as the people involved

Yes, "at least as many" implies that there may be more, and I think you are
right and there are more. For example, I have *several* opinions, all
different, as to what constitutes the "best interface" (which is why I'm
staying well out of that discussion), and I am convinced that *each* of
them is best - i.e. better than all the others - in a particular situation
(but, of course, not necessarily in other situations).