C needs a BOOST

[jacob navia]

overloading.
The problem with operator overloading is tht it requires references.
Now, if you introduce references into C, it becomes a lot less "C-
like".
So I guess that monumental collections of generic programs requires a
language like C++.

There are many other solutions.

I rewrote part of my library with

list list_add(list, $$T$$ arg)
{
// code
}

and developed a very small program that would automatically specialize
the generic code for a given type. Then you pass the expanded
code to the compiler and put it in a static library.

The C++ compiler makes not *much* more and this is completely
customizable, simple and easy to use.

 

[Charlie Gordon]

I don't think that there is such a thing as a "member of GNU".

Since you are playing smartie, let's see how good your French is:

Le membre du gnou peut mesurer jusqu'à un mètre en érection.

For sure, you would want to stay out of its way ;-)

 

[Default User]

[...]

Generic functions like
list = list_add(list,int);
list = list_add(list,double);
list = list_add(list,&CustomerStruct);

would make the library very easy to use. Above all, they
could be extended by the user at any time with

list = list_add(list,&MyNewDataStruct);

P.S. I will look at the glib again.

Ok, but C doesn't have generic functions, and you can't write a
function that takes either an int, a double, or a pointer as its
second argument.

Um, what about:

int list_add(List *list, ...);

With the type of the variable argument known based on something set in
the
List when it is created? Mind you, that might be painful to use, but
it
seems to work. I guess all pointer lists would be void* or some such.

Difficult to do with a user-defined type.




Brian

 

[David Resnick]

[...]

Ok, but C doesn't have generic functions, and you can't write a
function that takes either an int, a double, or a pointer as its
second argument.

Um, what about:

int list_add(List *list, ...);

With the type of the variable argument known based on something set in
the
List when it is created? Mind you, that might be painful to use, but
it
seems to work. I guess all pointer lists would be void* or some such.

Difficult to do with a user-defined type.

Brian

Which is why I said all pointer lists would be void *. I'd guess the
list needs something like a union of all types supported. Which
wouldn't include user defined types (by which you mean structs I
assume?), though pointers to those types would be fine... I agree it
would be clunky, just possible.

-David

 

[jacob navia]

There are many other solutions.

I rewrote part of my library with

list list_add(list, $$T$$ arg)
{
// code
}

and developed a very small program that would automatically specialize
the generic code for a given type. Then you pass the expanded
code to the compiler and put it in a static library.

The C++ compiler makes not *much* more and this is completely
customizable, simple and easy to use.

P.S. Here is the code, using the string library of lcc-win32:
#include <str.h>
int main(int argc,char *argv[])
{
if (argc < 4) {
printf(
"Usage: %s <template file> <resulting type> <input type\n",argv[0]);
return 1;
}
// Read a file into a string
String template = Strfromfile(argv[1],0);
// Replace TYPENAME with input type
Strrepl(template,"$(TYPENAME)",argv[2]);
// Replace T with output Type
Strrepl(template,"$(T)",argv[3]);
// Note the cast of a String into a char *
printf("%s\n",(char *)template);
// Done
return 0;
}

 

[santosh]

Excuse me but did I understand you correctly?

So, you say that new development shouldn't be done in C but in
"higher level" languages.

Actually then, you say it is better not to develop anything new in C.

You talk as if C were a silver bullet. Different languages are suitable for
different tasks. C is not suitable for any and every type of programming.
It very good in what it _is_ suitable for, which is why it is among the top
five oldest programming languages. But things change.

It funny you know, how you constantly complain that the "regulars" of this
group, (and comp.std.c), want to "enshrine" C and cling to the past, while
you're doing exactly the same. You seem to be obsessed with "saving" C from
a supposed death. As Andre Gillibert asked, would it _kill_ you if C did
indeed slowly fade away?

I hope we all agree that programming is more important than any one language
or the other.

 

[Charlie Gordon]

There are many other solutions.

I rewrote part of my library with

list list_add(list, $$T$$ arg)
{
// code
}

and developed a very small program that would automatically specialize
the generic code for a given type. Then you pass the expanded
code to the compiler and put it in a static library.

The C++ compiler makes not *much* more and this is completely
customizable, simple and easy to use.

P.S. Here is the code, using the string library of lcc-win32:
#include <str.h>
int main(int argc,char *argv[])
{
if (argc < 4) {
printf(
"Usage: %s <template file> <resulting type> <input type\n",argv[0]);
return 1;
}
// Read a file into a string
String template = Strfromfile(argv[1],0);
// Replace TYPENAME with input type
Strrepl(template,"$(TYPENAME)",argv[2]);
// Replace T with output Type
Strrepl(template,"$(T)",argv[3]);
// Note the cast of a String into a char *
printf("%s\n",(char *)template);

what does this cast do?
is it a form of operator overloading?
what is the life cycle of the char array to which a pointer is returned?
or are your Strings both '\0' terminated and length specified?

 

[jacob navia]

You talk as if C were a silver bullet. Different languages are suitable for
different tasks. C is not suitable for any and every type of programming.
It very good in what it _is_ suitable for, which is why it is among the top
five oldest programming languages. But things change.

It funny you know, how you constantly complain that the "regulars" of this
group, (and comp.std.c), want to "enshrine" C and cling to the past, while
you're doing exactly the same. You seem to be obsessed with "saving" C from
a supposed death. As Andre Gillibert asked, would it _kill_ you if C did
indeed slowly fade away?

I have been working since 12 years in the development of a C99
compatible standard compliant compiler system. I wanted a system easy
to use, simple, with a simple language but with all modern
sophistication of a windowed debugger, a good IDE, etc.

Yes, I believe in simple, small things. The whole IDE of lcc-win
makes for a 700K executable, compared to modern IDes that need
more than hundre MB for the same thing it demonstrates the power
of the language.

I am convinced that C is the way of the future. Simple, transparent,
it requires less memory from the user's brain, less figuring out
of what is going on, less opaque "black boxes" like the C++
compiler, programs of a sheer complexity that nobody understands
any more.

I see this at work when a coworker tells me:

Ohh sh...! This module uses the STL and I just do not understand
at all what it does!

Remember the dinosaurs?

They were extremely sophisticated compared to the small mammals.

I hope we all agree that programming is more important than any one language
or the other.

Not so. I remember APL for instance, a language that deeply
impressed me. It was fun to program in APL.

I remember MWBAsic too. It wasn't the same thing as in APL.

Yes, I program a lot in assembly, but that is completely different
again.

The language matters. And I think C is the way to go. Small
efficient and simple.

 

[jacob navia]

user923005 wrote:
overloading.
The problem with operator overloading is tht it requires references.
Now, if you introduce references into C, it becomes a lot less "C-
like".
So I guess that monumental collections of generic programs requires a
language like C++.
There are many other solutions.

I rewrote part of my library with

list list_add(list, $$T$$ arg)
{
// code
}

and developed a very small program that would automatically specialize
the generic code for a given type. Then you pass the expanded
code to the compiler and put it in a static library.

The C++ compiler makes not *much* more and this is completely
customizable, simple and easy to use.

P.S. Here is the code, using the string library of lcc-win32:
#include <str.h>
int main(int argc,char *argv[])
{
if (argc < 4) {
printf(
"Usage: %s <template file> <resulting type> <input type\n",argv[0]);
return 1;
}
// Read a file into a string
String template = Strfromfile(argv[1],0);
// Replace TYPENAME with input type
Strrepl(template,"$(TYPENAME)",argv[2]);
// Replace T with output Type
Strrepl(template,"$(T)",argv[3]);
// Note the cast of a String into a char *
printf("%s\n",(char *)template);

what does this cast do?

"Unbox" the structure and return a plain char pointer.

is it a form of operator overloading? yes
what is the life cycle of the char array to which a pointer is returned?

It still belongs to the string.

or are your Strings both '\0' terminated and length specified?

Both. This is useful as an extra check that a valid
string is passed to me. I know at all times that

String->Data[length] == 0

If that is not the case this is not a string!

 

[jxh]

[snip]

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

It would be a nice experiment to add template support to C and see
what kinds of generic solutions would fall out from it. OTOH, there
are plenty of C shops that are using C++ compilers, and cherry pick
features they want to use (such as STL).

The problem I see with template support is that it requires operator
overloading.
The problem with operator overloading is tht it requires references.
Now, if you introduce references into C, it becomes a lot less "C-
like".
So I guess that monumental collections of generic programs requires a
language like C++.

I was thinking of templates as a more elegant and powerful mechanism
for code generation than what C macros provide today. The type safety
aspect of templates are also a plus. I was not thinking of trying to
replicate STL or BOOST into C.

My hope was that clever C developers would figure out how to use C
templates for useful generic and type safe solutions that are more
efficient than the current approach of void * containers and
algorithms.

This is in the spirit of how STL evolved. C++ introduced templates
without STL first. STL was a by product of a useful C++ feature, not
a feature of C++ itself (Doug G. pointed this out).

-- James

 

[James Dennett]

Not to a so large extent.

YMMV. I've seen it achieved to an extent I judge to be
very large indeed. Your experience may not cover that;
maybe you've seen too much bad code and not enough good
code. (Come to that, *I've* seen too much bad code and
not enough good code. A common ailment.)

Maybe the string append function of std::string is as fast as, or faster
than, I could ever write, but, when using std::string, anybody tends to
make much much more copies and costy operations than when manually
managing pointers.

Bad programmers write bad code with std::string, it's true.
And they also write horrendous code when managing pointers
manually.

I remember than, when I refactored a lexical parser using the STL, to
use lower level features, I got a x20 speed up, keeping the same
algorithmic complexity.

Similarly, you might get a factor of 20 speedup by using a
good modern std::string compared to most manual pointer based
approaches, in particular as it can avoid dynamic allocation
for most strings while keeping code simple.

(There are also terrible implementations of std::string out
there, which used inappropriate pessimisations such as CoW
particularly in multi-threaded situations.)

However, std::string isn't/wasn't part of the STL, so this
somewhat misses the point. It's certainly not an example of
elegant design; it was a result of standardizing existing
practice, which happened to be ugly.

I fear this is drifting off-topic on comp.std.c, and even
for comp.lang.c. I'll bow out at this point; you may have
the last word if you wish.

-- James

 

[Laurent Deniau]

[snip]
Opinions? Is keeping the language tiny worth the cost of C
programmers having to constantly reinvent the wheel?
It would be a nice experiment to add template support to C and see
what kinds of generic solutions would fall out from it. OTOH, there
are plenty of C shops that are using C++ compilers, and cherry pick
features they want to use (such as STL).

The problem I see with template support is that it requires operator
overloading.
The problem with operator overloading is tht it requires references.
Now, if you introduce references into C, it becomes a lot less "C-
like".
So I guess that monumental collections of generic programs requires a
language like C++.

I was thinking of templates as a more elegant and powerful mechanism
for code generation than what C macros provide today. The type safety
aspect of templates are also a plus.

Type safety can be achieved easily in C. See my post for a generic
typesafe array in this news groups some time ago (google for "deniau
array"):

http://groups.google.fr/group/comp....0000?lnk=gst&q=deniau&rnum=7#0b263e52c0850000

The code is a bit heavy (e.g. macro B()) because despite of its
genericity and its type safety, it behaves like a C array (i.e. arr
is valid) while array_get provides bound-checked access. It was part
of my previous framework (called Object Oriented C aka ooc) so it is
not complete and requires the framework for exception handling. But it
takes 10 minutes to make it standalone. I have also other typesafe ADT
containers like hash table and set. The technic is not new and
frequently used in the C++ STL where templated code (e.g. std::map)
rely on standalone generic code to avoid code blowup.

I was not thinking of trying to
replicate STL or BOOST into C.

good since you can't.

My hope was that clever C developers would figure out how to use C
templates for useful generic and type safe solutions that are more
efficient than the current approach of void * containers and
algorithms.

What you can't do with macros that templates can do is specialisation.
And this is the conerstone of the "more efficient when appropriate"
like for bool containers.

This is in the spirit of how STL evolved. C++ introduced templates
without STL first. STL was a by product of a useful C++ feature, not
a feature of C++ itself (Doug G. pointed this out).

Right, but once you put the fingers into templated code, it's hard to
get out of it. BTW, templates are turing complete while cpp macros are
not. Not talking of the heavy mecanism required by the macros to
emulate part of the templates features. People who find templates
metaprogramming hugly might be afraid by macros metaprogramming.

a+, ld.

 

[Nick Keighley]

Note:
I used only ONE exclamation mark.

no you didn't.
Why do you say things like this!

 

[Nick Keighley]

Because C's implementation should be SUBSTANTIALLY smaller,
giving just bare bones usage and not all the blat that comes
with the STL

so what could be ommitted?

Yes. SMALL! Like C. And the point of is that SMALL is better in
software. Like smaller integrated circuits that are MORE efficient
than bulky ones,

bad analogy. In transistor count (ie. functionality) ICs are
getting bigger. Much bigger. That's one reason there are so few
CPU designs out there. Designing a modern IC is expensive.

SMALL software components are more mangeable and
easy to understand and USE!!!!!!!

count the '!'s...

<snip>

 

[Chris Thomasson]

Chris Thomasson said:


Previous attempts by clc to participate in similar projects have not been
conspiciously successful.

Still - hope springs eternal, eh?

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 is only one requirement I would personally leverage against any
submission: The KISS principal should be the main goal... C is low-level,
therefore we should keep anything we create for this group bound to the land
of minimalism...

Any thoughts?

 

[jacob navia]

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 is only one requirement I would personally leverage against any
submission: The KISS principal should be the main goal... C is
low-level, therefore we should keep anything we create for this group
bound to the land of minimalism...

Any thoughts?

Perfect!

 

[Richard Heathfield]

Chris Thomasson said:

Humm... I will post an example LIFO linked collection API (e.g. stack) in
a day or two.

Um... well, it's entirely up to you, obviously.

We should be able to tear it apart into something usable...

Knowing clc, I can guarantee the first bit. I'm not so sure about the
second.

<snip>

 

[Mark McIntyre]

jacob navia wrote, On 03/10/07 21:50:

I'm using a linked list package that someone else wrote for something
completely different in order to proved a number of unrelated linked
lists in a library used by several other programs.

Just to complement this: the original remark was absurd - nobody
rewrites everything from scratch at each new project - and the poster
knew it. Its exactly this kind of foolish remark that gives people a
bad reputation as posters.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[James Kuyper Jr.]

On 2007-10-03 at 17:31 jacob navia wrote:
....

> easy to understand and USE!!!!!!!

On 2007-10-03 at 18:32 jacob navia wrote:
....

I used only ONE exclamation mark.

I count 7. Is the name for 7 spelled "ONE" in your part of the world?

 

[Chris Dollin]

On 2007-10-03 at 17:31 jacob navia wrote:
...

On 2007-10-03 at 18:32 jacob navia wrote:
...

I count 7. Is the name for 7 spelled "ONE" in your part of the world?

They're just multiple /references/ to the same Platonic ideal exclamation
mark.