www.digitalmars.com         C & C++   DMDScript  

D - *sigh*

reply "Johnny Lai" <bl12 uow.edu.au> writes:
Hi!

Well I'm disappointed that people seem to feel that the preprocessor and
templates are not features that are worth having...

I personally miss the preprocessor when I use Java. Otherwise how do we do
code tuned for multiple platforms in 1 source? Or to include debugging code
and removing at will (not just asserts)? Sometimes it's nice to have an
extra level of indirection ^_^.. maybe we need instead is a preprocessor
language that can be applied to any/many language(s) when needed.

And templates! Yes they are complex stuff and I wish they were easier but...
they allow you to do things that you would otherwise be unable to do, or
have to pay dearly for. With templates, apart from the normal usage for
providing type-safe functions, they can be used to implement inheritance.
Using templates to implement inheritance isn't as fully featured as run-time
polymorphism and all that, but they are faster cos they do not need the
vtables (ok it's a small cost). And with templates you can write code to
generate code - statically compiled code, and that's really groovy.
Unfortunately, right now in C++, it is difficult and unintuitive to do, but
it is possible (there's a nice book that discusses some of these things, and
you'll be amazed at what they can get templates to do - Generative
Programming by Krzysztof Czarnecki, and Ulrich W. Eisenecker).

Well that's just my opinion... One of the reasons why I love C++ is because
I have this feeling of safety when I use it. Basically I know whatever I
want to do, it is possible (ok in very very rare circumstances it probably
isn't).

Oh a brighter note, I think it is nice there's an import. At least there's
none of that header file nested include nightmare... and I like not having
to have another section to define my functions


Johnny
Aug 16 2001
next sibling parent reply "Nathan Matthews" <nedthefed nospam.hotmail.com> writes:
I personally am not a fan of templates, I agree they are powerful but they
can lead to problems.  There is no relationship between set<float> and
set<int> for instance although sometimes you might want a function to
iterate through both types.  To do that you need to templatize the function
and so on, the changes tend to cascade.  I think java has a better more
elegant solution through rtti, a set class holds a set of references to
Objects.  Types are checked on casting.

Having said all this there is 'allways' a trade off beween a 'nice' solution
and the theoretically most efficient solution.  Sometimes people want the
fastest solution and are prepared to make the sacrifice.

On a performance note I wonder if it might be worth letting the user run the
garbage collector if they want to and specify the time its allowed to run.
This would result in at least some of the memory freeing up if it doent
manage to complete and would make the language suitable in systems such as
realtime and computer gaming.

"Johnny Lai" <bl12 uow.edu.au> wrote in message
news:9lgki2$24sf$1 digitaldaemon.com...

 Hi!

 Well I'm disappointed that people seem to feel that the preprocessor and
 templates are not features that are worth having...

 I personally miss the preprocessor when I use Java. Otherwise how do we do
 code tuned for multiple platforms in 1 source? Or to include debugging


code

 and removing at will (not just asserts)? Sometimes it's nice to have an
 extra level of indirection ^_^.. maybe we need instead is a preprocessor
 language that can be applied to any/many language(s) when needed.

 And templates! Yes they are complex stuff and I wish they were easier


but...

 they allow you to do things that you would otherwise be unable to do, or
 have to pay dearly for. With templates, apart from the normal usage for
 providing type-safe functions, they can be used to implement inheritance.
 Using templates to implement inheritance isn't as fully featured as


run-time

 polymorphism and all that, but they are faster cos they do not need the
 vtables (ok it's a small cost). And with templates you can write code to
 generate code - statically compiled code, and that's really groovy.
 Unfortunately, right now in C++, it is difficult and unintuitive to do,


but

 it is possible (there's a nice book that discusses some of these things,


and

 you'll be amazed at what they can get templates to do - Generative
 Programming by Krzysztof Czarnecki, and Ulrich W. Eisenecker).

 Well that's just my opinion... One of the reasons why I love C++ is


because

 I have this feeling of safety when I use it. Basically I know whatever I
 want to do, it is possible (ok in very very rare circumstances it probably
 isn't).

 Oh a brighter note, I think it is nice there's an import. At least there's
 none of that header file nested include nightmare... and I like not having
 to have another section to define my functions


 Johnny
Aug 16 2001
parent reply "Hendrik Schober" <SpamTrap gmx.de> writes:
"Nathan Matthews" <nedthefed nospam.hotmail.com> wrote:

 I personally am not a fan of templates, I agree they are powerful but they
 can lead to problems.


  Pointers are powerfull but they can lead to problems.
  Exceptions are powerful but they can lead to problems.
  Macros are powerful, but they can lead to problems.
  ...


                        There is no relationship between set<float> and
 set<int> for instance


  Of course, there is: To implement it by hand, you
  would write the exactly same code twice.


                       although sometimes you might want a function to
 iterate through both types.


  Then you want two functions with exactly the same
  code that iterate through thier approriate sets.
  Isn't it amazing that there's a mechanism that
  allows you to do this by writing the function only
  once?


                              To do that you need to templatize the function
 and so on, the changes tend to cascade.


  Yeah, in that is is like forgetting a 'const'
  somewhere in a header file. Adding it will yield
  another place where a 'const' is missing, this forces
  another 'const'.
  Such is the benefit of design errors. ;^>

  (Whenever I entered a project I quickly found myself
  spending hours adding missing 'const's all over the
  code. At the end of the day, those who had been in
  the project for a long time had stopped laughing
  about me wasting precious time because they were busy
  fixing their bugs which I found this way.)


                                          I think java has a better more
 elegant solution through rtti, a set class holds a set of references to
 Objects.  Types are checked on casting.


  First: If you want to generalize a function within
  this model, you have to go through the exactly same
  painful process of generalizing all functions it
  depends on.
  Second: Such libraries exist in C++. For many many
  years. Many many libraries. Yet, STL came and
  conquered. What do you think why that happened?


 [...]


  Schobi

--
SpamTrap gmx.de is never read
I'm hschober at gmx dot de

P.S.: Ich suche einen Job in Berlin.
Aug 16 2001
parent reply "Jason M. Felice" <jfelice cronosys.com> writes:
Hendrik Schober wrote:


 "Nathan Matthews" <nedthefed nospam.hotmail.com> wrote:

 I personally am not a fan of templates, I agree they are powerful but they
 can lead to problems.




C++ Templates suck.  They suck solely because it is trying to support the
ancient C/C++ cruft.  The syntax
is horrific and awkward.  The old C types is the reason you need to explicitly
specify template parameters.

The template problem  should be solved.  I have typed an implementation of a
circularly linked list in C so
many times that I can disengage my brain and type a whole 150+ lines of code.

What's wrong with templates like this:

a' max (a' left, a' right)
{
     if (left > right) return left;
     return right;
}

In Standard ML, a' would be a type variable (in D, this would probably conflict
with the character-quoting operator, but for demonstration purposes...).  You
are telling the compiler that left and right are of the same
type and the function returns the same type.  There would be an expansion error
if you tried to use max with
a set of types that didn't support bool operator > ('a, 'a).  You could provide
specializations just by
explicitly specifying types.  I'm not sure that specializations are really
necessary.  No C++ pointer specialization junk, for sure.

If you wanted to do a lot of work on the language but make something really
cool, the function should be
declared like this:

max (left, right)
{
   if (left > right) return left;
   return right;
}

If you think about it, if the compiler can't infer a type restriction on the
arguments or the return value based on how they are used or returned from the
function, there is no reason for there to be one.  The compiler can
infer that the return type of the function must be the type of left, etc.

Okay, back to reality.  Think about this:

class a' list {
   void add (a' newelem) {
   }
   void remove (a' oldelem) {
   }
   int count () {
   }
};

int list i = new int list;
i.add(1);
i.add(2);

Not anywhere near so bad as C++, eh?  And we still solve a whole slew of
generalized programming issues
that we can't otherwise solve.  Look at Standard ML and Objective CAML for more
info.  I've wrote a few
programs in both (I do a lot of languages -- sort of my hobby along with
compiler/parser theory) -- I _love_
their type system but _hate_ the language syntax.

-Jay 'Eraserhead' Felice
Aug 16 2001
parent "Walter" <walter digitalmars.com> writes:
I agree with you. Templates are a great idea, but there's *got* to be a
better way. I intend to find it <g>.

"Jason M. Felice" <jfelice cronosys.com> wrote in message
news:3B7C0A1E.35920B77 cronosys.com...

 Hendrik Schober wrote:


 "Nathan Matthews" <nedthefed nospam.hotmail.com> wrote:

 I personally am not a fan of templates, I agree they are powerful but






they

 can lead to problems.




 C++ Templates suck.  They suck solely because it is trying to support the
 ancient C/C++ cruft.  The syntax
 is horrific and awkward.  The old C types is the reason you need to


explicitly

 specify template parameters.

 The template problem  should be solved.  I have typed an implementation of


a

 circularly linked list in C so
 many times that I can disengage my brain and type a whole 150+ lines of


code.

 What's wrong with templates like this:

 a' max (a' left, a' right)
 {
      if (left > right) return left;
      return right;
 }

 In Standard ML, a' would be a type variable (in D, this would probably


conflict

 with the character-quoting operator, but for demonstration purposes...).


You

 are telling the compiler that left and right are of the same
 type and the function returns the same type.  There would be an expansion


error

 if you tried to use max with
 a set of types that didn't support bool operator > ('a, 'a).  You could


provide

 specializations just by
 explicitly specifying types.  I'm not sure that specializations are really
 necessary.  No C++ pointer specialization junk, for sure.

 If you wanted to do a lot of work on the language but make something


really

 cool, the function should be
 declared like this:

 max (left, right)
 {
    if (left > right) return left;
    return right;
 }

 If you think about it, if the compiler can't infer a type restriction on


the

 arguments or the return value based on how they are used or returned from


the

 function, there is no reason for there to be one.  The compiler can
 infer that the return type of the function must be the type of left, etc.

 Okay, back to reality.  Think about this:

 class a' list {
    void add (a' newelem) {
    }
    void remove (a' oldelem) {
    }
    int count () {
    }
 };

 int list i = new int list;
 i.add(1);
 i.add(2);

 Not anywhere near so bad as C++, eh?  And we still solve a whole slew of
 generalized programming issues
 that we can't otherwise solve.  Look at Standard ML and Objective CAML for


more

 info.  I've wrote a few
 programs in both (I do a lot of languages -- sort of my hobby along with
 compiler/parser theory) -- I _love_
 their type system but _hate_ the language syntax.

 -Jay 'Eraserhead' Felice
Aug 16 2001
prev sibling next sibling parent reply weingart cs.ualberta.ca (Tobias Weingartner) writes:
In article <9lgki2$24sf$1 digitaldaemon.com>, Johnny Lai wrote:

 
 Well I'm disappointed that people seem to feel that the preprocessor
 and templates are not features that are worth having...


Ok, these are reasons to look at.  Maybe not valid, but they are
there...



 I personally miss the preprocessor when I use Java. Otherwise how do
 we do code tuned for multiple platforms in 1 source? Or to include
 debugging code and removing at will (not just asserts)? Sometimes it's
 nice to have an extra level of indirection ^_^.. maybe we need instead
 is a preprocessor language that can be applied to any/many language(s)
 when needed.


So much in such a small paragraph.  I'll try to address these all in
sequence.

First, using a preprocessor to tune/port source to multiple platforms is
a *VERY* bad idea.  As someone who as worked at porting various things
to many different platforms, I can attest to that.  (10+ platforms, 2
huge products, 5.5M+ lines of source)

Having said that, an extra level of indirection is very nice to have.
It is very usefull in debugging things quickly, and in hacking things
up for various purposes.  It is however in direct conflict with writing
production source.

A preprocessor exists with such a goal (at least under *nix), it is
called m4.  It is not pretty, nor is it easy to learn, but it does do
what you asked for...



 And templates! Yes they are complex stuff and I wish they were easier
 but... they allow you to do things that you would otherwise be unable
 to do, or have to pay dearly for. With templates, apart from the
 normal usage for providing type-safe functions, they can be used to
 implement inheritance.  Using templates to implement inheritance
 isn't as fully featured as run-time polymorphism and all that, but
 they are faster cos they do not need the vtables (ok it's a small
 cost). And with templates you can write code to generate code -
 statically compiled code, and that's really groovy.  Unfortunately,
 right now in C++, it is difficult and unintuitive to do, but it is
 possible (there's a nice book that discusses some of these things, and
 you'll be amazed at what they can get templates to do - Generative
 Programming by Krzysztof Czarnecki, and Ulrich W. Eisenecker).


Templates are an interesting idea.  I think that the fundamental problem
with templates is that they went about solving the generic programming
the wrong way.  (Of course, everybody has a different idea on this).
The problem is one of the following (in C++):

int add2(int x, int y){
	return x+y;
}

long add2(long x, long y){
	return x+y;
}

This is the first type of generic programming.  Here two "compatible"
types are being done an operation to.  In some sense, the exact same
code is being produced (at least if int == long) for both of these
functions.  It would be nice to be able to write the function once, and
use it for both (in this case you can, int promotes to long).

In one sense, generic programming is about coallescing functions that
are the same (at the binary level), or compiling to functions that are a
little more generic, and thereby making more functions equivelant, and
then collapsing them.


The other generic programming idea is one of where you write code
in a high-level language, and have the compiler generate different
code, which depends on the type(s) within the function.  This one is
harder to solve in the traditional edit-compile-link-run cycle of these
traditional languages.  The problem is one of not knowing ahead of time
what type(s) are going to be in every possible instantiation of the
function.  I can see two ways of solving this:

1) Every type is an object, and you generate a generic function, using
the base object as the type.  In this way the generic function can
always be used, but more specialized generated functions (for speed,
etc) can also be explicitly generated at compile time.

2) Make the compile-link section be a loop, which loops until there are
no undefined symbols (generic functions) left to compile.  This breaks
the library encapsulation abstraction, as source (of some sort) for the
generic libraries would have to be available (user defined types will
need a new version of generic routines compiled from library source).


Given these constraints, I can see a good reason not to include
templates in the current design of the language.  Instead forcing the
writer of the library (or other sourcecode) to write "generic" functions
in a manner more consistent with proceedural languages.  This is not
always such a bad thing...



 Well that's just my opinion... One of the reasons why I love C++
 is because I have this feeling of safety when I use it. Basically
 I know whatever I want to do, it is possible (ok in very very rare
 circumstances it probably isn't).


Almost any language has this property.


-- 
Tobias Weingartner |        Unix Guru, Admin, Systems-Dude
Apt B 7707-110 St. |        http://www.tepid.org/~weingart/
Edmonton, AB       |-------------------------------------------------
Canada, T6G 1G3    | %SYSTEM-F-ANARCHISM, The OS has been overthrown
Aug 16 2001
next sibling parent Charles Hixson <charleshixsn earthlink.net> writes:
Tobias Weingartner wrote:

 In article <9lgki2$24sf$1 digitaldaemon.com>, Johnny Lai wrote:
 

Well I'm disappointed that people seem to feel that the preprocessor
and templates are not features that are worth having...


 
 Ok, these are reasons to look at.  Maybe not valid, but they are
 there...
 ...


Well, first, not all preprocessing is at compile time.

In this light, most IDE's and aware editors use a form of preprocessing. 
  Not as extensive as if you could say, e.g., "Take all the green words, 
and move the first letter to the back", but then how often would one 
want to do this?  Of course, it could be quite nice to, e.g., locate all 
references to green words matching the regexp ..., or that kind of 
thing.  IDE's sometimes provide this kind of facility.

Or consider JavaDoc, or Eiffel's short command.  These are a sort of 
preprocessor.  The Eiffel short command will even follow up the chains 
of inheritance while constructing a list of all routines/variables 
visible to clients of a class.  It's a kind of preprocessing.

What about anything that builds and maintains a project file?  Some of 
them merely store meta-information, but some of them actively analyze 
the code to extract the information.

Now let's consider compile time preprocessing:
Some of the work that this could do is better done by generics.
Some of the work that this could do is better done by const variables.
Some of the work that this could do is better done by inlining of functions.
The only remaining task that I can think of would be better done by an 
alias construct.  It's true that the only form that comes to my mind 
right now is a preprocessor-ish form:
Alias(t_right, "tree->node.right")
That sort of thing.  I don't want the second argument to be a string, 
though.  That's just the way it appeared in my thoughts (of how to do it 
with a preprocessor).  And I'm not sure that it's a desireable thing for 
a preprocessor to do.  (I just escaped maintaining some C code that was 
full of the equivalent done with the C preprocessor...this needs careful 
thought.  That was pretty unreadable code.)

What are the other reasonable uses of a preprocessor?
Aug 17 2001
prev sibling parent reply a <hursh infonet.isl.net> writes:
Tobias Weingartner wrote:

 
 In article <9lgki2$24sf$1 digitaldaemon.com>, Johnny Lai wrote:

 I personally miss the preprocessor when I use Java. Otherwise how do
 we do code tuned for multiple platforms in 1 source? Or to include
 debugging code and removing at will (not just asserts)? Sometimes it's
 nice to have an extra level of indirection ^_^.. maybe we need instead
 is a preprocessor language that can be applied to any/many language(s)
 when needed.


 
 So much in such a small paragraph.  I'll try to address these all in
 sequence.
 
 First, using a preprocessor to tune/port source to multiple platforms is
 a *VERY* bad idea.  As someone who as worked at porting various things
 to many different platforms, I can attest to that.  (10+ platforms, 2
 huge products, 5.5M+ lines of source)


	If the preprocessor is not the way, what is?  I'm not saying we need a
text macro preprocessor, but we something I would assume.  Where I work
we have moved a lot of code to java and we now have to maintain a tree
of common code and a tree of platform specific code for each platform. 
Because of this we can't use straight make either.  Java does not
provide the platform independence it claims to and I don't have high
hopes for a natively compiled language.  
	I must admit that I despise a number of the problems that the
preprocessor cause, but conditional compilation for platforms should
really be addressed if the language is to be seriously used. 
Conditional imports would be the absolute minimum, allowing you to hide
platform specifics in a module.  This could be over kill for issues like
filesystem directory separators and the like.
	Anyhow, you say the preprocessor is bad for multi-platform support.  It
sounds like you have experience.  What would be better?  Platform
independence is too idealistic.  I won't buy that D can deliver it and
still be generally useful.

Dan
Aug 19 2001
next sibling parent reply "Rajiv Bhagwat" <dataflow vsnl.com> writes:
The Aug 2001 issue of CUJ (I think..the AUG part is pukka) has an article
that discusses the elimination of common uses of preprocessor for such
tasks. (C++ related article.)

He says that (not exact quote, the mag is not in front of me): "using #ifdef
to write multiplatform code does not create platform independant code, but
code that is dependent on multiple platforms!"

Taking his hints, I have found that keeping the common, platform
independant, interface in the .hpp file and having multiple .cpp files, one
for each platform; does simplify the code clutter. The appropriate files are
to be choosen in the makefile during the platform specific build. The
downside is that the number of files increases, but I guess the clear
distiction between the 'interface' and the 'implementation' compensates for
it.


a <hursh infonet.isl.net> wrote in message
news:3B806CC6.FE5992 infonet.isl.net...

 Tobias Weingartner wrote:

 In article <9lgki2$24sf$1 digitaldaemon.com>, Johnny Lai wrote:

 I personally miss the preprocessor when I use Java. Otherwise how do
 we do code tuned for multiple platforms in 1 source? Or to include
 debugging code and removing at will (not just asserts)? Sometimes it's
 nice to have an extra level of indirection ^_^.. maybe we need instead
 is a preprocessor language that can be applied to any/many language(s)
 when needed.


 So much in such a small paragraph.  I'll try to address these all in
 sequence.

 First, using a preprocessor to tune/port source to multiple platforms is
 a *VERY* bad idea.  As someone who as worked at porting various things
 to many different platforms, I can attest to that.  (10+ platforms, 2
 huge products, 5.5M+ lines of source)


 If the preprocessor is not the way, what is?  I'm not saying we need a
 text macro preprocessor, but we something I would assume.  Where I work
 we have moved a lot of code to java and we now have to maintain a tree
 of common code and a tree of platform specific code for each platform.
 Because of this we can't use straight make either.  Java does not
 provide the platform independence it claims to and I don't have high
 hopes for a natively compiled language.
 I must admit that I despise a number of the problems that the
 preprocessor cause, but conditional compilation for platforms should
 really be addressed if the language is to be seriously used.
 Conditional imports would be the absolute minimum, allowing you to hide
 platform specifics in a module.  This could be over kill for issues like
 filesystem directory separators and the like.
 Anyhow, you say the preprocessor is bad for multi-platform support.  It
 sounds like you have experience.  What would be better?  Platform
 independence is too idealistic.  I won't buy that D can deliver it and
 still be generally useful.

 Dan
Aug 20 2001
parent Dan Hursh <hursh infonet.isl.net> writes:
Rajiv Bhagwat wrote:

 
 The Aug 2001 issue of CUJ (I think..the AUG part is pukka) has an article
 that discusses the elimination of common uses of preprocessor for such
 tasks. (C++ related article.)
 
 He says that (not exact quote, the mag is not in front of me): "using #ifdef
 to write multiplatform code does not create platform independant code, but
 code that is dependent on multiple platforms!"
 
 Taking his hints, I have found that keeping the common, platform
 independant, interface in the .hpp file and having multiple .cpp files, one
 for each platform; does simplify the code clutter. The appropriate files are
 to be choosen in the makefile during the platform specific build. The
 downside is that the number of files increases, but I guess the clear
 distiction between the 'interface' and the 'implementation' compensates for
 it.


 
	I can agree with this, but I have done a number of very small programs
for a very heterogeneous environment.  If I had to start make them
multi-file project because there is no way I would switch to D for
them.  :-(
	On another note, I guess I the observation that you aren't writing
platform independent code doesn't break may heart.  I try to keep as
much of my code platform independent as possible, I'm an admin and
frankly I don't believe I could accomplish anything meaningful in
platform independent code.  In many cases the headers you need to
include are different on different platforms.  I don't honestly see D
fixing that.  Vendors just seem to be different out of a lack of
tangible merit.

Dan


 a <hursh infonet.isl.net> wrote in message
 news:3B806CC6.FE5992 infonet.isl.net...

 Tobias Weingartner wrote:

 In article <9lgki2$24sf$1 digitaldaemon.com>, Johnny Lai wrote:

 I personally miss the preprocessor when I use Java. Otherwise how do
 we do code tuned for multiple platforms in 1 source? Or to include
 debugging code and removing at will (not just asserts)? Sometimes it's
 nice to have an extra level of indirection ^_^.. maybe we need instead
 is a preprocessor language that can be applied to any/many language(s)
 when needed.


 So much in such a small paragraph.  I'll try to address these all in
 sequence.

 First, using a preprocessor to tune/port source to multiple platforms is
 a *VERY* bad idea.  As someone who as worked at porting various things
 to many different platforms, I can attest to that.  (10+ platforms, 2
 huge products, 5.5M+ lines of source)


 If the preprocessor is not the way, what is?  I'm not saying we need a
 text macro preprocessor, but we something I would assume.  Where I work
 we have moved a lot of code to java and we now have to maintain a tree
 of common code and a tree of platform specific code for each platform.
 Because of this we can't use straight make either.  Java does not
 provide the platform independence it claims to and I don't have high
 hopes for a natively compiled language.
 I must admit that I despise a number of the problems that the
 preprocessor cause, but conditional compilation for platforms should
 really be addressed if the language is to be seriously used.
 Conditional imports would be the absolute minimum, allowing you to hide
 platform specifics in a module.  This could be over kill for issues like
 filesystem directory separators and the like.
 Anyhow, you say the preprocessor is bad for multi-platform support.  It
 sounds like you have experience.  What would be better?  Platform
 independence is too idealistic.  I won't buy that D can deliver it and
 still be generally useful.

 Dan
Aug 21 2001
prev sibling next sibling parent reply weingart cs.ualberta.ca (Tobias Weingartner) writes:
In article <3B806CC6.FE5992 infonet.isl.net>, a wrote:

 Tobias Weingartner wrote:

 
 First, using a preprocessor to tune/port source to multiple platforms is
 a *VERY* bad idea.  As someone who as worked at porting various things
 to many different platforms, I can attest to that.  (10+ platforms, 2
 huge products, 5.5M+ lines of source)


 
 	If the preprocessor is not the way, what is?  I'm not saying we need a
 text macro preprocessor, but we something I would assume.  Where I work
 we have moved a lot of code to java and we now have to maintain a tree
 of common code and a tree of platform specific code for each platform. 
 Because of this we can't use straight make either.  Java does not
 provide the platform independence it claims to and I don't have high
 hopes for a natively compiled language.  


Separate files for each platform (or api/feature) is the way to go.  It
helps in keeping the spagethi code away as more platforms are added.  It
also helps in coallescing support for platforms as bugs, apis and features
migrate into a cohesive mass.



 	I must admit that I despise a number of the problems that the
 preprocessor cause, but conditional compilation for platforms should
 really be addressed if the language is to be seriously used. 


Certainly.  However, I believe strongly, that it should be discouraged.
How many times do you see '#ifdef __linux', when they really mean to say
'#ifdef SVR4'?  Most people don't know which standards define which api,
giving them "platform" dependant compilation, usually means they make the
wrong choice...



 Conditional imports would be the absolute minimum, allowing you to hide
 platform specifics in a module.  This could be over kill for issues like
 filesystem directory separators and the like.


Conditional imports are not necessary.  Build libraries to abstract system
and API differences.  Import libraries, and use their common API.



 	Anyhow, you say the preprocessor is bad for multi-platform support.  It
 sounds like you have experience.  What would be better?  Platform
 independence is too idealistic.  I won't buy that D can deliver it and
 still be generally useful.


Not using preprocessor for multi-platform.  It sounds hard, and it can be.
It sounds over-kill, and it can be.  But really, once you get beyond the
3-4 machine level, a little foresight, and forebearance of the over-kill
things will make life a *lot* easier...


--Toby.
Aug 20 2001
next sibling parent reply "Brent Schartung" <bschartung home.com> writes:
It just seems to me that all the usually platform-specific bs can go into
the D standard library--that is, threads and semaphores, sockets, maybe
graphics, basic filesystem functions, and then the basic types that seem to
depend on word size, etc.  Also byte-order needs to be addressed in some
instances, maybe have a library call for NetworkByteOrder(...).  (BTW, if D
is the big success we hope it is, and it spreads to some old-school and some
brand-spankin new systems, will 'int', etc be changed to mean 16- or 64-bit
integer??)

My question is this:  Is there anything in the typical platform murk that
can't be handled by an extensive base library?

Another 2 cents,
Brent
Aug 20 2001
next sibling parent reply Russ Lewis <russ deming-os.org> writes:
Brent Schartung wrote:


 My question is this:  Is there anything in the typical platform murk that
 can't be handled by an extensive base library?


For the stuff you mentioned, the technical, under-the-covers stuff of computing,
I would guess that a standard library would work well.  Such a thing
(particularly if it covers threading and synchronization) would be a Good Idea.

The trouble, though, comes when you are dealing with the more mundane (but
perhaps more important) part of the program - the structure of its user
interface.  How do you write a class library that works equally well with
graphical and text-based user interfaces?  If you just deal with graphical ones,
do you assume that the window is local (like Mac and Windows) or remote (like
X-Windows)?  Do you choose a synchronous event model, which will *trash*
performance for people connected via a modem or the Internet, or do you choose
an asynchronous event model, which will make your program much more complex?  Do
you recognize and use graphics accelerators, or ignore them?

I'm not saying that it can't be done - in fact, I think that it *should* be
done.  But when you get to that level, things are no longer trivial.
Aug 20 2001
parent reply "Brent Schartung" <bschartung home.com> writes:
What do Qt and GTK do?  Don't they do the 'networked' X-Windows thing?

Sorry, I've never actually dev'd with them!

 - Brent



 The trouble, though, comes when you are dealing with the more mundane (but
 perhaps more important) part of the program - the structure of its user
 interface.  How do you write a class library that works equally well with
 graphical and text-based user interfaces?  If you just deal with graphical


ones,

 do you assume that the window is local (like Mac and Windows) or remote


(like

 X-Windows)?  Do you choose a synchronous event model, which will *trash*
 performance for people connected via a modem or the Internet, or do you


choose

 an asynchronous event model, which will make your program much more


complex?  Do

 you recognize and use graphics accelerators, or ignore them?

 I'm not saying that it can't be done - in fact, I think that it *should*


be

 done.  But when you get to that level, things are no longer trivial.
Aug 20 2001
parent Russ Lewis <russ deming-os.org> writes:
Brent Schartung wrote:


 What do Qt and GTK do?  Don't they do the 'networked' X-Windows thing?

 Sorry, I've never actually dev'd with them!


Right, tools exist to develop X-Windows.  But how many of those tools can also
run on Windows w/o a major code change (or a very complex Windows X Server)?
Aug 21 2001
prev sibling parent "Walter" <walter digitalmars.com> writes:
The library can abstract away most common stuff. But it is of necessity then
the lowest common denominator. There will always be a need to access
platform specific functionality for complex system apps.


Brent Schartung wrote in message <9ls3bi$18mn$1 digitaldaemon.com>...

It just seems to me that all the usually platform-specific bs can go into
the D standard library--that is, threads and semaphores, sockets, maybe
graphics, basic filesystem functions, and then the basic types that seem to
depend on word size, etc.  Also byte-order needs to be addressed in some
instances, maybe have a library call for NetworkByteOrder(...).  (BTW, if D
is the big success we hope it is, and it spreads to some old-school and


some

brand-spankin new systems, will 'int', etc be changed to mean 16- or 64-bit
integer??)

My question is this:  Is there anything in the typical platform murk that
can't be handled by an extensive base library?

Another 2 cents,
Brent
Aug 21 2001
prev sibling parent "Walter" <walter digitalmars.com> writes:
Tobias Weingartner wrote in message ...

How many times do you see '#ifdef __linux', when they really mean to say
'#ifdef SVR4'?  Most people don't know which standards define which api,
giving them "platform" dependant compilation, usually means they make the
wrong choice...



That is one of the things I found discouraging about using conditional
compilation for OS support. The programmer was always using the wrong one.
They'd use _WIN32 when they meant _MSC_VER, they'd use __GCC__ when they
meant linux, and on and on. They'd also use the #else clause to mean some
(unspecified) default operating system.
Aug 21 2001
prev sibling parent "Walter" <walter digitalmars.com> writes:
a wrote in message <3B806CC6.FE5992 infonet.isl.net>...

 I won't buy that D can deliver it and
still be generally useful.



D  will likely only be somewhat more platform independent than C is.
Aug 21 2001
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Johnny Lai" <bl12 uow.edu.au> wrote in message
news:9lgki2$24sf$1 digitaldaemon.com...

 Well I'm disappointed that people seem to feel that the preprocessor and
 templates are not features that are worth having...


I expected heat about templates, but less so about the preprocessor.



 I personally miss the preprocessor when I use Java. Otherwise how do we do
 code tuned for multiple platforms in 1 source? Or to include debugging


code

 and removing at will (not just asserts)? Sometimes it's nice to have an
 extra level of indirection ^_^.. maybe we need instead is a preprocessor
 language that can be applied to any/many language(s) when needed.


I've dealt with much code over the years tuned for multiple platforms with
#ifdef's. Inevitably, they turn into a hopeless snarl. I've since reached
the conclusion that platform dependencies should be isolated to separate
files and then write a new file for the different platforms.

Inserting and removing debugging code at will is ably handled with the debug
attribute and debug statement. Asserts are not really debug code, but are
part of the design by contract stuff.



 And templates! Yes they are complex stuff and I wish they were easier


but...

 they allow you to do things that you would otherwise be unable to do, or
 have to pay dearly for. With templates, apart from the normal usage for
 providing type-safe functions, they can be used to implement inheritance.
 Using templates to implement inheritance isn't as fully featured as


run-time

 polymorphism and all that, but they are faster cos they do not need the
 vtables (ok it's a small cost). And with templates you can write code to
 generate code - statically compiled code, and that's really groovy.
 Unfortunately, right now in C++, it is difficult and unintuitive to do,


but

 it is possible (there's a nice book that discusses some of these things,


and

 you'll be amazed at what they can get templates to do - Generative
 Programming by Krzysztof Czarnecki, and Ulrich W. Eisenecker).


Clearly, people like templates a *lot*. I'm going to have to think a lot
more about this.
Aug 16 2001
parent reply "Kent Sandvik" <sandvik excitehome.net> writes:
 I've dealt with much code over the years tuned for multiple platforms with
 #ifdef's. Inevitably, they turn into a hopeless snarl. I've since reached
 the conclusion that platform dependencies should be isolated to separate
 files and then write a new file for the different platforms.


Yes, agree. One way we did this in a project was to specify class objects
that were global, across the platforms, and the implementation files then
had implementations for each platform, included via makefiles. That makes me
wonder if this could be done in D in case the header files are gone, and we
are dealing with modules, so it would be nice to somehow indicate the
implementation detail (or then write multiple modules for each
platform...). --Kent
Aug 16 2001
parent reply "Walter" <walter digitalmars.com> writes:
"Kent Sandvik" <sandvik excitehome.net> wrote in message
news:9lho7p$as5$1 digitaldaemon.com...

 I've dealt with much code over the years tuned for multiple platforms




with

 #ifdef's. Inevitably, they turn into a hopeless snarl. I've since




reached

 the conclusion that platform dependencies should be isolated to separate
 files and then write a new file for the different platforms.


 Yes, agree. One way we did this in a project was to specify class objects
 that were global, across the platforms, and the implementation files then
 had implementations for each platform, included via makefiles. That makes


me

 wonder if this could be done in D in case the header files are gone, and


we

 are dealing with modules, so it would be nice to somehow indicate the
 implementation detail (or then write multiple modules for each
 platform...). --Kent


I think it would fall naturally out of D. A switch to the compiler tells it
where to look for the imports for the target platform.
Aug 16 2001
parent reply Russell Bornschlegel <kaleja estarcion.com> writes:
Walter wrote:

 
 "Kent Sandvik" <sandvik excitehome.net> wrote in message
 news:9lho7p$as5$1 digitaldaemon.com...

 I've dealt with much code over the years tuned for multiple platforms




 with

 #ifdef's. Inevitably, they turn into a hopeless snarl. I've since




 reached

 the conclusion that platform dependencies should be isolated to separate
 files and then write a new file for the different platforms.


 Yes, agree. One way we did this in a project was to specify class objects
 that were global, across the platforms, and the implementation files then
 had implementations for each platform, included via makefiles. That makes


 me

 wonder if this could be done in D in case the header files are gone, and


 we

 are dealing with modules, so it would be nice to somehow indicate the
 implementation detail (or then write multiple modules for each
 platform...). --Kent


 
 I think it would fall naturally out of D. A switch to the compiler tells it
 where to look for the imports for the target platform.


I nearly jumped for joy upon seeing D's "debug" attribute. At the 
risk of getting stomped on for proposing a new keyword, how about 
adding a "config" attribute, with an identifier:

   config (MacOSX)
   {
      // do OS X specific stuff
   }
   config (Win32)
   {
      // do Win32 specific stuff
   }
   config (PalmOS)
   {
      // do PalmOS specific stuff
   }

again, with compiler switches to pass in the identifier?
Aug 16 2001
parent "news.digitalmars.com" <bradeeoh crosswinds.net> writes:
 I nearly jumped for joy upon seeing D's "debug" attribute. At the
 risk of getting stomped on for proposing a new keyword, how about
 adding a "config" attribute, with an identifier:

    config (MacOSX)
    {
       // do OS X specific stuff
    }
    config (Win32)
    {
       // do Win32 specific stuff
    }
    config (PalmOS)
    {
       // do PalmOS specific stuff
    }

 again, with compiler switches to pass in the identifier?


Have nothing incredibly useful to say, but I REALLY like that idea.  I was
already convinced that with garbage collection, single inheretence +
interfaces, and the debug keyword that D is my new language of choice
if/when it becomes a reality.

Toss in the config keyword, and my Win32 vs Linux woes would be greatly
reduced WITHOUT having to use the messy preprocessor, and I would throw
Walter a party for the accomplishment personally  :)
Aug 17 2001
prev sibling next sibling parent reply "Tim Sweeney" <tim epicgames.com> writes:
 I personally miss the preprocessor when I use Java.


Agreed, but only because of Java's limitations (no templates, etc.), and not
because I *want* to use macros.


 And templates! Yes they are complex stuff and I wish they were easier


but...

 they allow you to do things that you would otherwise be unable to do, or
 have to pay dearly for.


Agreed 100%!  I would never consider writing a large-scale program in a
language without template-style functionality.  It's really astounding how
much simplification and generality one can attain with templates -- not just
talking about the cannonical (and IMO poor) example of "container classes",
but for complex related type hierarchies, parser tools, math structures,
etc.

The stigma of templates being useful just for container classes and a few
other isolated cases (which a language could well implement as a special
feature) is really unfortunate.  I suppose that's because container classes
are the next obvious step for a C programmer.  But if you spend a few weeks
experimenting with languages like Haskell (not useful for practical
programming, but a GREAT thing to learn), you come back to C++ templates
with a completely new perspective and start writing code in a much more
compact and general way!

(Here I'm advocating template-style functionality -- I actually think the
C++ syntax for templates is pretty kludgy, but that's a minor issue in the
grand scheme of things.)


 Unfortunately, right now in C++, it is difficult and unintuitive to do,


but

 it is possible (there's a nice book that discusses some of these things,


and

 you'll be amazed at what they can get templates to do - Generative
 Programming by Krzysztof Czarnecki, and Ulrich W. Eisenecker).


Agreed 101%!

-Tim
Aug 17 2001
parent reply reiter nomadics.com (Mac Reiter) writes:
On Fri, 17 Aug 2001 21:15:47 -0400, "Tim Sweeney" <tim epicgames.com>
wrote:


Agreed, but only because of Java's limitations (no templates, etc.), and not
because I *want* to use macros.


 And templates! Yes they are complex stuff and I wish they were easier


but...

 they allow you to do things that you would otherwise be unable to do, or
 have to pay dearly for.


Agreed 100%!  I would never consider writing a large-scale program in a
language without template-style functionality.  It's really astounding how
much simplification and generality one can attain with templates -- not just
talking about the cannonical (and IMO poor) example of "container classes",
but for complex related type hierarchies, parser tools, math structures,
etc.

The stigma of templates being useful just for container classes and a few
other isolated cases (which a language could well implement as a special
feature) is really unfortunate.  I suppose that's because container classes


I know that some of you have read at least some of the Eiffel work,
since Design By Contract is built into D.  Does anyone here have large
scale experience with Eiffel's use of Generic/Parameterized Classes?
In my training and what work I have done with the language, they
seemed to be very simple to use, but contained enough power to
represent inter-class type relationships beyond the simple container
class work.  I do not, however, have large scale experience, and may
have simply not been exposed to their problems.

Also, I realize that D is not Eiffel, so even if Eiffel had the
perfect genericity system it might not translate directly into D.  I
only suggest looking at Eiffel references (Object Oriented Software
Construction, 2nd Edition by Bertrand Meyer has an EXTENSIVE
discussion and analysis) to see if there are any features there that
help focus the design.

I have recently purchased Digital Mars C++ for evaluation because
templates are important to the kind of work I do, and because my
current compiler (MSVC -- make sign of the cross, say prayer for
salvation of my soul) is almost completely hosed with regards to
compiling templates.  

Rather than posting a huge amount of copied code, I will simply supply
a link to a description of Eiffel's genericity system.
http://www.eiffel.com/doc/online/eiffel50/intro/language/tutorial-08.html#pgfId-514722

For classes, you simply change:
	class C
into:
	class C[G]

Eiffel does not allow free-standing functions -- all functions are
member functions of some class.  So any generic/templatized function
that you could write would be inside a class that would be made
generic in terms of the type(s) you need to use for its members.  

	class C[G,H]
containing a member function:
	filter(G input) : H

filter() is a function that takes a type G and returns a type H.

You can also tie types together through covariance mechanisms, and
much more.  Genericity is one of the cornerstones of the Eiffel
design.

Just a thought.  Sorry if it's already been mentioned...
Mac Reiter
Jan 11 2002
next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"Mac Reiter" <reiter nomadics.com> wrote in message
news:3c3f6c4a.26816560 news.digitalmars.com...


 I know that some of you have read at least some of the Eiffel work,
 since Design By Contract is built into D.  Does anyone here have large
 scale experience with Eiffel's use of Generic/Parameterized Classes?
 In my training and what work I have done with the language, they
 seemed to be very simple to use, but contained enough power to
 represent inter-class type relationships beyond the simple container
 class work.  I do not, however, have large scale experience, and may
 have simply not been exposed to their problems.


Well I've read the chapter... it looks pretty much like C++
templates, only template arguments are always types - or
am I missing something?

Anyways, it'd be great for D to support templates. Very powerful
and time-saving feature, it is.
Jan 11 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
B. Meyer has been the inspiration for some of D's features, like DBC. Meyer
has a lot of great ideas, and Eiffel is a great language. The look and feel,
so to speak, of Eiffel, however, just isn't my style <g>.

I've been using DBC in my own code for some time now,  and can attest that
it produces a *real* improvement in productivity and reliability. C, C++,


I've shelved the templates in D idea for the moment while I try to get the
compiler into beta quality, but this issue will get addressed.
Jan 11 2002
prev sibling parent reply a <hursh infonet.isl.net> writes:
	I admit that I don't care for the problems that came with the
preprocessor, but it had it's pluses.  Rather that just blast D (since
it looks 'cool' and all) I was curious how I would address conditional
compilation.  I'll consider two cases and I'm curious how they would be
addressed in D.

	First would be a small project.  Say I want to write a wizzle decoder. 
It a basic project that take files contain wizzle encoded data,
de-wizzles it and presents it to the user.  for the most part the
de-wizzling is number crunching but the will inevitably be issues of
dealing with basic system interfaces to get data (files) and present it
(files, a window, audio, idunno).  I C/C++ I would write a file or for
each platform with the code for getting data, and presenting it and use
#ifdefs to select which files I want to #include.  The makefile would
handle compiling the write code.
	How would I do this in D?  Unless I put each implementation in a
separate directory, I would have to give each file a different name, and
hence a different module name.  I would then have to do trick to point
at these different directories, and the organizational overhead is just
seems a bit steep for de-wizzling. ;-)  This also excludes ports to
platforms that don't have hierarchical files systems.  (Loth the
mainframe.)  This also doesn't address the rare few programs that are so
small (even with an #ifdef or two) that they would otherwise fit nicely
into one file.  I guess that is a peeve I have with java.  It tends to
require more file than I feel should be necessary for some smallish
projects.

	Second, say I'm making an OS kernel. I've decide that the world is
ready for Danux.  Now here, having a directory for each platform is
pretty justified even without D's requirements.  My question here has to
do with configuration management.  If you've compiled linux you know
that there are a lot of compile time options.  Let face it, Danux is
going to have to be just as flexible if not more so.  How would I go
about supporting the ability to pass compile time configuration options
into D to tell it what I want compiled and how do I act upon that
information?  
	The first thing that comes to mind is to abuse the debug(identifier)
syntax.  I don't know if it would work though to do imports that way. 
Let's face it though, that is abuse.  I would need to tell the program
which OS modules/drivers/functionality is being supported for this
build.  I would also need to tell it option setting like is a driver
being build statically, or is it a run time loadable.  What should the
max/default sizes for given properties be.  Short of writing a program
that will in turn write my program with the correct options (that would
be a preprocessor wouldn't it?) I don't really know how I would handle
this in D.  Let's face it.  We are not just dewizzling data here.  We
need power.

Dan
Aug 19 2001
next sibling parent reply weingart cs.ualberta.ca (Tobias Weingartner) writes:
In article <3B807834.59635C0C infonet.isl.net>, a wrote:

 
 	First would be a small project.  Say I want to write a wizzle decoder. 
 It a basic project that take files contain wizzle encoded data,
 de-wizzles it and presents it to the user.  for the most part the
 de-wizzling is number crunching but the will inevitably be issues of
 dealing with basic system interfaces to get data (files) and present it
 (files, a window, audio, idunno).  I C/C++ I would write a file or for
 each platform with the code for getting data, and presenting it and use
 #ifdefs to select which files I want to #include.  The makefile would
 handle compiling the write code.
 	How would I do this in D?  Unless I put each implementation in a
 separate directory, I would have to give each file a different name, and
 hence a different module name.  I would then have to do trick to point
 at these different directories, and the organizational overhead is just
 seems a bit steep for de-wizzling. ;-)  This also excludes ports to
 platforms that don't have hierarchical files systems.  (Loth the
 mainframe.)  This also doesn't address the rare few programs that are so
 small (even with an #ifdef or two) that they would otherwise fit nicely
 into one file.  I guess that is a peeve I have with java.  It tends to
 require more file than I feel should be necessary for some smallish
 projects.


Ouch, why would you tie the module name and the import name together?
Just because some implementation of displaying data is in linux-display.d
and another is in openbsd-display.d, you should still be able to use
"import display" in the main program to get whichever was compiled.  Think
"libraries", linux-diplay.d would be compiled, and put in a library called
"display" (traditional unix would use libdisplay.a for a static library).



 	Second, say I'm making an OS kernel. I've decide that the world is
 ready for Danux.  Now here, having a directory for each platform is
 pretty justified even without D's requirements.  My question here has to
 do with configuration management.  If you've compiled linux you know
 that there are a lot of compile time options.  Let face it, Danux is
 going to have to be just as flexible if not more so.  How would I go
 about supporting the ability to pass compile time configuration options
 into D to tell it what I want compiled and how do I act upon that
 information?  


Great.  There are a number of good configuration tools out there.  I will
agree that conditional compilation can make things easier in these cases.
However, if properly constructed, a simple "if" statement can be as effective
in this case.  Since it evaluates to "if(0)", and the compiler removes that
part of the code, it is just as if conditional compilation happened.



 	The first thing that comes to mind is to abuse the debug(identifier)
 syntax.  I don't know if it would work though to do imports that way. 
 Let's face it though, that is abuse.  I would need to tell the program
 which OS modules/drivers/functionality is being supported for this
 build.  I would also need to tell it option setting like is a driver
 being build statically, or is it a run time loadable.  What should the
 max/default sizes for given properties be.  Short of writing a program
 that will in turn write my program with the correct options (that would
 be a preprocessor wouldn't it?) I don't really know how I would handle
 this in D.  Let's face it.  We are not just dewizzling data here.  We
 need power.


Write more generic code.  Seriously, one of my main problems with open
code today is that it is targeted to linux, instead of the broader unix
comunity out there.  It used to be that windows programs/utilities were
the hardest to port to a "standard" unix environment (solaris, *bsd, osf,
etc).  Today that has been largely replaced with the huge number of linux
centric code out there.  Code that depends on certain behaviour that the
linux api has, rather than following the written standard that exists.

--Toby.
Aug 20 2001
parent reply "Sean L. Palmer" <spalmer iname.com> writes:
Sorry to stir this old thread but I just had to make a quick point here:


Great.  There are a number of good configuration tools out there.  I will
agree that conditional compilation can make things easier in these cases.
However, if properly constructed, a simple "if" statement can be as


effective

in this case.  Since it evaluates to "if(0)", and the compiler removes that
part of the code, it is just as if conditional compilation happened.


Think about this hypothetical situation:

const int useplatformspecificapi=0;

int myfunc()
{
  if (useplatformspecificapi)
  {
     import platformspecificapi;          // let's assume this module is not
available anyway
     platformspecificapi_function(0);   // Undeclared identifier error, most
likely
     return 0;
  }
  return 1;
}

Think about what the compiler will do while parsing myfunc (I'm new to D so
if I wrote the above wrong, forgive me).  It still has to parse down into
there and figure out what platformspecificapi_function(0); means... that
means it needs to know if it's a function or whatever.  If
useplatformspecificapi is 0, the parser will probably generate an
"Undeclared identifier" error.  I'm sure if one tried one could come up with
several more examples where an ordinary parser would fall over.  So if
statements by themselves aren't the answer, but they *could* be given a
technological advance or two.  The trick seems to be to lazy-parse sections
*after* evaluating any constant expressions in the controlling if clause.
I'm not sure I could pull this off but I'm sure it's not beyond the
top-notch compiler writers today.

BTW I like what I see so far about D.  I can only find a few minor flaws in
the design, which I'll discuss presently.

also I seem to have noticed that at one point the website mentions that in
an array declaration, the brackets go with the rest of the typespec instead
of the C way where the brackets go after the variable.  I think that having
the typespec contiguous is superior (especially if you are writing a
compiler).  However many of the samples on the website seem to be using C
syntax for array declarations.

So, which is it?

Does D declare arrays like this:

int myarray[5];

or like this?

 int[5] myarray;

Sean
Oct 16 2001
parent reply "Walter" <walter digitalmars.com> writes:
Sean L. Palmer wrote in message <9qgprk$1lgp$1 digitaldaemon.com>...

Great.  There are a number of good configuration tools out there.  I will
agree that conditional compilation can make things easier in these cases.
However, if properly constructed, a simple "if" statement can be as


effective

in this case.  Since it evaluates to "if(0)", and the compiler removes




that

part of the code, it is just as if conditional compilation happened.


Think about this hypothetical situation:

const int useplatformspecificapi=0;
int myfunc()
{
  if (useplatformspecificapi)
  {
     import platformspecificapi;          // let's assume this module is


not

available anyway
     platformspecificapi_function(0);   // Undeclared identifier error,


most

likely
     return 0;
  }
  return 1;
}

Think about what the compiler will do while parsing myfunc (I'm new to D so
if I wrote the above wrong, forgive me).  It still has to parse down into
there and figure out what platformspecificapi_function(0); means... that
means it needs to know if it's a function or whatever.  If
useplatformspecificapi is 0, the parser will probably generate an
"Undeclared identifier" error.  I'm sure if one tried one could come up


with

several more examples where an ordinary parser would fall over.  So if
statements by themselves aren't the answer, but they *could* be given a
technological advance or two.  The trick seems to be to lazy-parse sections
*after* evaluating any constant expressions in the controlling if clause.
I'm not sure I could pull this off but I'm sure it's not beyond the
top-notch compiler writers today.



It's not that hard if you defer semantic processing until after syntax
analysis, which the D spec separates.


also I seem to have noticed that at one point the website mentions that in
an array declaration, the brackets go with the rest of the typespec instead
of the C way where the brackets go after the variable.  I think that having
the typespec contiguous is superior (especially if you are writing a
compiler).  However many of the samples on the website seem to be using C
syntax for array declarations.
So, which is it?

Does D declare arrays like this:

int myarray[5];

or like this?

 int[5] myarray;

Sean



At the moment, both work <g>.
Oct 16 2001
parent reply "Sean L. Palmer" <spalmer iname.com> writes:
 It's not that hard if you defer semantic processing until after syntax
 analysis, which the D spec separates.


Cool.


also I seem to have noticed that at one point the website mentions that




in

an array declaration, the brackets go with the rest of the typespec




instead

of the C way where the brackets go after the variable.  I think that




having

the typespec contiguous is superior (especially if you are writing a
compiler).  However many of the samples on the website seem to be using C
syntax for array declarations.
So, which is it?

Does D declare arrays like this:

int myarray[5];

or like this?

 int[5] myarray;

Sean



 At the moment, both work <g>.


That's pretty slick!  What would this do?

int[5] myarray[6];
Oct 18 2001
parent reply "Ben Cohen" <bc skygate.co.uk> writes:
In article <9qm7l7$1tjc$1 digitaldaemon.com>, "Sean L. Palmer"
<spalmer iname.com> wrote:


Does D declare arrays like this:

int myarray[5];

or like this?

 int[5] myarray;

Sean



 At the moment, both work <g>.


 
 That's pretty slick!  What would this do?
 
 int[5] myarray[6];


I think you can do something like that in Java, to confuse yourself.
(See http://asc.di.fct.unl.pt/~jml/mirror/unmain.html for this and other
similar ideas.)

Will they always both work (i.e., is that in the spec?)
Oct 18 2001
parent "Walter" <walter digitalmars.com> writes:
Ben Cohen wrote in message <9qm9u5$1utt$1 digitaldaemon.com>...

In article <9qm7l7$1tjc$1 digitaldaemon.com>, "Sean L. Palmer"
<spalmer iname.com> wrote:

 That's pretty slick!  What would this do?
 int[5] myarray[6];





int[5][6] myarray;


Will they always both work (i.e., is that in the spec?)


I'll probably drop the C version.
Oct 18 2001
prev sibling parent reply "Glen Dayton" <dayton timesten.com> writes:
Ada deals with conditional compilation rather nicely -- any "if" statement
with a constant conditional is optimized out at compile time.

C++ behaves the same way.  One of Bjarne Stroup's stated goals in creating
C++ was eliminating the pre-processor.  Thus, instead of writing

#define DOITTHISWAY 1
...
#if DOITTHISWAY
...
#endif


write

const int DOITTHISWAY = 1;

if (DOITTHISWAY) {
...
}


The disadvantage of this method is the lack of ability to define DOITTHISWAY
on the command line of the compiler, but from a configuration management
standpoint, this isn't a disadvantage at all.
Aug 28 2001
next sibling parent "Kent Sandvik" <sandvik excitehome.net> writes:
 The disadvantage of this method is the lack of ability to define


DOITTHISWAY

 on the command line of the compiler, but from a configuration management
 standpoint, this isn't a disadvantage at all.


I've been involved in building cross-platform C++ frameworks, and if there's
a way to build multiple versions of the sources with compile switches, it
makes a big difference versus doing for example shell scripting or perl
hacks to move around configuration files around for the various builds. It's
doable with perl hacking, but it would be more natural to just specify
compilation options directly to the build process. --Kent
Aug 28 2001
prev sibling parent "Walter" <walter digitalmars.com> writes:
I am leaning towards using the "if" for conditional compilation. One major
difference between D and C++ usage of it is that in D, the false conditional
would only have to parse, it would not have to be semantically correct.

-Walter


Glen Dayton wrote in message <9mh6em$1rhs$1 digitaldaemon.com>...

Ada deals with conditional compilation rather nicely -- any "if" statement
with a constant conditional is optimized out at compile time.

C++ behaves the same way.  One of Bjarne Stroup's stated goals in creating
C++ was eliminating the pre-processor.  Thus, instead of writing

#define DOITTHISWAY 1
...
#if DOITTHISWAY
...
#endif


write

const int DOITTHISWAY = 1;

if (DOITTHISWAY) {
...
}


The disadvantage of this method is the lack of ability to define


DOITTHISWAY

on the command line of the compiler, but from a configuration management
standpoint, this isn't a disadvantage at all.
Aug 29 2001