C needs a BOOST

"Eric Sosman" <Er*********@sun.comwrote in message
news:1191595375.510864@news1nwk...

Chris Thomasson wrote On 10/05/07 06:14,:
>>
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?

Perhaps it might be too ambitious to begin with
something as advanced as a stack.

Lest start off with the small stuff... A LIFO is not advanced; at least that
the way it is imo...

If we cannot break a LIFO down into a minimial (e.g. macro level) API like I
have in mind:

<pseudo-code>
_______________________________
typedef struct clc_slink_s clc_slink;

struct clc_slink_s {
clc_slink* nx;
};

CLC_SLIST_STATIC_INIT(...); /* static initialization */
void clc_slist_init(...); /* dynamic initialization */
void clc_slist_push(...); /* push a link */
slink* clc_slist_pop(...); /* pop a link */
_______________________________
We have problems indeed! Anyway;

The macro API level represents the basic interface for the job at hand...
Extensions would represent a micro API level down below the macro... Sort of
like the following C++ analog:

http://groups.google.com/group/comp....45c17cdd3c04a3

Oct 6 '07 #154

OOPS! wrong link:

http://groups.google.com/group/comp....45c17cdd3c04a3

Refer to the last paragraph (e.g. at bottom of post):

http://groups.google.com/group/comp....44cdcc315a5f07

Sorry for any confusions!

Oct 6 '07 #155

[...]

<pseudo-code>
_______________________________
typedef struct clc_slink_s clc_slink;

struct clc_slink_s {
clc_slink* nx;
};

CLC_SLIST_STATIC_INIT(...); /* static initialization */
void clc_slist_init(...); /* dynamic initialization */
void clc_slist_push(...); /* push a link */
slink* clc_slist_pop(...); /* pop a link */

^^^^^^^^^^^^^

clc_slink* clc_slist_pop(...); /* pop a link */

_______________________________

I will post workable/compliable code sometime tomorrow.

Oct 6 '07 #156

Richard Heathfield

[followups set to comp.lang.c]

Chris Thomasson said:

<snip>

void clc_slist_init(...); /* dynamic initialization */

Where is the "graceful failure" mechanism?

void clc_slist_push(...); /* push a link */

Ditto.

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

Oct 6 '07 #157

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:xb******************************@bt.com...

[followups set to comp.lang.c]

Chris Thomasson said:

<snip>
>void clc_slist_init(...); /* dynamic initialization */

Where is the "graceful failure" mechanism?

Okay... We could do this:
<pseudo-code>
_________________________________________________

/*
typedef struct clc_slink_s clc_slink;

struct clc_slink_s {
clc_slink* nx;
};
*/
/* returns 'nx' param;
- returns NULL on failure */
clc_slink* clc_slist_init(
clc_slink* const _this,
clc_slink* const nx
) {
_this->nx = nx;
return nx;
}

>void clc_slist_push(...); /* push a link */

-------------------------------------------
/* returns 'link' param;
- returns NULL on failure */
clc_slink* clc_slist_push(
clc_slink* const _this,
clc_slink* const link
) {
if (link) {
link->nx = _this->nx;
_this->nx = link;
}
return link;
}
_________________________________________________

Now we can do stuff like:
_________________________________________________
typedef struct my_node_s my_node;

struct my_node_s {
clc_slink slink;
[...];
};

static clc_slink mylist = CLC_SLIST_STATIC_INIT(0);

/* returns NULL on failure */
my_node* my_node_produce(...) {
my_node* const _this =
clc_slist_push(&mylist, malloc(sizeof(*_this)));
return _this;
}
_________________________________________________

[...]
Any better?

Oct 6 '07 #158

"Chris Thomasson" <cr*****@comcast.netwrote in message

Lest start off with the small stuff... A LIFO is not advanced; at least
that the way it is imo...

I'd advise you to start off with a red black tree or a hash table.

Everyone can write their own linked list routines or stacks, and the
benefits of yours aren't obvious. However a more complex structure takes
non-trivial effort to code, so you've got a much better chance of
acceptance. After the complex structures have some sort of following, people
might accept linked lists or dynamic arrays that operate with the same
conventions. But they are not going to rewrite their code tomorrow just
because CT says "we should have a fucntion called clc_llunlink() to remove a
node from a linked list".
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Oct 6 '07 #159

jacob navia wrote:

André Gillibert wrote:
> I was talking about templates, constructors and destructors.

Wow, that would be C++.

Yes. It would just be (C++ - a few things)
+ many_useless_incompatibilities.

Constructors and destructors look simple but are HELL to implement:

int foo(int n)
{
int arg;
// ...
if (arg 0)) {
struct foo;
// ... some code
goto exit;
// ... some code
}
exit:
return 56;
}

The destructor of foo needs to be called before the goto gets
executed... This was a bug still in MSVC some years ago.

Wow. I find it hard to believe that a commercial application was so buggy,
while this is the first thing I would have thought of!
Anybody with a brain, when implementing constructors and destructors,
starts by thinking about:
1) What are the scope and lifetimes of objects.
2) What are the ways to enter and exit these scopes (such as return, goto,
break, continue, longjmp, C++ exceptions) and what to do in each case.

Now, I don't doubt of the incompetence of MSVC programmers.

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

Oct 6 '07 #160

"Douglas A. Gwyn" <DA****@null.netwrote in message

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

Some things can't be done by committee. For instance I don't think there is
a single example of a famous poem written by a committee of people.

Language design is another of those things that don't seem to respond well
to committee treament. The mentality of a brilliant software designer and a
good committee member seem to be opposed. The reason is that a successful
language is usually a cloaking of a simple, radical idea with usable syntax,
without compromises. Committee members by nature compromise with each other.
Most language designs are not too successful. For instance my idea of
MiniBasic - 1980s style BASIC as an embedded script, on the basis that there
is a base of millions of amateur BASIC programmers - hasn't caught on as I
had hoped. But it might have worked.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Oct 6 '07 #161

"Mark McIntyre" <ma**********@spamcop.netwrote in message

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.

That's not true in games.
What typically happens in a games company is that a product is released. If
it is successful, the graphics will be changed and a few tweaks and twiddles
made to the code, to get something that plays rather differently and looks
new to the user but costs less to develop. After about the third time round
the whole thing is getting creaky, the programmers are getting bored, and
technology has moved on. So management decide to invest in a new version,
"starting with a clean sheet".

All the code from the old version will be rigorously thrown away, and every
single line rewritten from scratch, for a brand new project. It is largely
psychological, to do something new rather than rehash the old game.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Oct 6 '07 #162

jacob navia wrote:

How do you get rid of the goto?

int Search_byName(char *name,int HowtoSearch)
{
switch(HowtoSearch) {
// ...
case 42:
for (int i=0; i<Len; i++) {
if (!strcmp(name,nameTab[i]))
goto found; // <<<<--
}
fprintf(stderr,
"Not found\,%s is an illegal name);
return 0;
case 65:
// ...
}
return -1;
found:
// Some code
return 1;
}

Goto allergic people will say that you just can:
1) Define a boolean indicating the type of exit of the switch statement.
Something like:

_Bool error=1;
switch(HowtoSearch) {
case 42:
for (int i=0; i<Len; i++) {
if (!strcmp(name,nameTab[i]))
{error=0;break;}
}
case 65:
/* ... */
}
if (error) return -1;
/* Some code */

2) Move the "return -1;" statement to everywhere you exit the switch
normally (e.g. with break). For more complex conditions, a separate
function should be implemented to do the work so that the statement
becomes: return FunctionCall(...);
(Personally, I would find it harder to maintain and dangerous not to
forget one exit case).

Note: In the set of goto allergic people, there's the subset of
goto/continue/break/short-return allergic people.
They use many boolean variables to do things such as;
for(i=0; i<n && !exit_from_loop; i++) {
/* ... */
if (condition) {exit_from_loop=1;}
else {
/* ... */
}
}

The break statement has no arguments, and for breaking out
of several nested scopes you *have* to use gotos.

Or boolean variables (which typically has an overhead for nested loops).

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

Oct 6 '07 #163

jacob navia wrote:

int foo(int n)
{
int arg;
// ...
if (arg 0)) {
struct foo;
// ... some code
goto exit;
// ... some code
}
exit:
return 56;
}

The destructor of foo needs to be called before the goto gets
executed... This was a bug still in MSVC some years ago.

Just by curiosity, had MSVC bugs (such as silently compiling and not
initializing the variable) when entering a scope with a goto or switch
case?

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

Oct 6 '07 #164

jacob navia wrote:

Why is this not a good idea?

Constructors and destructors look great in principle, but
they are
o difficult to implement correctly. It took the C++ people 5-6
years to get it right.
o They add too much implicit code to the language. And this is
a very important point.

3] Don't mix well with traditional error codes.
As an example, read Gripe #4 at:
http://blogs.msdn.com/ericlippert/ar.../23/94651.aspx

4] Are hard to use *correctly* without exceptions.
Whenever a constructor allocates a resource whose creation mail fail, it
must signals that.
There're several ways to get it right without exceptions.
1) A zoombie flag that has to be checked explicitly just after explicit
(or implicit) object creation.
2) Making the constructor do nothing except initialize some state bits to
indicate that the object is uninitialized and then, providing a
AllocateResource() function that does the real work and returns an error
code.

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

Oct 6 '07 #165

"Malcolm McLean" <re*******@btinternet.comwrote in message
news:-L******************************@bt.com...

>
"Chris Thomasson" <cr*****@comcast.netwrote in message
>Lest start off with the small stuff... A LIFO is not advanced; at least
that the way it is imo...

I'd advise you to start off with a red black tree or a hash table.

Well, I am very curious to find out if we are even able to agree on a simple
LIFO interface... Let's get a simple/trivial API out of the way, then we can
increase the complexity by adding more and more advanced data-structures.

Everyone can write their own linked list routines or stacks, and the
benefits of yours aren't obvious.

I guess a possible benefit would be a pseudo-standardization of common
data-structures within the context of this newsgroup. How useful that would
be is up for debate indeed...

However a more complex structure takes non-trivial effort to code, so
you've got a much better chance of acceptance. After the complex
structures have some sort of following, people might accept linked lists
or dynamic arrays that operate with the same conventions.

Perhaps. Although, if we can't flesh out a LIFO API, then how can we
possibly do something more "advanced"?

But they are not going to rewrite their code tomorrow just because CT says
"we should have a function called clc_llunlink() to remove a node from a
linked list".

I am not advocating that we should change our code to use an API that is
defined by this newsgroup. Anyway, IMHO, the CLC Standard API itself, along
with its various implementations, would be a good resource for any C
newbie's.

Hummm... Thinking on this one.

Oct 6 '07 #166

santosh

Malcolm McLean wrote:

"Mark McIntyre" <ma**********@spamcop.netwrote in message
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.
That's not true in games.
What typically happens in a games company is that a product is released. If
it is successful, the graphics will be changed and a few tweaks and twiddles
made to the code, to get something that plays rather differently and looks
new to the user but costs less to develop. After about the third time round
the whole thing is getting creaky, the programmers are getting bored, and
technology has moved on. So management decide to invest in a new version,
"starting with a clean sheet".

All the code from the old version will be rigorously thrown away, and every
single line rewritten from scratch, for a brand new project. It is largely
psychological, to do something new rather than rehash the old game.

As far as I'm concerned game programmers can play around all they
want. :)

Oct 6 '07 #167

jacob navia wrote:

Yes, but it has the class hierarchy rules, that C doesn't have.

In C the rules can't be the same.

Yes, they can. It wouldn't be possible if C had MORE types than C++, but
it has FEWER.

We would need a new set of rules,
and some years of testing of those rules in the field, etc.

Maybe you would create simplier rules, but it would be very harmful, in my
opinion, to reinvent something by doing it differently.
Incompatibilities between C and C++ would become numerous and harmful.
It's hard enough to live with the existing incompatibilities. Please,
don't add any new.
You may not feel concerned if you don't use C++, but if you did, you would
see that making C projects/libs cooperate with C++ projects/libs is
something that would be eased by a better compatibility.

BTW: I don't find the C++ standard harder to read than the C standard.
--
If you've a question that doesn't belong to Usenet, contact me at
<ta*****************@yahoDELETETHATo.fr>

Oct 6 '07 #168

In article <1191444337.572042@news1nwk>, Eric Sosman
<Er*********@sun.comwrites

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

Actually C is used for a LOT of seriously safety critical work. Much of
the time your life depends on C programs.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Oct 6 '07 #169

In article <11**********************@y42g2000hsy.googlegroups .com>,
user923005 <dc*****@connx.comwrites

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

The recent "reverse the words in this sentence" problem posted made me
think about it.
It's like 5 lines to do it in C++ because of all the nifty algorithms
that come with the language (I think BOOST is going to get bolted on
to the C++ language like STL did).

It's a lot more work in C than C++. Why doesn't C have stacks,
dequeues, and other common, simple tool sets already in its standard
library?

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

Actually in the last ISO C meeting the ISO C panel finally realised that
the major use of C is in the embedded field and C99 is already too big.

In fact any changes to C are likely to include reducing it rather than
enlarging it by much.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Oct 6 '07 #170

Malcolm McLean wrote:

Some things can't be done by committee. For instance I don't think there
is a single example of a famous poem written by a committee of people.

Yes, you're most probably right for poems.

Language design is another of those things that don't seem to respond
well to committee treament.

The law of jungle is MUCH MUCH worse than committee treatment.
e.g. The "state" of C++ before standardization was really awful. After
standardization, it became consistent, understandable, though complex.
C was awful too, before standardization. Less than C++, but it was too.

I judge that C90 had been one of the best standardization success of the
the twentieth century in IT.
Moreover, I think that C90 didn't sacrificied simplicity.

The mentality of a brilliant software designer and a good committee
member seem to be opposed.

The problem is not: Committee member vs software designer.
The problems are: More than one brain for a design, more than one
implementation and more than one platform for a language.

A language designed by a single person will be consistent, relatively
simple, won't have obvious flaws, but will have many non-obvious ones.
Moreover, if there're more than one implementation, they all will be
incompatible because informal specifications are always full of corner
cases.

A language designed by many non-cooperating persons, will be incredibely
inconsistent, go into all directions, and be a real nightmare to use,
since every implementation would be incompatible and have zounds of
absolutely useless extensions. That's the state of BASIC.
Personally, I wouldn't be able to *define* what BASIC is! All
implementations are so different and incompatible that I cannot find much
common.
Note: There has been a standard, but, most implementations don't follow
it, either because they don't care, or because they've been written before
the standardization.

A language designed by a committee (a set of people who try to build
something coherent from a mess) from an existing language having many
incompatible implementations, will please most members, without bloating
too much the language (unless it's already bloated), and keeping some
internal consistency.
Moreover, portability flaws (e.g. platform, technology or human language
dependence) will be removed, so that it becomes possible to implement it
everywhere it makes sense.

Many languages follow the three steps:
Design by one creator (it may "look" good, but be either unusable or too
platform dependent... Sometimes, it's right from the start), cahotic
evolution by implementors, and final standardization.

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

Oct 6 '07 #171

jacob navia

Chris Hills wrote:

In article <11**********************@y42g2000hsy.googlegroups .com>,
user923005 <dc*****@connx.comwrites
>It would be really nice if C could adopt a really nice algorithms
library like C++'s STL + BOOST.

The recent "reverse the words in this sentence" problem posted made me
think about it.
It's like 5 lines to do it in C++ because of all the nifty algorithms
that come with the language (I think BOOST is going to get bolted on
to the C++ language like STL did).

It's a lot more work in C than C++. Why doesn't C have stacks,
dequeues, and other common, simple tool sets already in its standard
library?

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

Actually in the last ISO C meeting the ISO C panel finally realised that
the major use of C is in the embedded field and C99 is already too big.

In fact any changes to C are likely to include reducing it rather than
enlarging it by much.

Great!

I would vote for getting rid of
gets()
asctime()
trigraphs
strtok()

If we introduce operator overloading we can get rid of complex numbers
*in the language*. They would become another numeric data type that can
be used with that feature. The same for fixed point numbers, decimal
numbers, and several other proposals like bignums, extended precision
floats etc. All those packages wouldn't be part of the language itself
but would be in libraries that can be added on an "as needed " basis.

Actually, if we add the proposed changes the language becomes richer and
smaller. We can use hash_tables and other containers transparently
using the [ ] operator, and extending the basic types becomes
much easier.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Oct 6 '07 #172

In article <47***************@null.net>, Douglas A. Gwyn
<DA****@null.netwrites

>"André Gillibert" wrote:
>Douglas A. Gwyn wrote:
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.

Sure, and I haven't said otherwise. I use it myself.

I maintain that C is not a good choice for most "modern" major
applications.

So what language would you suggest?

>However, if you already have access to a good
C programming support environment (libraries, disciplines) then
that could influence the decision. Also, C still has an edge
over any of the alternatives when it comes to breadth of
portability.

Agreed.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Oct 6 '07 #173

In article <47***********@mindspring.com>, pete <pf*****@mindspring.com>
writes

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

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

Yes.

Why shouldn't C be more like C++?
Because there is C++.

Absolutely!

The other thing to bear in mind is that on platforms where there is a C
compiler but no C++ compiler it is usually for a very good reason. Even
if these things were added to C (like many things were added to C90 to
get C99) I doubt they would be implemented.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Oct 6 '07 #174

In article <47***********************@news.orange.fr>, jacob navia
<ja***@nospam.orgwrites

>James Dennett wrote:
>jacob navia wrote:
>>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

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.

I know of at least one GCC maintainer who is on a C standards panel
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Oct 6 '07 #175

In article <47***************@null.net>, Douglas A. Gwyn
<DA****@null.netwrites

>"André Gillibert" wrote:
>The fact that C99 is already to big and requires YEARS to be implemented
correctly (unlike C90 which is much simplier)

C99 didn't *require* years to implement. In fact, there was at least
one C99 front end (from Edison) not very long after C99 was published.

C99 has required years to implement. A parser is not a compiler. It is
part of a compiler.

There are very few (if any) compilers that do a full implementation of
C99

>The rate at which C99 conformance is being attained by GCC could be
explained by a combination of low customer demand (C90 being adequate
for most C programmers) and relative lack of interest by implementors.

I think the came is true for ALL C compiler makes not just GCC

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Oct 6 '07 #176

In article <5m************@mid.individual.net>, Default User
<de***********@yahoo.comwrites

>Richard Heathfield wrote:

>Default User said:

Richard Heathfield wrote:
Just out of curiosity: are all Frenchmen so wilfully ignorant as to
drop honorifics from names (as you habitually do), or is it just
you >giving your countrymen a bad name?
>
I thought you Brits were used to that sort of thing.

No. In fact, we're not even used to being called Brits. :-)

Beats "Yanks" or "Seppos".

Er Septics not Seppos

>We like to call everybody by their first name. Do you prefer Ricky or
Richie?

Bub or Mac? :-)

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Oct 6 '07 #177

In article <nq******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites

>Default User said:

>Richard Heathfield wrote:

>>Just out of curiosity: are all Frenchmen so wilfully ignorant as to
drop honorifics from names (as you habitually do), or is it just you
giving your countrymen a bad name?

I thought you Brits were used to that sort of thing.

No. In fact, we're not even used to being called Brits. :-)

Well quite often it is common to drop the honorific ( suppose it
depends where you went to school) and we are quite often called Brits.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Oct 6 '07 #178

In article <Q_******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites

>[csc snipped]

Default User said:

<snip>

>We like to call everybody by their first name. Do you prefer Ricky or
Richie?

No. :-)

Dick or Dicky?

(Ducky even :-))))
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Oct 6 '07 #179

In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites

>"Default User" <de***********@yahoo.comwrites:
>Richard Heathfield wrote:
>>Default User said:
Ok, Dickie it is.

You might want to reconsider that.

You don't seem very friendly.

I hereby declare this subthread terminated, by virtue of my authority
-- oh, wait, I don't have any. Well, I declare this subthread
terminated anyway.

Come on, guys, play nice.

Ok Mr Kenneth Thompson :-)

Its a Saturday afternoon and we need a little fun before the Aussies
beat us at rugby :-(
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Oct 6 '07 #180

"Chris Hills" <ch***@phaedsys.orgwrote in message

>>I maintain that C is not a good choice for most "modern" major
applications.

So what language would you suggest?

Major applications are notorious for cost overruns, if not outright failure.
A lot of them are written in C, or least were until a few years ago. That
tells us that use of C doesn't guarantee success, and it suggests that a
better language should be found.

Unfortunately there isn't one. Projects written in competing languages such
as C sharp, C++, Java, or in mixtures of various scripting lanauges and
database interfaces, also regularly fail. There might be a slight
improvement or deterioration with respect to C, but it is so slight that it
is hard to measure.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Oct 6 '07 #181

jacob navia

Malcolm McLean wrote:

>
"Chris Hills" <ch***@phaedsys.orgwrote in message

>>I maintain that C is not a good choice for most "modern" major
applications.

So what language would you suggest?

Major applications are notorious for cost overruns, if not outright
failure. A lot of them are written in C, or least were until a few years
ago. That tells us that use of C doesn't guarantee success, and it
suggests that a better language should be found.

Unfortunately there isn't one. Projects written in competing languages
such as C sharp, C++, Java, or in mixtures of various scripting lanauges
and database interfaces, also regularly fail. There might be a slight
improvement or deterioration with respect to C, but it is so slight that
it is hard to measure.

Result:

Programming languages do not affect really the outcome of large
projects.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Oct 6 '07 #182

santosh

Chris Hills wrote:

In article <11**********************@y42g2000hsy.googlegroups .com>,
user923005 <dc*****@connx.comwrites
It would be really nice if C could adopt a really nice algorithms
library like C++'s STL + BOOST.

The recent "reverse the words in this sentence" problem posted made me
think about it.
It's like 5 lines to do it in C++ because of all the nifty algorithms
that come with the language (I think BOOST is going to get bolted on
to the C++ language like STL did).

It's a lot more work in C than C++. Why doesn't C have stacks,
dequeues, and other common, simple tool sets already in its standard
library?

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

Actually in the last ISO C meeting the ISO C panel finally realised that
the major use of C is in the embedded field and C99 is already too big.

In fact any changes to C are likely to include reducing it rather than
enlarging it by much.

In your estimation which parts of C99 are most likely to be dropped if
a new
Standard does come out? The least used parts perhaps? Like VLAs,
tgmath.h,
standard pragmas?

Oct 6 '07 #183

In article <11**********************@57g2000hsv.googlegroups. com>,
santosh <sa*********@gmail.comwrites

>
Chris Hills wrote:
>In article <11**********************@y42g2000hsy.googlegroups .com>,
user923005 <dc*****@connx.comwrites
>It would be really nice if C could adopt a really nice algorithms
library like C++'s STL + BOOST.

The recent "reverse the words in this sentence" problem posted made me
think about it.
It's like 5 lines to do it in C++ because of all the nifty algorithms
that come with the language (I think BOOST is going to get bolted on
to the C++ language like STL did).

It's a lot more work in C than C++. Why doesn't C have stacks,
dequeues, and other common, simple tool sets already in its standard
library?

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

Actually in the last ISO C meeting the ISO C panel finally realised that
the major use of C is in the embedded field and C99 is already too big.

In fact any changes to C are likely to include reducing it rather than
enlarging it by much.

In your estimation which parts of C99 are most likely to be dropped if
a new
Standard does come out? The least used parts perhaps? Like VLAs,
tgmath.h,
standard pragmas?

No idea. It was just a preliminary discussion. There is a long way to go
yet.

I think the suggestion was anything not implemented by more than 2
mainstream (in their market) compilers.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Oct 6 '07 #184

Ed Jensen

Ian Collins <ia******@hotmail.comwrote:

>
Ed Jensen wrote:
>In comp.lang.c Ian Collins <ia******@hotmail.comwrote:
>>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.

I think your conclusion is wrong.

My conclusion is that many developers chose to move to less primitive
languages with more comprehensive standard libraries instead.

It what way does that contradict my conclusion?

The demand was, and still is, there; however, since the powers-that-be
aren't evolving C to meet those demands, developers simply end up
leaving the language.

Oct 6 '07 #185

"Chris Hills" <ch***@phaedsys.orgwrote in message

>
C99 has required years to implement.

Has taken years to implement.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Oct 6 '07 #186

"Keith Thompson" <ks***@mib.orgwrote in message

That's a matter of taste. Personally, given a language that supports
operator overloading, I have no problem with using "+" for string
concatenation. The fact that it's not commutative just doesn't bother
me. The intended meaning of
"hello" + " " + "world"
seems perfectly obvious. It's a convenient notation; mathematical
purity isn't required.

The problem is that this doesn't arise too often. The actual example you
posed would always be rendered "hello world", for example, so really it is

char *audience;

"hello " + audience;

Most often you want to embed numbers in strings you create on the fly,
because usually the output will be numerical.

"hello " + audience ", you have " + ticks + "seconds on your account".

Unfortuately then

"hello " + audience + "time left " + hours + minutes + "\n";

isn't clear.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Oct 6 '07 #187

Tor Rustad

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?

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

What about requiring that implementations use a stable algorithm for
qsort() first?

From the systems programmers perspective, I think they want the C to
stay small and simple language. I can remember how Linus flamed, on the
suggestion of adding strlcpy/strlcat to glibc. In his view, glibc was
already too bloated and should instead remove stuff.

IMO, the OO way of designing ADT is superior. If extending C's abilities
in this regard, the natural path to my mind, would rather be to pull in
some C++ features, like class. Going down that road, you want operator
overloading, templates etc. etc. =use C++

--
Tor <torust [at] online [dot] no>

"There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the
other way is to make it so complicated that there are no obvious
deficiencies"

Oct 6 '07 #188

jacob navia

Ed Jensen wrote:

Ian Collins <ia******@hotmail.comwrote:
>Ed Jensen wrote:
>>In comp.lang.c Ian Collins <ia******@hotmail.comwrote:
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.
I think your conclusion is wrong.

My conclusion is that many developers chose to move to less primitive
languages with more comprehensive standard libraries instead.
It what way does that contradict my conclusion?

The demand was, and still is, there; however, since the powers-that-be
aren't evolving C to meet those demands, developers simply end up
leaving the language.

EXACTLY.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Oct 6 '07 #189

Chris Hills <ch***@phaedsys.orgwrites:

In article <47***************@null.net>, Douglas A. Gwyn
<DA****@null.netwrites
>>"André Gillibert" wrote:
>>The fact that C99 is already to big and requires YEARS to be implemented
correctly (unlike C90 which is much simplier)

C99 didn't *require* years to implement. In fact, there was at least
one C99 front end (from Edison) not very long after C99 was published.

C99 has required years to implement. A parser is not a compiler. It
is part of a compiler.

[...]

A parser is not a front end. It is part of a front end.

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

Oct 6 '07 #190

"Malcolm McLean" <re*******@btinternet.comwrites:

"Keith Thompson" <ks***@mib.orgwrote in message
>That's a matter of taste. Personally, given a language that supports
operator overloading, I have no problem with using "+" for string
concatenation. The fact that it's not commutative just doesn't bother
me. The intended meaning of
"hello" + " " + "world"
seems perfectly obvious. It's a convenient notation; mathematical
purity isn't required.

The problem is that this doesn't arise too often. The actual example
you posed would always be rendered "hello world", for example, so
really it is

char *audience;

"hello " + audience;

Most often you want to embed numbers in strings you create on the fly,
because usually the output will be numerical.

"hello " + audience ", you have " + ticks + "seconds on your account".

That "," should be "+", yes?

Unfortuately then

"hello " + audience + "time left " + hours + minutes + "\n";

isn't clear.

So you provide a function that converts an integer to a string:

"hello " + audience + "time left " + image(hours) + image(minutes) + "\n";

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

Oct 6 '07 #191

"Keith Thompson" <ks***@mib.orgwrote in message

So you provide a function that converts an integer to a string:

"hello " + audience + "time left " + image(hours) + image(minutes) + "\n";

Now you've introduced a requirement for automatic garbage collection.
It's the approach I used in MiniBasic, but then it was never sold as a fast,
low-level language.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Oct 6 '07 #192

Chris Hills <ch***@phaedsys.orgwrites:

In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites
>>"Default User" <de***********@yahoo.comwrites:
>>Richard Heathfield wrote:
Default User said:
Ok, Dickie it is.

You might want to reconsider that.

You don't seem very friendly.

I hereby declare this subthread terminated, by virtue of my authority
-- oh, wait, I don't have any. Well, I declare this subthread
terminated anyway.

Come on, guys, play nice.

Ok Mr Kenneth Thompson :-)

Hey, I've been mistaken for Ken Thompson before. ("Are you *the*
Keith Thompson, the Unix guru?" Well, sort of, but not the one you're
thinking of.)

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

Oct 6 '07 #193

Ian Collins

Ed Jensen wrote:

Ian Collins <ia******@hotmail.comwrote:
>Ed Jensen wrote:
>>In comp.lang.c Ian Collins <ia******@hotmail.comwrote:
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.
I think your conclusion is wrong.

My conclusion is that many developers chose to move to less primitive
languages with more comprehensive standard libraries instead.
It what way does that contradict my conclusion?

The demand was, and still is, there; however, since the powers-that-be
aren't evolving C to meet those demands, developers simply end up
leaving the language.

The powers that be didn't develop the STL. It was in widespread use
well before it was integrated into the C++ standard library.

If the demand was there, there would be at least one C equivalent, but
there isn't.

--
Ian Collins.

Oct 6 '07 #194