Hello aJ,
"BCS" <n...@anon.com> wrote in message
news:a6268ffbc7d8cc213dc5fee...@news.digitalmars.com...
and then writing the implementation in a .d file... ah... that's a
bad idea (for one there is no error checking between a .di file and
the implementation file).
Now you get what I was saying above! Yes?
Ohhhh! You mean that .di files are NOT like C++ header files. I think
I see what you mean. Other people have told me I could work the same
way I currently do in C++, but apparently, there is a big paradigm
shift in the development model between C++ and D. I never even
considered that D meant changing the process. Very, very good info I
am getting here. Maybe I asked too soon about a D IDE, as I can't
invest as much time (brainpower actually) as required to get my mind
around the "whole smear" right now. I may just concentrate on select
features of D for now (as I have been doing).
Maybe some background on how import works:
The line "import foo;" causes DMD to go looking for the file "foo.di" if
it can't find it, it then goes looking for "foo.d" if it finds either, it
then goes on and parses the file for the info it needs. IIRC, once it has
located the file DMD doesn't care which it is, the processing is the same.
When DMD is compiling foo.d it never even looks for foo.di and in fact if
you compile foo.d and bar.d (where bar.d imports foo) DMD might well be free
to never even look at foo.di even if it exists. DMD assumes that x.di and
x.d are identical in every way that it cares about.
D goes off the point that the ONLY reason that C doesn't extract the info
from other .c files and instead use a preprocessor to tack a pile of files
together, was that back in the good old days, computers just didn't have
enough memory to do that.
