ques 1.34 c-faq

[Ken Brody]

On 3/13/2014 10:01 AM, BartC wrote:
[...]

I will make the promise that, if and when I release some sizeable project of
mine and it has to be in source form, it will be as simple to compile as a
Hello, World program.)

You mean like this one?

http://www.gnu.org/software/hello/manual/hello.html

 

[BartC]

Thanks. I don't know where I ended up with my search, but it said nothing
about binaries nor even downloads.

But, it's quite a hefty compiler! (28MB just for the main executable.)

[...]

The Visual Studio 2012 installation on my Windows box is 3GB. (The C
compiler [okay, C and C++ compiler] binaries alone are 85MB.)

(My own compiler I'd been using, that compiled to an actual executable,
before I thought it might be time to move to C, was 0.2MB excluding symbols.
That also reported undeclared names without prompting...)

 

[Keith Thompson]

And I see what you mean about having a gcc-compatible interface: you compile
hello.c and up with the output in a.out. Very useful in Windows! And you say
it would be better if all compilers did this...

Yes, that's an odd convention. It has some historical basis, but
nothing that's particularly applicable today. (I think that in early
UNIX history, the compiler and assembler were invoked separately;
"a.out" meant "assembler output".) And a Windows compiler should at
least generate an executable with a ".exe" suffix. (I think gcc on
Cygwin generates "a.exe".)

But that's just the default behavior. If you're using gcc, even on a
Unix-like system, you'd usually write "gcc hello.c -o hello" -- and if
you use "make", it even has a built-in rule that does that.

 

[BartC]

"BartC" <[email protected]> writes:

[Clang for Windows]

Yes, that's an odd convention. It has some historical basis, but
nothing that's particularly applicable today. (I think that in early
UNIX history, the compiler and assembler were invoked separately;
"a.out" meant "assembler output".) And a Windows compiler should at
least generate an executable with a ".exe" suffix. (I think gcc on
Cygwin generates "a.exe".)

Something odder (assuming clang is written in C, or C++), is that all text
output seems to have LF line-endings instead of the CR,LF endings you might
expect in this version specially built for Windows. I thought C was immune
to these problems, as the local runtime system did the conversions needed?
Or has the wrong library been linked in? It's a nuisance anyway.

Another funny thing was Clang not liking lines such as:

#include "/a/b/c.h"

unless they were written as #include "C:/a/b/c.h". Although that might just
be the compiler doing something strange with the current drive setting
(which the other 4 compilers didn't!). (The fact that, immediately after and
within the same IDE session, the normal fine gcc compiler seemed to be
afflicted with the same problem, points towards that.)

(As for performance: for all its size, on my project it generated 30-40%
slower code than gcc, with the same -O3 setting. Although probably still
faster than any non-gcc compiler I've used.)

 

[Keith Thompson]

"BartC" <[email protected]> writes:

[Clang for Windows]

Yes, that's an odd convention. It has some historical basis, but
nothing that's particularly applicable today. (I think that in early
UNIX history, the compiler and assembler were invoked separately;
"a.out" meant "assembler output".) And a Windows compiler should at
least generate an executable with a ".exe" suffix. (I think gcc on
Cygwin generates "a.exe".)

Something odder (assuming clang is written in C, or C++), is that all text
output seems to have LF line-endings instead of the CR,LF endings you might
expect in this version specially built for Windows. I thought C was immune
to these problems, as the local runtime system did the conversions needed?
Or has the wrong library been linked in? It's a nuisance anyway.

C certainly isn't *immune* to such issues, but if a program writes
output to a text stream on Windows, '\n' characters should be translated
to "\r\n" sequences. Are you talking about text written to files, or
text written to standard output?

Another funny thing was Clang not liking lines such as:

#include "/a/b/c.h"

unless they were written as #include "C:/a/b/c.h". Although that might just
be the compiler doing something strange with the current drive setting
(which the other 4 compilers didn't!). (The fact that, immediately after and
within the same IDE session, the normal fine gcc compiler seemed to be
afflicted with the same problem, points towards that.)

As far as the standard is concerned, the mapping of the "..." sequence
to a file name is implementation-defined. Incidentally, that "..."
sequence is *not* syntactically a string literal, which means, among
other things, that if you want to use \ as the delimiter, it's
implementation-defined whether you need to escape it.

But wouldn't it be better to specify a relative path like "b/c.h" or
even "c.h", and use compiler options or some other configuration method
to control where the compiler searches for it? Hardwiring the drive
letter and directory path into your source file seems like a recipe for
disaster.

 

[BartC]

"BartC" <[email protected]> writes:

[Clang on Windows]

C certainly isn't *immune* to such issues, but if a program writes
output to a text stream on Windows, '\n' characters should be translated
to "\r\n" sequences. Are you talking about text written to files, or
text written to standard output?

Probably stdout and stderr, as these are messages from the compiler itself
(not programs compiled with it writing out '\n'). (I see the wrong endings
when output is directed to a file.) Actual file output such as .s
intermediate files. Also existing text files that are part of the
distribution.

(The usual set of .h include files seem to be missing; that might explain
the larger-than-normal executables.)

 

[Ben Bacarisse]

Aargh! I hope not!

I like things to become simpler not more complicated. It was a joy recently,
after a couple of years using gcc, to try out lccwin32 again and see
it whizz through my sources. And any messages were simple, compact and
understandable. (It also reported undeclared functions without being
told!)

I responded to your complaint that compiler options are all different by
suggesting a solution. I did not say that other compilers should be
slow, nor that the messages should be complex or verbose. I did not
evens say that they should have the same defaults. They can be fast,
with simple and compact error messages, whist *still* avoiding the
problem you complained of -- having to "start all over again" finding
out what options do what -- by using the same cli interface.

(I've just looked at clang, with a view to trying it out, but it seems to be
one of those apps only available in source form. It also seems to be part of
llvm, which, last time I checked it out, was an even more ginormous project
than gcc. (I counted 44 /sets/ of documentation for it!

For me, I type "apt-get install clang" and there it is.

I will make the promise that, if and when I release some sizeable project of
mine and it has to be in source form, it will be as simple to compile as a
Hello, World program.)

That's quite hard to get right, but it is an admirable aim.