C needs a BOOST

[user923005]

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?

[Charlie Gordon]

"Szabolcs Nagy" <ns*******@gmail.coma écrit dans le message de news:
11**********************@50g2000hsm.googlegroups.c om...

>
jxh wrote:

>For a different example, a template function based quick sort
implementation could allow the compiler to inline the call to the
comparison function.

/* generic_qsort.c */
PREFIX(qsort)(TYPE *arr, size_t len) {
...
if (LESS(*right, pivot)) {...}
...
}
/* int_qsort.c */
#define PREFIX(s) int_##s
typedef int TYPE;
static inline int LESS(int a, int b) {return a < b;}
#include "generic_qsort.c"
#undef PREFIX

not much longer than c++ templates imho
macros are ugly though

generic)qsort is not generic enough: the LESS function and the TYPE typename
should be macroized with PREFIX as well, to allow for multiple
instantiations of generic qsort routines for different types in the same
module.

/* generic_qsort.c */
void PREFIX(qsort)(PREFIX(TYPE) *arr, size_t len) {
...
if (PREFIX(LESS)(*right, pivot)) {...}
...
}

/* mymodule.c */
#define PREFIX(s) int_##s
typedef int int_TYPE;
static inline int int_LESS(int a, int b) {return a < b;}
#include "generic_qsort.c"
#undef PREFIX
....
#define PREFIX(s) string_##s
typedef const char * string_TYPE;
static inline int string_LESS(const char *a, const char *b) {return
strcmp(a, b) < 0;}
#include "generic_qsort.c"
#undef PREFIX

TYPE, LESS and QSORT could be made macros themselves, with a similarly ugly
implementation/instantiation:

/* generic_qsort.c */
void QSORT(TYPE *arr, size_t len) {
...
if (LESS(*right, pivot)) {...}
...
}

/* mymodule.c */
#define QSORT int_qsort
#define TYPE int
#define LESS(a, b) ((a) < (b))
#include "generic_qsort.c"
#undef PREFIX
#undef TYPE
#undef QSORT
....
#define QSORT string_qsort
#define TYPE const char *
#define LESS(a, b) (strcmp(a, b) < 0)
#include "generic_qsort.c"
#undef PREFIX
#undef TYPE
#undef QSORT

Some better mechanism would certainly help writing type safe generic code:

/* hypothetical example */
/* generic_qsort.h */
template generic_qsort(qsort, type, isless) {
typedef type;
int isless(type a, type b);
void qsort(type *arr, size_t len) {
...
if (isless(*right, pivot)) {...}
...
}
}

/* mymodule.c */
#include "generic_qsort.h"

static inline int int_less(int a, int b) {return a < b;}
static inline int string_less(const char *a, const char *b) {return
strcmp(a, b) < 0;}
generic_qsort(int_qsort, int, int_less);
generic_qsort(string_qsort, const char *, string_less);

--
Chqrlie.

[user923005]

On Oct 11, 2:07 am, Richard Heathfield <[e-mail]:

J. J. Farrell said:

On Oct 10, 10:51 pm, jacob navia <[e-mail]:

<snip>

Interesting , Mr "user923005". So you are Heathfield. It seemed to me
that both "you" and "he" are the same. I wonder how many of the
c.l.c "regulars" are just the same guy!

How on earth did you make that remarkable leap of logic?

Rover is a dog. Fido is a dog. Therefore, Rover is Fido.

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

[Keith Thompson]

user923005 <dc*****@connx.comwrites:

On Oct 11, 2:07 am, Richard Heathfield <[e-mail]:

>J. J. Farrell said:

On Oct 10, 10:51 pm, jacob navia <[e-mail]:

<snip>

>Interesting , Mr "user923005". So you are Heathfield. It seemed to me
that both "you" and "he" are the same. I wonder how many of the
c.l.c "regulars" are just the same guy!

How on earth did you make that remarkable leap of logic?

Rover is a dog. Fido is a dog. Therefore, Rover is Fido.

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[jxh]

On Oct 11, 3:24 am, "Charlie Gordon" <[e-mail]:

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]

jxh wrote:

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++.

--
If you've a question that doesn't belong to Usenet, contact me at
<ta*****************@yahoDELETETHATo.fr>

[¬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:

>>"¬a\/b" <[e-mail] in message
news:6l********************************@4ax.com. ..

>>>
than there is the problem ("123"+"457") + ("123"+"456")
if the 2 () have the same precedence

Can't see anything difficult about that. Parentheses however are superfluous
beacuse concatenation is inherently associative.

("Fred" + "is") + "dead" = "Fred" + ("is" + "dead")

for all values of Fred.

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]

jxh <jx*@despammed.comwrote:

On Oct 10, 4:55 am, [e-mail] (Richard Bos) wrote:

I never used the word detraction, and I don't see what it
would detract from. I _do_ see that C is mostly a systems
language, not a bells-and- whistles already-slow application
language. Because of that, many C programmers will want to use
ADTs which have been tuned to their application, and not a
one-size-fits-all solution which does in fact _not_ fit 90% of
all cases very well.

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

[Douglas A. Gwyn]

Giorgos Keramidas wrote:

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.

[Szabolcs Nagy]

Giorgos Keramidas wrote:

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

[Giorgos Keramidas]

On Thu, 25 Oct 2007 15:01:24 GMT, "Douglas A. Gwyn" <DA****@null.netwrote:

Giorgos Keramidas wrote:

>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.

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 :)