469,268 Members | 942 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,268 developers. It's quick & easy.

Visual C++ Express Edition or lcc-win32?

Apologies if my cross posting has offended anyone....

For a pure hobbyist C/C++ programmer, who wants to develop
applications to run on Windows, what would be a better choice to
install: Visual C++ Express 2005 Edition or lcc-win32? Does anyone
have any opinion to share?

Also, is there a C++ compiler akin to lcc-win32?

Thanks,
Nimmi

Sep 2 '07
166 6653
On Wed, 05 Sep 2007 17:06:46 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>The gcc team, of several dozens specialist, supported by RedHat Corp,
IBM and other BIG names in the industry obtains surely a better compiler
than a single developer not supported by anyone!
FYI, boasting is extremely unattractive, and highly unlikely to raise
anyone's opinion of you...
--
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
Sep 5 '07 #101
Mark McIntyre wrote:
On Wed, 05 Sep 2007 10:07:20 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>d:\lcc\gp>pedump /summary gp.exe
gp.exe 781856 bytes, linked Wed Sep 05 10:01:02 2007
Size of code: 667136
Size of initialized data: 113664
Size of uninitialized data: 2048

For gcc the output is:
d:\lcc\gp>pedump /summary gpgcc.exe
gpgcc.exe 1582964 bytes, linked Wed Sep 05 10:03:10 2007
Size of code: 841216
Size of initialized data: 17408
Size of uninitialized data: 2048

I would be moderately unsurprised to discover that the difference here
was down to optimsation and linkage flags.
Optimization was -O2
Linkage has no effect since the utility reads the effective size
of the code segment from the executable. Those are NOT file sizes.

But I compiled another program proposed by a gcc user and the result
was the same. See my other messages in this thread.

jacob
Sep 5 '07 #102
Mark McIntyre wrote:
On Wed, 05 Sep 2007 17:06:46 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>The gcc team, of several dozens specialist, supported by RedHat Corp,
IBM and other BIG names in the industry obtains surely a better compiler
than a single developer not supported by anyone!

FYI, boasting is extremely unattractive, and highly unlikely to raise
anyone's opinion of you...
It would be surprising if ANYTHING I say would please you Mr.

Anyway... forget it.
Sep 5 '07 #103
On Wed, 05 Sep 2007 20:37:18 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>Optimization was -O2
Which means nothing - the strategy used by gcc and lcc-win32 could be
radically different.
>Linkage has no effect since the utility reads the effective size
of the code segment from the executable.
And what if one compiler inlines library functions for speed purposes,
whereas the other dynamically links them ?

In any events this is all wildly off topic. Plus executable size is
not a metric for quality. If it were, I could write a _really_ top
quality compiler in one line of shell script

touch `ls -1 $1 | awk -F. '{print $1}'` && chmod +x `ls -1 $1 | awk
-F. '{print $1}'`

:-)
--
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
Sep 5 '07 #104
On Wed, 05 Sep 2007 20:38:09 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>Mark McIntyre wrote:
>On Wed, 05 Sep 2007 17:06:46 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>>The gcc team, of several dozens specialist, supported by RedHat Corp,
IBM and other BIG names in the industry obtains surely a better compiler
than a single developer not supported by anyone!

FYI, boasting is extremely unattractive, and highly unlikely to raise
anyone's opinion of you...

It would be surprising if ANYTHING I say would please you Mr.
As it happens you have sometimes posted something that I've been quite
happy with. When you say something that isn't either boastful,
insulting, offtopic or incorrect, I enter that state. It helps if its
correct and to the point, from where you are, all directions are up.

--
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
Sep 5 '07 #105
Mark McIntyre wrote:
On Wed, 05 Sep 2007 20:37:18 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>Optimization was -O2

Which means nothing - the strategy used by gcc and lcc-win32 could be
radically different.
>Linkage has no effect since the utility reads the effective size
of the code segment from the executable.

And what if one compiler inlines library functions for speed purposes,
whereas the other dynamically links them ?
I said that "lcc-win generates small executable"
CB Falconer said that that wasn't true.

I proved that it is true.

Now you start arguing that:
executable size is
not a metric for quality.
OK. I do not argue against that. I wanted to prove that what I said
was right, that's all. Lcc-win generates small executables.
Sep 5 '07 #106
On Wed, 05 Sep 2007 21:15:07 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>Mark McIntyre wrote:
>And what if one compiler inlines library functions for speed purposes,
whereas the other dynamically links them ?
I said that "lcc-win generates small executable"
You said "Generates very small programs."
>CB Falconer said that that wasn't true.
CBF said "I find that code generated by gcc is significantly smaller."
>I proved that it is true.
Actually, you attempted to show that the code segment of the
executable was more compact, and created a fuss when people went back
to the size of the executable.

And in any events All you did was show some file and machinecode
sizes. "Small" compared to what? Borland Turbo C made _much_ smaller
executables.
>OK. I do not argue against that. I wanted to prove that what I said
was right, that's all. Lcc-win generates small executables.
You wanted to trumpet this as a benefit of lcc-win32 - be honest!
--
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
Sep 5 '07 #107
On Sep 5, 9:49 am, CBFalconer <cbfalco...@yahoo.comwrote:
Amazing claim. I find that code generated by gcc is significantly
smaller.
Who cares how small the generated code is? I'm more
concerned with:
- correctness
- speed

For example, the compiler I use does things like
unrolling loops and inlining functions to produce
faster code; obviously this increases the code size.

Sep 5 '07 #108
Old Wolf wrote:
On Sep 5, 9:49 am, CBFalconer <cbfalco...@yahoo.comwrote:
>Amazing claim. I find that code generated by gcc is significantly
smaller.

Who cares how small the generated code is? I'm more
concerned with:
- correctness
- speed

For example, the compiler I use does things like
unrolling loops and inlining functions to produce
faster code; obviously this increases the code size.
Speed is related to code size. The bulkier code takes longer
to load into the CPU, slowing down the program.
Sep 5 '07 #109
In article <46***********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:
>Old Wolf wrote:
>Who cares how small the generated code is? I'm more
concerned with:
- correctness
- speed
>For example, the compiler I use does things like
unrolling loops and inlining functions to produce
faster code; obviously this increases the code size.
>Speed is related to code size. The bulkier code takes longer
to load into the CPU, slowing down the program.
That's an... uhhh... "interesting"... claim. Where-ever did you
pick it up? And was it part of a set of interesting claims or
was there just the one available? I would take it apart to see
what makes it tick, but I'm not sure I'd be able to get it back
together again afterwards, so I'll refrain...
--
Okay, buzzwords only. Two syllables, tops. -- Laurie Anderson
Sep 6 '07 #110
jacob navia wrote:
Old Wolf wrote:
>Who cares how small the generated code is? I'm more
concerned with:
- correctness
- speed

For example, the compiler I use does things like
unrolling loops and inlining functions to produce
faster code; obviously this increases the code size.

Speed is related to code size. The bulkier code takes longer
to load into the CPU, slowing down the program.
Wow! Just... Wow!

Have you ever heard of loop unrolling? loop fission? loop tiling?
loop peeling? software pipelining? code inlining? (To name a few.)

Are you aware that the straight-forward matrix multiply implementation
is very inefficient on modern CPUs with multi-level cache hierarchies
and complex pipelines?

http://gala.univ-perp.fr/~dparello/p..._awareness.pdf
Sep 6 '07 #111
Spoon wrote:
jacob navia wrote:
>Old Wolf wrote:
>>Who cares how small the generated code is? I'm more
concerned with:
- correctness
- speed

For example, the compiler I use does things like
unrolling loops and inlining functions to produce
faster code; obviously this increases the code size.

Speed is related to code size. The bulkier code takes longer
to load into the CPU, slowing down the program.

Wow! Just... Wow!

Have you ever heard of loop unrolling? loop fission? loop tiling?
loop peeling? software pipelining? code inlining? (To name a few.)
Many of those "optimizations" have the opposite effect.
because memory speed ahd code loading slow down the
machine. Read something about it if you like. In
any case here is not the right forum to discuss this.

Take a book in modern compiler design and read about loop
unrolling and its drawbacks.
Are you aware that the straight-forward matrix multiply implementation
is very inefficient on modern CPUs with multi-level cache hierarchies
and complex pipelines?

http://gala.univ-perp.fr/~dparello/p..._awareness.pdf
Sep 6 '07 #112
Spoon wrote:
>
http://gala.univ-perp.fr/~dparello/p..._awareness.pdf
That article has nothing to do with the subject we are discussing
(code size) but all the article is about improving the program by
reducing memory bandwidth!

Well, a smaller program (other conditions being equal) improves memory
bandwidth. That is all I am saying.
Sep 6 '07 #113
Spoon said:
jacob navia wrote:
<snip>
>Speed is related to code size. The bulkier code takes longer
to load into the CPU, slowing down the program.

Wow! Just... Wow!

Have you ever heard of loop unrolling? loop fission? loop tiling?
loop peeling? software pipelining? code inlining? (To name a few.)
Actually, I hadn't heard of some of those. :-) But others, of course, I
have heard of. And yes, they're relevant (or at least, I presume the
ones I haven't heard of are as relevant as the ones I have heard of) -
***BUT*** there is a "but". Here it comes.

But... Mr Navia is not entirely mistaken. Code size /can/ have a
negative effect on speed.

Let's take one of the things you mention that I do happen to have heard
of - loop unrolling. For those who might not know what it is, loop
unrolling is a technique for reducing the number of jumps in a loop.
For example, an optimiser might turn this:

for(i = 2; i < 39; i++)
{
zog(i);
}

into this:

i = 2;
while(i < 37)
{
zog(i++); zog(i++); zog(i++); zog(i++); zog(i++); zog(i++); zog(i++);
}
zog(i++);
zog(i++);

which will save - oh, how many is it? I make it 32 jump instructions
(+/-!). And, although it looks like there are more function calls and
increments, that's merely a matter of appearance. The zog function is
called 37 times in each case, and i is incremented 37 times in each
case. (If addition is cheaper than increment, the optimiser might even
unroll it using zog(i), zog(i + 1), zog(i + 2), etc, with an i += 7
just inside the loop's closing brace.)

If you scale that up sufficiently, you might be seeing the makings of a
significant speed economy.

The trouble is that, by the time you've scaled it up sufficiently, you
might just have a lump of code that's too big to fit conveniently into
the memory reserved for this program by the system, and this can have a
*negative* impact on performance, as code is swapped in and out.

Of course, the hardware guys are aware of this, and no doubt some of
them have found solutions - but we can't guarantee - at least, not here
in comp.lang.c - that we're running on suitably clever hardware.

So in fact we *don't know* whether the unrolled loop will improve
performance or harm it. The only way to find out is to measure. And
naturally the measurement is highly specific to the conditions under
which the measurement is taken (hardware, OS if any, processor load,
the compiler, its switch settings, etc etc).

It has often been said in comp.lang.c: "Measure, measure, measure." But
that's wrong. It should be "Measure, measure, measure, measure,
measure, measure, measure!"

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Sep 6 '07 #114
On Sep 5, 8:21 am, r...@hoekstra-uitgeverij.nl (Richard Bos) wrote:
Sherm Pendley <spamt...@dot-app.orgwrote:
r...@hoekstra-uitgeverij.nl (Richard Bos) writes:
Dev-C++, then. Unlike either of the ones mentioned by the
OP, it is both free (in the sense of not having to pay for
it) and free (in the sense of not shackling you into its
own preferred way of creating programs), though not Frea
(in the sense of chaining you to a Gnu licence, as gcc
does). It's a pretty small download, as well. And it does
both C _and_ C++ (though not, AFAIK, C/C++).
The GPL is only relevant if your app includes some or all of
the source code of a GPL'd app, as-is or modified.
Wrong. The GPL is relevant as long as lawyers exist to make a
quick buck out of FUD.
Yes. The problem is not always what the authors intend as
restrictions, but rather how your company's lawyers interpret
the wording in their license. In practice, I'm sure that you'll
never have the slightest legal problems using g++ for
development, but corporate lawyers often have problems getting
their heads around the idea that the authors of the license
might actually be honest people, and are not out to trick you
somehow.
The GPL has *zero* impact on the output of a GPL'd app. Your
app is not somehow "infected" by the simple act of editing
your own code with a GPL'd IDE, or compiling it with a GPL'd
compiler. The idea that it would (or can) be is pure FUD.
And FUD is still - unfortunately - a relevant factor in
business decisions. Because if you want to sell your software,
you cannot afford to doubt whether it would be legal.
There's no doubt in my mind. But then, I understand a little
bit about how such software is developed. It can be difficult
to convince white collar management that the FUD is just that,
FUD.
For example, I note that you do not mention linking in GPL'd
libraries.
Don't do that, or you do "contaminate" your product. That's why
gcc's librarys are LGPL, and not GPL---so that you can link
against them without contamination.

At one time, there was a problem concerning templates, inline
functions and even #define's; the LGPL didn't really make clear
that this wasn't contamination. Presumably, a few #defines
would have been covered under the "fair use" rules, or something
like that, but it was a problem with templates in C++---many
librarys are only header files (so you are, in fact,
incorporating source code into your application, and not just
linking against a library). I'm fairly sure that this was never
the intent of the authors of the C++ standard library, but it
wasn't really clear in the wording of the LGPL. I think that
the libstdc++ comes with an ammended LGPL now, however, which
explicitly says that including a header counts the same as
linking against the library, and thus doesn't contaminate
anything.

With regards to libraries in general: make sure that they are
LGPL, and not just GPL, and don't modify them in any way, and
you should have no problems. (In general, for any third party
libraries, LGPL'ed or commercial, it's probably best to keep the
library is a separate, write protected directory tree, on its
own.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Sep 6 '07 #115
On Sep 4, 10:00 am, Chris Hills <ch...@phaedsys.orgwrote:
In article <lnlkbnee3c....@nuthaus.mib.org>, Keith Thompson
<ks...@mib.orgwrites
Chris Hills <ch...@phaedsys.orgwrites:
[...]
Gcc is not ISO C99 compliant either. (And I think less so than the
MS compilers these days.)
Really? My impression, based entirely on what I've read here, is that
MS has expressed no interest in supporting C99. Do you have better
information?
PJP said (I think here) that MSVC was now C99 compliant as MS had got
religion in the last couple of years and don standards compliant.
PJP certainly knows the situation better than I do, but my
impression is that currently, MS does not offer a C
compiler---only a C++ compiler which will compile C for reasons
of backwards compatibility. Because the C is only for reasons
of backwards compatibility, there is no effort to track the more
recent standards.

MS has "got religion" concerning standard C++ in the last few
years. Like most people who get religion, however, it can be
somewhat selective. Still, with a few exceptions (e.g. export),
they do try to track the C++ standard.
Actually MS is very actively doing a lot in the standards
world (usually via ECMA and ruffling a few feathers in ISO)
They're very active in the C++ standardization effort. And
whatever their underlying motives might be, they've been very
good about it: not just talking, but also listening, and
investing significant effort.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Sep 6 '07 #116
On Sep 3, 8:25 pm, Chris Hills <ch...@phaedsys.orgwrote:
In article <1188694481.599815.259...@d55g2000hsg.googlegroups .com>,
Nimmi Srivastav <nimmi_srivas...@yahoo.comwrites
Apologies if my cross posting has offended anyone....
For a pure hobbyist C/C++ programmer, who wants to develop
applications to run on Windows, what would be a better choice to
install: Visual C++ Express 2005 Edition or lcc-win32? Does anyone
have any opinion to share?
No contest. Visual C++ Express 2005.
I agree, but..
Why?
[...]
In short it is VERY easy for a novice to set up and use with minimum
fuss.
I'm not so sure about that. I had to download and install some
essential parts of the library separately, and play around some
with my environment so that the compiler would find them.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Sep 6 '07 #117
In article <11*********************@g4g2000hsf.googlegroups.c om>, James
Kanze <ja*********@gmail.comwrites
>On Sep 4, 10:00 am, Chris Hills <ch...@phaedsys.orgwrote:
>In article <lnlkbnee3c....@nuthaus.mib.org>, Keith Thompson
<ks...@mib.orgwrites
>Chris Hills <ch...@phaedsys.orgwrites:
[...]
Gcc is not ISO C99 compliant either. (And I think less so than the
MS compilers these days.)
>Really? My impression, based entirely on what I've read here, is that
MS has expressed no interest in supporting C99. Do you have better
information?
>PJP said (I think here) that MSVC was now C99 compliant as MS had got
religion in the last couple of years and don standards compliant.

PJP certainly knows the situation better than I do,
I will have to check that I am quoting him correctly too
but my
impression is that currently, MS does not offer a C
compiler---only a C++ compiler which will compile C for reasons
of backwards compatibility
Yes.
>. Because the C is only for reasons
of backwards compatibility, there is no effort to track the more
recent standards.
I think that they do track C99 to some extent as they use C99 libraries.
>MS has "got religion" concerning standard C++ in the last few
years. Like most people who get religion, however, it can be
somewhat selective.
Oh yes....
>Actually MS is very actively doing a lot in the standards
world (usually via ECMA and ruffling a few feathers in ISO)

They're very active in the C++ standardization effort. And
whatever their underlying motives might be,
Aye there's the rub... See their efforts with ECMA (Java script, C# .
C++/CLI, Cli etc) also the "secure" libraries.
>they've been very
good about it: not just talking, but also listening, and
investing significant effort.
Yes.... MS will be the new standard.....

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

Sep 6 '07 #118
In article <11*********************@g4g2000hsf.googlegroups.c om>, James
Kanze <ja*********@gmail.comwrites
>On Sep 4, 10:00 am, Chris Hills <ch...@phaedsys.orgwrote:
>In article <lnlkbnee3c....@nuthaus.mib.org>, Keith Thompson
<ks...@mib.orgwrites
>Chris Hills <ch...@phaedsys.orgwrites:
[...]
Gcc is not ISO C99 compliant either. (And I think less so than the
MS compilers these days.)
>Really? My impression, based entirely on what I've read here, is that
MS has expressed no interest in supporting C99. Do you have better
information?
>PJP said (I think here) that MSVC was now C99 compliant as MS had got
religion in the last couple of years and don standards compliant.

PJP certainly knows the situation better than I do, but my
impression is that currently, MS does not offer a C
compiler---only a C++ compiler which will compile C for reasons
of backwards compatibility. Because the C is only for reasons
of backwards compatibility, there is no effort to track the more
recent standards.

I found the item...
PJP said... 10 May 2006 13:32:07 however I think MS have improved on
the C99 since then. Certainly they have kept pace with gcc.

////////////////////////
But gcc got 'ligion somewhere along the way (as has Microsoft more
recently). Today, there are three top compilers for C/C++ conformance:

COMPILER C89 C95 C99 C++

EDG excellent excellent excellent excellent
VC++ excellent very good so so very good
gcc excellent very good so so very good

And there's a significant gap between these and whatever's fourth.

Note that, qualitatively at least, VC++ and gcc are in about the same
league.
/////////////////////////////////

Incidentally in the embedded world most of the top compilers use the EDG
front end as I am sure you all knew.

Interestingly in the same thread 09 May 2006 19:58:15 he also said
//////////////////////////////////
Yes, it does. But as I keep repeating, *every compiler I've ever used
does exactly the same thing.* People who know the value of writing
portable code know to follow standards. Those who don't simply don't,
and mostly don't care, and mostly benefit from using the nonstandard
extensions. So what's the big deal?
////////////////////////////

So an interesting take on portability from some one who earns his living
writing portable code......

If you are a novice just wanting to write windows programs for yourself
(or even commercially) VC++ is a good idea.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Sep 6 '07 #119
Chris Hills wrote:
James Kanze <ja*********@gmail.comwrites
>Chris Hills <ch...@phaedsys.orgwrote:
.... snip ...
>>
>>Actually MS is very actively doing a lot in the standards
world (usually via ECMA and ruffling a few feathers in ISO)

They're very active in the C++ standardization effort. And
whatever their underlying motives might be,

Aye there's the rub... See their efforts with ECMA (Java script,
C# . C++/CLI, Cli etc) also the "secure" libraries.
>they've been very good about it: not just talking, but also
listening, and investing significant effort.

Yes.... MS will be the new standard.....
This needs stamping as sarcasm. Nobody sane should accept MS
efforts to divert the normal standardization efforts, especially
ISO standards.

F'ups set to eliminate silly cross-posting.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Sep 6 '07 #120
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
>rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
Dev-C++, then. Unlike either of the ones mentioned by the OP, it is both
free (in the sense of not having to pay for it) and free (in the sense
of not shackling you into its own preferred way of creating programs),
though not Frea (in the sense of chaining you to a Gnu licence, as gcc
does). It's a pretty small download, as well. And it does both C _and_
C++ (though not, AFAIK, C/C++).

For example, I note that you do not mention linking in GPL'd libraries.
I didn't mention it because it's not relevant to the case I made. Your post
said that simply compiling your code with GCC would "chain you to a Gnu
license." It won't.

What's more, your so-called "advice" above is completely nonsensical. The
Bloodshed Dev-C++ IDE is GPL'd, and uses either the MinGW or Cygwin bundles
of GCC. You're advising the OP to avoid GPL'd IDEs and GCC, and use a GPL'd
IDE and GCC instead.

<http://www.bloodshed.net/devcpp.html>

You clearly have no idea what you're talking about here.

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
Sep 6 '07 #121
jacob navia <ja***@jacob.remcomp.frwrites:
Spoon wrote:
>http://gala.univ-perp.fr/~dparello/p..._awareness.pdf

That article has nothing to do with the subject we are discussing
(code size) but all the article is about improving the program by
reducing memory bandwidth!

Well, a smaller program (other conditions being equal) improves memory
bandwidth. That is all I am saying.
Other conditions are hardly ever equal. The only way to be sure is to
measure. Have you measured? (I haven't, but I'm not making any
claims.)

--
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"
Sep 6 '07 #122
James Kanze <ja*********@gmail.comwrites:
[...]
PJP certainly knows the situation better than I do, but my
impression is that currently, MS does not offer a C
compiler---only a C++ compiler which will compile C for reasons
of backwards compatibility. Because the C is only for reasons
of backwards compatibility, there is no effort to track the more
recent standards.
[...]

Hmm. It seems to me that a compiler that compiles C, for whatever
reasons, is a C compiler. Tracking recent standards is certainly an
issue, though.

--
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"
Sep 6 '07 #123
On Thu, 06 Sep 2007 01:34:37 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>Speed is related to code size.
Only for extremely trivial programmes.
>The bulkier code takes longer
to load into the CPU, slowing down the program.
Thats a truly bizarre claim, expressed in that way.

What I presume you mean is "less instructions = faster code". Even
that is nonsense - twenty expensive instructions may be much slower
than a million cheap ones. And you ignore the side-effects of
cacheing and so forth.

--
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
Sep 6 '07 #124
James Kanze <ja*********@gmail.comwrote:
On Sep 5, 8:21 am, r...@hoekstra-uitgeverij.nl (Richard Bos) wrote:
Sherm Pendley <spamt...@dot-app.orgwrote:
The GPL is only relevant if your app includes some or all of
the source code of a GPL'd app, as-is or modified.
Wrong. The GPL is relevant as long as lawyers exist to make a
quick buck out of FUD.

Yes. The problem is not always what the authors intend as
restrictions, but rather how your company's lawyers interpret
the wording in their license. In practice, I'm sure that you'll
never have the slightest legal problems using g++ for
development, but corporate lawyers often have problems getting
their heads around the idea that the authors of the license
might actually be honest people, and are not out to trick you
somehow.
Yes, that's precisely what I meant.
For example, I note that you do not mention linking in GPL'd
libraries.

Don't do that, or you do "contaminate" your product. That's why
gcc's librarys are LGPL, and not GPL---so that you can link
against them without contamination.
You know that, and I know that, but what's relevant is that the lawyers
aforementioned do not know and probably do not want to know that.

Richard
Sep 7 '07 #125
In article <46***************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites
>Chris Hills wrote:
>James Kanze <ja*********@gmail.comwrites
>>Chris Hills <ch...@phaedsys.orgwrote:
... snip ...
>>>
Actually MS is very actively doing a lot in the standards
world (usually via ECMA and ruffling a few feathers in ISO)

They're very active in the C++ standardization effort. And
whatever their underlying motives might be,

Aye there's the rub... See their efforts with ECMA (Java script,
C# . C++/CLI, Cli etc) also the "secure" libraries.
>>they've been very good about it: not just talking, but also
listening, and investing significant effort.

Yes.... MS will be the new standard.....

This needs stamping as sarcasm.
It was but unfortunately... becoming a reality :-(
Nobody sane should accept MS
efforts to divert the normal standardization efforts, especially
ISO standards.
I agree totally The problem is ISO made such a mess of C99 The other
problem is that the way it is being done it is not Ms per say by ECMA
and other TR's that are being used.

They are, in my view, using the standards apparatus to subvert things
their way. Very well executed I give them that as they appear to be
succeeding.

I love Bill Gates.... How about a nice game of chess at the Cherry Tree
Cafe, Winston?

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

Sep 7 '07 #126
On Mon, 03 Sep 2007 20:29:31 +0200, jacob navia wrote:
Army1987 wrote:
>And in stdint.h you have (except for the comments):
#ifndef __stdint_h__

#define __stdint_h__
[snip]

What's matter with you?
The most useful thing to do when you are told of a bug is to fix
it. Certainly adding pairs of parentheses, or rewriting
-2147483648 as (-2147483647 - 1), would take much, much shorter
than clutching at straws the way you're doing. What's the point of
that?
Just to show you how easy it is, here is a corrected version of
your stdint.h, it should conform to the C99 standard unless I did
some silly mistake.

#ifndef __stdint_h__
#define __stdint_h__
typedef signed char int8_t;
typedef unsigned char uint8_t;
#define INT8_C(a) a
#define UINT8_C(a) a
typedef short int16_t;
typedef unsigned short uint16_t;
#define INT16_C(a) a
#define UINT16_C(a) a
typedef int int32_t;
#define INT32_C(a) (a)
typedef unsigned int uint32_t;
#define UINT32_C(a) (a##U)
typedef long long int64_t;
#define INT64_C(a) (a##LL)
typedef unsigned long long uint64_t;
#define UINT64_C(a) (a##ULL)

typedef signed char int_least8_t;
typedef unsigned char uint_least8_t;
typedef short int_least16_t;
typedef unsigned short uint_least16_t;
typedef int int_least32_t;
typedef unsigned int uint_least32_t;
typedef long long int_least64_t;
typedef unsigned long long uint_least64_t;

#define INTMAX_C(a) (a##LL)
#define UINTMAX_C(a) (a##ULL)

typedef char int_fast8_t;
typedef unsigned char uint_fast8_t;
typedef int int_fast16_t;
typedef unsigned int uint_fast16_t;
typedef int int_fast32_t;
typedef unsigned int uint_fast32_t;
typedef long long int_fast64_t;
typedef unsigned long long uint_fast64_t;

typedef int intptr_t;
typedef unsigned int uintptr_t;
typedef long long intmax_t;
typedef unsigned long long uintmax_t;

#define INT8_MIN (-128)
#define INT16_MIN (-32768)
#define INT32_MIN (-2147483647 - 1)
#define INT64_MIN (-9223372036854775807LL - 1)
#define INT8_MAX 127
#define INT16_MAX 32767
#define INT32_MAX 2147483647
#define INT64_MAX 9223372036854775807LL

#define UINT8_MAX 255
#define UINT16_MAX 65535
#define UINT32_MAX 4294967295U
#define UINT64_MAX 18446744073709551615ULL

#define INT_LEAST8_MIN (-128)
#define INT_LEAST16_MIN (-32768)
#define INT_LEAST32_MIN (-2147483647 - 1)
#define INT_LEAST64_MIN (-9223372036854775807LL - 1)

#define INT_LEAST8_MAX 127
#define INT_LEAST16_MAX 32767
#define INT_LEAST32_MAX 2147483647
#define INT_LEAST64_MAX 9223372036854775807LL

#define UINT_LEAST8_MAX 255
#define UINT_LEAST16_MAX 65535
#define UINT_LEAST32_MAX 4294967295U
#define UINT_LEAST64_MAX 18446744073709551615ULL

#define INT_FAST8_MIN (-128)
#define INT_FAST16_MIN (-2147483647 - 1)
#define INT_FAST32_MIN (-2147483647 - 1)
#define INT_FAST64_MIN (-9223372036854775807LL - 1)

#define INT_FAST8_MAX 127
#define INT_FAST16_MAX 2147483647
#define INT_FAST32_MAX 2147483647
#define INT_FAST64_MAX 9223372036854775807LL

#define UINT_FAST8_MAX 255
#define UINT_FAST16_MAX 4294967295U
#define UINT_FAST32_MAX 4294967295U
#define UINT_FAST64_MAX 18446744073709551615ULL

#define INTPTR_MIN INT32_MIN
#define INTPTR_MAX INT32_MAX
#define UINTPTR_MAX UINT32_MAX

#define INTMAX_MIN INT64_MIN
#define INTMAX_MAX INT64_MAX
#define UINTMAX_MAX UINT64_MAX

#define SIG_ATOMIC_MIN (-2147483647 - 1)
#define SIG_ATOMIC_MAX 2147483647

#define SIZE_MAX 0xffffffff
#define PTRDIFF_MIN INT32_MIN
#define PTRDIFF_MAX INT32_MAX

#if __STDC__ != 1 /* or whatever */
#define RSIZE_MAX INT32_MAX
#endif

#define WCHAR_MAX 65535
#define WCHAR_MIN 0
#define WINT_MAX 65535
#define WINT_MIN 0

#endif

Understanding all the changes I made is left as an exercise.

--
Army1987 (Replace "NOSPAM" with "email")
If you're sending e-mail from a Windows machine, turn off Microsoft's
stupid “Smart Quotes” feature. This is so you'll avoid sprinkling garbage
characters through your mail. -- Eric S. Raymond and Rick Moen

Sep 7 '07 #127
Mark McIntyre <ma**********@spamcop.netwrites:
On Thu, 06 Sep 2007 01:34:37 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>>Speed is related to code size.

Only for extremely trivial programmes.
>>The bulkier code takes longer
to load into the CPU, slowing down the program.

Thats a truly bizarre claim, expressed in that way.

What I presume you mean is "less instructions = faster code". Even
that is nonsense - twenty expensive instructions may be much slower
than a million cheap ones. And you ignore the side-effects of
cacheing and so forth.
Actually no he doesn't. Any sane rendering of smaller=faster indicates
that the smaller the code the more can be cached. It further leads, in
memo critical situations, to less swapping. But like all things like
this nothing is black and white. Could unwrapping a loop lead to faster
code? Or will it break some kind of CPU specific cache boundary? It
could be argued to the death.
Sep 7 '07 #128
Richard wrote:
Mark McIntyre <ma**********@spamcop.netwrites:
>On Thu, 06 Sep 2007 01:34:37 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>>Speed is related to code size.
Only for extremely trivial programmes.
>>The bulkier code takes longer
to load into the CPU, slowing down the program.
Thats a truly bizarre claim, expressed in that way.

What I presume you mean is "less instructions = faster code". Even
that is nonsense - twenty expensive instructions may be much slower
than a million cheap ones. And you ignore the side-effects of
cacheing and so forth.

Actually no he doesn't. Any sane rendering of smaller=faster indicates
that the smaller the code the more can be cached. It further leads, in
memo critical situations, to less swapping. But like all things like
this nothing is black and white. Could unwrapping a loop lead to faster
code? Or will it break some kind of CPU specific cache boundary? It
could be argued to the death.
The "subject" of this thread is "Faulty claims for lcc-win32".

Why?

Because CBFalconer said that it was a lie that I produced small
programs. He said that gcc produced even smaller ones and changed
the thread name as you can see.

Then, I answered that it is true, and produced the results of my own
benchmarks, but I used an old version of gcc.

They told me, that's an outdated version. Someone said that he had
compiled the "lua" software with gcc and produced a small executable
of 132K. I downloaded that, and compiled it to an executable of
almost the same size.

OK, that did not work. Then, since I said that lcc-win32 produces small
executables, others begun saying to me that small programs are slower
anyway. I told them that that is not the case, small programs load
into the cache faster and make for less i/o to RAM.

And now we are here. I am sure that if I say:

"bugs are bad"

somebody would wake up and try to advance in the hierarchy here by
telling me:

Nonsense!
You do not know what you are talking about!
Sep 7 '07 #129
Jacob Navia wrote:
[...] Then, since I said that lcc-win32 produces small
executables, others begun saying to me that small programs are slower
anyway. I told them that that is not the case, small programs load
into the cache faster and make for less i/o to RAM.
You claimed, and I quote verbatim:

"Speed is related to code size. The bulkier code takes longer to load
into the CPU, slowing down the program."

I do not dispute the first statement. (Because it is true.)

Do you agree that your second statement is equivalent to the following
proposition?

BEGIN PROPOSITION

Given two executables E1 and E2, performing the same computation,
if codesize(E1) < codesize(E2) then runtime(E1) < runtime(E2)

END PROPOSITION

(The proposition is false, because it is trivial to find (E1, E2) pairs
where codesize(E1) < codesize(E2) and runtime(E1) runtime(E2))
Sep 7 '07 #130
Jacob Navia wrote:
Spoon wrote:
>>
http://gala.univ-perp.fr/~dparello/p..._awareness.pdf

That article has nothing to do with the subject we are discussing
(code size) but all the article is about improving the program by
reducing memory bandwidth!
I'll give you the benefit of the doubt, and assume you didn't read the
paper. Which is a shame, because you'd learn something.

This paper discusses how to improve a naive matrix multiply
implementation. The naive implementation is very compact.

do i=1, Ni
do k=1, Nk
R=b(k,i)
do j=1, Nj
c(j,i)=c(j,i)+R*a(j,k)
enddo
enddo
enddo

The optimized version is *much* larger in terms of code size, but runs
13.56 times faster (on a given CPU, of course).

They improved the performance by adding NOPs.

I'd like to see you explain that.
Well, a smaller program (other conditions being equal) improves memory
bandwidth. That is all I am saying.
Is it now?
Sep 7 '07 #131
Richard Heathfield wrote:
Spoon said:
>Have you ever heard of loop unrolling? loop fission? loop tiling?
loop peeling? software pipelining? code inlining? (To name a few.)

Actually, I hadn't heard of some of those. :-)
Wikipedia appears to be a good starting point.
http://en.wikipedia.org/wiki/Categor..._optimizations
But... Mr Navia is not entirely mistaken. Code size /can/ have a
negative effect on speed.
I never disputed that statement for the simple reason that it is true!

:-)
Sep 7 '07 #132

CBFalconer wrote:
>Richard Bos wrote:
>Sherm Pendley wrote:
>>The GPL has *zero* impact on the output of a GPL'd app. Your app
is not somehow "infected" by the simple act of editing your own
code with a GPL'd IDE, or compiling it with a GPL'd compiler. The
idea that it would (or can) be is pure FUD.

And FUD is still - unfortunately - a relevant factor in business
decisions. Because if you want to sell your software, you cannot
afford to doubt whether it would be legal. For example, I note
that you do not mention linking in GPL'd libraries.

However most libraries, such as the c-library, are released under
the more liberal GPLL ? license, which allows use without releasing
source. The exceptions are such specialized things as my hashlib,
which remain under GPL. The only FUD is that which you are
raising.
Concerning the statement "if you want to sell your software,
you cannot afford to doubt whether it would be legal", there
are over 100 million smartphones by Nokia, Siemens, Panasonic
and Samsung running GCC-compiled applications on the Symbian
OS, and and Sony PlayStation and Sega Dreamcast both use
software compiled with GCC. I doubt that they would be using
GCC to create proprietary software if the legality of doing
so was in question.
Back to lurking for me. (Thanks, CBF, for the suggestion!)

Also see:
[ http://www.gnu.org/licenses/gpl-faq....eGPLToolsForNF ]:

"Can I use GPL-covered editors such as GNU Emacs to develop
non-free programs? Can I use GPL-covered tools such as GCC
to compile them?

"Yes, because the copyright on the editors and tools does
not cover the code you write. Using them does not place
any restrictions, legally, on the license you use for
your code."
[ http://en.wikipedia.org/wiki/GNU_Compiler_Collection ]:

"In addition to its use in free software, GCC [GNU Compiler
Collection] is widely deployed as a tool in commercial and
closed development environments."
--
Guy Macon
<http://www.guymacon.com/>

Sep 7 '07 #133
jacob navia wrote:
>
.... snip ...
>
The "subject" of this thread is "Faulty claims for lcc-win32".

Why?

Because CBFalconer said that it was a lie that I produced small
programs. He said that gcc produced even smaller ones and changed
the thread name as you can see.
I never accused you, or anybody, of lieing. This is a nasty evil
accusation on your part. I did say the statement was wrong. A
prompt apology is needed.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Sep 7 '07 #134
CBFalconer wrote:
jacob navia wrote:
... snip ...
>The "subject" of this thread is "Faulty claims for lcc-win32".

Why?

Because CBFalconer said that it was a lie that I produced small
programs. He said that gcc produced even smaller ones and changed
the thread name as you can see.

I never accused you, or anybody, of lieing. This is a nasty evil
accusation on your part. I did say the statement was wrong. A
prompt apology is needed.
Look. I proved that it was right.
I compiled the LUA software that somebody of the gcc side
proposed and obtained a similar executable in size as gcc

This means that my statement wasn't wrong as you said.
Now, *I* must apologize?

OK. I apologize if you apologize for putting my statements
in doubt!

:-)

Let's keep cool Chuck

Sep 7 '07 #135
CBFalconer wrote:

I never accused you, or anybody, of lieing. This is a nasty evil
accusation on your part. I did say the statement was wrong. A
prompt apology is needed.

Can't you just ignore the guy? Post after post of bickering with the
idiot is not doing much for the group.


Brian
Sep 7 '07 #136
Default User wrote:
CBFalconer wrote:

>I never accused you, or anybody, of lieing. This is a nasty evil
accusation on your part. I did say the statement was wrong. A
prompt apology is needed.


Can't you just ignore the guy? Post after post of bickering with the
idiot is not doing much for the group.


Brian
Hi Brian

Didn't you know?

Only people whose opinion is something worth for me
can insult me. The others...

Sep 7 '07 #137
CBFalconer said:
jacob navia wrote:
>>
... snip ...
>>
The "subject" of this thread is "Faulty claims for lcc-win32".

Why?

Because CBFalconer said that it was a lie that I produced small
programs. He said that gcc produced even smaller ones and changed
the thread name as you can see.

I never accused you, or anybody, of lieing.
Indeed you didn't. (I checked.)
This is a nasty evil accusation on your part.
I don't think so, actually. In fact, I don't believe that Mr Navia knows
what "lie" means. Otherwise he would not use the word so freely.
I did say the statement was wrong. A prompt apology is needed.
Not a snowball's chance in Arizona, Chuck. Normal standards of civilised
behaviour don't apply to Mr Navia for some reason. The killfile is your
best bet.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Sep 7 '07 #138
Guy Macon wrote:
CBFalconer wrote:
>Richard Bos wrote:
>>Sherm Pendley wrote:

The GPL has *zero* impact on the output of a GPL'd app. Your app
is not somehow "infected" by the simple act of editing your own
code with a GPL'd IDE, or compiling it with a GPL'd compiler. The
idea that it would (or can) be is pure FUD.

And FUD is still - unfortunately - a relevant factor in business
decisions. Because if you want to sell your software, you cannot
afford to doubt whether it would be legal. For example, I note
that you do not mention linking in GPL'd libraries.

However most libraries, such as the c-library, are released under
the more liberal GPLL ? license, which allows use without releasing
source. The exceptions are such specialized things as my hashlib,
which remain under GPL. The only FUD is that which you are
raising.
.... snip ...
>
Back to lurking for me. (Thanks, CBF, for the suggestion!)
Hunh? I am confused. I have left everything you quoted.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Sep 8 '07 #139
In article <ln************@nuthaus.mib.org>, ks***@mib.org says...

[ ... ]
Hmm. It seems to me that a compiler that compiles C, for whatever
reasons, is a C compiler.
But does it qualify as a C compiler if it rejects a large percentage of
code written for the current standard?

--
Later,
Jerry.

The universe is a figment of its own imagination.
Sep 8 '07 #140
Jerry Coffin <jc*****@taeus.comwrites:
In article <ln************@nuthaus.mib.org>, ks***@mib.org says...

[ ... ]
>Hmm. It seems to me that a compiler that compiles C, for whatever
reasons, is a C compiler.

But does it qualify as a C compiler if it rejects a large percentage of
code written for the current standard?
Strictly speaking, no, but if it implements the C90 standard, I for
one am not going to say it's "not a C compiler".

--
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"
Sep 8 '07 #141
Jerry Coffin said:
In article <ln************@nuthaus.mib.org>, ks***@mib.org says...

[ ... ]
>Hmm. It seems to me that a compiler that compiles C, for whatever
reasons, is a C compiler.

But does it qualify as a C compiler if it rejects a large percentage
of code written for the current standard?
The support for C99 in the real world is such that the distinction
between "C90" and "C" is not a useful one.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Sep 8 '07 #142

CBFalconer wrote:
>Back to lurking for me. (Thanks, CBF, for the suggestion!)

Hunh? I am confused. I have left everything you quoted.
Sorry for being unclear. I was referring to the suggestion
you made in this post in comp.arch.embedded:

|
| Message-ID: <46***************@yahoo.com>
| Date: Thu, 06 Sep 2007 20:15:42 -0400
| From: CBFalconer <cb********@yahoo.com>
| Newsgroups: comp.arch.embedded
| Subject: Re: 16/32 bit processor for OS development
|
|
| Guy Macon wrote:
| >
| ... snip ...
| >
| To digress a bit from the original question...
| One interesting idea that I am just starting to explore is to run
| FreeBASIC under FreeDOS (It also runs under 32-bit Windows and
| Linux). What is most interesting about FreeBASIC is that it is
| written in FreeBASIC, thus making it easy for BASIC programmers
| to modify/extend the language. I am pretty good at assembly
| language and modern, structured BASICs, and can find my way
| around FORTH, but my C/C++ skills are something to be pitied,
| which means that extending or modifying the OS or the compiler
| tends to blow up in my face. :(
|
| Why don't you hang out on comp.lang.c for a while. That will
| probably lick your C abilities into shape quite quickly. We
| attempt to keep the discussions to portable things, i.e. standard
| C. You should rapidly learn who the idiots are.
|
| --
| Chuck F (cbfalconer at maineline dot net)
| Available for consulting/temporary embedded and systems.
| <http://cbfalconer.home.att.net>
|

--
Guy Macon
<http://www.guymacon.com/>

Sep 8 '07 #143
In article <nd******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites
>Jerry Coffin said:
>In article <ln************@nuthaus.mib.org>, ks***@mib.org says...

[ ... ]
>>Hmm. It seems to me that a compiler that compiles C, for whatever
reasons, is a C compiler.

But does it qualify as a C compiler if it rejects a large percentage
of code written for the current standard?

The support for C99 in the real world is such that the distinction
between "C90" and "C" is not a useful one.

The MISRA-C team has to make a decision: should it move from Referencing
C95 (9899:1990+A1+RC1+TC2) to referencing C99 for the next MISRA-C?

In the real world (especially embedded, safety-critical and
high-integrity circles) there are no C99 compilers in use as on
September 2007. There are a lot that are C95+.

Any thoughts from anyone involved in writing compilers? Either to the NG
or to my email address. Yes, I have asked most of the main embedded
compiler companies I have contacts for (about 15 of them so far) .

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

Sep 8 '07 #144
Chris Hills wrote:
Any thoughts from anyone involved in writing compilers? Either to the NG
or to my email address. Yes, I have asked most of the main embedded
compiler companies I have contacts for (about 15 of them so far) .
The problem is, nobody using C seems to care about C99 compliance. Or if
they do care, they keep it to themselves.

Digital Mars C is very close to C99 (not perfect), and C99 is what I use
when resolving issues of how things should work, but the demand for it
isn't there.

P.S. I consider demand for a feature being what people will actually pay
money for <g>. I get plenty of features asked for every day from paying
customers, and nobody asks for 100% C99 compliance.

P.P.S. DMC does implement C99 things like complex & imaginary floating
point numbers, VLAs, restrict, variadic macros, unicode, long longs,
long doubles, etc.

-----
Walter Bright
http://www.digitalmars.com C, C++, D programming language compilers
http://www.astoriaseminar.com Extraordinary C++
Sep 8 '07 #145
Chris Hills wrote:
>
.... snip ...
>
The MISRA-C team has to make a decision: should it move from
Referencing C95 (9899:1990+A1+RC1+TC2) to referencing C99 for
the next MISRA-C?

In the real world (especially embedded, safety-critical and
high-integrity circles) there are no C99 compilers in use as on
September 2007. There are a lot that are C95+.

Any thoughts from anyone involved in writing compilers? Either to
the NG or to my email address. Yes, I have asked most of the
main embedded compiler companies I have contacts for (about 15 of
them so far) .
Since the C99 standard is easily available, and the C90 is not, I
think MISRA should switch. Their recommended practices can be used
to eliminate C99 features that are not widely implemented. The GNU
C99 report should be an excellent guide.

F'ups set to eliminate silly crossposting.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Sep 8 '07 #146
In article <ft**************@phaedsys.demon.co.uk>,
Chris Hills <ch***@phaedsys.demon.co.ukwrote:
>In article <nd******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites
>>Jerry Coffin said:
>>In article <ln************@nuthaus.mib.org>, ks***@mib.org says...
Hmm. It seems to me that a compiler that compiles C, for whatever
reasons, is a C compiler.

But does it qualify as a C compiler if it rejects a large percentage
of code written for the current standard?

The support for C99 in the real world is such that the distinction
between "C90" and "C" is not a useful one.

The MISRA-C team has to make a decision: should it move from Referencing
C95 (9899:1990+A1+RC1+TC2) to referencing C99 for the next MISRA-C?

In the real world (especially embedded, safety-critical and
high-integrity circles) there are no C99 compilers in use as on
September 2007. There are a lot that are C95+.

Any thoughts from anyone involved in writing compilers? Either to the NG
or to my email address. Yes, I have asked most of the main embedded
compiler companies I have contacts for (about 15 of them so far) .
Comeau C99 and Dinkumware C99 lib have both been available for
many years on a number of mainstream platforms. Both companies
also do custom porting with a fairly fast turnaround, and at a
low cost, including to embedded platforms.

As a company involved with compilers, I would go with C99.
It is clear that that standard is in slo-mo, however, the standard
is real, is being adopted incrementally, and is the standard one
normally will get when requesting C from the standards orgs.
C99 will also get a prod as C++ compilers pick up C99 features
(as Comeau C++ has in some C++ modes like variadic macros, long long,
etc ) even if only library ones.

Since IMO MISRA-C is, um, shall I say cautious, I don't think C99
would be a set back to that line of approach.
--
Greg Comeau / 4.3.9 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Sep 8 '07 #147
On Sep 6, 12:56 pm, CBFalconer <cbfalco...@yahoo.comwrote:

[...]
This needs stamping as sarcasm. Nobody sane should accept MS
efforts to divert the normal standardization efforts, especially
ISO standards.
And that's loaded language. The ISO standard (for both C and
C++) is written by those who choose to participate. ISO sets
the rules. MS obviously participates for reasons of its own.
Just as do Sun, IBM and... myself. If you consider any
willingness to invest one's time in the standard an attempt at
diversion, then everyone working on it is diverting it. And
without them, there'd be no standard.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Sep 9 '07 #148
On Sep 6, 9:29 pm, Keith Thompson <ks...@mib.orgwrote:
James Kanze <james.ka...@gmail.comwrites:
[...]PJP certainly knows the situation better than I do, but my
impression is that currently, MS does not offer a C
compiler---only a C++ compiler which will compile C for reasons
of backwards compatibility. Because the C is only for reasons
of backwards compatibility, there is no effort to track the more
recent standards.
[...]
Hmm. It seems to me that a compiler that compiles C, for whatever
reasons, is a C compiler.
What if it only compiles a subset of C?
Tracking recent standards is certainly an issue, though.
Perhaps I didn't really express myself clearly. From what I
understand (and I could easily be mistaken---I don't follow
developments under Windows very closely), Microsoft only
commercializes a C++ compiler system. That compiler system does
compile some C, for reasons of backwards compatibility, or
interfacing existing systems, or whatever, but it is not sold as
a conforming C compiler, and it makes no attempt to be
conforming. In sum, it's like the bundled C compiler in the
final versions of Sun OS 4.x.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Sep 9 '07 #149
James Kanze <ja*********@gmail.comwrites:
On Sep 6, 9:29 pm, Keith Thompson <ks...@mib.orgwrote:
>James Kanze <james.ka...@gmail.comwrites:
[...]PJP certainly knows the situation better than I do, but my
impression is that currently, MS does not offer a C
compiler---only a C++ compiler which will compile C for reasons
of backwards compatibility. Because the C is only for reasons
of backwards compatibility, there is no effort to track the more
recent standards.
>[...]
>Hmm. It seems to me that a compiler that compiles C, for whatever
reasons, is a C compiler.

What if it only compiles a subset of C?
>Tracking recent standards is certainly an issue, though.

Perhaps I didn't really express myself clearly. From what I
understand (and I could easily be mistaken---I don't follow
developments under Windows very closely), Microsoft only
commercializes a C++ compiler system. That compiler system does
compile some C, for reasons of backwards compatibility, or
interfacing existing systems, or whatever, but it is not sold as
a conforming C compiler, and it makes no attempt to be
conforming. In sum, it's like the bundled C compiler in the
final versions of Sun OS 4.x.
My understanding (and I also could be easily mistaken) is that
Microsoft's C compiler conforms quite well to the C90 standard, but
not to the C99 standard. (How they choose to market it is another
matter.)

--
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"
Sep 9 '07 #150

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by clintonG | last post: by
2 posts views Thread by Progman | last post: by
6 posts views Thread by Simon Brown | last post: by
1 post views Thread by Dr T | last post: by
24 posts views Thread by JJ | last post: by
reply views Thread by zhoujie | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.