http://slashdot.org/
"The leaner, lighter, faster, and most importantly, BSD Licensed,
Compiler PCC has been imported into OpenBSD's CVS and NetBSD's pkgsrc.
The compiler is based on the original Portable C Compiler by S. C.
Johnson, written in the late 70's. Even though much of the compiler has
been rewritten, some of the basics still remain. It is currently not
bug-free, but it compiles on x86 platform, and work is being done on it
to take on GCC's job."
The PCC was the first C compiler I used and studied, back then, when
Unix and C started appearing here in France. We had a source license,
and browsing there I found the PCC code.
The discussion is here. http://undeadly.org/cgi?action=artic...mode=expanded/
It is interesting to see the level of frustration of the BSD people
with GCC. They just want a compiler that is simple, small, and...
supports all architectures that Open BSD supports.
Will they succeed?
Of course it is easy to have a compiler that supports 3 back ends, say.
But supporting 10?
With a mixture of weird CPUs etc?
In any case PCC should be up to the task. I remember it run in the
Honeywell-Bull computers of that time (beginning of the 80s), so
it should run in many others... Running with those was really a
challenge. 42  3393 
On Sep 17, 2:53 pm, jacob navia <ja...@jacob.remcomp.frwrote:
http://slashdot.org/
"The leaner, lighter, faster, and most importantly, BSD Licensed,
Compiler PCC has been imported into OpenBSD's CVS and NetBSD's pkgsrc.
The compiler is based on the original Portable C Compiler by S. C.
Johnson, written in the late 70's. Even though much of the compiler has
been rewritten, some of the basics still remain. It is currently not
bug-free, but it compiles on x86 platform, and work is being done on it
to take on GCC's job."
The PCC was the first C compiler I used and studied, back then, when
Unix and C started appearing here in France. We had a source license,
and browsing there I found the PCC code.
The discussion is here.
http://undeadly.org/cgi?action=artic...mode=expanded/
It is interesting to see the level of frustration of the BSD people
with GCC. They just want a compiler that is simple, small, and...
supports all architectures that Open BSD supports.
Will they succeed?
Of course it is easy to have a compiler that supports 3 back ends, say.
But supporting 10?
With a mixture of weird CPUs etc?
In any case PCC should be up to the task. I remember it run in the
Honeywell-Bull computers of that time (beginning of the 80s), so
it should run in many others... Running with those was really a
challenge.
Starting with PCC and trying to compete with GCC is like starting with
a dingy and planning to race a 65' yacht.
I guess that : http://www.tendra.org/about/
has a much better chance to succeed.
Other attempts: http://www.thefreecountry.com/compilers/cpp.shtml
user923005 <dc*****@connx.comwrote:
On Sep 17, 2:53 pm, jacob navia <ja...@jacob.remcomp.frwrote:
>http://slashdot.org/
"The leaner, lighter, faster, and most importantly, BSD Licensed,
Compiler PCC has been imported into OpenBSD's CVS and NetBSD's pkgsrc.
The compiler is based on the original Portable C Compiler by S. C.
Johnson, written in the late 70's. Even though much of the compiler has
been rewritten, some of the basics still remain. It is currently not
bug-free, but it compiles on x86 platform, and work is being done on it
to take on GCC's job."
The PCC was the first C compiler I used and studied, back then, when
Unix and C started appearing here in France. We had a source license,
and browsing there I found the PCC code.
The discussion is here.
http://undeadly.org/cgi?action=artic...mode=expanded/
It is interesting to see the level of frustration of the BSD people
with GCC. They just want a compiler that is simple, small, and...
supports all architectures that Open BSD supports.
Will they succeed?
Of course it is easy to have a compiler that supports 3 back ends, say.
But supporting 10?
With a mixture of weird CPUs etc?
In any case PCC should be up to the task. I remember it run in the
Honeywell-Bull computers of that time (beginning of the 80s), so
it should run in many others... Running with those was really a
challenge.
Starting with PCC and trying to compete with GCC is like starting with
a dingy and planning to race a 65' yacht.
That depends on in what manner you are trying to compete. It is true that it
seems unlikely that PCC will be able to generate as good code as GCC anytime
in the near future. On the other hand it should not be very difficult to
compete with GCC with regards to compile time and memory usage needed by the
compiler (areas in which GCC is not very good.)
For people trying to do development on older machines these features can be worth
much more than having the generated code run 0.5% faster.
Other people will have other priorities.
>
I guess that :
http://www.tendra.org/about/
has a much better chance to succeed.
Other attempts:
http://www.thefreecountry.com/compilers/cpp.shtml
--
<Insert your favourite quote here.>
Erik Trulsson er******@student.uu.se
Erik Trulsson wrote:
That depends on in what manner you are trying to compete. It is true that
it seems unlikely that PCC will be able to generate as good code as GCC
anytime in the near future. Â*On the other hand it should not be very
difficult to compete with GCC with regards to compile time and memory
usage needed by the compiler (areas in which GCC is not very good.)
Properties such as compile time and memory usage are only relevant to the
compilation process, which is a very tiny part of the whole software
production process. As far as compilers go and what is expected from the
compiler, those features may be nice to have but they are very far from
being important. In fact, they are totally irrelevant.
No one in their right mind prefers a lighter compiler that produces weak or
buggy code to one which is not so light but produces strong, tight and even
secure code.
For people trying to do development on older machines these features can
be worth much more than having the generated code run 0.5% faster.
In this day and age anyone can purchase a very capable system with
multi-core processors for less than 300 euros. It is also possible to buy
used systems for almost nothing. Frankly, I don't believe that build times
are an issue anymore or have been for some time.
Other people will have other priorities.
I don't believe that any developer will ever be willing to trade quality
code for a snappier build process. Naturally it is a nice feature but there
is absolutely no way it would ever be seriously considered for any
tradeoff.
Rui Maciel
Rui Maciel wrote:
Erik Trulsson wrote:
>That depends on in what manner you are trying to compete. It is true that
it seems unlikely that PCC will be able to generate as good code as GCC
anytime in the near future. On the other hand it should not be very
difficult to compete with GCC with regards to compile time and memory
usage needed by the compiler (areas in which GCC is not very good.)
Properties such as compile time and memory usage are only relevant to the
compilation process, which is a very tiny part of the whole software
production process.
I have to disagree here.
Each time you make a change in C you have to rebuild. for many projects,
a change can affect a lot of files. Global changes that need a full
recompilation are done not VERY often, but they are done...
This means that a compiler that slows down the development process by
just 30-60 seconds per build, it is taking between 15-30 minutes per day
to each developer...
Multiply that for a team and you see that a lot of time people are just
waiting for gcc to finish. Of course, this is not visible in small
projects.
As far as compilers go and what is expected from the
compiler, those features may be nice to have but they are very far from
being important. In fact, they are totally irrelevant.
Surely not. A fast compiler allows YOU to develop faster. And that is
important. Gcc is not very fast, mind you.
No one in their right mind prefers a lighter compiler that produces weak or
buggy code to one which is not so light but produces strong, tight and even
secure code.
You are speaking here as if you had never a gcc bug...
And yes, a compiler can be slow AND buggy, just look at gcc 3.1.xx for
amd64 platform and you will see what a buggy compiler can be. The same
with the 4.0xx and 4.1 series...
A simpler compiler is surely easier to debug you see?
>
>For people trying to do development on older machines these features can
be worth much more than having the generated code run 0.5% faster.
In this day and age anyone can purchase a very capable system with
multi-core processors for less than 300 euros. It is also possible to buy
used systems for almost nothing. Frankly, I don't believe that build times
are an issue anymore or have been for some time.
For the company I am working, a full rebuild takes 10 minutes in a super
hyper fast lane dual core amd64 using MSVC. Using gcc it takes like 45
minutes...
>Other people will have other priorities.
I don't believe that any developer will ever be willing to trade quality
code for a snappier build process.
Quality of code? Gcc's code quality can be great when there is no bugs
in the optimizer... When they are, as it is sadly very often the case,
we have to use the debug version... And that code is quite bad.
We get then the worst of both worlds: slow AND buggy.
>Naturally it is a nice feature but there
is absolutely no way it would ever be seriously considered for any
tradeoff.
Since they have the monopoly under linux, there is nothing
anyone can do about that.
DISCLAIMER:
I am biased against it. I use another compiler.
Rui Maciel <ru********@gmail.comwrote:
Erik Trulsson wrote:
That depends on in what manner you are trying to compete. It is true that
it seems unlikely that PCC will be able to generate as good code as GCC
anytime in the near future. ??On the other hand it should not be very
difficult to compete with GCC with regards to compile time and memory
usage needed by the compiler (areas in which GCC is not very good.)
Properties such as compile time and memory usage are only relevant to the
compilation process, which is a very tiny part of the whole software
production process. As far as compilers go and what is expected from the
compiler, those features may be nice to have but they are very far from
being important. In fact, they are totally irrelevant.
No one in their right mind prefers a lighter compiler that produces weak or
buggy code to one which is not so light but produces strong, tight and even
secure code.
Indeed. And in fact, the OpenBSD developers have for years complained that
GCC does not produce strong, tight and secure code. In other words, they
claim that GCC slowly compiles fast, buggy code.
William Ahern wrote, On 18/09/07 16:06:
Rui Maciel <ru********@gmail.comwrote:
>Erik Trulsson wrote:
>>That depends on in what manner you are trying to compete. It is true that
it seems unlikely that PCC will be able to generate as good code as GCC
anytime in the near future. ??On the other hand it should not be very
difficult to compete with GCC with regards to compile time and memory
usage needed by the compiler (areas in which GCC is not very good.)
>Properties such as compile time and memory usage are only relevant to the
compilation process, which is a very tiny part of the whole software
production process. As far as compilers go and what is expected from the
compiler, those features may be nice to have but they are very far from
being important. In fact, they are totally irrelevant.
>No one in their right mind prefers a lighter compiler that produces weak or
buggy code to one which is not so light but produces strong, tight and even
secure code.
Indeed. And in fact, the OpenBSD developers have for years complained that
GCC does not produce strong, tight and secure code. In other words, they
claim that GCC slowly compiles fast, buggy code.
Not secure is not the same thing as buggy. If you want secure code you
want the code to do something safe on buffer overflows, for example, but
as far as the C standard is concerned whatever the code does on a buffer
overflow it is not a bug in the compiler. By strong and tight they could
also mean things which are nothing to do with whether gcc incorrectly
translates code.
--
Flash Gordon
jacob navia wrote, On 18/09/07 14:34:
Rui Maciel wrote:
>Erik Trulsson wrote:
>>That depends on in what manner you are trying to compete. It is true
that
it seems unlikely that PCC will be able to generate as good code as GCC
anytime in the near future. On the other hand it should not be very
difficult to compete with GCC with regards to compile time and memory
usage needed by the compiler (areas in which GCC is not very good.)
Properties such as compile time and memory usage are only relevant to the
compilation process, which is a very tiny part of the whole software
production process.
I have to disagree here.
Each time you make a change in C you have to rebuild. for many projects,
a change can affect a lot of files. Global changes that need a full
recompilation are done not VERY often, but they are done...
This means that a compiler that slows down the development process by
just 30-60 seconds per build, it is taking between 15-30 minutes per day
to each developer...
Multiply that for a team and you see that a lot of time people are just
waiting for gcc to finish. Of course, this is not visible in small
projects.
That is not long. Wait until you work on a project where a build take 8
hours!
>As far as compilers go and what is expected from the
compiler, those features may be nice to have but they are very far from
being important. In fact, they are totally irrelevant.
Surely not. A fast compiler allows YOU to develop faster. And that is
important. Gcc is not very fast, mind you.
Yes, I agree a fast compiler is useful, and gcc is not the fastest around.
>No one in their right mind prefers a lighter compiler that produces
weak or
buggy code to one which is not so light but produces strong, tight and
even
secure code.
You are speaking here as if you had never a gcc bug...
And yes, a compiler can be slow AND buggy, just look at gcc 3.1.xx for
amd64 platform and you will see what a buggy compiler can be. The same
with the 4.0xx and 4.1 series...
A simpler compiler is surely easier to debug you see?
Personally I've hit very few bugs in gcc. They do exist but I don't hit
them often enough to worry about.
>>For people trying to do development on older machines these features can
be worth much more than having the generated code run 0.5% faster.
In this day and age anyone can purchase a very capable system with
multi-core processors for less than 300 euros. It is also possible to buy
used systems for almost nothing. Frankly, I don't believe that build
times
are an issue anymore or have been for some time.
For the company I am working, a full rebuild takes 10 minutes in a super
hyper fast lane dual core amd64 using MSVC. Using gcc it takes like 45
minutes...
A dual core amd64 is *not* super hyper fast. Anyway, make sure you have
make configured to do multiple compilations at once. On Linux it is
often recommended that you set make to compile two files per core at a
time, so on a dual core machine you should be compiling 4 files in parallel.
>>Other people will have other priorities.
I don't believe that any developer will ever be willing to trade quality
code for a snappier build process.
Quality of code? Gcc's code quality can be great when there is no bugs
in the optimizer... When they are, as it is sadly very often the case,
we have to use the debug version... And that code is quite bad.
At -O2 I've *very* rarely hit problems.
We get then the worst of both worlds: slow AND buggy.
>>Naturally it is a nice feature but there
is absolutely no way it would ever be seriously considered for any
tradeoff.
Since they have the monopoly under linux, there is nothing
anyone can do about that.
No gcc does not have a monopoly under Linux. There is tcc, although that
is still flagged as experimental on Ubuntu, Tendra and of course Intel's
icc.
DISCLAIMER:
I am biased against it. I use another compiler.
I use gcc a *lot* under Linux, and historically I have used it a fair
bit under SCO and AIX with some use under Cygwin and MinGW as well and
have not hit the level of bugs you claim for it.
--
Flash Gordon
Erik Trulsson wrote:
That depends on in what manner you are trying to compete. It is true that
it seems unlikely that PCC will be able to generate as good code as GCC
anytime in the near future. Â*On the other hand it should not be very
difficult to compete with GCC with regards to compile time and memory
usage needed by the compiler (areas in which GCC is not very good.)
Properties such as compile time and memory usage are only relevant to the
compilation process, which is a very tiny part of the whole software
production process. As far as compilers go and what is expected from the
compiler, those features may be nice to have but they are very far from
being important. In fact, they are totally irrelevant.
No one in their right mind prefers a lighter compiler that produces weak or
buggy code to one which is not so light but produces strong, tight and even
secure code.
For people trying to do development on older machines these features can
be worth much more than having the generated code run 0.5% faster.
In this day and age anyone can purchase a very capable system with
multi-core processors for less than 300 euros. It is also possible to buy
used systems for almost nothing. Frankly, I don't believe that build times
are an issue anymore or have been for some time.
Other people will have other priorities.
I don't believe that any developer will ever be willing to trade quality
code for a snappier build process. Naturally it is a nice feature but there
is absolutely no way it would ever be seriously considered for any
tradeoff.
Rui Maciel
Rui Maciel <ru********@gmail.comwrote:
<snip>
Other people will have other priorities.
I don't believe that any developer will ever be willing to trade quality
code for a snappier build process. Naturally it is a nice feature but there
is absolutely no way it would ever be seriously considered for any
tradeoff.
And yet, it is being seriously considered by OpenBSD and NetBSD. The OpenBSD
folks have specifically stated that they would prefer a faster build to
faster code.
Your overly broad and loaded "quality" argument serves only to muddy the
waters. GCC's output isn't shinier than any other output.
On Tue, 18 Sep 2007 13:34:02 +0100, Rui Maciel <ru********@gmail.com>
wrote:
>No one in their right mind prefers a lighter compiler that produces weak or
buggy code to one which is not so light but produces strong, tight and even
secure code.
So, either the compiler in question does not fit that description, or
the BSD programmers are not in their right mind. Or both?
--
Al Balmer
Sun City, AZ
Al Balmer wrote:
So, either the compiler in question does not fit that description, or
the BSD programmers are not in their right mind. Or both?
You have to ask them why they decided to invest their time in that
endeavour. Personally I hope PCC matures and becomes an excellent compiler.
Everyone benefits if there is another FLOS compiler available. I would be
very happy if it could also support C++ and Fortran and could also offer
better support for the standards.
Nonetheless, the only reasons that so far have been given to justify it's
adoption was PCC's reduced compilation times and it's license. It has been
speculated that the later has been the main reason. If that's the case then
I have to say that they don't seem to be in their right minds.
Rui Maciel
On Tue, 18 Sep 2007 22:33:15 +0200, jacob navia wrote:
This is normal for me.
A build after 10 minutes is quite normal when I am developing. Maybe
more. I made a typing mistake, and discover that at link time...
or, I misspelled a variable, or called the wrong function, then you
correct and build again. A normal thing...
Just a minute - surely you only have to do this if you typo in a header?
Or is your build system screwed? Or perhaps you keep code in headers?
(Otherwise only the file you changed generally needs to be rebuilt,
depending on your dependency tree.)
B.
Rob Kendrick wrote:
On Tue, 18 Sep 2007 22:33:15 +0200, jacob navia wrote:
>This is normal for me.
A build after 10 minutes is quite normal when I am developing. Maybe
more. I made a typing mistake, and discover that at link time...
or, I misspelled a variable, or called the wrong function, then you
correct and build again. A normal thing...
Just a minute - surely you only have to do this if you typo in a header?
Or is your build system screwed? Or perhaps you keep code in headers?
(Otherwise only the file you changed generally needs to be rebuilt,
depending on your dependency tree.)
B.
Of course, only one file is rebuilt. But there is always the link step,
what is not fast really, specially with BIG projects.
On Tue, 18 Sep 2007 23:31:30 +0200, jacob navia wrote:
Of course, only one file is rebuilt. But there is always the link step,
what is not fast really, specially with BIG projects.
Woah, 10 minutes of *linking* ? I think it's time you investigate making
your build system suck less.
B.
jacob navia wrote, On 18/09/07 21:33:
Rui Maciel wrote:
>jacob navia wrote:
<snip>
>Once again, GCC is perfectly irrelevant to this subject. Why you keep on
whining about GCC is beyond me.
I am not "whinning", this is just a problem of the GCC "support" people.
They think that they can forget their "customers" because they offer
their software for free. I have never treated people pointing me the
bugs in the compiler as "whinners".
When people here have pointed out bugs in your implementation you have
certainly not taken it well. Look at how much work everyone had to put
in before you admitted that you needed to use parenthesis on numeric
constants in limits.h, and even then you did not seem pleased about
fixing it.
<snip>
>Do you believe that taking less time to produce
non-optimised, bug-ridden code is in some way better than the heavily
optimised code that GCC generates or even the fact that it supports
dozens
of target platforms and 6 programming languages?
1) I do not care about 4 from those 6 languages. I program in C, and the
company uses C++.
2) Maybe is great that GCC supports many platforms but (for instance)
under AIX is unusable because of too many bugs, we had to use IBM's
AIX compiler. Under Solaris the situation is similar. We use Sun's
compiler. And those are company decisions, not mine.
Well, we have a large company in the UK running SW daily with hundreds
of users that I've been building with gcc on AIX for the last few years.
I did once hit a bug with gcc specific to AIX, but it had already been
fixed in a later version by then.
>>>>Naturally it is a nice feature but there
is absolutely no way it would ever be seriously considered for any
tradeoff.
Since they have the monopoly under linux, there is nothing
anyone can do about that.
Monopoly? What the hell are you talking about? No one forces anyone or
any
linux distro to adopt GCC nor anyone bars anyone from installing and
using
some other compiler on a linux distro.
Look.
Did you know that /usr/lib/libc.so is not a binary shared library?
NO!
It is an ASCII LINKER SCRIPT for GNU's "ld"...
So? That is not part of gcc and the actual C library is available as a
shared object, check /lib/libc.so.6. That is two reasons why your
argument here is rubbish.
Ahhh you do not use "ld"?
What has that got to do with whether you are using gcc? ld is a seperate
product which gcc happens to use.
Then you are doomed stupid!
Most of the headers and system headers under linux are full of
__attribute__ etc etc etc!
I have ported lcc-win to linux and I can tell you that I had to write
my own headers,
So? When gcc is built it goes through a lot of hoops to create suitable
headers based on whatever the system provides.
exactly like under windows
So why complain it is a gcc problem?
with the BIG difference that
with Microsoft it is still possible to use the windows SDK headers.
What you mean is you support the extensions MS use in their headers but
you don't support the extensions used in the headers shipped with glibc.
glibc is another seperate product by the way, and not part of gcc.
Under linux if you do not support __attribute__ you are doomed.
By the same argument under Windows you are doomed if you don't support
__cdecl or whatever it is that MS use in all their headers.
>Some companies even sell compilers
for linux.
Borland tried ... Where are they now?
Over here http://www.codegear.com/ although they have stopped the Linux
port now. However, I would not have chosen their compiler for serious
work on Windows either.
Intel is there though, but that is the only one. Never heard from anyone
else.
What about you, or don't you count? I also listed a couple of others in
my other post. In any case, one alternative shows it is not a monopoly,
especially as the Intel compiler is designed to be compatible with gcc.
>Heck, some linux distros even compile their binaries with other
compilers such as Intel's. What on earth are you smoking?
Yeah I stopped somking some years ago.
Bad decision, it was a good defense against getting excited about this
kind of stuff.
You haven't answered the point about there being complete distributions
built with other than gcc.
--
Flash Gordon
Flash Gordon wrote:
You haven't answered the point about there being complete distributions
built with other than gcc.
As I said several lines before:
>Intel is there though, but that is the only one. Never heard from
anyone else.
Yes, Intel has the resources to throw into something like that. It has
developed a "gcc clone" mode, where it even copies the command line
options of gcc.
Flash Gordon wrote:
jacob navia wrote, On 18/09/07 21:33:
>Look.
Did you know that /usr/lib/libc.so is not a binary shared library?
NO!
It is an ASCII LINKER SCRIPT for GNU's "ld"...
So? That is not part of gcc and the actual C library is available as a
shared object, check /lib/libc.so.6. That is two reasons why your
argument here is rubbish.
OK. You find normal that the system library uses an ASCII script for a
specific linker. If Microsoft would have done that, nobody could
link under windows without using their linker...
>Ahhh you do not use "ld"?
What has that got to do with whether you are using gcc? ld is a seperate
product which gcc happens to use.
A developer uses the whole chain:
compiler --assembler-->linker-->debugger.
>Then you are doomed stupid!
Most of the headers and system headers under linux are full of
__attribute__ etc etc etc!
I have ported lcc-win to linux and I can tell you that I had to write
my own headers,
So? When gcc is built it goes through a lot of hoops to create suitable
headers based on whatever the system provides.
Yes. They are no better than Microsoft or IBM. Just the same.
>exactly like under windows
Yes
So why complain it is a gcc problem?
I do not complain. I say that they have the monopoly. I do not complain
about Microsoft. I just say that they have a windows monopoly.
>with the BIG difference that
with Microsoft it is still possible to use the windows SDK headers.
What you mean is you support the extensions MS use in their headers but
you don't support the extensions used in the headers shipped with glibc.
I only support stdcall. No other MS extension is supported unless it is
generally useful like dllexport/import.
glibc is another seperate product by the way, and not part of gcc.
Yes, sure.
>Under linux if you do not support __attribute__ you are doomed.
By the same argument under Windows you are doomed if you don't support
__cdecl or whatever it is that MS use in all their headers.
I do not support __cdecl.
William Ahern wrote:
And yet, it is being seriously considered by OpenBSD and NetBSD. The
OpenBSD folks have specifically stated that they would prefer a faster
build to faster code.
Your overly broad and loaded "quality" argument serves only to muddy the
waters. GCC's output isn't shinier than any other output.
Please note that GCC and it's features is not nor it has ever been the
subject of this discussion. I've stated that compilation times isn't a
relevant feature when we are dealing with compilers. It is a nice feature
to have but it will never be a trade-off with features like stability or
optimisation. What good is a compiler for if it is quick to compile but
produces code which is buggy and slow?
And yet GCC is being constantly dragged into any comparison with PCC, as if
the objective was to smear GCC instead of defending PCC's strong points.
Rui Maciel
Al Balmer wrote:
So, either the compiler in question does not fit that description, or
the BSD programmers are not in their right mind. Or both?
You have to ask them why they decided to invest their time in that
endeavour. Personally I hope PCC matures and becomes an excellent compiler.
Everyone benefits if there is another FLOS compiler available. I would be
very happy if it could also support C++ and Fortran and could also offer
better support for the standards.
Nonetheless, the only reasons that so far have been given to justify it's
adoption was PCC's reduced compilation times and it's license. It has been
speculated that the later has been the main reason. If that's the case then
I have to say that they don't seem to be in their right minds.
Rui Maciel
On Sep 19, 10:34 am, jacob navia <ja...@jacob.remcomp.frwrote:
Ahhh you do not use "ld"?
What has that got to do with whether you are using gcc? ld is a seperate
product which gcc happens to use.
A developer uses the whole chain:
compiler --assembler-->linker-->debugger.
"ld" has nothing to do with GCC. GCC does not
distribute with an assembler, nor with a linker.
Often "ld" is a proprietary product.
You are complaning about slow link times. That is
the fault of your choice of linker, not of GCC.
On 18 Sep 2007 at 22:32, Rui Maciel wrote:
jacob navia wrote:
>Yeah, if it compiles C it is of no much use, I know.
But maybe it *could* be that *some* people *like* C you see?
Sarcasm aside, no one has ever stated that no one liked C. As this very
thread is taking place in a newsgroup dedicated to the C programming
language, that insinuation is rather amusing. Were you trying to fan the
flames?
Gee, do you reckon? Jacob's whole modus operandi in this group is to be
completely unreasonable, get people really riled up, and then when they
react he plays the victim - "everyone's picking on me!"
Look at this thread. It serves absolutely no purpose except for Jacob to
spread a load of FUD about gcc.
Jacob obviously thinks the world owes him a living because he took
someone else's compiler, knocked up a pretty GUI IDE to go with it, and
repackaged it as a commercial product. It's clear from his postings to
this group over several years that he doesn't have the first beginnings
of a clue about C - he's not just a social pariah, he's technically
inept to go with it.
This group would be a better place if Jacob would stop posting to it and
leave us all in peace.
A N Other wrote:
[snip]
The *only* messages you post in this group are long messages
of despair about "jacob"...
I must be really important to you my dear, what an interest
for my humble person.
Have a nice time and next time do not be afraid.
Just post with your correct name as I do. Nothing will
happen to you.
jacob
On Wed, 19 Sep 2007 00:34:44 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>Flash Gordon wrote:
>jacob navia wrote, On 18/09/07 21:33:
>>>
It is an ASCII LINKER SCRIPT for GNU's "ld"...
So? That is not part of gcc and the actual C library is available as a
shared object, check /lib/libc.so.6. That is two reasons why your
argument here is rubbish.
OK. You find normal that the system library uses an ASCII script for a
specific linker.
The point is, you were criticising gcc, and this isn't part of it.
Your argument was consequently nonsense.
>If Microsoft would have done that, nobody could
link under windows without using their linker...
Nonsense. All your linker has to do is parse the script. Even easier,
do as cygwin do, and provide your own standard library.
>A developer uses the whole chain:
Again, so what? If you attack a tool, don't blame the tool for flaws
in someone else's product.
"My mother was injured in the Pamplona bull run. I blame the gas
board."
>>Under linux if you do not support __attribute__ you are doomed.
By the same argument under Windows you are doomed if you don't support
__cdecl or whatever it is that MS use in all their headers.
I do not support __cdecl.
Then by your own logic, you are doomed, right?
--
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
On Sep 18, 3:29 am, Erik Trulsson <ertr1...@student.uu.sewrote:
user923005 <dcor...@connx.comwrote:
On Sep 17, 2:53 pm, jacob navia <ja...@jacob.remcomp.frwrote:
>http://slashdot.org/
"The leaner, lighter, faster, and most importantly, BSD Licensed,
Compiler PCC has been imported into OpenBSD's CVS and NetBSD's pkgsrc.
The compiler is based on the original Portable C Compiler by S. C.
Johnson, written in the late 70's. Even though much of the compiler has
been rewritten, some of the basics still remain. It is currently not
bug-free, but it compiles on x86 platform, and work is being done on it
to take on GCC's job."
The PCC was the first C compiler I used and studied, back then, when
Unix and C started appearing here in France. We had a source license,
and browsing there I found the PCC code.
The discussion is here.
>http://undeadly.org/cgi?action=artic...mode=expanded/
It is interesting to see the level of frustration of the BSD people
with GCC. They just want a compiler that is simple, small, and...
supports all architectures that Open BSD supports.
Will they succeed?
Of course it is easy to have a compiler that supports 3 back ends, say.
But supporting 10?
With a mixture of weird CPUs etc?
In any case PCC should be up to the task. I remember it run in the
Honeywell-Bull computers of that time (beginning of the 80s), so
it should run in many others... Running with those was really a
challenge.
Starting with PCC and trying to compete with GCC is like starting with
a dingy and planning to race a 65' yacht.
That depends on in what manner you are trying to compete. It is true that it
seems unlikely that PCC will be able to generate as good code as GCC anytime
in the near future. On the other hand it should not be very difficult to
compete with GCC with regards to compile time and memory usage needed by the
compiler (areas in which GCC is not very good.)
For people trying to do development on older machines these features can be worth
much more than having the generated code run 0.5% faster.
GCC works great as a cross compiler. Why work on some crusty old
platform?
Other people will have other priorities.
[snip]
jacob navia wrote:
>
.... snip ...
>
Each time you make a change in C you have to rebuild. for many
projects, a change can affect a lot of files. Global changes that
need a full recompilation are done not VERY often, but they are
done...
This means that a compiler that slows down the development process
by just 30-60 seconds per build, it is taking between 15-30
minutes per day to each developer...
To me, the requirement for such a long routine compile indicates
mis-organization. Normally you would only be modifying one source
file, and the rebuild should be limited to recompiling that and
relinking. Sometimes the associated .h file may need revision, and
then (rarely) the work can become considerably larger. So in
general the compilation should not be a problem, however the
linking may be.
--
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
A N Other <sp******@invalid.comwrites:
[...]
Jacob obviously thinks the world owes him a living because he took
someone else's compiler, knocked up a pretty GUI IDE to go with it, and
repackaged it as a commercial product.
[...]
jacob has claimed here that lcc-win32 is a complete rewrite of lcc,
and that little or no original lcc source code remains.
I have no basis on which to judge the accuracy of that claim.
--
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"
Keith Thompson said:
A N Other <sp******@invalid.comwrites:
[...]
>Jacob obviously thinks the world owes him a living because he took
someone else's compiler, knocked up a pretty GUI IDE to go with it, and
repackaged it as a commercial product.
[...]
jacob has claimed here that lcc-win32 is a complete rewrite of lcc,
and that little or no original lcc source code remains.
I have no basis on which to judge the accuracy of that claim.
Simply compare it to the accuracy of all his other claims.
Since I killfiled Mr Navia, people have stopped complaining at me for
arguing with him all the time. I am not ungrateful for this. I have
noticed, however, a marked increase in the rate with which *other people*
are arguing with him. When you sack firefighters, you should expect more
fires.
I would be interested in hearing people's justifications for arguing with
Mr Navia, given that I was often criticised for so doing.
--
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
jacob navia wrote, On 18/09/07 23:27:
Flash Gordon wrote:
>You haven't answered the point about there being complete
distributions built with other than gcc.
As I said several lines before:
>Intel is there though, but that is the only one. Never heard from
>anyone else.
Yes, Intel has the resources to throw into something like that. It has
developed a "gcc clone" mode, where it even copies the command line
options of gcc.
Therefore gcc does *not* have the monopoly you were claiming it has.
--
Flash Gordon
jacob navia wrote:
Flash Gordon wrote:
>You haven't answered the point about there being complete
distributions built with other than gcc.
As a reverse example, OpenSolaris builds with Sun cc and gcc.
As I said several lines before:
>>Intel is there though, but that is the only one. Never heard from
anyone else.
Yes, Intel has the resources to throw into something like that. It has
developed a "gcc clone" mode, where it even copies the command line
options of gcc.
As does Sun Studio. Before too long, we'll have non-standardised, but
near universal compiler options, which makes porting a heck of a lot
easier. Just goes to show what happens one one compiler dominates a sector.
--
Ian Collins.
jacob navia wrote, On 18/09/07 23:34:
Flash Gordon wrote:
>jacob navia wrote, On 18/09/07 21:33:
>>Look.
Did you know that /usr/lib/libc.so is not a binary shared library?
NO!
It is an ASCII LINKER SCRIPT for GNU's "ld"...
So? That is not part of gcc and the actual C library is available as a
shared object, check /lib/libc.so.6. That is two reasons why your
argument here is rubbish.
OK. You find normal that the system library uses an ASCII script for a
specific linker.
They also provide the ACTUAL C library if you want to use it. They also
provide a linker you can use. You can also see how the damn thing works
so you can write your linker to use it if you want.
If Microsoft would have done that, nobody could
link under windows without using their linker...
You have to either use the Microsoft linker or write your own compatible
with it or provide your own C library. The ONLY difference with Linux is
that the linker is actually provided free and installed already on most
systems.
>>Ahhh you do not use "ld"?
What has that got to do with whether you are using gcc? ld is a
seperate product which gcc happens to use.
A developer uses the whole chain:
compiler --assembler-->linker-->debugger.
Well, not everyone uses an assembler. However, if we ignore that you are
forgetting how things work there is still the point that gcc is is NOT a
linker nor is it a debugger. So what are you complaining about, just gcc
which is all you initially mentioned, gcc and GNU ld, or the debugger as
well, or what?
>>Then you are doomed stupid!
Most of the headers and system headers under linux are full of
__attribute__ etc etc etc!
I have ported lcc-win to linux and I can tell you that I had to write
my own headers,
So? When gcc is built it goes through a lot of hoops to create
suitable headers based on whatever the system provides.
Yes. They are no better than Microsoft or IBM. Just the same.
I think you will find that the headers for all C libraries use
implementation specific tricks. For a start, offsetof cannot be
implemented *without* using implementation specific tricks. So EVERY
provider of implementations including *you* is guilty. So what on earth
are you complaining about?
>>exactly like under windows
Yes
So why raise it as a problem with gcc?
>So why complain it is a gcc problem?
I do not complain. I say that they have the monopoly. I do not complain
about Microsoft. I just say that they have a windows monopoly.
You are wrong. See all the stuff you have just read including the posts
you have replied to pointing out there are complete distributions built
*without* gcc.
>>with the BIG difference that
with Microsoft it is still possible to use the windows SDK headers.
What you mean is you support the extensions MS use in their headers
but you don't support the extensions used in the headers shipped with
glibc.
I only support stdcall. No other MS extension is supported unless it is
generally useful like dllexport/import.
>glibc is another seperate product by the way, and not part of gcc.
Yes, sure.
So why raise things about glibc as complaints about gcc?
>>Under linux if you do not support __attribute__ you are doomed.
By the same argument under Windows you are doomed if you don't support
__cdecl or whatever it is that MS use in all their headers.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
I do not support __cdecl.
Since I EXPLICITLY cover that I might not have remembered what MS use
why not address the obvious and real point, namely that you DO support
whatever extension it is that MS use.
--
Flash Gordon
Flash Gordon <sp**@flash-gordon.me.ukwrites:
Personally I've hit very few bugs in gcc. They do exist but I don't hit
them often enough to worry about.
I've been hit by about the same number of bugs in gcc than in other
compilers we use. Very few. I've been far more often explained to someone
that, no it wasn't a bug in the compiler, it is a bug in the program.
Since they have the monopoly under linux, there is nothing anyone can
do about that.
No gcc does not have a monopoly under Linux. There is tcc, although that
is still flagged as experimental on Ubuntu, Tendra and of course Intel's
icc.
There is also
- lcc
- the compiler of SunStudio (which claims C99 compliance -- I've not
checked and don't remember if it comes with a compliant library or use glibc)
- the C compiler of Comeau (which use gcc as back end, and also claims
C99 compliance but use glibc).
- IBM xlC is also available for Linux according to the web pages, I don't
know if they support x86
- Open64
I'm probably missing some. And I'm pretty sure that if pcc does bring
something, somebody will port it to Linux.
But it is true that most people and even compagnies use gcc.
--
Jean-Marc
Rui Maciel <ru********@gmail.comwrites:
Once again, GCC is perfectly irrelevant to this subject. Why you keep on
whining about GCC is beyond me. Moreover, no one ever claimed that GCC was
the best compiler around or even the fastest. The claim that was made was
that the "people building on old machines" claim is perfectly irrelevant,
knowing that any system sold in the past 3 or 4 years is more than capable
of doing a decent build job.
In the case of OpenBSD and NetBSD distributions, they target things which
where already outdated 10 years ago (vaxes were still sold 10 years ago but
I'd have problem to say they were current at that time).
Yours,
--
Jean-Marc
jacob navia <ja***@jacob.remcomp.frwrites:
Yes, Intel has the resources to throw into something like that. It has
developed a "gcc clone" mode, where it even copies the command line
options of gcc.
That's the think everybody does when there is a big player in a market: be
as compatible -- sometimes even bug compatible -- with it. That's not the
same as having a monopoly.
Yours,
--
Jean-Marc
Richard Heathfield wrote:
Since I killfiled Mr Navia, people have stopped complaining at me for
arguing with him all the time. I am not ungrateful for this. I have
noticed, however, a marked increase in the rate with which *other people*
are arguing with him.
Sniff, sniff....
"CBFalconer" <cb********@yahoo.coma écrit dans le message de news: 46***************@yahoo.com...
jacob navia wrote:
>>
... snip ...
>>
Each time you make a change in C you have to rebuild. for many
projects, a change can affect a lot of files. Global changes that
need a full recompilation are done not VERY often, but they are
done...
This means that a compiler that slows down the development process
by just 30-60 seconds per build, it is taking between 15-30
minutes per day to each developer...
To me, the requirement for such a long routine compile indicates
mis-organization. Normally you would only be modifying one source
file, and the rebuild should be limited to recompiling that and
relinking. Sometimes the associated .h file may need revision, and
then (rarely) the work can become considerably larger. So in
general the compilation should not be a problem, however the
linking may be.
I suspect the project Jacob is talking about is actually mostly C++.
Changing a class header file or a template causes a lot of recompilation,
and g++ is notoriously slow.
--
Chqrlie.
Charlie Gordon wrote:
"CBFalconer" <cb********@yahoo.coma écrit dans le message de news:
46***************@yahoo.com...
>jacob navia wrote:
... snip ...
>>Each time you make a change in C you have to rebuild. for many
projects, a change can affect a lot of files. Global changes that
need a full recompilation are done not VERY often, but they are
done...
This means that a compiler that slows down the development process
by just 30-60 seconds per build, it is taking between 15-30
minutes per day to each developer...
To me, the requirement for such a long routine compile indicates
mis-organization. Normally you would only be modifying one source
file, and the rebuild should be limited to recompiling that and
relinking. Sometimes the associated .h file may need revision, and
then (rarely) the work can become considerably larger. So in
general the compilation should not be a problem, however the
linking may be.
I suspect the project Jacob is talking about is actually mostly C++.
Yes, as I said the company uses C++
Changing a class header file or a template causes a lot of recompilation,
and g++ is notoriously slow.
The linker is VERY slow, and that hits you even when doing
a trivial change.
On Sep 19, 6:54 am, jacob navia <ja...@jacob.remcomp.frwrote:
Charlie Gordon wrote:
"CBFalconer" <cbfalco...@yahoo.coma écrit dans le message de news:
46F04BF7.212AE...@yahoo.com...
jacob navia wrote:
... snip ...
Each time you make a change in C you have to rebuild. for many
projects, a change can affect a lot of files. Global changes that
need a full recompilation are done not VERY often, but they are
done...
>This means that a compiler that slows down the development process
by just 30-60 seconds per build, it is taking between 15-30
minutes per day to each developer...
To me, the requirement for such a long routine compile indicates
mis-organization. Normally you would only be modifying one source
file, and the rebuild should be limited to recompiling that and
relinking. Sometimes the associated .h file may need revision, and
then (rarely) the work can become considerably larger. So in
general the compilation should not be a problem, however the
linking may be.
I suspect the project Jacob is talking about is actually mostly C++.
Yes, as I said the company uses C++
Changing a class header file or a template causes a lot of recompilation,
and g++ is notoriously slow.
The linker is VERY slow, and that hits you even when doing
a trivial change.
GCC is totally irrelevant as far as linking is concerned. The speed
of linking for PCC or any other compiler will not be any different at
all, since both PCC and GCC are going to perform exactly the same link
step using exactly the same linker. The link step is performed by the
operating system's linker, and so the speed of the link won't change
at all unless a compiler vendor supplies its own linker. Microsoft
does that, but then again, they also wrote the operating system for
their compiler so no great surprise there.
I believe that this has all been explained to you before. I think
that you are deliberately being thick here.
user923005 said:
On Sep 19, 6:54 am, jacob navia <ja...@jacob.remcomp.frwrote:
<snip>
>The linker is VERY slow, and that hits you even when doing
a trivial change.
GCC is totally irrelevant as far as linking is concerned. [...]
I believe that this has all been explained to you before. I think
that you are deliberately being thick here.
Hanlon's Razor applies.
--
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
A N Other <sp******@invalid.comwrites:
On 18 Sep 2007 at 22:32, Rui Maciel wrote:
>jacob navia wrote:
>>Yeah, if it compiles C it is of no much use, I know.
But maybe it *could* be that *some* people *like* C you see?
Sarcasm aside, no one has ever stated that no one liked C. As this very
thread is taking place in a newsgroup dedicated to the C programming
language, that insinuation is rather amusing. Were you trying to fan the
flames?
Gee, do you reckon? Jacob's whole modus operandi in this group is to be
completely unreasonable, get people really riled up, and then when they
react he plays the victim - "everyone's picking on me!"
That is not what I have seen.
>
Look at this thread. It serves absolutely no purpose except for Jacob to
spread a load of FUD about gcc.
Jacob obviously thinks the world owes him a living because he took
someone else's compiler, knocked up a pretty GUI IDE to go with it, and
repackaged it as a commercial product. It's clear from his postings to
this group over several years that he doesn't have the first beginnings
of a clue about C - he's not just a social pariah, he's technically
inept to go with it.
Hmm. I see a certain pattern emerging in your style.
>
This group would be a better place if Jacob would stop posting to it and
leave us all in peace.
Who is "us"?
user923005 wrote:
On Sep 19, 6:54 am, jacob navia <ja...@jacob.remcomp.frwrote:
>Charlie Gordon wrote:
>>"CBFalconer" <cbfalco...@yahoo.coma écrit dans le message de news:
46F04BF7.212AE...@yahoo.com...
jacob navia wrote:
... snip ...
Each time you make a change in C you have to rebuild. for many
projects, a change can affect a lot of files. Global changes that
need a full recompilation are done not VERY often, but they are
done...
This means that a compiler that slows down the development process
by just 30-60 seconds per build, it is taking between 15-30
minutes per day to each developer...
To me, the requirement for such a long routine compile indicates
mis-organization. Normally you would only be modifying one source
file, and the rebuild should be limited to recompiling that and
relinking. Sometimes the associated .h file may need revision, and
then (rarely) the work can become considerably larger. So in
general the compilation should not be a problem, however the
linking may be.
I suspect the project Jacob is talking about is actually mostly C++.
Yes, as I said the company uses C++
>>Changing a class header file or a template causes a lot of recompilation,
and g++ is notoriously slow.
The linker is VERY slow, and that hits you even when doing
a trivial change.
GCC is totally irrelevant as far as linking is concerned. The speed
of linking for PCC or any other compiler will not be any different at
all, since both PCC and GCC are going to perform exactly the same link
step using exactly the same linker.
If they do that, it would be really stupid.
The linker of GNU is very slow.
But I am not saying that GCC is responsible for the flaws of ld,
even if is in the same tool chain. It was just a remark about the
speed of the link step.
The internal structure of that linker is quite involved, doing several
passes to find constructors, then putting them in an automatically
generated C file, then compiling that (yes, they compile C code
within the link step!!) and then (and only THEN) linking the whole
mess.
The speed of gcc *is* important within the linker since the
linker compiles C code when linking.
:-)
I was completely surprised when I discovered that.
The link step is performed by the
operating system's linker, and so the speed of the link won't change
at all unless a compiler vendor supplies its own linker. Microsoft
does that, but then again, they also wrote the operating system for
their compiler so no great surprise there.
The OS supplies no linker under windows, That's why I had to write one.
>
I believe that this has all been explained to you before. I think
that you are deliberately being thick here.
You take a remark as "ld is slow" and just suppose that I am blaming
gcc. No I am not. But... see above :-)
"jacob navia" <ja***@jacob.remcomp.fra écrit dans le message de news:
46***********************@news.orange.fr...
Charlie Gordon wrote:
>"CBFalconer" <cb********@yahoo.coma écrit dans le message de news:
46***************@yahoo.com...
>>jacob navia wrote:
... snip ...
Each time you make a change in C you have to rebuild. for many
projects, a change can affect a lot of files. Global changes that
need a full recompilation are done not VERY often, but they are
done...
This means that a compiler that slows down the development process
by just 30-60 seconds per build, it is taking between 15-30
minutes per day to each developer...
To me, the requirement for such a long routine compile indicates
mis-organization. Normally you would only be modifying one source
file, and the rebuild should be limited to recompiling that and
relinking. Sometimes the associated .h file may need revision, and
then (rarely) the work can become considerably larger. So in
general the compilation should not be a problem, however the
linking may be.
I suspect the project Jacob is talking about is actually mostly C++.
Yes, as I said the company uses C++
>Changing a class header file or a template causes a lot of recompilation,
and g++ is notoriously slow.
The linker is VERY slow, and that hits you even when doing
a trivial change.
Your digression on compile times is completely irrelevant to C.
I'm not saying gcc is fast, tinycc is *much* faster and includes the linking
phase too, but your example is irrelevant. C++ projects take a toll on
developpers ? We all know that, we prefer C.
For those who care about build speed, there is a very effective tool called
ccache.
--
Chqrlie.
On 2007-09-18 21:51, Rob Kendrick <nn**@rjek.comwrote:
On Tue, 18 Sep 2007 23:31:30 +0200, jacob navia wrote:
>Of course, only one file is rebuilt. But there is always the link step,
what is not fast really, specially with BIG projects.
Woah, 10 minutes of *linking* ? I think it's time you investigate making
your build system suck less.
I've seen link times in excess of an hour for reasonably-sized programs
(OpenSSH in this case). The +O4 option on the HP ANSI-C compiler causes
global optimization on the whole executable, which can of course only be
done at link time. Of course nobody would use +O4 on an HP system during
the normal edit-compile-test cycle. That's strictly for release
candidates (unless you are looking for a bug which only manifests itself
at that optimization level).
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall" This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: John Smith |
last post by:
Hi
I'm looking for a header-file only STL implementation. I know the vendors
provide one with compilers but often they are either buggy or has some other
problems.
My problem is that under...
|
by: Mark Shelor |
last post by:
Problem: find a portable way to determine whether a compiler supports
the "long long" type of C99.
I thought I had this one solved with the following code:
#include <limits.h>
#ifdef...
|
by: Kobu |
last post by:
In embedded systems (programmed in C), often times structure
declarations are used to group together several status/control/data
registers of external hardware (or even internal registers). The...
|
by: suresh_C# |
last post by:
Dear All,
What is difference between Portable Executable (PE) file and a Assembly?
Thanks,
Mahesh
|
by: pemo |
last post by:
Is C really portable? And, apologies, but this is possibly a little OT?
In c.l.c we often see 'not portable' comments, but I wonder just how
portable C apps really are.
I don't write...
|
by: Richard Giuly |
last post by:
Hello,
I would like to write "portable" C++ code that could theoretically run
on linux, windows, and other platforms, and I'd like to use VS as the
editor/compiler/linker.
The simplest thing...
|
by: rkk |
last post by:
Hi,
Is there an equivalent typeof macro/method to determine the type of a
variable in runtime & most importantly that works well with most known
C compilers?
gcc compiler supports typeof()...
|
by: r.z. |
last post by:
class vector3
{
public:
union
{
float data;
struct
{
float x, y, z;
};
|
by: asit |
last post by:
what is the difference between portable C, posix C and windows C ???
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
