www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - scope keyword - a maintenance nightmare?

reply Guenther Brunthaler <gb dont.spam.me.invalid> writes:
When I evaluated D some time ago, I found it very interesting and promising.

I found its "Resource Acquisition Is Initialization" (RAII) paradigm especially
appealing.

It really looked like a good candidate for replacing C++ at that time.

After toying around a couple of days with D, however, I found at least the
following reasons why I chose *not* to use D, and rather stick with C++:

* While the closed source Digital Mars compiler really created small and nice
executables, the GCC-backend created executables multiple times that size

* There is is no equivalent to MODULA 2s "Definition Modules". While I think it
is a good idea to get rid of C++'s primitive "header" files, there must still
be some means of separating interface descriptions from the actual code.
Otherwise, you always have to ship the complete source code to anyone who just
wants to use some interface as a client. Consider writing a plugin for
OpenOffice.org that way...

* Maintenance-Nightmare with "auto" (now "scope").

When checking http://www.digitalmars.com/d/class.html for the new "scope"-class
feature in more detail, I unfortunately had to learn that only half of my
critique on D's synchronous destructors has been rendered obsolete by the new D
2.0 design.

What they have actually done was renaming "auto" into "scope", and forcing to
add the "scope" declarator to both the class declaration as well as to object
variable definitions.

While this is clearly an improvement, because the compiler can now detect
missing "scope" declarators in object variable definitions and give an error
message, it still does not solve the problem that it is necessary to write
"scope" at the object variable definitions.

This can and will become a problem in evolving projects.

Of course, in a perfect world each application will be completely designed
before even the first line of code is written.

In such an optimal scenario, all the classes will be properly defined before
the actual coding starts, and for each class it will be thus known in advance
whether it requires a "scope" declarator or not.

In this perfect world, it will always be clear from the beginning that all the
object variables ever defined for objects of such classes must also include the
"scope" declarator.

But in the harsh reality of real life, things rarely if ever work out as
smoothly as in our perfect-world scenario.

Real programs evolve over time.

It is quite common to add functionality to classes later which no-one has
thought of when they have been designed in the first place.

This is especially true in open source projects, where multiple external
developers add code to an existing project, adding things the original author
might have never dreamt of.

Now imagine there is a D class in such a project which initially did not manage
any resources but memory.

Such classes usually don't have any special destructors, because they leave it
to D's garbage collector to eventually deallocate the memory. Also, as such
classes do not control any particular operating system resources, there is no
need to declare them as "scope". And of course, no object variable throughout
the project will have been declared "scope" in order to match the class
declaration.

Let's assume 50 developer are working on such a project.

What happens if any of them decides to add a feature to our class which
requires controlling some operating system resource other than memory - say the
handle of a class-internal log file?

Note that the developer only added functionality to that class by adding some
sort of logging framework interface to it; this is new functionality which does
not interfere with any existing functionality if the class.

Adding such functionality is in fact quite common, and has never been a problem
in C++: In this case, the header file will be updated and all dependent source
files will have to be recompiled - a process automatically taken care of by the
"make" utility (assuming a correctly written Makefile).

But the existing C++ source files do not have to be modified in any way because
of this change.

Not so in D.

As adding something as a logfile feature to a class in a well-co-ordinated way
usually requires some cleanup to be done in the destructor (such as closing the
logfile) and this cleanup should be done in a predictable manner, it is
necessary to convert the non-"scope" class into a "scope"-class.

But in contrary to C++, it is not enough to add "scope" to the class
declaration in D.

No, in addition to that, all the source files of all the 50 programmers in the
project have to be scanned for object variables defined for this class, and
"scope" has to be added to any such instances found.

Just consider the "fun" those programmers might have, especially in a
distributed development scenario, when they note their code no longer compiles
after each couple of updates they receive from the main version control
repository, and forces them to add dozens of "scope" declarations to their
variable definitions, because "scope" has been added to the declaration of some
class they are using.

I consider such a situation to be a maintenance nightmare.

The solution to that problem should also be obvious: The requirement to repeat
the "scope" keyword from object variable definitions has to be dropped.

It seems to be unnessesary anyway, because the compiler will find the "scope"
when it looks at the class declaration; it is pure nonsense to repeat that
declarator at each object variable definition for that class over and over
again. (That is, nonsense from the view of an application developer programming
in D. Perhaps there is good reason to do so from a language designer's point of
view. But that excuse won't help avoid the maintenance problem.)

Summing up: By changing "auto" into "scope", D 2.0 has been updated from
"nearly unusable" to "just unmaintainable", at least for large-scale projects
which are have a design based on RAII.

For smaller tasks D might be OK - but then, why not using a simpler language
like Python, Perl or JAVA instead? (And Python, albeit "just a scripting
language", is even more powerful than D regarding RAII, because it already has
synchronous destructors - no need for any "scope"-like declarations there. Same
for Perl.)

Another problem of D is inherent from its design decision to use garbage
collection: As http://www.digitalmars.com/d/garbage.html states,
Zitat:
All threads other than the garbage collector thread must be halted while the
collection is in progress.

In other words, even the most high-sophisticated multi-threaded web-server
written in D must be expected to take a nap at any time - and all threads
running will have to take a nap, too. Great - that was exactly what
multi-threading was made for. :( And no-one can say how long this nap will
actually take, because
Zitat:

The time it takes for a collection to run is not bounded. While in practice it
is very quick, this cannot be guaranteed.

Such interruptions of normal service might be tolerable in many situations, but
not in all.

D is therefore especially not well suited for real-time applications.

Of course, JAVA has the same problems. But it is D and not JAVA claiming C++'s
crown.

Or let's put it the other way: D might be a valid competitor to JAVA, but it
still has not got what it takes to replace C or C++ as system programming
languages. It just takes more to challenge C++ than D can provide at the moment.

On the other hand, D is still an evolving language, and so there is still a
chance left for hope that those shortcomings will eventually be eliminated.

=====

Note to the reader: I originally posted this article in a slightly modified
form at



where other forum members encouraged me to also post it here, because it might
perhaps provide some ideas to improve D even further.

Personal mail can be sent to me if necessary via the Gentoo forum, follow the
link above.
Aug 17 2007
next sibling parent Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Guenther Brunthaler wrote:

 * While the closed source Digital Mars compiler really created small and nice
 executables, the GCC-backend created executables multiple times that size


Running 'strip' makes them somewhat smaller. You might want to ask on the D.gnu
newsgroup about why they grow so big.


 * There is is no equivalent to MODULA 2s "Definition Modules". While I think
 it is a good idea to get rid of C++'s primitive "header" files, there must
 still be some means of separating interface descriptions from the actual
 code. Otherwise, you always have to ship the complete source code to anyone
 who just wants to use some interface as a client. Consider writing a plugin
 for OpenOffice.org that way...


http://www.digitalmars.com/d/dcompiler.html#interface_files

Unfortunately, this only separates interface descriptions from object code. What
I miss is the ability to define a function's type and its implementation in two
different locations.
Aug 17 2007
prev sibling next sibling parent Radu <radu.racariu void.space> writes:
Guenther Brunthaler wrote:


 When I evaluated D some time ago, I found it very interesting and promising.

 I found its "Resource Acquisition Is Initialization" (RAII) paradigm
especially appealing.

 It really looked like a good candidate for replacing C++ at that time.

 After toying around a couple of days with D, however, I found at least the
following reasons why I chose *not* to use D, and rather stick with C++:

 * While the closed source Digital Mars compiler really created small and nice
executables, the GCC-backend created executables multiple times that size

   


strange, never tested myself but obviously it's a gdc problem not at D 
general problem

 * There is is no equivalent to MODULA 2s "Definition Modules". While I think
it is a good idea to get rid of C++'s primitive "header" files, there must
still be some means of separating interface descriptions from the actual code.
Otherwise, you always have to ship the complete source code to anyone who just
wants to use some interface as a client. Consider writing a plugin for
OpenOffice.org that way...

   


it is .di files that are a general description file (headers). you can 
generate them by using dmd -H command. problems still exist with 
templates (as with c++)

 * Maintenance-Nightmare with "auto" (now "scope").

   


*very long read :)* anyhow scope classes are  indeed somehow strange to 
use and especially design as there is limited scope (no pun intended) on 
their usage. I for one use only the scope storage declaration for 
local+stack allocated classes.
Aug 17 2007
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Guenther Brunthaler wrote:

 
 * While the closed source Digital Mars compiler really created small and nice
executables, the GCC-backend created executables multiple times that size


Valid point, though this isn't really a problem with D.


 * There is is no equivalent to MODULA 2s "Definition Modules". While I think
it is a good idea to get rid of C++'s primitive "header" files, there must
still be some means of separating interface descriptions from the actual code.
Otherwise, you always have to ship the complete source code to anyone who just
wants to use some interface as a client. Consider writing a plugin for
OpenOffice.org that way...


Sure there are.  In fact, DMD offers the -H option to generate header 
files during compilation.


 * Maintenance-Nightmare with "auto" (now "scope").


I'm not sure I understand, but more later I suppose.


 When checking http://www.digitalmars.com/d/class.html for the new
"scope"-class feature in more detail, I unfortunately had to learn that only
half of my critique on D's synchronous destructors has been rendered obsolete
by the new D 2.0 design.
 
 What they have actually done was renaming "auto" into "scope", and forcing to
add the "scope" declarator to both the class declaration as well as to object
variable definitions.


It is exactly the same in 1.0, unless I'm missing something.  The only 
change I am aware of regarding this was the switch from "auto" to 
"scope" as the qualifier to use.


 While this is clearly an improvement, because the compiler can now detect
missing "scope" declarators in object variable definitions and give an error
message, it still does not solve the problem that it is necessary to write
"scope" at the object variable definitions.
 
 This can and will become a problem in evolving projects.


How so?  Personally, I think that not requiring "scope" at the point of 
declaration would be more of a maintenance problem.  Without some sort 
of visual cue that a reference variable is scoped, it would be easy to 
unknowingly return references to destroyed objects from functions, etc.


 It is quite common to add functionality to classes later which no-one has
thought of when they have been designed in the first place.


Certainly.  But it is generally a fundamental change in behavior to make 
a non-scoped class scoped.  Also, I don't believe it is always necessary 
to place the "scope" qualifier on the class definition.  In fact, I 
rarely use it (possibly a mistake on my part).


 As adding something as a logfile feature to a class in a well-co-ordinated way
usually requires some cleanup to be done in the destructor (such as closing the
logfile) and this cleanup should be done in a predictable manner, it is
necessary to convert the non-"scope" class into a "scope"-class.


I disagree.  There are many instances where the lifetime of an object 
must be deterministic but must also exist beyond the scope of a function 
call.  The scope qualifier does not apply here.


 But in contrary to C++, it is not enough to add "scope" to the class
declaration in D.
 
 No, in addition to that, all the source files of all the 50 programmers in the
project have to be scanned for object variables defined for this class, and
"scope" has to be added to any such instances found.
 
 Just consider the "fun" those programmers might have, especially in a
distributed development scenario, when they note their code no longer compiles
after each couple of updates they receive from the main version control
repository, and forces them to add dozens of "scope" declarations to their
variable definitions, because "scope" has been added to the declaration of some
class they are using.
 
 I consider such a situation to be a maintenance nightmare.


I think a greater maintenance nightmare would the the lack of "scope" at 
the point of declaration, as it would be likely to cause a segfault if 
the maintainer is not aware that a particular type is scoped.


 Another problem of D is inherent from its design decision to use garbage
collection: As http://www.digitalmars.com/d/garbage.html states,
 Zitat:
 All threads other than the garbage collector thread must be halted while the
collection is in progress.
 
 In other words, even the most high-sophisticated multi-threaded web-server
written in D must be expected to take a nap at any time - and all threads
running will have to take a nap, too. Great - that was exactly what
multi-threading was made for. :( And no-one can say how long this nap will
actually take, because
 Zitat:
 
 The time it takes for a collection to run is not bounded. While in practice it
is very quick, this cannot be guaranteed.


This is true of the current garbage collector implementation.  There are 
real-time garbage collectors available which do provide guarantees about 
delay however.  That said, it's not entirely clear how easily such a GC 
would map into D.


 Such interruptions of normal service might be tolerable in many situations,
but not in all.
 
 D is therefore especially not well suited for real-time applications.


See above.  For what it's worth, the GCs to which I am referring are 
implemented for Java.


 Or let's put it the other way: D might be a valid competitor to JAVA, but it
still has not got what it takes to replace C or C++ as system programming
languages. It just takes more to challenge C++ than D can provide at the moment.


Since C++ will be adding garbage collection in the next iteration of its 
standard, I don't see its presence in D as a particularly strong 
argument for why D cannot compete with C++.


Sean
Aug 17 2007
parent reply James Dennett <jdennett acm.org> writes:
Sean Kelly wrote:

 Guenther Brunthaler wrote:


[snip]


 Or let's put it the other way: D might be a valid competitor to JAVA,
 but it still has not got what it takes to replace C or C++ as system
 programming languages. It just takes more to challenge C++ than D can
 provide at the moment.


 
 Since C++ will be adding garbage collection in the next iteration of its
 standard, I don't see its presence in D as a particularly strong
 argument for why D cannot compete with C++.


There's one fundamental difference: C++ language features
and standard library are GC-neutral, i.e., will work with
or without GC.  GC is more inherent to D (which means that
D can benefit from certain simplifications, but also that
you can't use so much of D if you're in a situation where
GC isn't an acceptable option).

-- James
Aug 18 2007
next sibling parent Sean Kelly <sean f4.ca> writes:
James Dennett wrote:

 Sean Kelly wrote:

 Guenther Brunthaler wrote:


 
 [snip]
 

 Or let's put it the other way: D might be a valid competitor to JAVA,
 but it still has not got what it takes to replace C or C++ as system
 programming languages. It just takes more to challenge C++ than D can
 provide at the moment.


 Since C++ will be adding garbage collection in the next iteration of its
 standard, I don't see its presence in D as a particularly strong
 argument for why D cannot compete with C++.


 
 There's one fundamental difference: C++ language features
 and standard library are GC-neutral, i.e., will work with
 or without GC.  GC is more inherent to D (which means that
 D can benefit from certain simplifications, but also that
 you can't use so much of D if you're in a situation where
 GC isn't an acceptable option).


True enough.  But for the record, the only D feature that absolutely 
relies on garbage collection is associative arrays.  Normal arrays can 
be used without GC so long as concatenation operations are excluded, and 
the remaining features are all fine.  The greatest difference between D 
and C++ for memory management is the lack of object value semantics in 
D, since smart pointers have become such a popular tool in C++.  It's 
probably more appropriate to compare D to C here.


Sean
Aug 18 2007
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
James Dennett wrote:

 There's one fundamental difference: C++ language features
 and standard library are GC-neutral, i.e., will work with
 or without GC.  GC is more inherent to D (which means that
 D can benefit from certain simplifications, but also that
 you can't use so much of D if you're in a situation where
 GC isn't an acceptable option).


I don't agree. While the library relies on gc, very little of the D core 
language itself relies on it - only associative arrays, and array 
resizing and concatenation does.

The latter array operations can also be done in D without using the gc, 
it's just more convenient to use the gc.
Aug 18 2007
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Guenther Brunthaler wrote:

 * There is is no equivalent to MODULA 2s "Definition Modules". While I think
it is a good idea to get rid of C++'s primitive "header" files, there must
still be some means of separating interface descriptions from the actual code.
Otherwise, you always have to ship the complete source code to anyone who just
wants to use some interface as a client. Consider writing a plugin for
OpenOffice.org that way...


Like others have said, D has .di files that let you separate interface 
from implementation.  And the nice thing is the compiler can even 
generate them for you.  Unfortunately what it generates is pretty ugly. 
  It doesn't seem to expect that humans will be reading them for some 
reason.  But there's no reason why it couldn't do a better job.


 * Maintenance-Nightmare with "auto" (now "scope").


I don't think scope is really meant to be used in the way that you want 
to use it.  Scope means the class is destroyed when it goes out of 
scope.  It is only meant to be for classes used within one scope. 
Period.  So if you had a pre-existing class that was already in use in 
lots of code, chances are good that they would be violating this "only 
one scope" rule, for instance by returning the scope class from a 
function.  So scope simply doesn't aim to be a general purpose mechanism 
for deterministic destruction.  It's probably most like using auto_ptr 
in C++.

What you want seems to be more like a reference counting scheme, like a 
C++ boost::shared_ptr, which gets destroyed immediately when all 
outstanding references to it are gone.  That would indeed be a nice 
addition to D, and has been discussed before.  It would be much more 
widely useful than scope.

--bb
Aug 17 2007
next sibling parent Sean Kelly <sean f4.ca> writes:
Bill Baxter wrote:

 
 Like others have said, D has .di files that let you separate interface 
 from implementation.  And the nice thing is the compiler can even 
 generate them for you.  Unfortunately what it generates is pretty ugly. 
  It doesn't seem to expect that humans will be reading them for some 
 reason.  But there's no reason why it couldn't do a better job.


For what it's worth, I have the Tango snapshot process run uncrustify on 
these files before packaging them.  The result still isn't as good as a 
hand-crafted version, but it's readable.


Sean
Aug 17 2007
prev sibling parent reply Guenther Brunthaler <gb dont.spam.me.invalid> writes:
Bill Baxter Wrote:


 It doesn't seem to expect that humans will be reading them for some 
 reason.  But there's no reason why it couldn't do a better job.


I agree.

di files are exactly the type of thing I was looking for.

And even if they don't look as beautiful as manually-written files - in C++
there isn't even a way to extract header files automatically from the source
files.

There is also no-one stopping the developer from manually "beautifying" what
D's .di file extractor has output.

If di files only were part of the language rather than optional extensions!


 C++ boost::shared_ptr, which gets destroyed immediately when all 
 outstanding references to it are gone.  That would indeed be a nice 
 addition to D, and has been discussed before.


Well, in C++ object destruction is also not based on reference counts, and RAII
still works fine.

Perl and Python already implement destructors the reference-counted way, and it
surely is a nice feature to have at one's disposal.

But it's a convenience feature, and one can as well live without it with a
little bookkeeping effort: In C++ it is quite possible to add an object
controlling a resource as an instance data member to some other object which
has dynamically controlled life-time, i. e. allocated with "new" rather than on
the stack.

But the predictable automated destruction still works: As soon as the
containing object gets destroyed by "delete", the destructor of the contained
instance-data sub-object will be triggered and clean up the resource as
expected.

This allows the outer object's lifetime to be controlled by whatever means
considered appropriate, may it be lexical scope, reference counting or even
some other technique.

I actually assumed the "scope" keyword would work in a quite similar way in D!

But, if i got you right, are you suggesting "scope" only works on a lexical
scope basis?

That it, a "scope" class object's lifetime does *not* depend on the lifetime of
the object the variable is allocated within (such as the lexical scope *or*
another object), but is *always* controlled by the lifetime of the lexical
scope only?

That would be indeed a bad thing, at least for the way I use RAII.
Aug 17 2007
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Guenther Brunthaler" <gb dont.spam.me.invalid> wrote in message 
news:fa610v$1j33$1 digitalmars.com...

 If di files only were part of the language rather than optional 
 extensions!


But they _are_, as far as I know, part of the language.  They're probably 
just not documented as well as they could be (like many other features).


 I actually assumed the "scope" keyword would work in a quite similar way 
 in D!

 But, if i got you right, are you suggesting "scope" only works on a 
 lexical scope basis?

 That it, a "scope" class object's lifetime does *not* depend on the 
 lifetime of the object the variable is allocated within (such as the 
 lexical scope *or* another object), but is *always* controlled by the 
 lifetime of the lexical scope only?


You've got it right, and I agree, we need 'scope' to be extended to mean 
'the lifetime of this object is dependent upon where it was created'.  It 
would probably greatly reduce the need for the GC in many instances in fact, 
leaving the GC to deal with true garbage, rather than objects which just 
happened to be orphaned when the data structure they were part of was no 
longer needed.
Aug 18 2007
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:fa6s2j$2s36$1 digitalmars.com...

 "Guenther Brunthaler" <gb dont.spam.me.invalid> wrote in message 
 news:fa610v$1j33$1 digitalmars.com...

 If di files only were part of the language rather than optional 
 extensions!


 But they _are_, as far as I know, part of the language.  They're probably 
 just not documented as well as they could be (like many other features).


And I just noticed your other post, so nevermind :)
Aug 18 2007
prev sibling next sibling parent reply Guenther Brunthaler <gb dont.spam.me.invalid> writes:
Deewiant Wrote:


 http://www.digitalmars.com/d/dcompiler.html#interface_files
 
 Unfortunately, this only separates interface descriptions from object code.
What


Thank you for pointing that out!

It's a new feature too which I did not know about yet. It certainly wasn't
there when I evaluated the language the first time.

Sounds pretty useful. Seems to be more or less what I wanted.

However, there is one thing left in the linked web page above like which I
still find rather disturbing:


 But they are not required in the way that C++ header files are, and they are
 not part of the D language. They are a feature of the compiler, and serve
 only as an optimization of the build process.


If they are not part of the language, then one is at the mercy of a compiler to
provide them! And in fact, every compiler could do it its own way, using a
different layout or even a different syntax if it wants to.

It therefore seems more like the "precompiled header files" feature of some
C/C++ compilers to me: While clearly useful, not all compilers do support it,
and precompiled header files are typically not compatible between the different
vendor's implementations.

So let's hope .di files actually become part of the D language standard in a
future revision of the language!
Aug 17 2007
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Guenther Brunthaler wrote:

 Deewiant Wrote:
 

 http://www.digitalmars.com/d/dcompiler.html#interface_files

 Unfortunately, this only separates interface descriptions from object code.
What


 
 Thank you for pointing that out!
 
 It's a new feature too which I did not know about yet. It certainly wasn't
there when I evaluated the language the first time.
 
 Sounds pretty useful. Seems to be more or less what I wanted.
 
 However, there is one thing left in the linked web page above like which I
still find rather disturbing:
 

 But they are not required in the way that C++ header files are, and they are
 not part of the D language. They are a feature of the compiler, and serve
 only as an optimization of the build process.


 
 If they are not part of the language, then one is at the mercy of a compiler
to provide them! And in fact, every compiler could do it its own way, using a
different layout or even a different syntax if it wants to.
 
 It therefore seems more like the "precompiled header files" feature of some
C/C++ compilers to me: While clearly useful, not all compilers do support it,
and precompiled header files are typically not compatible between the different
vendor's implementations.
 
 So let's hope .di files actually become part of the D language standard in a
future revision of the language!



Whoa, I hadn't noticed that.  Yes I agree.  While I'm a big fan of open 
source, support for hiding implementation is still a very real 
requirement in the many corners of the corporate world.

--bb
Aug 17 2007
prev sibling next sibling parent BCS <ao pathlink.com> writes:
Reply to Guenther,


 Deewiant Wrote:
 

 http://www.digitalmars.com/d/dcompiler.html#interface_files
 
 Unfortunately, this only separates interface descriptions from object
 code. What
 


 Thank you for pointing that out!
 
 It's a new feature too which I did not know about yet. It certainly
 wasn't there when I evaluated the language the first time.
 
 Sounds pretty useful. Seems to be more or less what I wanted.
 
 However, there is one thing left in the linked web page above like
 which I still find rather disturbing:
 

 But they are not required in the way that C++ header files are, and
 they are not part of the D language. They are a feature of the
 compiler, and serve only as an optimization of the build process.
 


 If they are not part of the language, then one is at the mercy of a
 compiler to provide them! And in fact, every compiler could do it its
 own way, using a different layout or even a different syntax if it
 wants to.
 
 It therefore seems more like the "precompiled header files" feature of
 some C/C++ compilers to me: While clearly useful, not all compilers do
 support it, and precompiled header files are typically not compatible
 between the different vendor's implementations.
 
 So let's hope .di files actually become part of the D language
 standard in a future revision of the language!
 


It isn't quite as good as being part of the language, but .di files are just 
D code without the function bodies. If you ship object code, and a .di file, 
then the worst that can happen is that the end user needs to rename the file 
as a .d file. Heck, even if you use a compiler that doesn't generate .di 
files, you can still run your code through one that does and then use the 
files with whatever compiler you want.
Aug 17 2007
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Guenther Brunthaler wrote:
...

 However, there is one thing left in the linked web page above like which I
still find rather disturbing:
 

 But they are not required in the way that C++ header files are, and they are
 not part of the D language. They are a feature of the compiler, and serve
 only as an optimization of the build process.


 
 If they are not part of the language, then one is at the mercy of a compiler
to provide them! And in fact, every compiler could do it its own way, using a
different layout or even a different syntax if it wants to.


Is that really a problem? Practically speaking, it could be done by some 
tool too. D is far easier to parse than C++ so I don't think this is a 
difficult thing to achieve. IIRC, in C++ the whole interface / 
implementation file seperation thing is not standardized either.
Aug 18 2007
prev sibling parent Carlos Santander <csantander619 gmail.com> writes:
Guenther Brunthaler escribió:

 Deewiant Wrote:
 

 http://www.digitalmars.com/d/dcompiler.html#interface_files
 
 Unfortunately, this only separates interface descriptions from object code.
 What


 
 Thank you for pointing that out!
 
 It's a new feature too which I did not know about yet. It certainly wasn't
 there when I evaluated the language the first time.
 
 Sounds pretty useful. Seems to be more or less what I wanted.
 
 However, there is one thing left in the linked web page above like which I
 still find rather disturbing:
 

 But they are not required in the way that C++ header files are, and they
 are not part of the D language. They are a feature of the compiler, and
 serve only as an optimization of the build process.


 
 If they are not part of the language, then one is at the mercy of a compiler
 to provide them! And in fact, every compiler could do it its own way, using a
 different layout or even a different syntax if it wants to.
 
 It therefore seems more like the "precompiled header files" feature of some
 C/C++ compilers to me: While clearly useful, not all compilers do support it,
 and precompiled header files are typically not compatible between the
 different vendor's implementations.
 
 So let's hope .di files actually become part of the D language standard in a
 future revision of the language!


I'm guessing all it means is that you don't need to provide that feature in 
order to create a D compiler. As Lutger said, if your compiler doesn't have
that 
feature, you can use an external tool that has it. In fact, I think that's how 
this feature got implemented in the first place, but I'm not 100% sure.

-- 
Carlos Santander Bernal
Aug 18 2007
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Guenther Brunthaler wrote:

 * There is is no equivalent to MODULA 2s "Definition Modules". While
 I think it is a good idea to get rid of C++'s primitive "header"
 files, there must still be some means of separating interface
 descriptions from the actual code. Otherwise, you always have to ship
 the complete source code to anyone who just wants to use some
 interface as a client. Consider writing a plugin for OpenOffice.org
 that way...


There is such a mechanism, .di files. They can be written either 
manually, or automatically generated with the -H switch.


 * Maintenance-Nightmare with "auto" (now "scope").


[...]

 
 Just consider the "fun" those programmers might have, especially in a
 distributed development scenario, when they note their code no longer
 compiles after each couple of updates they receive from the main
 version control repository, and forces them to add dozens of "scope"
 declarations to their variable definitions, because "scope" has been
 added to the declaration of some class they are using.
 
 I consider such a situation to be a maintenance nightmare.


You have a good point in questioning the redundancy of requiring the 
scope keyword on declarations if it is on the class. But I disagree that 
it's a maintenance nightmare. Tedious, possibly. But a nightmare, no, 
because the compiler will tell you where the changes need to be made. A 
nightmare is when the compiler doesn't say anything, but the recompiled 
code no longer works.

I can point to several such nightmares in C++ that are plugged in D - 
see the recent thread about slicing of polymorphic objects for one example.



 The time it takes for a collection to run is not bounded. While in
 practice it is very quick, this cannot be guaranteed.
 
 Such interruptions of normal service might be tolerable in many
 situations, but not in all.
 
 D is therefore especially not well suited for real-time applications.


I've written some real time code in the past, and have talked to people 
who write real time code professionally. You cannot use new() in C++ in 
real time code; you cannot even use malloc()! Why? Because the execution 
time of new() and malloc() is NOT bounded (and it cannot be bounded).

How hard real time code is written is all the memory needed is 
preallocated, and the real time code does not do memory allocation.
The D garbage collector will not arbitrarily or randomly pause your 
program, as collection cycles only run synchronously with calls to 
allocate gc memory. If there is no attempt to allocate gc memory, your 
app is guaranteed to not run a collection cycle.

Absolutely this (preallocating memory) is possible in D, and it's just 
as straightforward as in C/C++.

You can completely avoid using gc memory in D if your app requirements 
so choose, using only malloc/free, or even statically allocate all 
memory (the D version of Empire did this).
Aug 18 2007
parent reply Guenther Brunthaler <gb dont.spam.me.invalid> writes:
Walter Bright Wrote:


 * There is is no equivalent to MODULA 2s "Definition Modules". While


 There is such a mechanism, .di files. They can be written either 
 manually, or automatically generated with the -H switch.


Well, yes. But the D 2.0 specs say that di files are not part of the language
standard and a mere optimization. That is, a feature much like precompiler
header files: Quite useful, but by no means standardized.

No D compliant compiler is therefore required to support di files, nor is there
any guarantee about the format of such files and that they have to be
compatible between different implementations.


 scope keyword on declarations if it is on the class. But I disagree that 
 it's a maintenance nightmare. Tedious, possibly. But a nightmare, no


OK. But you got the idea.


 real time code; you cannot even use malloc()! Why? Because the execution 
 time of new() and malloc() is NOT bounded (and it cannot be bounded).


I think realtime applications have to use the services provided by a real time
operating system.

If some of those services map to malloc and can guarantee bounded execution
time, than that's fine.

If not, then the application must not use malloc but write its own memory
management code or statically pre-allocate as you suggested - whichever seems
more appropriate.


 allocate gc memory. If there is no attempt to allocate gc memory, your 
 app is guaranteed to not run a collection cycle.


That's good news.

But is this behavior documented somewhere in the official D specs? I certainly
did not find such a guarantee when reading the specs the first time. But then,
this has been 2 or 3 years since.


 Absolutely this (preallocating memory) is possible in D, and it's just 
 as straightforward as in C/C++.


I was not aware of this either.


 You can completely avoid using gc memory in D if your app requirements 
 so choose, using only malloc/free, or even statically allocate all 
 memory (the D version of Empire did this).


Very good! It there anything special one has to do in order do avoid running
the GC? A HOWTO or something?

I'm pretty sure one cannot use all of the standard library if CG runs are going
to be avoided. So it's important to know which standard functions/features can
be used and which can't in realtime applications.
Aug 19 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Guenther Brunthaler wrote:

 Walter Bright Wrote:
 

 * There is is no equivalent to MODULA 2s "Definition Modules".
 While


 There is such a mechanism, .di files. They can be written either 
 manually, or automatically generated with the -H switch.


 
 Well, yes. But the D 2.0 specs say that di files are not part of the
 language standard and a mere optimization. That is, a feature much
 like precompiler header files: Quite useful, but by no means
 standardized.
 
 No D compliant compiler is therefore required to support di files,
 nor is there any guarantee about the format of such files and that
 they have to be compatible between different implementations.


I think there's a misunderstanding here. C++ compilers aren't required 
to support ".h" files either - .h is just a convention. The C++ standard 
says nothing at all about file extensions. There is nothing special 
about .h files, they are filled with standard C++ code.

Ditto for .di files. They are filled with standard D code. There is 
nothing whatsoever different about the syntax in them - it's standard D, 
and can be handled by any D compiler.

What was meant by the comment in the spec is that a compiler can 
implement interface files in its own proprietary format. But it still 
must read standard D files, and .di files can be written as standard D 
code, and always can be.

It's quite analogous to C++ .h files. Yes, it is allowed for a C++ 
compiler to have .h files in some special proprietary format - but all 
C++ compiler still must compile standard C++ code.



 

 scope keyword on declarations if it is on the class. But I disagree
 that it's a maintenance nightmare. Tedious, possibly. But a
 nightmare, no


 
 OK. But you got the idea.


Sure. But also consider that, while C++ objects are designed from the 
ground up to be RAII, in D they generally are not. So it might be very 
worthwhile to be notified by the compiler where objects are declared, as 
  a review of their use might be in order when switching the design of 
it to be RAII.



 real time code; you cannot even use malloc()! Why? Because the
 execution time of new() and malloc() is NOT bounded (and it cannot
 be bounded).


 
 I think realtime applications have to use the services provided by a
 real time operating system.
 
 If some of those services map to malloc and can guarantee bounded
 execution time, than that's fine.
 
 If not, then the application must not use malloc but write its own
 memory management code or statically pre-allocate as you suggested -
 whichever seems more appropriate.


Yes, all of which you can do with D. Note that you can also override 
operators new and delete on a per-class basis.



 allocate gc memory. If there is no attempt to allocate gc memory,
 your app is guaranteed to not run a collection cycle.


 
 That's good news.
 
 But is this behavior documented somewhere in the official D specs? I
 certainly did not find such a guarantee when reading the specs the
 first time. But then, this has been 2 or 3 years since.
 

 Absolutely this (preallocating memory) is possible in D, and it's
 just as straightforward as in C/C++.


 
 I was not aware of this either.
 

 You can completely avoid using gc memory in D if your app
 requirements so choose, using only malloc/free, or even statically
 allocate all memory (the D version of Empire did this).


 
 Very good! It there anything special one has to do in order do avoid
 running the GC? A HOWTO or something?


Nothing special, just don't use it.



 I'm pretty sure one cannot use all of the standard library if CG runs
 are going to be avoided. So it's important to know which standard
 functions/features can be used and which can't in realtime
 applications.


These could be better documented, but they are usually fairly obvious.
Aug 19 2007
prev sibling parent Robert Fraser <fraserofthenight gmail.coim> writes:
Guenther Brunthaler Wrote:


 What they have actually done was renaming "auto" into "scope", and forcing to
add the "scope" declarator to both the class declaration as well as to object
variable definitions.


Just wait a year for a good IDE to come out, and this can likely be done
automatically.
Aug 19 2007