C needs a BOOST

[jxh]

Why use this horrible syntax ?

As stated in the quoted material, it is for compatibility with
C++, but also to lessen the burden of introducing the feature
into C compilers.

-- James

 

[André Gillibert]

As stated in the quoted material, it is for compatibility with
C++, but also to lessen the burden of introducing the feature
into C compilers.

I guess you are refering to environments providing tightly cooperating
C++ and C compilers.
That's what some people call C/C++ compilers, but I don't like the latter
term as it gives the wrong feeling that C/C++ is a language.

 

[jxh]

I guess you are refering to environments providing tightly cooperating
C++ and C compilers.
That's what some people call C/C++ compilers, but I don't like the latter
term as it gives the wrong feeling that C/C++ is a language.

I guess we are in complete agreement.

-- James

 

[¬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 * function(char *a)
{obj* tmp= & (obj[ 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]

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

One of the most important differences between C and many other
languages, including C+++Boost, is that C does not believe the marketing
line that "One size fits all". This is a Good Thing. It would be nicest
if it stayed that way.

Richard

 

[Douglas A. Gwyn]

And size_t which can be larger than unsigned long or ptrdiff_t which can
be larger than long.

That matters only in an environment under which you would have
had problems anyway. The essential assumption which has changed
was that type {unsigned} long would be wide enough to hold any
value of any integer type (typedefed or not). While we tried to
insist on C90 implementors choosing types accordingly, several
implementations felt obliged to "cheat" in order to accommodate
the much larger object sizes that were becoming common. At
least with C99 there is now a "widest supported type" that is
specifically designed to be used for such purposes.

 

[Douglas A. Gwyn]

... jacob has argued against C++-style destructors
because they're difficult to implement; the point is to make the
compiler, rather than the programmer, do that hard work.

Note also that this was raised in connection with GC, which is
quite analogous: make the compiler keep track, rather than the
programmer.

 

[user923005]

One of the most important differences between C and many other
languages, including C+++Boost, is that C does not believe the marketing
line that "One size fits all". This is a Good Thing. It would be nicest
if it stayed that way.

Do you honestly believe that having a huge, debugged, efficient
toolkit at your disposal is a *detraction*?
That's really weird (to me).
I can think of literally zero drawbacks from having the STL and BOOST
at your disposal in C++.
They are supremely well documented and very well engineered.

It turns out that it would be very hard (because of the lack of
generic programming fascilities) to produce the same thing in C.
This means that C is relegated to a niche that it could otherwise
escape if it had the same tools available.

 

[Ian Collins]

Do you honestly believe that having a huge, debugged, efficient
toolkit at your disposal is a *detraction*?
That's really weird (to me).
I can think of literally zero drawbacks from having the STL and BOOST
at your disposal in C++.
They are supremely well documented and very well engineered.

It turns out that it would be very hard (because of the lack of
generic programming fascilities) to produce the same thing in C.
This means that C is relegated to a niche that it could otherwise
escape if it had the same tools available.

A part of C did escape, then it morphed into C++....

 

[santosh]

A part of C did escape, then it morphed into C++....

I suppose Bjarne did a fork() of C then did an execv("C++", ...);

 

[Malcolm McLean]

Chris Thomasson said:


Practically, there is no "rule of two" anyway. It's just something that
Malcolm has made up. A "rule of two" assumes that the number two not only
exists but is a significant and therefore reasonable number.

It's a psychological rule. As are all the ten rules of programming.

 

[Ben Pfaff]

It's a psychological rule. As are all the ten rules of programming.

Shouldn't there only be two rules of programming?

 

[Richard Heathfield]

Ben Pfaff said:

Shouldn't there only be two rules of programming?

The two rules of programming are:

1 : Don't do it;

2 (for experts only) : Don't do it yet.

 

[jxh]

Note I'm not proposing the addition, it's just that RAII is
the one thing I miss most when swapping from C++ to C. Just
about everything else can be worked around in standard C. The
closest equivalent I know of is pthreads cleanup handlers.
Maybe something along those lines might be a more acceptable
extension to C?

Not exactly RAII, but it gives the feel of an "atreturn"
mechanism. First a sample program that uses it:

#include <stdio.h>
#include <stdlib.h>
#include "atreturn.h"

int main (void) {
void *p = malloc(10);
if (p == 0) {
fprintf(stderr, "malloc failed\n");
atreturn EXIT_FAILURE;
}
atreturn_begin {
puts("in atreturn");
free(p);
} atreturn_end;
printf("p is %p\n", p);
atreturn 0;
}


I define the atreturn word to signal the intention of using
an atreturn block, because I couldn't figure how to write a
macro that defined return itself that wouldn't break if there
was no atreturn block defined.

The implementation uses setjmp/longjmp, which is kind of
heavy duty for a "within function" application, but it seemed
the only reasonable way to deal with multiple atreturn
statements from the same function. It also made writing an
atreturn macro that emulated a single statement easier.

The "atreturn.h" header file follows:

#ifndef X_ATRETURN_H_X
#define X_ATRETURN_H_X

#include <setjmp.h>

static jmp_buf x_atreturn_jmp_buf_x;

#define atreturn \
if (setjmp(x_atreturn_jmp_buf_x) == 0) \
goto x_atreturn_begin_x; \
else return

#define atreturn_begin \
do { \
goto x_atreturn_end_x; \
x_atreturn_begin_x: \
do

#define atreturn_end \
while (0); \
longjmp(x_atreturn_jmp_buf_x, 1); \
x_atreturn_end_x: (void)0; \
} while (0)

#endif /* X_ATRETURN_H_X */


-- James

 

[Richard Bos]

Do you honestly believe that having a huge, debugged, efficient
toolkit at your disposal is a *detraction*?

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.
IOW: many, perhaps most, C programmers are going to either ignore or
hack around in any semi-standard ADT libraries anyway. This is in fact
what many programmers now do with non-standard ADT libraries already.
Therefore, the advantage of a semi-standard ADT library over, say, the
old Snippets libraries (remember those?) would be near nil.

Richard

 

[jxh]

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

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

-- James

 

[Szabolcs Nagy]

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

 

[user923005]

/* 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

I used this very technique in the source code for chapter 13 of "C
Unleashed".
I called it PRELUDE instead of PREFIX.

 

[jxh]

/* 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

This is nice general way for explicit instantiation of a
routine.

However, for each new array of things to be sorted, a new
explicit instantiation block will need to be added, and the
caller will need to remember what prefix he used to properly
call the routine. A different developer may not know that
an instantiation already exists, and may create another
instantiation. For compound types, different developers may
create duplicate instantiations that use different prefix
names, although the actual underlying type is the same.

I am not sufficiently clever enough to devise on the spot a
useful example that templates could solve that cannot be
mimic'd in some way with C macros. But, I am certain that
*someone* would be able to, if not on the spot, then in the
near future. And, the availability of templates would increase
the chances of efficient generic data structures and algorithms
being available in a future C standard (which is how it
happened for C++).

-- James

 

[jacob navia]

I used this very technique in the source code for chapter 13 of "C
Unleashed".
I called it PRELUDE instead of PREFIX.

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!