Making C better (by borrowing from C++)

[Chris Croughton]

fopen et al are available of course...

That's not what you wrote: "you can't do anything else but use the
console with putc and getc".

Because they are _stdcall and that is an extension my dear.

But it is in the implementation namespace, since it starts with an
underscore.

Exactly. You get it now. There are several other problems too.

It's something which the compiler could handle (only allow extensions in
MS header files, or whatever, it's undefined by the standard how those
are pulled into the translation unit).

(but it should be

No, it is not possible since for variable argument functions like
printf that convention CAN't be used! I have to keep BOTH you see?

Then you have a problem with the OS, akin to the one with systems which
need hardware access, and have to go outside the standard to do it. For
instance by providing your own libraries of functions to implement the
functionality.

but the OS (or compiler implementer) can always provide their

Of course, I would have to rewrite the 15 000 APIs that Windows
offers and that my compiler allows access to.

Only that. Very easy.

Indeed it is.

And keep 2-5 people maintainig them to keep track of changes to the API

Nope, it can be done with a tool which reads the Windows headers and
generates appropriate functions with C semantics to interface them.

All of this to avoid writing

_stdcall

In the headers.

It can be done. It /is/ done on a number of systems.

There is no mouse, no graphics, no sound, no nothing. Most of the
software written in C uses those, so most of the software in C is
written in a "dialect" then. Who cares?

'Most'? I might agree with "most of the software purchased" (since that
includes all of the MS stuff), but I doubt that its most of the software
written. I have never written professionally[1] a C program which used
a mouse, graphics or sound, and I've written a lot of C code.

OK. Then you can use "pure C" as you wish. lcc-win32 is a C compiler
that targets the Windows desktop platform. Not your stuff.

Indeed. It is also not standard C, and thus is off-topic in
comp.lang.c, no matter how much you keep pushing it.

As I explained already, all the extensions of lcc-win32 are exactly like
that: they do not use the user's namespace and a conforming program
cannot use them explicitely unless they use the extension.

Aparrently not:

For instance a normal C program can't write:

int operator+(myStruct a,myStruct b);

So if they do write this they are using lcc-win32's extensions.

No, they are writing invalid C code for which the standard requires a
diagnostic. Had you named it _operator you might have a leg to stand
on, because the implementation is allowed to define that as an
identifier, but possibly not. As I pointed out, most of the etensions
are things which look like -- and can be implemented as -- macros, so I
can write

void _cdecl __attribute(datasect) int fred(void);

with no problems because an implementation can just do

#define _cdecl
#define __attribute(_x)

if it doesn't support those extensions. However, if a person uses your
operator+ then there is no way of converting it to C code.

Worse, since it alters the semantics and not just the syntax of the
program, there is no way of automatically converting the code which uses
it to standard C (without having a compiler for your language).

Of course. The standard is mistaken. When you like it, you are "FOR
STANDARD C"!! when you do not like it you say the standard is mistaken.

Of course. I have never said that the standard is perfect, nor that its
authors always made the correct decisions (see threads about the
precedence of bit and relational operators, Dennis Ritchie himself has
apparently said that it was wrong). However, any language which has
extensions not covered by the spec. is not compliant, it doesn't matter
how useful the extensions are if they are used by programs those
programs are not C compliant.

That is EXACTLY WHAT I AM DOING. I am letting all users do the
overloading if they wish!

But it isn't standard, and it isn't C. If you want to petition for
adding operator overloading to the C specification, I may well join you
(or I may go the other way and petition to have tgmath.h removed, or to
have typeof added which would also allow the same sort of 'overloading'
of functions as in tgmath.h), but unilaterally adding a feature to a
compiler simply locks the users into that compiler. Which is nice for
you, since people won't be able to resist buying your compiler (as MS
have done for years), but it does nothing to help portable programming
and re-use of code.

The same is of course true of the GCC extensions. I like GCC's version
of macro varargs, and thing that it is better designed than the C99 one,
but if I want to make my programs portable I ignore the extension (in
practice, if I want to make them portable I ignore the C99 extensions as
well, since they are rarely implemented fully as yet).

No, a normal need: It is very difficult and error prone to memorize
several similar function names, and not make a mistake when calling
the one or the other. This is a work that machines do very well. They
can do dumb things very quickly and do not get bored. So why do not
let the machines do the work for you?

However did C programmers manage without them? Quite well, as it
happens, I've never known anyone write production code with bugs of that
form in (it's probably happened, but it's pretty rare). If you don't
know what type your variables are, and it matters, then you'll have a
lot worse problems than forgetting to call sqrtf() instead of sqrt()
(particularly since the base function names take double parameters, so
although that may be better precision than needed it won't be worse).

The names are pretty logical, as well, I no more have to memorise three
names for each than I have to memorise all variants of words in English,
they have consistent suffixes (none for double, f for float and l for
long double).

Although I'm sure 'sqrtl' is a creature from Pokemon(tm)...

Chris C

 

[jacob navia]

So am I. I'd break a several-year tradition of mine and actually
spend money on such software, provided it had the following features:

1) Full support for C90 language and library
2) Full support for C99 language and library
3) No diagnostics except those required by the Standard for
syntax errors and constraint violations
4) Available for at least Win32 and Linux
5) No extensions whatsoever

That would be an extremely useful implementation indeed.

For C90 there is already a compiler like that. It is lcc (not lcc-win32)
and runs under windows and unix. You can download it from
http://www.cs.princeton.edu/software/lcc/

It has no assembler or linker but under linux it will use
gcc's assembler and linker. Under windows you will need masm
(the microsoft assembler) and link.exe, the microsoft linker.

The debug info under unix is stabs, so you can use gdb to debug
the programs. Under windows there is no debugger.

It is free of charge.

 

[CBFalconer]

.... snip ...

I am sure an ANSIC only version of a C compiler would be
smashing success !

I suspect that the majority of c.l.c readers do the majority of
their work with a compiler limited to the ANSI (or standard)
language. For gcc a suitable incantation is:

gcc -W -Wall -ansi -pedantic Wwrite-strings -Wfloat-equal -O1

which is installed automaticall via an alias here. It is always
possible to modify this for the rare file which needs to take
liberties.

 

[Mark McIntyre]

Please understand the differeence between a library call
(not an extension at all) and a real extension of the
language.

You're choosing to define extend as "add keywords, new syntax or grammar".
I'm not. I belive my definition to be more generally in use.

There is no mouse, no graphics, no sound, no nothing. Most of the
software written in C uses those, so most of the software in C is
written in a "dialect" then. Who cares?

I'm trying to remember where I argued that using nonstandard libraries and
constructs was a bad thing. I don't think I did, but your attitude
certainly makes me wish I had, if merely to wind you up. Grow up will you?

Extensions are a modification of the syntax, however slight.
Nope.

"__builtin" constructs, "__special__" etc etc. Gcc uses them,
MSVC uses them, etc.

What the implementation does under the hood is quite irrelevant.

This are necessary adaptations of the
syntax to particular environments. Without them, you couldn't
do any real world programming.

You must live in a very strange real world.

If I would have done it by hardwiring the overloaded functions into
the compiler it would be the same thing. This functions are overloaded
BY DEFINITION in the standard itself.

Nope.

 

[Mark McIntyre]

Because they are _stdcall and that is an extension my dear.

What /are/ you talking about? I can call library functions without any
weird extensions.

No, it is not possible since for variable argument functions like
printf that convention CAN't be used! I have to keep BOTH you see?

Then maybe you simply aren't clever enough at coding. Perhaps you should
leave it to the pros. =:-0
(gd&r)

OK. Then you can use "pure C" as you wish. lcc-win32 is a C compiler
that targets the Windows desktop platform. Not your stuff.

So you're saying you can't write ISO-standard C on it? That seems an
idiotic design decision.

Of course. The standard is mistaken. When you like it, you are "FOR
STANDARD C"!! when you do not like it you say the standard is mistaken.

Its worth pointing out that
a) thats precisely what you're saying too and
b) everyone is entitled to their opinion.

Personally I think that single-line comments and declare-at-use are an
abhomination and make code maintenance a zillion times harder. Obviously
the ISO committee didn't agree with me.

 

[jacob navia]

What /are/ you talking about? I can call library functions without any
weird extensions.

All API functions under win32 use the _stdcall calling convention.
This means that the called function cleans up the stack, i.e. adds
to the stack before returning the space allocate to make the
argument frame. This means that all code for stack adjustment
is moved fom all call sites to the single instruction in the called
function.

This can't be done with functions that receive an unknown number
of arguments like printf, for instance.

In C you prototype those functions as
int myfn(char *,...);

It would be impossible for such functions to clean up the stack
since they can't know how much was pushed, they discover it at
run time, and it could be perfectly legal to pass more arguments
than needed.

It is needed then to have two disctinct calling conventions,
(there are more like fastcall where the arguments are passed in
registers but let's leave it at that).

In a similar vein, functions that should be exported from a dll
need a special mark to tell the compiler to emit records to be
processed by the linker to add those functions to the list of
exported ones. This is done under windows with

int __declspec(dllexport) fn(void);

for instance.

ETC ETC.

In embedded systems there are needs to distinguish between
RAM variables, EPROM variables, ROM variables, etc etc.

But this wasn't the thema of this thread. We are talking about
"Making C better (by borrowing from C++)"

In lcc-win32 I have tried to improve the language using some
stuff from C++ like operator overloading, generic functions,
default arguments, and some others. This makes it easier
to program the extensions of C99 for instance: sqrt is a true
generic function, like all others in tgmath.h but not only those

I made that feature available to users.

The biggest advantage is that the code for the complex number
libraries is open and it can be modified by the user. As you
may know, there are several ways of multiplying complex numbers,
and each one is better suited for different applications: you
can need more accuracy, another will want more speed, and yet
another will like to use more complex and slower algorithms
that make overflow errors more difficult, etc etc.

Using operator overloading the code can be distributed and
users can modify it if they wish.

Other goodies that operator overloading makes possible are 350 bit
floats (qfloats) bignums, and many other kinds of numbers.
In general operator overloading works best when you have
numeric data types.

The string library using operator overloading allows for a
simple syntax like String s; ... s[5] = 'b';
instead of set_string_element(s,5,b); or String s = "abc";
instead of String s = newStringfromCharPointer("abc");

Of course this has brought me all kind of arguments like
"If you want C++ you know where to find it" specially from
the people that think that C is dead and a corpse shouldn't be
disturbed.

It is interesting to see how different the C++ discussion
groups are, in the sense that people are open to improvements
propositions, suggestions etc, without all those "heretic! herectic!"
cries that I hear over here.

Our own "in-house" troll, Mr Tisdale has expressed it like this:
The only reason that C exists
is so that C programmers can maintain legacy codes.
C programmers don't want C to evolve or grow.
It is sad to see how many people here prove him right

jacob

 

[Keith Thompson]

Of course this has brought me all kind of arguments like
"If you want C++ you know where to find it" specially from
the people that think that C is dead and a corpse shouldn't be
disturbed.

It is interesting to see how different the C++ discussion
groups are, in the sense that people are open to improvements
propositions, suggestions etc, without all those "heretic! herectic!"
cries that I hear over here.

That's your misinterpretation of what others have said. Please cite
an article from a comp.lang.c regular saying that "C is dead and a
corpse shouldn't be disturbed" or calling anyone a "heretic".

The C language does evolve, though perhaps not at the speed or in the
direction some might like. The folks who talk about proposed changes
to the language hang out in comp.std.c.

 

[infobahn]

For C90 there is already a compiler like that. It is lcc (not lcc-win32)
and runs under windows and unix. You can download it from
http://www.cs.princeton.edu/software/lcc/

I took a look, but I can't pretend to have made a detailed study. It
does indeed appear that you (I presume it was you?) have gone to a
great deal of trouble to resist the temptation of adding extensions.
(My research consisted of looking for strdup and isascii, since I
thought they'd be the most likely to sneak into the mix unheeded.)

I haven't had a chance to test your claim that it issues no
diagnostics except in circumstances where it must. Not that I
don't believe you or anything, but I'm sure you understand the
"I want to see it for myself" mentality... But I'm hopeful.

It has no assembler or linker but under linux it will use
gcc's assembler and linker. Under windows you will need masm
(the microsoft assembler) and link.exe, the microsoft linker.

Oh, I don't think a linker is entirely necessary. Not for my
purposes, anyway.

It is free of charge.

In which case I can forgive it for not supporting C99.

 

[RoSsIaCrIiLoIA]

I suspect that the majority of c.l.c readers do the majority of
their work with a compiler limited to the ANSI (or standard)
language. For gcc a suitable incantation is:

gcc -W -Wall -ansi -pedantic Wwrite-strings -Wfloat-equal -O1

yes
lcc_win32 -ansi90 file.c
for ansi programs that don't allow extensions

lcc_win32 file.c
for exented C programs

 

[Chris Croughton]

I suspect that the majority of c.l.c readers do the majority of
their work with a compiler limited to the ANSI (or standard)
language. For gcc a suitable incantation is:

gcc -W -Wall -ansi -pedantic Wwrite-strings -Wfloat-equal -O1

which is installed automaticall via an alias here. It is always
possible to modify this for the rare file which needs to take
liberties.

I don't believe that is good enough, especially where the library and
headers are concerned. What is needed is a "reference implementation",
it doesn't matter how slow or how poor the code generated is (as long as
it is compliant -- generation of code for a virtual machine, with an
interpreter written in Standard C would be fine). Lint would be good if
it could be contrained to report /all/ standard violations and /no/
extraneous messages (I hane yet to see any version which does that, they
all seem to delight in warning about anything that anyone has ever
thought might be even slightly dubious).

If anyone's interested in such a project, I'd be interested in helping
with it...

Chris C

 

[Mark McIntyre]

All API functions under win32 use the _stdcall calling convention.

Which is not an extension. Names beginning with an underscore are reserved
for the implementation.

This means

It will come as no surprise to you that I know what it means.

This can't be done with functions that receive an unknown number
of arguments like printf, for instance.

Its certainly harder. However the caller knew, so the compiler can tell the
callee.

int __declspec(dllexport) fn(void);

again, in the implementation space, not an extension. In fact this one is
more reserved than the one above.

In lcc-win32 I have tried to improve the language using some
stuff from C++ like operator overloading, generic functions,
default arguments, and some others.

This is fine, I have no problem with you inventing a new language. But
don't make the mistake of thinking that lcc-win32 implements C. Its
evidently a hybrid language between C++ and C.

Of course this has brought me all kind of arguments like
"If you want C++ you know where to find it"

And you don't think its a fair point - why /are/ you reinventing the C++
wheel? It seems a singularly pointless exercise.

specially from
the people that think that C is dead and a corpse shouldn't be
disturbed.

The only people who think that round here are the trolls.

 

[Chris Hills]

What /are/ you talking about? I can call library functions without any
weird extensions.


Then maybe you simply aren't clever enough at coding. Perhaps you should
leave it to the pros. =:-0
(gd&r)


So you're saying you can't write ISO-standard C on it? That seems an
idiotic design decision.


Its worth pointing out that
a) thats precisely what you're saying too and
b) everyone is entitled to their opinion.

Personally I think that single-line comments and declare-at-use are an
abhomination and make code maintenance a zillion times harder. Obviously
the ISO committee didn't agree with me.

Some do

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Chris Hills]

You must live in a very strange real world.

Actually the majority of C programming these days is in the embedded
world. If you want know what an embedded system is, practically speaking
these days, it is anything with an electric current in it.

Automobiles have 50-100 embedded systems each, airliners several
thousand.

Embedded systems programming (well 95% of it) have to talk to the
hardware. The most common MCU on the planet has a region of bit
addressable HW and therefore has single bit bit types.

Without extensions C would be useless for most embedded stuff. A LOT of
which is safety critical.

BTW I saw a quote from Denise Richie saying that lint was developed to
warn about legal but dubious uses of C. Not just the errors. I must dig
it out.



/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Chris Croughton]

Actually the majority of C programming these days is in the embedded
world.

Hmm, the GNU people might disagree with you.

If you want know what an embedded system is, practically speaking
these days, it is anything with an electric current in it.

Pretty much, although I still have a toaster and a kettle with no
embedded chips (stove on the other hand has embedded chips, I must get
round to cleaning it sometime)...

Automobiles have 50-100 embedded systems each, airliners several
thousand.

Mobile phones have quite a few. Heck, PC keyboards have had them simce
the PC was invented...

Embedded systems programming (well 95% of it) have to talk to the
hardware.

Not really. The programs as a whole have to talk to the hardware (but
the same is true of anything useful, it's not much good if it just sits
there and thinks!), but the majority of the code doesn't have to know
anything about the details of talking to the hardware. Even in embedded
systems there is generally an abstraction layer, the rest of the code
can often happily run on a Unix box or Windows for testing, and can be
(although seldom is) strictly conforming.

The most common MCU on the planet has a region of bit
addressable HW and therefore has single bit bit types.

Mapped by the compiler?

Without extensions C would be useless for most embedded stuff. A LOT of
which is safety critical.

If you consider stuff written in assembler as an abstraction layer to be
an 'extension' (which it is in a strictly conforming program but not in
a conforming one).

BTW I saw a quote from Denise Richie

saying that lint was developed to warn about legal but dubious uses of
C. Not just the errors. I must dig it out.

I've always understood that this was the purpose, I don't remember it
being explicitly stated anywhere but it wouldn't surprise me.

Chris C

 

[Michael Mair]

Is there something we haven't been told? <g>

This probably never should have gotten out -- now all the
macho C programmers have to look for a new language;
all the years, the beard was good enough ;-)

I've always understood that this was the purpose, I don't remember it
being explicitly stated anywhere but it wouldn't surprise me.

Probably
http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
(search for lint)


Cheers
Michael

 

[CBFalconer]

All API functions under win32 use the _stdcall calling
convention. This means that the called function cleans up the
stack, i.e. adds to the stack before returning the space allocate
to make the argument frame. This means that all code for stack
adjustment is moved fom all call sites to the single instruction
in the called function.

This can't be done with functions that receive an unknown number
of arguments like printf, for instance.

In C you prototype those functions as
int myfn(char *,...);

It would be impossible for such functions to clean up the stack
since they can't know how much was pushed, they discover it at
run time, and it could be perfectly legal to pass more arguments
than needed.

It is needed then to have two disctinct calling conventions,
(there are more like fastcall where the arguments are passed in
registers but let's leave it at that).

Things like printf, and variadic functions in general, are NOT OS
calls (although they are a source of bugs). They are the creation
of the C library alone. If the C compiler has a different calling
protocol than the OS, then you simply need a collection of
interface functions to do the conversion. Those go in the library.

 

[Chris Hills]

Hmm, the GNU people might disagree with you.

Pretty much, although I still have a toaster and a kettle with no
embedded chips (stove on the other hand has embedded chips,

Exactly.
BTW my toaster does have an MCU in it!! God knows why. They are
everywhere

I must get
round to cleaning it sometime)...


Mobile phones have quite a few. Heck, PC keyboards have had them simce
the PC was invented...


Not really. The programs as a whole have to talk to the hardware (but
the same is true of anything useful, it's not much good if it just sits
there and thinks!), but the majority of the code doesn't have to know
anything about the details of talking to the hardware. Even in embedded
systems there is generally an abstraction layer, the rest of the code
can often happily run on a Unix box or Windows for testing, and can be
(although seldom is) strictly conforming.

Absolutely not true. where is the Xdata on a Unix machine? The vast
majority of embedded systems don't use and OS. The do talk directly to
the HW. Or the memory.

Mapped by the compiler?

Yes. the compilers (well the decent ones that hold 98% of the
professional market) do have bit types.

ALL the compielrs asl so map Xdata, Data, PData, BData, spaces.

You can write an ISO-C program for the MCU but it will be hopelessly
inefficient and take a lot more room/Money.

If it costs 50 cents to go from the 8K memory version to the 16K memory
model and you are producing 100K of them that is 50K USD more on the
cost.

Not to mention additional time to develop with out the extensions to get
the thing to perform fast enough. (More NRE costs)

If you consider stuff written in assembler as an abstraction layer to be
an 'extension' (which it is in a strictly conforming program but not in
a conforming one).

It is not written in Assembler but C. What abstraction layer? In a lot
possibly a majority of embedded systems there is no abstraction layer.

Many of these parts have between 2-32K code memory and 129-256 RAM
total,

Is there something we haven't been told? <g>

Yes I am dyslexic and can't spell. I some time make mistakes with the
spell checker esp. late at knight

I've always understood that this was the purpose, I don't remember it
being explicitly stated anywhere but it wouldn't surprise me.

I will dig out the quote. Prob next week as I am off to Nuremberg for
Electronica


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Chris Hills]

This probably never should have gotten out -- now all the
macho C programmers have to look for a new language;
all the years, the beard was good enough ;-)



Probably
http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
(search for lint)

That's the one. Thanks.

Legal C does not mean it is "right"

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Chris Croughton]

Things like printf, and variadic functions in general, are NOT OS
calls (although they are a source of bugs). They are the creation
of the C library alone. If the C compiler has a different calling
protocol than the OS, then you simply need a collection of
interface functions to do the conversion. Those go in the library.

Thinking about it, it's quite possible for a compiler to use two
different calling conventions automatically. If it's a variadic
function, or (in C90) has a null prototype (), the calling code pops the
parameters, otherwise the called function pops them. If a function has
a fixed number of parameters (as anything using _stdcall must do) this
this is not a problem.

If there isn't a prototype in scope at the time of the function call,
assume whichever you like and issue a warning, it's te programmer's
problem...

(Sorry jacob, you're just not inventive enough...)

Chris C

 

[Mark McIntyre]

BTW I saw a quote from Denise Richie saying that lint was developed to
warn about legal but dubious uses of C.

That would be Dennis' sister? or another woman who inspired a programming
language?
gd&r...