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>.

> 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];

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?)

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.

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

"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.

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++, Java, C#, etc., have all missed the boat on that issue (and on unit tests).

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.

I just finished dowloading all of the old D ng (Just plain old D, not digitalmars.D) and just for fun I peeked at a few of the first posts and found this:

Reply to Walter,

> I agree with you. Templates are a great idea, but there's *got* to be
> a better way. I intend to find it <g>.
> 

Well done Walter, I'd say you found it!

Benjamin Shropshire wrote:
> I just finished dowloading all of the old D ng (Just plain old D, not digitalmars.D) and just for fun I peeked at a few of the first posts and found this:
> 
> Reply to Walter,
> 
>> I agree with you. Templates are a great idea, but there's *got* to be
>> a better way. I intend to find it <g>.
>>
> 
> Well done Walter, I'd say you found it!

Thank you! It still has warts, but I can at least remember how to use it. With C++ templates, I have to keep looking it up again.