Hi. I'm starting to play arround with the DMD frontend bundled with the
compiler.
My firt big surprise, and not a good one, was that the frontend files are
named with the .c extension, instead of .cpp, .cxx, or anything used for
C++ files. Is there a rationale behind that? I find it very confusing.
Second, I saw the code has a lot of:
#if DEBUG
printf(...);
#endif
(LOG or simply 0 are used too)
This is really annoying and can easily be changed for something like:
#if DEBUG
# define debug(...) printf(__VA_ARGS__)
#else
# define debug(...)
#endif
(I know macros with variable arguments are just in C99, but I think most
compilers has a vendor-specific way of doing it)
And then just write: debug(...);
This makes the code much more readable.
In some places there's a sightly more complicated:
#if DEBUG
if (condition)
printf(...);
#endif
which can be solved by adding a new macro, for example "cdebug" (c for
conditional):
#if DEBUG
# define cdebug(c, ...) ((c) && printf(__VA_ARGS__))
#else
# define cdebug(c, ...)
#endif
And just writing: cdebug(condition, ...);
If you are willing to accept a patch that implement this, I'm willing to
do it.
And please, can you please, please consider on putting the frontend on a
SCM? (git would be great, dsource's svn is ok :).
Thanks!
--
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Fitter, happier, more productive, comfortable, not drinking too much,
regular exercise at the gym (3 days a week),
getting on better with your associate employee contemporaries,

This is really annoying and can easily be changed for something like:
#if DEBUG
# define debug(...) printf(__VA_ARGS__)
#else
# define debug(...)
#endif
(I know macros with variable arguments are just in C99, but I think most
compilers has a vendor-specific way of doing it)

You can do it without varags.
#if DEBUG
# define dprintf(x) printf x
#else
# define dprintf(x)
#endif
So long as you're prepared to call it like this:
dprintf(("Error on line %d",n));
My favorite C trick, though, was always:
#ifdef DEBUG
# define debug
#else
# define debug /##/
#endif
Then you do
debug printf(whatever);
which resolves to
printf(whatever);
in debug mode, but to
// printf(whatever);
in release mode. Now "debug" works almost like in D. Yes, I know,
technically C doesn't support // comments, but I've never yet
encountered a compiler that doesn't understand them.
(I still have to write C sometimes, professionally).
I don't care what language the D compiler is written in, as long as it
works. (Although now that D1 is stable, it would be quite cool to
rewrite it in that).

This is really annoying and can easily be changed for something like:
#if DEBUG
# define debug(...) printf(__VA_ARGS__)
#else
# define debug(...)
#endif
(I know macros with variable arguments are just in C99, but I think most
compilers has a vendor-specific way of doing it)

You can do it without varags.
#if DEBUG
# define dprintf(x) printf x
#else
# define dprintf(x)
#endif
So long as you're prepared to call it like this:
dprintf(("Error on line %d",n));

Yes, but that's a little more uglier and error prone, so if DMC supports
varargs (I can't test it because I don't have Windows, and I can't find a
DMC download for Linux), I'll defenetly go with varargs.

I've used those debug macros in various forms in other projects. Over
time, I just gradually swung back to using the more straightforward #if
method.
This also has evolved into the 'debug' conditional compilation present in D.

My firt big surprise, and not a good one, was that the frontend files are
named with the .c extension, instead of .cpp, .cxx, or anything used for
C++ files. Is there a rationale behind that? I find it very confusing.

When I first started with C++, I carefully named all my h files ".hpp"
and source files ".cpp". Over time, the .hpp was dropped in favor of .h,
and eventually .cpp => .c.
It's not confusing to me because I never mix C and C++ source files in
the same project.

My firt big surprise, and not a good one, was that the frontend files are
named with the .c extension, instead of .cpp, .cxx, or anything used for
C++ files. Is there a rationale behind that? I find it very confusing.

When I first started with C++, I carefully named all my h files ".hpp"
and source files ".cpp". Over time, the .hpp was dropped in favor of .h,
and eventually .cpp => .c.
It's not confusing to me because I never mix C and C++ source files in
the same project.

Well, but other people might look at your sources the first time, not
knowing what language those are actually written in..
Consistency is one of the good measurements for product quality.

My firt big surprise, and not a good one, was that the frontend files
are
named with the .c extension, instead of .cpp, .cxx, or anything used for
C++ files. Is there a rationale behind that? I find it very confusing.

When I first started with C++, I carefully named all my h files ".hpp"
and source files ".cpp". Over time, the .hpp was dropped in favor of
.h, and eventually .cpp => .c.
It's not confusing to me because I never mix C and C++ source files in
the same project.

Well, but other people might look at your sources the first time, not
knowing what language those are actually written in..
Consistency is one of the good measurements for product quality.

But Walter just said he's consistent about it! Too consistent -- always
.c no matter what.
It's consistent, it just doesn't conform with standard practices.
--bb

My firt big surprise, and not a good one, was that the frontend files are
named with the .c extension, instead of .cpp, .cxx, or anything used for
C++ files. Is there a rationale behind that? I find it very confusing.

When I first started with C++, I carefully named all my h files ".hpp" and
source files
".cpp". Over time, the .hpp was dropped in favor of .h, and eventually .cpp =>
.c.
It's not confusing to me because I never mix C and C++ source files in the
same project.

My firt big surprise, and not a good one, was that the frontend files are
named with the .c extension, instead of .cpp, .cxx, or anything used for
C++ files. Is there a rationale behind that? I find it very confusing.

".cpp". Over time, the .hpp was dropped in favor of .h, and eventually .cpp =>
.c.
It's not confusing to me because I never mix C and C++ source files in the
same project.

It's not confusing to you! If you do it in a closed source project, it's
perfectly fine but if you do it in an open source project, it's a bad
thing (TM). You are putting a barrier to people to contribute (and making
D look ugly).
What are the chances that you rename them to a commonly used C++
extension?
And what about the debug stuff. Are you willing to accept patcher or not?
I'm just looking for a "yes" or "no". Please?
Thank you.

Additionally, some IDEs decide what compiler to use based on the
filename extension and will automatically try to use a C compiler
instead of a C++ one if the filename is .c. It doesn't matter for
headers to be called .h since they're not directly compiled. (Even with
pre-compiled headers you pre-compile them by #including them all in a
single source file).
Also editors often decide on what syntax highlighting mode to use based
on the extension.
So it's not just about people getting confused.
--bb

It's not confusing to me because I never mix C and C++ source files in the
same project.

It's not confusing to you! If you do it in a closed source project, it's
perfectly fine but if you do it in an open source project, it's a bad
thing (TM). You are putting a barrier to people to contribute (and making
D look ugly).
What are the chances that you rename them to a commonly used C++
extension?

.c is a commonly used C++ extension, but I understand your point. I'd
also rather not change it, as it's an admittedly personal preference.

And what about the debug stuff. Are you willing to accept patcher or not?
I'm just looking for a "yes" or "no". Please?

Not for just altering the debug print statements, again, it's a personal
preference.

It's not confusing to me because I never mix C and C++ source files
in the same project.

It's not confusing to you! If you do it in a closed source project, it's
perfectly fine but if you do it in an open source project, it's a bad
thing (TM). You are putting a barrier to people to contribute (and making
D look ugly).
What are the chances that you rename them to a commonly used C++
extension?

.c is a commonly used C++ extension, but I understand your point. I'd
also rather not change it, as it's an admittedly personal preference.

You gotta be kidding. I've seen lots of extensions used for C++ code,
but never .c.
file.cpp, file.cc, file.C, file.CC, file.cxx, file.c++, file.C++, yes
yes and yes.
But never file.c.
Calling it "commonly used" is a stretch.
But I think that being a "barrier to contributors" is a stretch as well.
File naming pales in comparison to the other barriers that exist.
--bb

It's not confusing to me because I never mix C and C++ source files
in the same project.

It's not confusing to you! If you do it in a closed source project, it's
perfectly fine but if you do it in an open source project, it's a bad
thing (TM). You are putting a barrier to people to contribute (and
making
D look ugly).
What are the chances that you rename them to a commonly used C++
extension?

.c is a commonly used C++ extension, but I understand your point. I'd
also rather not change it, as it's an admittedly personal preference.

You gotta be kidding. I've seen lots of extensions used for C++ code,
but never .c.
file.cpp, file.cc, file.C, file.CC, file.cxx, file.c++, file.C++, yes
yes and yes.
But never file.c.
Calling it "commonly used" is a stretch.
But I think that being a "barrier to contributors" is a stretch as well.
File naming pales in comparison to the other barriers that exist.
--bb

When I took my first class that introduced C and C++ programming, the
professor said that ".c" was the only standardized extension for C++
files, and that ".cpp",".cc", and ".cxx" were nonstandard and shouldn't
be used.

It's not confusing to me because I never mix C and C++ source files
in the same project.

It's not confusing to you! If you do it in a closed source project,
it's
perfectly fine but if you do it in an open source project, it's a bad
thing (TM). You are putting a barrier to people to contribute (and
making
D look ugly).
What are the chances that you rename them to a commonly used C++
extension?

.c is a commonly used C++ extension, but I understand your point. I'd
also rather not change it, as it's an admittedly personal preference.

You gotta be kidding. I've seen lots of extensions used for C++ code,
but never .c.
file.cpp, file.cc, file.C, file.CC, file.cxx, file.c++, file.C++, yes
yes and yes.
But never file.c.
Calling it "commonly used" is a stretch.
But I think that being a "barrier to contributors" is a stretch as
well. File naming pales in comparison to the other barriers that exist.
--bb

When I took my first class that introduced C and C++ programming, the
professor said that ".c" was the only standardized extension for C++
files, and that ".cpp",".cc", and ".cxx" were nonstandard and shouldn't
be used.

Weird. I mean I don't even think Stroustrup's own book on his own
language uses .c as the extension, so how could it be the "only
standardized extension"?
--bb

When I took my first class that introduced C and C++ programming, the
professor said that ".c" was the only standardized extension for C++
files, and that ".cpp",".cc", and ".cxx" were nonstandard and shouldn't
be used.

You gotta be kidding. I've seen lots of extensions used for C++ code,
but never .c.
file.cpp, file.cc, file.C, file.CC, file.cxx, file.c++, file.C++, yes
yes and yes.
But never file.c.

All I can say is, I have. That's why dmc has a switch to treat .c files
as C++ source, and it has had that switch pretty much from the beginning
(20 years ago), from long before I gave up on using .cpp.

Calling it "commonly used" is a stretch.

C++, from day 1, never standardized on an extension. If it had, this
discussion would be moot.

You gotta be kidding. I've seen lots of extensions used for C++ code,
but never .c.
file.cpp, file.cc, file.C, file.CC, file.cxx, file.c++, file.C++, yes
yes and yes.
But never file.c.

All I can say is, I have. That's why dmc has a switch to treat .c files
as C++ source, and it has had that switch pretty much from the beginning
(20 years ago), from long before I gave up on using .cpp.

My experience only goes back to 10 years. It makes some sense that
people would be using .c back at the very beginnings of C++. Especially
given that Stroustrup didn't specify what the extension should be, and
from what I understand he started out just with the intention of making
C easier to use by adding classes. The initial implementations were
just fancy preprocessors that generated C code, so it makes sense that
the extension then would still be .c. They don't call Qt source code
files .qt just because you have to run that moc preprocessor on them,
after all.

Calling it "commonly used" is a stretch.

C++, from day 1, never standardized on an extension. If it had, this
discussion would be moot.

Indeed. Could have saved a lot of headaches over the years if there had
been one. .cpp is my personal favorite. :-)
--bb

C++, from day 1, never standardized on an extension. If it had, this
discussion would be moot.

I think today ".c++" and "cpp" are rather a de facto standard...
And all my editors and IDEs recognize them as C++ sources.
Where I work the personal preferences are things like the colors to show on
screen used by the syntax highlighting, but not the file extensions to use.
Bye,
bearophile

You gotta be kidding. I've seen lots of extensions used for C++ code,
but never .c.
file.cpp, file.cc, file.C, file.CC, file.cxx, file.c++, file.C++, yes
yes and yes.
But never file.c.
Calling it "commonly used" is a stretch.
But I think that being a "barrier to contributors" is a stretch as well.
File naming pales in comparison to the other barriers that exist.
--bb

You gotta be kidding. I've seen lots of extensions used for C++ code,
but never .c.
file.cpp, file.cc, file.C, file.CC, file.cxx, file.c++, file.C++, yes
yes and yes.
But never file.c.
Calling it "commonly used" is a stretch.
But I think that being a "barrier to contributors" is a stretch as
well. File naming pales in comparison to the other barriers that exist.
--bb

That's a good idea for a search string, but most of those hits have the
'::' in a comment, and if you go look at the actual source files, they
are indeed plain C code.
There's another one that's a SWIG-generated wrapper that looks like it's
meant to be able to compile as either C or C++.
It would be quite surprising if Mozilla contained lots of C++ files
named .c, since their own portability guide says this:
http://developer.mozilla.org/en/docs/C%2B%2B_Portability_Guide#C.2B.2B_filename_extension_is_.cpp
The hit in Xerces appears to be a real C++ file using .c. However it
seems to be an anomoly. If you go look at the full source tree, you
find that it's the only one.
http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/dom/impl/
All the other files in that dir are using .cpp or .hpp
The STLport code is a good real example, though. Big high-profile
project, and the latest source tree has a slew of C++ files called .c.
http://stlport.cvs.sourceforge.net/stlport/STLport/stlport/stl/
HOWEVER, those are all nothing but templates. You have to #include them
(or rather they get #included for you via some chain of #includes when
you say #include <vector>). So really what they are is header files
with a .c extension. There's not really a problem with naming header
files whatever you want to name them, since compilers don't have to
guess what type they are. Other, non-header C++ files in the STL tree
seem to be named .cpp.
--bb

You gotta be kidding. I've seen lots of extensions used for C++ code, but
never .c.
file.cpp, file.cc, file.C, file.CC, file.cxx, file.c++, file.C++, yes yes and
yes.
But never file.c.
Calling it "commonly used" is a stretch.
But I think that being a "barrier to contributors" is a stretch as well. File
naming
pales in comparison to the other barriers that exist.
--bb

You gotta be kidding. I've seen lots of extensions used for C++ code, but
never .c.
file.cpp, file.cc, file.C, file.CC, file.cxx, file.c++, file.C++, yes yes and
yes.
But never file.c.
Calling it "commonly used" is a stretch.
But I think that being a "barrier to contributors" is a stretch as well. File
naming
pales in comparison to the other barriers that exist.
--bb