C needs a BOOST
user923005
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?
André Gillibert
> It would be really nice if C could adopt a really nice algorithms
> library like C++'s STL + BOOST.
>
How would you implement that in C?
Is there any solution simplier than transforming C into C++?
(GC and operator overloading proposed by jacob navia won't provide generic
algorithms).
> Is keeping the language tiny worth the cost of C
> programmers having to constantly reinvent the wheel?
>
Keeping the language small makes C different from C++, and that's why, C
can still be better than C++ for some projects.
On the other hand, transforming C into C++ would be pointless, as it would
make the C and C++ language duplicates.
> 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?
>
Propose an implementable solution. Ideally, with several successful
real-world implementations.
Then, we may consider your offer.
--
If you've a question that doesn't belong to Usenet, contact me at
<tabkanDEL...@yahoDELETETHATo.fr>
jacob navia
> user923005 wrote:
>
>> It would be really nice if C could adopt a really nice algorithms
>> library like C++'s STL + BOOST.
>>
>
> How would you implement that in C?
> Is there any solution simplier than transforming C into C++?
> (GC and operator overloading proposed by jacob navia won't provide
> generic algorithms).
>
There are several solutions to your "problem" of genericity.
The first one is the usage of the generic pointer in C: void *
I have written a dynamic table package using that approach. You tell
the software how big your objects are, and then you just use them.
Operator overloading allows you to assign and read the data.
True, the functions return a void pointer that must be casted into
something but that is a minor inconvenience.
>> Is keeping the language tiny worth the cost of C
>> programmers having to constantly reinvent the wheel?
>>
>
> Keeping the language small makes C different from C++, and that's why, C
> can still be better than C++ for some projects.
This is an error. Keeping the language in this state makes the language
impossible to use for any serious software development
unless your project is big enough to warrant rewriting the
C library and adding stacks, lists, etc etc at each project!
> On the other hand, transforming C into C++ would be pointless, as it
> would make the C and C++ language duplicates.
>
Yes. What I am proposing is nothing of the sort.
I am just proposing using operator overloading, a very common
feature found in almost all languages including FORTRAN, Visual Basic,
C# C++, and what have you!
>> 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?
>>
>
> Propose an implementable solution. Ideally, with several successful
> real-world implementations.
I have done just that.
Only flames ensued.
> Then, we may consider your offer.
>
You can consider mine. It is working, it has an implementation,
why not looking at it?
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Clever Monkey
> 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?
>
third-party APIs that give you this.
There are plenty of reasons to keep a language small, and let the
implementors provide solutions for their customers.
jacob navia
We had a discussion about this a few weeks ago.
I proposed several minor modifications to the language to be able to
access containers, stacks queues, lists and other objects by using
an uniform interface. Please see the thread "Operator overloading in C"
in comp.std.c, started by myself on September 5th.
You can download an implementation of those ideas at
http://www.cs.virginia.edu/~lcc-win32
Malcolm McLean
> It would be really nice if C could adopt a really nice algorithms
> library like C++'s STL + BOOST.
>
to use someone else's interface. In the case of the liked list, queue and
stack it is unclear whether this says something good or something bad about
C.
For more complicated structures it seems clear that you shouldn't have to do
them yourself. Plenty of code is publically available, some of it written by
myself. However it always seems to define bool, or take control of your
main, or demand the filling in of complex structures to get the system
operational, or doing at least something unspeakable. The code portion of my
website is not especially popular, with the exception only of the Basic
interpreter.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
jacob navia
> user923005 wrote:
>> 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?
>>
> Why does this have to be part of the language? There are plenty of
> third-party APIs that give you this.
>
Each one different than the other. There isn't a STANDARD way of doing a
list, so you have to construct a list each time you want to use one!
But we have discussed this several times, and nothing ever changes.
gets() is still there and will stay with us at least till 2019.
> There are plenty of reasons to keep a language small, and let the
> implementors provide solutions for their customers.
Most of the time this means that each developer is forced to write
a list handling stuff at each application.
--
jacob navia
jacob navia
> "user923005" <dco...@connx.com> wrote in message
>> It would be really nice if C could adopt a really nice algorithms
>> library like C++'s STL + BOOST.
>>
> It is generally slightly easier to implement a structure from scratch
> than to use someone else's interface. In the case of the liked list,
> queue and stack it is unclear whether this says something good or
> something bad about C.
>
It just says that you must reinvent the wheel at each
application.
Great Malcolm.
> For more complicated structures it seems clear that you shouldn't have
> to do them yourself. Plenty of code is publically available, some of it
> written by myself. However it always seems to define bool, or take
> control of your main, or demand the filling in of complex structures to
> get the system operational, or doing at least something unspeakable. The
> code portion of my website is not especially popular, with the exception
> only of the Basic interpreter.
Wouldn't it be a good idea to propose an STL clone?
It *can* be done in C!!!
That would be an interesting undertaking no?
--
jacob navia
Eric Sosman
> André Gillibert wrote:
>
>>Keeping the language small makes C different from C++, and that's why, C
>>can still be better than C++ for some projects.
>
>
> This is an error. Keeping the language in this state makes the language
> impossible to use for any serious software development
> unless your project is big enough to warrant rewriting the
> C library and adding stacks, lists, etc etc at each project!
Since C is impossible to use for serious software
development, one wonders why so many programmers spent
so many years writing so much non-serious (comic?)
software. Ritchie, Thompson, heck, even Torvalds have
just been clowning around, right?
jacob navia
Can't you read?
I cite this again then:
>> unless your project is big enough to warrant rewriting the
>> C library and adding stacks, lists, etc etc at each project!
In my debugger project there was obviously a list module
Then in the IDE too.
Then, in the compiler there is another one.
Then it seemed stupid to me at spent time making the debugger
use the IDE list package.
Yes, that happens. Not to you of course.
André Gillibert
> There are several solutions to your "problem" of genericity.
>The first one is the usage of the generic pointer in C: void *
At the cost of performances, but that's the cost of abstraction, anyway.
If that's all user923005 wants, he can use GLib or other C librairies.
> You can consider mine. It is working, it has an implementation,
> why not looking at it?
>
I looked at it.
jacob navia
> jacob navia wrote:
>
>
>> There are several solutions to your "problem" of genericity.
>> The first one is the usage of the generic pointer in C: void *
>
> At the cost of performances, but that's the cost of abstraction, anyway.
> If that's all user923005 wants, he can use GLib or other C librairies.
>
I tried to use the Glib, but then I was confronted with a HUGE package
that I would have to port everywhere and I could not control
at all.
It would be much better for everybody that we had a standard
interface like in C++ and then use a standard library!
André Gillibert
> I tried to use the Glib, but then I was confronted with a HUGE package
> that I would have to port everywhere and I could not control
> at all.
>
> It would be much better for everybody that we had a standard
> interface like in C++ and then use a standard library!
In that case, you must expect that this HUGE package be bundled with every
C implementation... I hardly can see why C implementors would produce
better code than GNU's guys.
Actually, with C++'s STL, I've seen that most implementations have an
incredibely low QOI. Consequently, I've always to use an external
implementation (STLPort) which has far less bugs, and produces much better
code.
I don't see why the STL problem wouldn't be reproduced for C.
Unfortunately, C doesn't support namespaces, so it's not easy to replace
the standard library with a different implementation.
With the C++ STL experience I got, I think it's important to get the
standard library small, mainly containing components that cannot easily
and efficiently be implemented in pure standard C.
Otherwise, you're sure to get all the bloat with every C implementation.
Cross-compiler linking will result in linking issues or duplication of the
code bloat.
Douglas A. Gwyn
> 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?
C++ didn't have those either, initially. They got tacked on
along the way as agreement was reached on them.
There are far fewer active workers on the C standard than have
been involved with C++, and no major incentive to spend any
significant fraction of the available resources working on
such libraries. Note that the C standards group *has* worked
on several extensions, generally described in Technical
Reports, and adopted complex numbers (with library support)
into the C standard due to demand from the numerical
programming community.
> Opinions? Is keeping the language tiny worth the cost of C
> programmers having to constantly reinvent the wheel?
You don't have to reinvent this wheel if you use an already-
developed library that provides what you need. It just won't
be provided automatically with the C compiler, so you have to
arrange to obtain it separately. I have my own library with
support for things like you mentioned, and other experienced
programmers and programming shops most likly do also.
If you find a good example that you would like standardized,
propose it during the next round of revision of the C
standard. It needs substantial user experience or it is
likely to be considered too risky to force it upon everybody.
santosh
> It would be really nice if C could adopt a really nice algorithms
> library like C++'s STL + BOOST.
Without some changes to the language, how are we going to implement generic
algorithms and data structures? Yes void * is always there, but that seems
a messy and ugly solution.
<snip>
> Opinions? Is keeping the language tiny worth the cost of C
> programmers having to constantly reinvent the wheel?
Constantly? A library like GLib can be ported to most architectures, and
where it's not practical to port to, a Standardised library is going to
face equally tough problems.
santosh
<snip>
> Wouldn't it be a good idea to propose an STL clone?
>
> It *can* be done in C!!!
Pure ISO C?
Ian Collins
was there, it filled a need and became extremely poplar. There were
competing libraries, but through the process of natural selection, the
STL became the most popular. So it became a de facto standard before it
was standardised. The same thing is happening with parts of boost.
Which raises the question why hasn't anyone written such a popular
library for C? C has been around a decade or more longer than C++,
plenty of time for a "killer library" to appear, but it hasn't.
My conclusion has to be that the demand isn't there.
By the way, does the C standard committee have an active library group?
--
Ian Collins.
jacob navia
> jacob navia wrote:
>
>> I tried to use the Glib, but then I was confronted with a HUGE package
>> that I would have to port everywhere and I could not control
>> at all.
>>
>> It would be much better for everybody that we had a standard
>> interface like in C++ and then use a standard library!
>
> In that case, you must expect that this HUGE package be bundled with
> every C implementation... I hardly can see why C implementors would
> produce better code than GNU's guys.
>
Because C's implementation should be SUBSTANTIALLY smaller,
giving just bare bones usage and not all the blat that comes
with the STL
Today at work I was with another coworker debugging a problem,
and when he loaded a C++ module he said:
Gosh this module uses the STL, and I can't stand it jacob. Nobody
knows exactly what the hell is doing!
I think we have a HUGE market there :-)
> Actually, with C++'s STL, I've seen that most implementations have an
> incredibely low QOI. Consequently, I've always to use an external
> implementation (STLPort) which has far less bugs, and produces much
> better code.
>
> I don't see why the STL problem wouldn't be reproduced for C.
>
Because we would NOT redo the STL of course!
We need just a small set of operations and some generic functions.
> Unfortunately, C doesn't support namespaces, so it's not easy to replace
> the standard library with a different implementation.
>
There is no NEED for namespaces! We could just LINK with a different
implementation! The standard defines a C library, and you can
use different versions of the library and different implementations
just by relinking your code!
> With the C++ STL experience I got, I think it's important to get the
> standard library small, mainly containing components that cannot easily
> and efficiently be implemented in pure standard C.
>
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, SMALL software components are more mangeable and
easy to understand and USE!!!!!!!
> Otherwise, you're sure to get all the bloat with every C implementation.
> Cross-compiler linking will result in linking issues or duplication of
> the code bloat.
>
Why? It would be just another LIBRARY
> --If you've a question that doesn't belong to Usenet, contact me at
> <tabkanDEL...@yahoDELETETHATo.fr>
A+
:-)
André Gillibert
> André Gillibert wrote:
>> every C implementation... I hardly can see why C implementors would
>> produce better code than GNU's guys.
>>
>
> Because C's implementation should be SUBSTANTIALLY smaller,
> giving just bare bones usage and not all the blat that comes
> with the STL
>
I wasn't comparing to STL but to GLib.
> Because we would NOT redo the STL of course!
>
But we would redo a good part of GLib which you find huge.
>> Unfortunately, C doesn't support namespaces, so it's not easy to
>> replace the standard library with a different implementation.
>>
>
> There is no NEED for namespaces! We could just LINK with a different
> implementation! The standard defines a C library, and you can
> use different versions of the library and different implementations
> just by relinking your code!
No, it doesn't work. I tried, but I never succeeded.
C implementations usually generate function importations to their
librairies.
e.g. when allocating a big array on stack on Win32, they may call a
function (whose name starts with two underscores or one underscore and a
upper-case letter) that touches the stack at every multiple of 4096 bytes.
Changing the standard library breaks that.
Startup code is also likely to call implementation-specific functions or
rely on implementation-specific details of standard library functions.
There are other issues: Implementations are allowed to recognize standard
library functions specially and to provide special optimizations for them
such as inlining. If stack_push is inlined, relying on a specific memory
layout for the stack object, and that stack_open links to another library,
then, bad bad things will occur.
>
>> With the C++ STL experience I got, I think it's important to get the
>> standard library small, mainly containing components that cannot easily
>> and efficiently be implemented in pure standard C.
>>
>
> 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, SMALL software components are more mangeable and
> easy to understand and USE!!!!!!!
>
Please, don't use more than one exclamation mark at once.
From Terry Pratchett's Masquerade:
| And all those exclamation marks, you notice? Five? A sure sign
| of someone who wears his underpants on his head.
>> Otherwise, you're sure to get all the bloat with every C implementation.
>> Cross-compiler linking will result in linking issues or duplication of
>> the code bloat.
>>
>
> Why? It would be just another LIBRARY
At least on Win32, most implementations don't share their standard
library, believe me.
Which means that, when linking an application or DLL compiled with
implementation A to a DLL compiled with implementation B, the final code
uses the libraries from both implementations, which, in average,
multiplies the library code bloat by a factor two. If the library is
small, it's acceptable. If it's large, it becomes less acceptable.
On other platforms, there's often a better cooperation.
--
André Gillibert
Yes.
André Gillibert
> user923005 wrote:
>
>> It would be really nice if C could adopt a really nice algorithms
>> library like C++'s STL + BOOST.
>
> Without some changes to the language, how are we going to implement
> generic algorithms and data structures? Yes void * is always there,
> but that seems a messy and ugly solution.
It's the best solution C has to offer currently.
You may also read jacob navia's proposal about operator overloading and GC.
Malcolm McLean
"santosh" <santo...@gmail.com> wrote in message
news:fe1141$jgq$2...@aioe.org...
The snag is that you need to call memcpy() or loop to perform basic
operations, when most of the time the objects in the array will be pointers,
ints, or something else held in a single register.
So in practise you hand code the array each time.
jacob navia
> user923005 wrote:
>> 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?
>
> C++ didn't have those either, initially. They got tacked on
> along the way as agreement was reached on them.
>
> There are far fewer active workers on the C standard than have
> been involved with C++, and no major incentive to spend any
> significant fraction of the available resources working on
> such libraries. Note that the C standards group *has* worked
> on several extensions, generally described in Technical
> Reports, and adopted complex numbers (with library support)
> into the C standard due to demand from the numerical
> programming community.
>
>> Opinions? Is keeping the language tiny worth the cost of C
>> programmers having to constantly reinvent the wheel?
>
> You don't have to reinvent this wheel if you use an already-
> developed library that provides what you need. It just won't
> be provided automatically with the C compiler, so you have to
> arrange to obtain it separately. I have my own library with
> support for things like you mentioned, and other experienced
> programmers and programming shops most likly do also.
>
Everybody has a slightly different one!
James Dennett
> jacob navia wrote:
>
>
>> There are several solutions to your "problem" of genericity.
>> The first one is the usage of the generic pointer in C: void *
>
> At the cost of performances, but that's the cost of abstraction, anyway.
And yet the field of generic programming has been built for
years on a foundation of abstraction *not* costing performance,
which is to a large extent realized with C++'s STL and real
current compilers.
There is compile-time cost, but there's no need for runtime
cost for abstraction.
-- James
pete
Yes.
Why shouldn't C be more like C++?
Because there is C++.
--
pete
Eric Sosman
> Eric Sosman wrote:
>
>>jacob navia wrote On 10/03/07 16:31,:
>>
>>>André Gillibert wrote:
>>>
>>>
>>>>Keeping the language small makes C different from C++, and that's why, C
>>>>can still be better than C++ for some projects.
>>>
>>>This is an error. Keeping the language in this state makes the language
>>>impossible to use for any serious software development
>>>unless your project is big enough to warrant rewriting the
>>>C library and adding stacks, lists, etc etc at each project!
>>
>> Since C is impossible to use for serious software
>>development, one wonders why so many programmers spent
>>so many years writing so much non-serious (comic?)
>>software. Ritchie, Thompson, heck, even Torvalds have
>>just been clowning around, right?
>>
>
>
> Can't you read?
> I cite this again then:
>
> >> unless your project is big enough to warrant rewriting the
> >> C library and adding stacks, lists, etc etc at each project!
So, you're saying that for every serious project they
did, Ritchie, Thompson, Torvalds et al. threw away and
rewrote the C library?
> In my debugger project [...]
Is this the same debugger about which you said "Without
[garbage collection], I would never have finished?"
Let's see: You've already described C's lack of
operator overloading as evidence of neglect on the part of
the committee, you've characterized __declspec(naked) as
an important language feature you use "very often," you've
railed at the absence of fixed-point arithmetic, ... Is
there any feature, doodad, or dingbat you think *isn't*
essential to C's survival?
jacob navia
> jacob navia wrote:
>
>> André Gillibert wrote:
>>> every C implementation... I hardly can see why C implementors would
>>> produce better code than GNU's guys.
>>>
>>
>> Because C's implementation should be SUBSTANTIALLY smaller,
>> giving just bare bones usage and not all the blat that comes
>> with the STL
>>
>
> I wasn't comparing to STL but to GLib.
>
>> Because we would NOT redo the STL of course!
>>
>
> But we would redo a good part of GLib which you find huge.
>
and 204 bytes of data. Maybe adding some overhead it *could* grow to
4-5K.
GNU software is bloated, but maybe the list module of the
glib can be trimmed to 4-5K.
>>> Unfortunately, C doesn't support namespaces, so it's not easy to
>>> replace the standard library with a different implementation.
>>>
>>
>> There is no NEED for namespaces! We could just LINK with a different
>> implementation! The standard defines a C library, and you can
>> use different versions of the library and different implementations
>> just by relinking your code!
>
> No, it doesn't work. I tried, but I never succeeded.
> C implementations usually generate function importations to their
> librairies.
>
Well, lcc-win32 *can* use the libc from the system, the libc from the
Microsoft compiler and probably the libc of GNU...
> e.g. when allocating a big array on stack on Win32, they may call a
> function (whose name starts with two underscores or one underscore and a
> upper-case letter) that touches the stack at every multiple of 4096 bytes.
> Changing the standard library breaks that.
No. If they are shared objects they just have a copy of the C runtime
with them anyway.
> Startup code is also likely to call implementation-specific functions or
> rely on implementation-specific details of standard library functions.
>
This is transparent in shared objects.
> There are other issues: Implementations are allowed to recognize
> standard library functions specially and to provide special
> optimizations for them such as inlining. If stack_push is inlined,
> relying on a specific memory layout for the stack object, and that
> stack_open links to another library, then, bad bad things will occur.
>
I said:
Link with another library
I did not said:
Use two libraries for lists at the same time!
Note:
I used only ONE exclamation mark.
jacob navia
You are misrepresenting everything since you do not want to argue
anymore, just polemic. I do have different opinions about things
here with many people. But I respect the work of the committee and
I have said that several times. I do not agree wit some decisions
and I have expressed my opinion. But I do not accuse anyone of
"neglect" (whatever that means in this context)
> you've characterized __declspec(naked) as
> an important language feature
Wrong again. I said here that using this low level interface
would be a bad idea, since after a discussion with people
here I saw my error. Contrary to some, I do respect the
arguments of other people and if they look convincing I
change my opinion and openly acknowledge that fact as I did
in this group.
> you've
> railed at the absence of fixed-point arithmetic, ...
No. I said that the TR that proposed modifications to the standard
would be better done if we give a general solution to the problem
of adding new numeric types.
> Is
> there any feature, doodad, or dingbat you think *isn't*
> essential to C's survival?
>
You just want to polemic but you are doomed. To start a polemic
you need two. And you are only one.
Yours sincerely
jacob navia
C++ has good ideas. Generic programming is implemented there with
all the bells and whistles you can imagine. This is not the goal
here. The goal would be just a small interface description to
a small library that can represent a MINIMAL interface to lists
stacks, LIFOs hash tables and other commonly used data structures
jacob navia
>
> Why shouldn't C be more like C++?
> Because there is C++.
>
Nobody is proposing that C should be "more like C++".
The complexity of C++ is at best avoided.
But lists, stacks and hash tables aren't any
C++ invention as far as I remember. Why can't
the C language offer a common interface to use those
commonly used data structures?
Flash Gordon
> Eric Sosman wrote:
>> jacob navia wrote On 10/03/07 16:31,:
>>> André Gillibert wrote:
>>>
>>>> Keeping the language small makes C different from C++, and that's
>>>> why, C can still be better than C++ for some projects.
>>>
>>> This is an error. Keeping the language in this state makes the language
>>> impossible to use for any serious software development
>>> unless your project is big enough to warrant rewriting the
>>> C library and adding stacks, lists, etc etc at each project!
>>
>> Since C is impossible to use for serious software
>> development, one wonders why so many programmers spent
>> so many years writing so much non-serious (comic?)
>> software. Ritchie, Thompson, heck, even Torvalds have
>> just been clowning around, right?
>>
>
> Can't you read?
> I cite this again then:
>
> >> unless your project is big enough to warrant rewriting the
> >> C library and adding stacks, lists, etc etc at each project!
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. Stragely enough I did
not have to rewrite the linked list module because it was designed to
provide a generic linked list.
> In my debugger project there was obviously a list module
>
> Then in the IDE too.
>
> Then, in the compiler there is another one.
>
> Then it seemed stupid to me at spent time making the debugger
> use the IDE list package.
Then you should have spent a little longer the first or second time to
write one that was generic enough to be reused, or used some third party
library designed to be generic.
> Yes, that happens. Not to you of course.
Well, it happens to me when using a completely different language. I
found that the linked list I wrote in Fortran && on the VAX did not
compile as C and had unacceptable limitations (well, I would have done
if I had access to the code) but I certainly don't have to rewrite
simple generic code as often as you seem to have to.
--
Flash Gordon
Flash Gordon
> It would be really nice if C could adopt a really nice algorithms
> library like C++'s STL + BOOST.
<snip>
> Opinions? Is keeping the language tiny worth the cost of C
> programmers having to constantly reinvent the wheel?
With modern linkers I would have no objection to it. After all, the
linker can just not link in the code if it is not used! Of course, there
might still be linkers around that are not that intelligent.
--
Flash Gordon
Keith Thompson
>>> Opinions? Is keeping the language tiny worth the cost of C
>>> programmers having to constantly reinvent the wheel?
>> You don't have to reinvent this wheel if you use an already-
>> developed library that provides what you need. It just won't
>> be provided automatically with the C compiler, so you have to
>> arrange to obtain it separately. I have my own library with
>> support for things like you mentioned, and other experienced
>> programmers and programming shops most likly do also.
>>
> The problem is that there isn't any that is standard.
>
> Everybody has a slightly different one!
Right, and you have to decide on a single solution *before* you can
add it to the standard.
I think glib attempts to be a general-purpose toolkit that might be
suitable for standardidization. (I don't know enough about it to have
an opinion on whether it should be standardized.) I suspect the
committee wouldn't agree to add a large library to the standard unless
there's at least some consensus on one particular interface.
And I strongly suspect that a library that depends on language
extensions provided by a single compiler wouldn't stand a chance.
You'd *first* have to persuade the committee to adopt the language
extensions. (If the library is sufficiently useful, that might be an
argument in favor of adopting the language extensions.)
--
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"
jacob navia
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.
Keith Thompson
> André Gillibert wrote:
>> user923005 wrote:
[...]
> There are several solutions to your "problem" of genericity.
>
> The first one is the usage of the generic pointer in C: void *
>
> the software how big your objects are, and then you just use them.
> Operator overloading allows you to assign and read the data.
>
> True, the functions return a void pointer that must be casted into
> something but that is a minor inconvenience.
You need to convert void* results to some specific pointer type, but
why would you need to cast them?
[...]
>>> 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?
>>>
>> Propose an implementable solution. Ideally, with several successful
>> real-world implementations.
>
> I have done just that.
> Only flames ensued.
You proposed operator overloading in an article posted to comp.std.c
on 2007-09-05, subject "Operator overloading in C". A lengthy
discussion ensued (Google Groups shows 143 articles in that thread).
In a cursory look through the thread, I see no flames, though I do see
a great deal of constructive criticism. (Telling you "I disagree, and
here's why" is not a flame.)
However, I don't recall you ever proposing a library that provides
stacks and other common data structures. Perhaps I missed it.
But you must be aware that if a proposed library depends on language
features that are not (yet) part of the standard, that's going to be a
considerable obstacle.
>> Then, we may consider your offer.
>
> You can consider mine. It is working, it has an implementation,
> why not looking at it?
Where is it?
(BTW, didn't you say recently that you were going to provide a freely
downloadable Linux version of your compiler? Have you done so?)
Ian Collins
>
> But lists, stacks and hash tables aren't any
> C++ invention as far as I remember. Why can't
> the C language offer a common interface to use those
> commonly used data structures?
>
--
Ian Collins.
jacob navia
>>> Propose an implementable solution. Ideally, with several successful
>>> real-world implementations.
>> I have done just that.
>> Only flames ensued.
>
> You proposed operator overloading in an article posted to comp.std.c
> on 2007-09-05, subject "Operator overloading in C". A lengthy
> discussion ensued (Google Groups shows 143 articles in that thread).
> In a cursory look through the thread, I see no flames, though I do see
> a great deal of constructive criticism. (Telling you "I disagree, and
> here's why" is not a flame.)
>
Look Keith, you are aware of the enthusiastic reception of my ideas
by the c.lang.c "regulars" isn't it?
No, in comp.std.c the situation was much better but I do not
see how that is going to go on. Maybe everyone is just waiting that
I go away :-)
> However, I don't recall you ever proposing a library that provides
> stacks and other common data structures. Perhaps I missed it.
>
> Where is it?
http://www.q-software-solutions.de/~jacob/proposal.pdf
The same document that proposes the extensions proposes a library
using some of the new features.
Specially look at the string library. The others
use vtables and I think this leads to bad syntax unless there is yet
another extension. I think a better approach would be to use the
generic functions feature and use:
list = list_add(NULL,45);
list = list_add(list,644.887);
list = list_add(list,"Customer Pierre Dupont and Annie Gonzalez");
To access it we would use
#define list_get(list,index, type) *(type *)(list->Data[index]);
or similar.
>
> (BTW, didn't you say recently that you were going to provide a freely
> downloadable Linux version of your compiler? Have you done so?)
>
Yes, I did it and you can download it from
http://www.q-software-solutions.de/products/lcc-linux32/index.shtml
Please be patient. I have worked a lot in it but it still has a lot of
rough edges. All extensions should be working except
__try/__except.
I think I will be using wine's implementation of that as a guide.
But use the windows version, it is more tested. In august, the windows
version went over the *half million* downloads mark!
Chris McDonald
>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
Could you please clarify these?
Did you mean to add at the head, or at the tail, or somewhere in the
middle, that the list remain sorted by some user-specified sorting
function, and should duplicates be permitted or removed?
Oh, never mind, I'll just write the 10 line function that I need and
understand.
--
Chris.
jacob navia
Because C++ started to grow as "the better C" and
C was thrown into the bin "old and obsolete".
Dozens of C++ books were written that as a matter of habit wrote
in their "Introduction to C++" how BAD the C language was, and
how WONDERFUL the new language was, compared to that OLD C, etc.
The C community reacted with a tendency to look into the past,
and it "enshrined" their language resisting any change
of it at all. C99 was the result: a standard that makes
small improvements (VLAs, complex numbers, and others)
but leaves the mess of the very old C library design intact.
The C++ guys just laughed at it, and gcc and Microsoft decided
to just drop C. Gcc hasn't still 8 years later finished the
C99 implementation, they do not participate into any standard
body (even if they could). Microsoft has participated in some
proposals (the safer C Technical Report) but in fact has
dropped C as a development language too.
C is then seen as an old and obsolete language by most
programmers. Its main use should be in small circuit
boards where there is no space for a language like
C++. When those circuit boards disappear, C will disappear
with them. It will remain (like COBOL) in a frozen state
for the biggest part of this century as the software
written in C is slowly rewritten in other, more
modern languages.
So the story goes.
But I think that C, *precisely* because of its small size, it
is *better* adapted for the software of the future. Yes, I have
proposed some changes to the syntax, fairly minor. They are
essentially:
o operator overloading
o generic functions
This would allow to write a small standard library that would
allow people to use higher level data structures with easy
within a common framework.
What is crucial is that the library has a small memory footprint.
Not in RAM of course, but in HUMAN memory footprint. This means that
the library is easy to remember and use, that it has a consistent
naming, and that it is kept as simple as possible.
Software has a tendency to bloat forever. But in software (as in
hardware) smaller means more efficient and less wasteful. Many
languages have started that try to be simpler than C++. But
there is NO need to go very far. C has retained its simplicity
and is well adapted to the future precisely because it is
small.
Keith Thompson
> pete wrote:
>> Why shouldn't C be more like C++? Because there is C++.
>
> Nobody is proposing that C should be "more like C++".
Sure you are.
You're not proposing that C should be just like C++, but you're
certainly proposing that it should be closer to C++ than it is now.
(I'm not saying that's necessarily a bad thing.)
jacob navia
> jacob navia <ja...@nospam.org> writes:
>
>> 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
>
>
> Could you please clarify these?
>
> Did you mean to add at the head, or at the tail,
At the tail
or somewhere in the
> middle,
that would be
list_insert
that the list remain sorted by some user-specified sorting
> function,
that would be
list_add_sorted
and should duplicates be permitted or removed?
A set of flags can be specified at list creation as
to how to insert things (with or without duplicates,
set/unset a sorting function that defaults to memcmp
and some options) but basically you need just little
of all that.
>
> Oh, never mind, I'll just write the 10 line function that I need and
> understand.
>
10 lines for the specs you yourself specified above?
I am giving just examples of generic functions that could be
used to
list_add
vector_add
hash_add
giving a generic, easy to remember interface. That was my point.
Chris McDonald
>Chris McDonald wrote:
>> jacob navia <ja...@nospam.org> writes:
>>
>>> 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
>>
>>
>> Could you please clarify these?
>>
>> Did you mean to add at the head, or at the tail,
>At the tail
Ohhh, so you don't mean 'list', you mean 'queue'?
Gee, this agreement can be tricky can't it?
--
Chris.
Keith Thompson
[...]
> 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.
What exactly are you proposing?
jacob navia
> jacob navia <ja...@nospam.org> writes:
>> pete wrote:
>>> Why shouldn't C be more like C++? Because there is C++.
>> Nobody is proposing that C should be "more like C++".
> [...]
>
> Sure you are.
>
> You're not proposing that C should be just like C++, but you're
> certainly proposing that it should be closer to C++ than it is now.
> (I'm not saying that's necessarily a bad thing.)
>
Operator overloading exists in many other languages than C++.
Fortran, Visual Basic, C#... many.
Overloaded functions that dispatch according to the type of the
arguments exist in other languages too.
But even if I use the same syntax, the simplicity of the language
is preserved. That's why I was completely opposed to introducing
constructors for instance, remember?
This limited set of changes makes the language more easy to
use (syntax sugar makes coffee easier to drink ) without changing
any of its fundamental concepts.
jacob navia
Lists (as you probably know) can be used to implement
other data structures.
A stack can be implemented with a list. Is it a stack or a list?
If you want to discuss, go ahead. But if you just
want to prove that you know more of the subject and are much clever
than me...
PLEASE bring YOUR proposal
:-)
Chris McDonald
>.... But if you just
>want to prove that you know more of the subject and are much clever
>than me...
No, I'll leave that to the many others here.
I had better not troll the troll.
--
Chris.
Keith Thompson
> Keith Thompson wrote:
>>>> Propose an implementable solution. Ideally, with several successful
>>>> real-world implementations.
>>> I have done just that.
>>> Only flames ensued.
>> You proposed operator overloading in an article posted to comp.std.c
>> on 2007-09-05, subject "Operator overloading in C". A lengthy
>> discussion ensued (Google Groups shows 143 articles in that thread).
>> In a cursory look through the thread, I see no flames, though I do see
>> a great deal of constructive criticism. (Telling you "I disagree, and
>> here's why" is not a flame.)
>>
>
> Look Keith, you are aware of the enthusiastic reception of my ideas
> by the c.lang.c "regulars" isn't it?
>
> No, in comp.std.c the situation was much better but I do not
> see how that is going to go on. Maybe everyone is just waiting that
> I go away :-)
You might have better luck if you concentrated on discussing your
ideas rather than complaining about people's reactions to them.
You made your proposal in comp.std.c. You claimed above that "Only
flames ensued"; that just isn't true.
Eric Sosman
> Eric Sosman wrote:
>> [...]
>> Let's see: You've already described C's lack of
>> operator overloading as evidence of neglect on the part of
>> the committee,
>
> You are misrepresenting everything since you do not want to argue
> anymore, just polemic. I do have different opinions about things
> here with many people. But I respect the work of the committee and
> I have said that several times. I do not agree wit some decisions
> and I have expressed my opinion. But I do not accuse anyone of
> "neglect" (whatever that means in this context)
"I do not accuse" is present tense, and it's true: after
several people castigated you and after a few attempts to deny
that you'd done such a thing, you amended your proposal to
remove the offending language. But the moving finger writes,
and the memory lingers.
>> you've characterized __declspec(naked) as
>> an important language feature
>
> Wrong again.
So, Google not only has a bad Usenet interface, but they
(or someone) are actively making forged posts under your name?
Go to google.groups.com, navigate to comp.lang.c, search for
__declspec, sort by date, and there you have it:
>>> [...] It is interesting that this
>>> document mentions almost all the __declspec constructs but
>>> doesn't mention one I considered important and use very often:
>>>
>>> __declspec(naked)
The supposed date of this post is September 21, within living
memory. Is it a defamatory forgery? Will you take legal action?
Google Groups also displays a September 6 post in which someone
claiming to be you describes removing the "neglected" language;
is that, too, a forgery? Are the black helicopters hovering?
A young cousin of mine once forgot, as children will, some
simple instruction he'd been given. His exasperated parent
berated him for his terrible memory. "But," said the lad, "I
have a very good forgettory!" A convenient ability, I guess.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Eric Sosman
> pete wrote:
>>
>> Why shouldn't C be more like C++? Because there is C++.
>>
>
> Nobody is proposing that C should be "more like C++".
> The complexity of C++ is at best avoided.
... says the proponent of operator overloading, generic
functions, and garbage collection.
"The true test of a first-rate mind is the ability to
hold two contradictory ideas at the same time." -- F.S.F.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Ian Collins
> Ian Collins wrote:
>> jacob navia wrote:
>>> But lists, stacks and hash tables aren't any
>>> C++ invention as far as I remember. Why can't
>>> the C language offer a common interface to use those
>>> commonly used data structures?
>>>
>> Then how come after 30 odd years, it doesn't?
>>
>
> Because C++ started to grow as "the better C" and
> C was thrown into the bin "old and obsolete".
>
> Dozens of C++ books were written that as a matter of habit wrote
> in their "Introduction to C++" how BAD the C language was, and
> how WONDERFUL the new language was, compared to that OLD C, etc.
>
> The C community reacted with a tendency to look into the past,
> and it "enshrined" their language resisting any change
> of it at all. C99 was the result: a standard that makes
> small improvements (VLAs, complex numbers, and others)
> but leaves the mess of the very old C library design intact.
>
or even popular extensions.
>
> Software has a tendency to bloat forever. But in software (as in
> hardware) smaller means more efficient and less wasteful.
The size of the language isn't necessarily reflected in the size of the
resulting executable.
--
Ian Collins.
Richard Heathfield
<snip>
> You may also read jacob navia's proposal about operator overloading and
> GC.
The problem with that idea is that Mr Navia is notorious in comp.lang.c for
not understanding the C language anything like as well as an implementer
ought to understand it, not understanding how to react properly to
criticism, and not understanding how not to libel other people. These
issues do not make it easy to hold rational discussions.
If you have any proposals from people whose opinions are widely respected
in the C community (e.g. Chris Torek, Steve Summit, or Lawrence Kirby, to
name but a few), I think you might find that such proposals would get a
wider readership and a proper debate.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Richard Heathfield
<snip>
> Look Keith, you are aware of the enthusiastic reception of my ideas
> by the c.lang.c "regulars" isn't it?
>
> No, in comp.std.c the situation was much better
But, my dear chap, that's only because they don't know you as well as we
do.
Chris Thomasson
news:1191441928.0...@y42g2000hsy.googlegroups.com...
> It would be really nice if C could adopt a really nice algorithms
> library like C++'s STL + BOOST.
>
> 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?
You can program your collections in C. For instance, a simple "inline" LIFO
linked-list:
http://appcore.home.comcast.net/misc/macro-slist-c.html
This is not rocket-science...
Chris Thomasson
news:5mim3eF...@mid.individual.net...
IMHVO, C is to low-level to standardize trivial collection interfaces.
However, I bet we could standardize an API for this newsgroup.
Richard Heathfield
Previous attempts by clc to participate in similar projects have not been
conspiciously successful.
Still - hope springs eternal, eh?
Ian Collins
You can also code it cleanly without resorting to macros!
--
Ian Collins.
John Whorfin
> It would be really nice if C could adopt a really nice algorithms
> library like C++'s STL + BOOST.
David Resnick
> jacob navia <ja...@nospam.org> writes:
>
> [...]
>
> > 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.
-David
Neil Booth
> [...] and gcc and Microsoft decided
> to just drop C. Gcc hasn't still 8 years later finished the
> C99 implementation, they do not participate into any standard
> body (even if they could).
Jacob, you do your argument no favours with falsehoods like this.
It just shows you don't know what you're talking about.
jacob navia
Of course "I do not know what I am talking about".
You do. Please tell us then, some proposition that gcc has done
since C99 for standardization. Or proposal. Or whatever in this
direction.
If possible I would like to know if the C99 support
is finished in gcc. Even if it is very good, the last thing I
know is a web page where VLAs and other features are marked missing
or broken.
http://gcc.gnu.org/c99status.html
Since I am not a member of GNU I have just to believe the
public information that GNU itself publishes. Sorry.
James Dennett
> Neil Booth wrote:
>> jacob navia wrote:
>>
>> > [...] and gcc and Microsoft decided
>>> to just drop C. Gcc hasn't still 8 years later finished the
>>> C99 implementation, they do not participate into any standard
>>> body (even if they could).
>>
>> Jacob, you do your argument no favours with falsehoods like this.
>> It just shows you don't know what you're talking about.
>
> Of course "I do not know what I am talking about".
>
> You do. Please tell us then, some proposition that gcc has done
> since C99 for standardization. Or proposal. Or whatever in this
> direction.
He's trying to tell you that GCC developers *do* participate
in standards bodies. You said they do not, and that was wrong.
It's OK, we're all wrong sometimes. It's a chance to learn.
-- James
jacob navia
OK. I see. They participate but they do not say that they are from
GNU or I do not know that fact and I think that nobody from
GNU is there.
A misunderstanding then.
Douglas A. Gwyn
> gets() is still there and will stay with us at least till 2019.
gets() was part of the Base Library. Generally the C Standard
bearers are cautious about changing previously supported
standardized features in incompatible ways, such as removing
them. The two main examples of removing features were both in
response to proposals I championed (one in a DR): implicit int
and gets. (Yes, gets has been officially deprecated.)
I don't know where "2019" comes from.
Douglas A. Gwyn
> This is an error. Keeping the language in this state makes the language
> impossible to use for any serious software development
> unless your project is big enough to warrant rewriting the
> C library and adding stacks, lists, etc etc at each project!
That's certainly not true. A large number of applications,
especially for embedded systems, are coded nearly entirely in C.
Why would you not maintain your programming support library
for reuse across multiple projects? Unless, perhaps, you
don't know how to design it well enough for reuse.
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).
Nice troll, BTW. :-)
-- James
Douglas A. Gwyn
> The C community reacted with a tendency to look into the past,
> and it "enshrined" their language resisting any change
> of it at all.
Your history and rationale were entirely wrong.
C99 did not radically change the existing standard interfaces
because that would not have been in the best interest of our
"customers". Even as a highly compatible upgrade, it took
a long time for C99 to become widely implemented. As an
incompatible product, it very likely would never have been
accepted at all.
The advantage of having a committee of experience experts
deciding on Standard C's direction is that there is balance
so that more relevant factors get considered before changes
are made. The net newsgroups have seen many people who think
that obviously they know best how things should be done and
that any other ideas are wrong-headed. Fortunately that is
not how C has evolved.
Douglas A. Gwyn
> My conclusion has to be that the demand isn't there.
The very age of C might be partly responsible, in that the vast
amount of existing C applications already embed some solutions
to the requirements for lists, etc. The maintenance programmer
(a)is unlikely to rework the existing app just to use some new
standardized interface for the same thing; and (b) has to
continue to maintain whatever libraries he has been using.
The only real use for such a library would be for new program
development, once the learning hurdle has been overcome. Much
new development really ought to use higher-level languages in
the first place.
> By the way, does the C standard committee have an active library group?
Not as a separate entity.
jacob navia
Because in customer xyz the list library used is such and such
that conflicts with mine in *some* areas but not in others. Then
I have to use the customer's library until I discover that it
has a bug in a few not well tested routines. Then I debug them,
but I can't test all of them. With the next project is the same,
they *have* too several routines for list handling, each
serious C project has, and all of them not well tested and full
of problems!
What you do not want to understand is that EACH project has its
list library and ALL of them will not be well tested ones, with
more or less problems. Why do we have to REPEAT this work at
each project?
If we follow your reasoning we would all have a strcmp routine
because we would not have a standard LIBRARY!
Why calculating the gamma function is deemed worth of
standardization and not a common place routine like the handling of
a single linked list?
How many MILLIONS of lines of C code have followed your reasoning
above and ended with not well tested libraries that produce always
problems?
The task of a standard is to avoid needless repetition of effort
by providing a common interface for this library routines. Then,
vendors would all be compatible with libraries of different quality
and different prices and each one stressing different parts of
the implementation.
Look at Mr Plaugher for instance, and his high quality C library.
A user of my compiler system can throw away my library and buy
Mr Plaugher's without rewriting a single line of his code
because the interface is fixed you understand?
You say:
"... unless, perhaps, you don't know how to design it well enough
for reuse".
This attitude is unwarranted Mr Gwyn.
user923005
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++.
> Nice troll, BTW. :-)
It turned out that way, but it wasn't my intention. I was just
wondering aloud why the C++ side of the fence has this wonderful bag
of 1001 tricks and C has an itty-bitty one. I was thinking it would
be nice to have more pre-built tools for problem solving ready to go.
It turns out it was more difficult than I thought to produce it.
santosh
Well if you take into account non-Standard code, then the amount of reusable
code in C, for C, is *massive*
It's just that the Standardised library is quite small, but many of the
reasons Doug Gywn has listed seem very plausible to me.
André Gillibert
> Well, lcc-win32 *can* use the libc from the system, the libc from the
> Microsoft compiler and probably the libc of GNU...
>
There are many reasons to use a different compiler.
>> e.g. when allocating a big array on stack on Win32, they may call a
>> function (whose name starts with two underscores or one underscore and
>> a upper-case letter) that touches the stack at every multiple of 4096
>> bytes.
>> Changing the standard library breaks that.
>
> No. If they are shared objects they just have a copy of the C runtime
> with them anyway.
>
Maybe for lcc-win32.
That it works for *one* compiler is insufficient.
> I said:
>
> Link with another library
>
> I did not said:
>
> Use two libraries for lists at the same time!
>
Which isn't possible with Borland C, for example, because non-standard
functions of the default library are implicitly linked even for very
simple pieces of code.
Moreover, if one function is inlined, it may be recognized BY NAME.
e.g. A call to memset, even if it's imported in a third party library may
be replaced by raw assembly code.
Redefining a library function is undefined behavior, and is likely to
behave badly on many implementations.
Maybe *your* compiler wouldn't make it that way, but that doesn't mean
other compilers won't.
> Note:
> I used only ONE exclamation mark.
>
Good.
> No. The list module I wrote makes fir 2380 bytes of code
> and 204 bytes of data. Maybe adding some overhead it *could* grow to
> 4-5K.
I think that's small enough to be a perfectly acceptable proposal.
If you add the modules for a few other common containers, it should still
be acceptable...
If possible, you should write a proposal that doesn't require extra
features (e.g. OOL), then, it has some chance of being accepted.
However, I highly doubt you can do something as full-featured as the
STL+BOOST as the OP wishes, in less than several hundred of kilobytes.
--
If you've a question that doesn't belong to Usenet, contact me at
<tabkanDEL...@yahoDELETETHATo.fr>
André Gillibert
>
> And yet the field of generic programming has been built for
> years on a foundation of abstraction *not* costing performance,
> which is to a large extent realized with C++'s STL and real
> current compilers.
>
Not to a so large extent.
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.
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.
André Gillibert
> P.S. I will look at the glib again.
>
Yes, in particular, even if the GNU implementation may be of low quality,
and to big, it may be possible to keep the SAME interface, and get a
lightweight library.
If GLib is too big, it may be possible to take a meaningful subset of
GLib, of course.
jacob navia
> Ian Collins wrote:
>> My conclusion has to be that the demand isn't there.
>
> The very age of C might be partly responsible, in that the vast
> amount of existing C applications already embed some solutions
> to the requirements for lists, etc. The maintenance programmer
> (a)is unlikely to rework the existing app just to use some new
> standardized interface for the same thing; and (b) has to
> continue to maintain whatever libraries he has been using.
>
> The only real use for such a library would be for new program
> development, once the learning hurdle has been overcome. Much
> new development really ought to use higher-level languages in
> the first place.
Excuse me but did I understand you correctly?
That library would be of no use but in new code you say.
Then,
"Much new development really ought to use higher level
languages in the first place".
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.
OK. I understand better now, what do you think about C, and
why our viewpoints differ completely. Until now I thought that
you (like people in a news group about the C language) would
agree that C is a language that is worth developing code
in.
I would like that you claify this of course. Did I understand you
correctly?
André Gillibert
> The only real use for such a library would be for new program
> development, once the learning hurdle has been overcome. Much
> new development really ought to use higher-level languages in
> the first place.
>
C can still be a good choice for many new projects.
André Gillibert
> C is then seen as an old and obsolete language by most
> programmers. Its main use should be in small circuit
> boards where there is no space for a language like
> C++.
I see more C as an UNIVERSAL language that had the advantage of not
changing every two years.
That's wonderful how PORTABLE C90 is. Much more portable than C++98.
(C99 broke the portability dream, which explains why C90 is still much
more popular than C99)
That's wonderful how reliable are the ports of C90 programs. You don't
have version conflicts.
C90 is ONE language.
Not changing is the strength of C90.
NOTE: I don't think that the container library would "break" the C
language. It wouldn't be a big change. It wouldn't create any
incompatibility. It may not increase too much the size of the library.
> When those circuit boards disappear, C will disappear
> with them. It will remain (like COBOL) in a frozen state
> for the biggest part of this century as the software
> written in C is slowly rewritten in other, more
> modern languages.
If that happens, would you die?
That's not as if there had to be an affectional relation to a language.
Sometimes it's better to use an entirely different new language, instead
of cheating in transforming the first language in the latter and creating
thousands of painful compatibility issues.
> What is crucial is that the library has a small memory footprint.
> Not in RAM of course, but in HUMAN memory footprint. This means that
> the library is easy to remember and use, that it has a consistent
> naming, and that it is kept as simple as possible.
>
It would equally be good if it had a small RAM footprint. :)
> Software has a tendency to bloat forever.
As languages have. Compare C99 to K&R C. Compare Fotran 2003 to Fotran 66.
André Gillibert
> Neil Booth wrote:
>> jacob navia wrote:
>> > [...] and gcc and Microsoft decided
>>> to just drop C. Gcc hasn't still 8 years later finished the
>>> C99 implementation, they do not participate into any standard
>>> body (even if they could).
>> Jacob, you do your argument no favours with falsehoods like this.
>> It just shows you don't know what you're talking about.
>
> Of course "I do not know what I am talking about".
>
> You do. Please tell us then, some proposition that gcc has done
> since C99 for standardization. Or proposal. Or whatever in this
> direction.
>
> If possible I would like to know if the C99 support
> is finished in gcc. Even if it is very good, the last thing I
> know is a web page where VLAs and other features are marked missing
> or broken.
GCC TRIES to support C99, but hasn't yet got it.
Similarly, GCC TRIES to support C++98, but hasn't yet got it.
Well, actually, it doesn't try to get full C++98 conformance, while it
does, for C99!
(GCC doesn't try to implement the C++ export feature).
The fact that C99 is already to big and requires YEARS to be implemented
correctly (unlike C90 which is much simplier)
Implementing standards requires time. Especially when they're big.
André Gillibert
> But even if I use the same syntax, the simplicity of the language
> is preserved. That's why I was completely opposed to introducing
> constructors for instance, remember?
>
And of course, it's obvious to everybody that OOL is much easier to
implement than constructors. Maybe it's possible to implement constructors
in 2000 LOC as you did for OOL.
Did you know that C++ had slowly evolved from C?
"C with objects" was very small.
Then, it became C++ as new features were added.
Similarly C evolved continuously from B... But, C99 clearly is much bigger
than B.
Ben Pfaff
> Since I am not a member of GNU I have just to believe the
> public information that GNU itself publishes. Sorry.
I don't think that there is such a thing as a "member of GNU".
--
Ben Pfaff
http://benpfaff.org
André Gillibert
> The problem I see with template support is that it requires operator
> overloading.
It's simply huge, very complex, and causes linking issues.
It's also quite weak without function overloading support with complex
resolution rules.
Classes support, with constructors and destructors, also greatly help to
the functionality of C++ templates.
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
87odfea...@blp.benpfaff.org...
> jacob navia <ja...@nospam.org> writes:
>
>> Since I am not a member of GNU I have just to believe the
>> public information that GNU itself publishes. Sorry.
>
> 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 ;-)
--
Chqrlie.
Default User
Difficult to do with a user-defined type.
Brian
David Resnick
> David Resnick wrote:
> > On Oct 3, 8:17 pm, Keith Thompson <ks...@mib.org> wrote:
> > > jacob navia <ja...@nospam.org> writes:
>
> > > [...]
>
>
> > > 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
> 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);
// Done
return 0;
santosh
> Douglas A. Gwyn wrote:
>> Ian Collins wrote:
>>> My conclusion has to be that the demand isn't there.
>>
>> The very age of C might be partly responsible, in that the vast
>> amount of existing C applications already embed some solutions
>> to the requirements for lists, etc. The maintenance programmer
>> (a)is unlikely to rework the existing app just to use some new
>> standardized interface for the same thing; and (b) has to
>> continue to maintain whatever libraries he has been using.
>>
>> The only real use for such a library would be for new program
>> development, once the learning hurdle has been overcome. Much
>> new development really ought to use higher-level languages in
>> the first place.
>
> Excuse me but did I understand you correctly?
<snip>
> 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
47054b9d$0$27372$ba4a...@news.orange.fr...
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?
> // Done
> return 0;
> }
--
Chqrlie.
jacob navia
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
"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!
>
>> // Done
>> return 0;
>> }
>
--
jxh
> On Oct 4, 11:04 am, jxh <j...@despammed.com> wrote:
>
> > On Oct 3, 1:05 pm, user923005 <dcor...@connx.com> wrote:
> > [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
> James Dennett wrote:
>
>>
>> And yet the field of generic programming has been built for
>> years on a foundation of abstraction *not* costing performance,
>> which is to a large extent realized with C++'s STL and real
>> current compilers.
>>
>
> 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
> On Oct 4, 11:37 am, user923005 <dcor...@connx.com> wrote:
>
>
>
> > On Oct 4, 11:04 am, jxh <j...@despammed.com> wrote:
>
> > > On Oct 3, 1:05 pm, user923005 <dcor...@connx.com> wrote:
> > > [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"):
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[i]
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
Nick Keighley
<snip>
> 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?
<snip>
> 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>
--
Nick Keighley
Chris Thomasson
news:seudnUv8GbG...@bt.com...
> Chris Thomasson said:
>
>> "Ian Collins" <ian-...@hotmail.com> wrote in message
>> news:5mim3eF...@mid.individual.net...
>>> jacob navia wrote:
>>>>
>>>> But lists, stacks and hash tables aren't any
>>>> C++ invention as far as I remember. Why can't
>>>> the C language offer a common interface to use those
>>>> commonly used data structures?
>>>>
>>> Then how come after 30 odd years, it doesn't?
>>
>> IMHVO, C is to low-level to standardize trivial collection interfaces.
>> However, I bet we could standardize an API for this newsgroup.
>
> 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
Richard Heathfield
> "Richard Heathfield" <r...@see.sig.invalid> wrote in message
> news:seudnUv8GbG...@bt.com...
>> Chris Thomasson said:
>>
<snip>
>>> IMHVO, C is to low-level to standardize trivial collection interfaces.
>>> However, I bet we could standardize an API for this newsgroup.
>>
>> 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.
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>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Mark McIntyre
<sp...@flash-gordon.me.uk> wrote:
>jacob navia wrote, On 03/10/07 21:50:
>> I cite this again then:
>>
>> >> unless your project is big enough to warrant rewriting the
>> >> C library and adding stacks, lists, etc etc at each project!
>
>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.
...
> 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
They're just multiple /references/ to the same Platonic ideal exclamation
mark.
--
Chris "no, wait, references are /C++/ ..." Dollin
Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England