.c vs .C in Xcode project compilation
mattrobe...@gmail.com
a few files into a command line project created using the c++ command
line wizard.
There were 4 c++ files which I could compile without error at the
command line using g++.
However, one of the files would not compile in Xcode - it kept giving
the error that the
header file line :
class foo {
...had a syntax error before "foo"
There were no includes above this - this was the first line in the .h
file.
I noticed that the other 3 corresponding code files (all also trivial
object definitions I was using as a test) were called [filename].C
while the code file associated with the non-compiling header file was
called [filename].c - that is, the ones with UPPERCASE C as the
extension would compile while the LOWERCASE .c extension would not
compile.
Changning the .c to a .C allowed this trivial class to compile in XCode
and the header file no longer reported any error.
Can anyone please explain to me why this happened? And perhaps also
advise on what other weird naming conventions I must follow in Xcode?
Thanks!
Matt
Tom Harrington
mattrobe...@gmail.com wrote:
> However, one of the files would not compile in Xcode - it kept giving
> the error that the
> header file line :
>
> class foo {
>
> ...had a syntax error before "foo"
>
> There were no includes above this - this was the first line in the .h
> file.
>
> I noticed that the other 3 corresponding code files (all also trivial
> object definitions I was using as a test) were called [filename].C
> while the code file associated with the non-compiling header file was
> called [filename].c - that is, the ones with UPPERCASE C as the
> extension would compile while the LOWERCASE .c extension would not
> compile.
>
> Changning the .c to a .C allowed this trivial class to compile in XCode
> and the header file no longer reported any error.
>
> Can anyone please explain to me why this happened? And perhaps also
> advise on what other weird naming conventions I must follow in Xcode?
The default is to treat foo.c as C and foo.C as C++. It's not an Xcode
thing, it's a gcc thing, but Xcode follows gcc's lead here. Gcc in turn
is just keeping with longstanding practice on Unix. As with so many
other cases, the filename extension is used as a clue to the type of the
file. Your "class" was a syntax error because it was being compiled as
pure C.
You can change the default language for any file in Xcode-- so you could
tell it to treat foo.c as C++ without renaming it. Do this by selecting
the file and choosing File menu --> "Get info". In the info window one
of the options is "file type", and you can select whatever language you
like.
--
Tom "Tom" Harrington
Macaroni, Automated System Maintenance for Mac OS X.
Version 2.0: Delocalize, Repair Permissions, lots more.
See http://www.atomicbird.com/
Michael Ash
> In article <1146952315.3...@j33g2000cwa.googlegroups.com>,
> mattrobe...@gmail.com wrote:
>
>> Changning the .c to a .C allowed this trivial class to compile in XCode
>> and the header file no longer reported any error.
>>
>> Can anyone please explain to me why this happened? And perhaps also
>> advise on what other weird naming conventions I must follow in Xcode?
>
> The default is to treat foo.c as C and foo.C as C++.
It should be noted that relying on this distinction on the Mac is
generally a bad idea. HFS+ is a case-insensitive (although
case-preserving) filesystem, as are others. So "file.c" and "file.C" are
in fact the same file. While the computer should be able to see whether
it's uppercase or lowercase (since it's case-preserving), you never know
when it might do something wird and try to open it as all lowercase or
something.
Much better is to use .cc or .cpp for your C++ files.
--
Michael Ash
Rogue Amoeba Software
Patrick Machielse
> > The default is to treat foo.c as C and foo.C as C++.
>
> It should be noted that relying on this distinction on the Mac is
> generally a bad idea. HFS+ is a case-insensitive (although
> case-preserving) filesystem, as are others. So "file.c" and "file.C" are
> in fact the same file. While the computer should be able to see whether
> it's uppercase or lowercase (since it's case-preserving), you never know
> when it might do something wird and try to open it as all lowercase or
> something.
But that would be a bug. If you are going to whorry about fundamenatal
concepts like case preservation being broken in the future, that's the
beginning of the end. Once you start doing that, soon you'll be naming
your projects "newproject" instead of "new project" too. (now, spaces in
paths really have tripped up the dev tools more than once...)
patrick
Ben Artin
nor...@mail.invalid (Patrick Machielse) wrote:
I totally agree -- I don't think advice on how to use a computer should be given
on the premise that you should be afraid of the computer, which is what this
basically says.
The case-preserving behavior of HFS+ is quite simple, and it does not make it a
bad idea to use case to signify something, as long as you don't ever expect to
have two files in one folder differ in nothing but their case.
Ben
--
If this message helped you, consider buying an item
from my wish list: <http://artins.org/ben/wishlist>
I changed my name: <http://periodic-kingdom.org/People/NameChange.php>
Michael Ash
And Xcode is *full* of bugs.
Consider this case:
$ cat > test.C
class foo {};
$ gcc -c test.C
$ gcc -c test.c
test.c:1: error: parse error before 'foo'
test.c:1: error: syntax error before '{' token
It does not have to be a bug in the filesystem, as you appear to assume.
It merely has to be a bug in Xcode's handling of something, somewhere,
which happens to lowercase the extension, and you lose.
It should be noted that I ceased putting spaces in my project names long
ago. Yes, the tools *should* deal with this properly, but there's still
too much that does not. In the end, I prefer being pragmatic and avoiding
behaviors that are likely to cause errors, regardless of who's fault it
ultimately is.
Eric Albert
Michael Ash <mi...@mikeash.com> wrote:
I'm pretty sure Xcode doesn't have bugs in this area. There's too much
code out there which expects '.C' to be C++, so if this broke in any
pre-release of Xcode Apple would hear about it immediately.
As Ben said, HFS+ is case-preserving, so Xcode would have to go out of
its way to explicitly change the case of a filename to cause .C files to
be treated like .c files.
-Eric
--
Eric Albert ejal...@cs.stanford.edu
http://outofcheese.org/
glenn andreas
Eric Albert <ejal...@cs.stanford.edu> wrote:
You mean like trying to describe something to another person on the
phone?
"So name the file foo dot c"
"it doesn't work"
(Cue bad Abbott & Costello routine here)
I also seem to remember that at one time you'd get problems if you used
a USB memory drive to move files around (but I don't remember exactly
how it happened - may have had something to do with moving stuff between
OS 9 and OS X).
So depending on ".C" for C++ code is just one of those "may not cause a
problem for you today, but might for somebody else tomorrow"
Gregory Weston
<gandreas-F4DD70...@sn-ip.vsrv-sjc.supernews.net>,
glenn andreas <gand...@no.reply> wrote:
> I also seem to remember that at one time you'd get problems if you used
> a USB memory drive to move files around (but I don't remember exactly
> how it happened - may have had something to do with moving stuff between
> OS 9 and OS X).
Most likely the underlying issue was that the USB device was formatted
FAT.
I really don't get the change Apple made in how files are stored on FAT
volumes. I'm willing to accept that there may be some esoteric benefit
in the mechanism used in OS X over the prior one, but I'm appalled that
it doesn't even know how to _read_ the old way any more.
G
--
"Congurutulation!!!" - The subject line on some spam I received recently.
I have no idea what it means, but it's such a cool "word" (by which I mean
pronouncable sequence of letters) regardless.
Tom Harrington
> Consider this case:
>
> $ cat > test.C
> class foo {};
> $ gcc -c test.C
> $ gcc -c test.c
> test.c:1: error: parse error before 'foo'
> test.c:1: error: syntax error before '{' token
>
> It does not have to be a bug in the filesystem, as you appear to assume.
> It merely has to be a bug in Xcode's handling of something, somewhere,
> which happens to lowercase the extension, and you lose.
You've encountered situations where Xcode has renamed a file, changing
the case of its extension?
Mat Cvetic
This is not an Xcode bug, it's a gcc "feature". I just tried it on a
Linux box and got the same kind of error. Remember Xcode, in addition to
a lot of other things, really just wraps gcc and gdb. If Apple modified
gcc, I'm sure this wasn't one of their changes.
I thought I saw in Disk Utility where you can tell a filesystem whether
you wanted it to be case sensitive. That could cause some problems in
this arena.
For me, I just name my c files foo.c and my c++ files foo.cpp. I think
foo.cc will also work for c++ files.
Michael Ash
> In article <11470173...@nfs-db1.segnet.com>,
> Michael Ash <mi...@mikeash.com> wrote:
>
>> Consider this case:
>>
>> $ cat > test.C
>> class foo {};
>> $ gcc -c test.C
>> $ gcc -c test.c
>> test.c:1: error: parse error before 'foo'
>> test.c:1: error: syntax error before '{' token
>>
>> It does not have to be a bug in the filesystem, as you appear to assume.
>> It merely has to be a bug in Xcode's handling of something, somewhere,
>> which happens to lowercase the extension, and you lose.
>
> You've encountered situations where Xcode has renamed a file, changing
> the case of its extension?
To be entirely honest, I haven't encountered this bug at all. Partly
because I don't use C++ that often, but also I've never had code that used
the .c/.C convention so it would be impossible for it to have happened to
me. I'm just repeating warnings I've heard elsewhere, probably with some
uninformed speculation sprinkled on the top.
However, this wouldn't have to be triggered by Xcode renaming a file; it
merely has to have a situation where Xcode somehow has the wrong path to a
file. This could happen, for example, if you renamed the file outside of
Xcode to have the same name but different case; Xcode would keep its path
reference to the old path, which would still work, but presumably produce
results such as the above, because it's using the wrong case to refer to
it.
But again, since I haven't seen it, I can't say what exactly would cause
it, I can only speculate. I happen to think that distinctions based solely
on case are a bad idea in general, whether we're talking about file names
or C identifiers. The hypothetical problem here is just another, minor
reason for it.
Tom Harrington
<invalid-BF4651...@network-065-024-007-027.columbus.rr.com>,
Mat Cvetic <inv...@invalid.net> wrote:
> For me, I just name my c files foo.c and my c++ files foo.cpp. I think
> foo.cc will also work for c++ files.
FYI, you can get a list of all of these defaults in the gcc man page,
under the section "Options Controlling the Kind of Output".