> I'm pretty familiar with the proprietary keywords that are rampant in C
and
> C++, and how new proprietary syntaxes constantly appear and evolve. The trouble with proprietary syntaxes is that different D compilers will not
be
> able to parse them even if they are protected with a version statement.
With
> the pragma syntax, proprietary extensions can be added in a way that other compilers can parse even if they cannot handle it otherwise.
>

OK, so what is the reason for parsing 'version' sections that are not active?

to find the end of the section?

dunno:D

In article <bt7gpe$1r0i$1@digitaldaemon.com>, Jeroen van Bemmel says...
>
>> I'm pretty familiar with the proprietary keywords that are rampant in C
>and
>> C++, and how new proprietary syntaxes constantly appear and evolve. The trouble with proprietary syntaxes is that different D compilers will not
>be
>> able to parse them even if they are protected with a version statement.
>With
>> the pragma syntax, proprietary extensions can be added in a way that other compilers can parse even if they cannot handle it otherwise.
>>
>
>OK, so what is the reason for parsing 'version' sections that are not active?
>
>

"Jeroen van Bemmel" <someone@somewhere.com> wrote in message news:bt7gpe$1r0i$1@digitaldaemon.com...
> > I'm pretty familiar with the proprietary keywords that are rampant in C
> and
> > C++, and how new proprietary syntaxes constantly appear and evolve. The trouble with proprietary syntaxes is that different D compilers will not
> be
> > able to parse them even if they are protected with a version statement.
> With
> > the pragma syntax, proprietary extensions can be added in a way that
other
> > compilers can parse even if they cannot handle it otherwise.
> >
>
> OK, so what is the reason for parsing 'version' sections that are not active?

So things like syntax directed editors and other syntax analyzers will work.

Walter

Is there a way to provide the equivalent to the following C/C++ in D?

#if defined(linux)
. . .
#elif defined(WIN32)
. . .
#else
# error Platform not discriminated
#endif

like

version(Linux)
{
}
version(Windows)
{
}
else
{
  X
}

And have X not break the compilation for Linux and Windows, but break the compilation (preferably with a meaningful message) for anything?

I have foundered on this a couple of times when writing libs. The ExeModule had this issue, and if neither -version=Windows or -version=Linux is specified, then it just gives some unintelligible error due to undefined constructs.

And though I'm sure no-one would suggest it, relying on else to give Windows in the absence of Linux, or vice versa, is just a future-platform-porting landmine.

version(Linux)
{
}
else // Assuming Windows
{
  // What happens if we're building for Palm!?
}



"Walter" <walter@digitalmars.com> wrote in message news:bt7j5t$1ul2$1@digitaldaemon.com...
>
> "Jeroen van Bemmel" <someone@somewhere.com> wrote in message news:bt7gpe$1r0i$1@digitaldaemon.com...
> > > I'm pretty familiar with the proprietary keywords that are rampant in
C
> > and
> > > C++, and how new proprietary syntaxes constantly appear and evolve.
The
> > > trouble with proprietary syntaxes is that different D compilers will
not
> > be
> > > able to parse them even if they are protected with a version
statement.
> > With
> > > the pragma syntax, proprietary extensions can be added in a way that
> other
> > > compilers can parse even if they cannot handle it otherwise.
> > >
> >
> > OK, so what is the reason for parsing 'version' sections that are not active?
>
> So things like syntax directed editors and other syntax analyzers will
work.
>
>

"davepermen" <davepermen_member@pathlink.com> wrote in message news:bt7h59$1rfr$1@digitaldaemon.com...
> to find the end of the section?

OK, perhaps I should elaborate on my question: regular C compilers (or actually their preprocessors) have to deal with "#ifdef {sym}" ... "#endif", and their behavior when the expression evaluates to false is simply to skip the contents until they encounter '#endif'

I would call this 'skipping' rather than 'parsing' (although technically it is still parsing), hence my question: why parse it?

My thought was that the D compiler could do the same for version sections, unless Walter had other reasons to do parsing of the sections (see his posting)

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:bt7nh7$24ot$1@digitaldaemon.com...
> Is there a way to provide the equivalent to the following C/C++ in D?
>
> #if defined(linux)
> . . .
> #elif defined(WIN32)
> . . .
> #else
> # error Platform not discriminated
> #endif
>
> like
>
> version(Linux)
> {
> }
> version(Windows)
> {
> }
> else
> {
>   X
> }
>
> And have X not break the compilation for Linux and Windows, but break the compilation (preferably with a meaningful message) for anything?

Replace X with:
    static assert(0);    // unimplemented version

> I have foundered on this a couple of times when writing libs. The
ExeModule
> had this issue, and if neither -version=Windows or -version=Linux is specified, then it just gives some unintelligible error due to undefined constructs.
>
> And though I'm sure no-one would suggest it, relying on else to give
Windows
> in the absence of Linux, or vice versa, is just a future-platform-porting landmine.

I agree. Don't do that <g>.

"Walter" <walter@digitalmars.com> wrote in message news:bt7pts$28dc$1@digitaldaemon.com...
>
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:bt7nh7$24ot$1@digitaldaemon.com...
> > Is there a way to provide the equivalent to the following C/C++ in D?
> >
> > #if defined(linux)
> > . . .
> > #elif defined(WIN32)
> > . . .
> > #else
> > # error Platform not discriminated
> > #endif
> >
> > like
> >
> > version(Linux)
> > {
> > }
> > version(Windows)
> > {
> > }
> > else
> > {
> >   X
> > }
> >
> > And have X not break the compilation for Linux and Windows, but break
the
> > compilation (preferably with a meaningful message) for anything?
>
> Replace X with:
>     static assert(0);    // unimplemented version

Doh!. Of course. :)

Even better, would be

version(Linux)
{
}
version(Windows)
{
}
else
{
  const unrecognised_platform = 0;

  static assert(unrecognised_platform);
}

I take it that will be accepted by the compiler?

> > I have foundered on this a couple of times when writing libs. The
> ExeModule
> > had this issue, and if neither -version=Windows or -version=Linux is specified, then it just gives some unintelligible error due to undefined constructs.
> >
> > And though I'm sure no-one would suggest it, relying on else to give
> Windows
> > in the absence of Linux, or vice versa, is just a
future-platform-porting
> > landmine.
>
> I agree. Don't do that <g>.

Quick! Make a wish!

<G>

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:bt7t0j$2cqr$1@digitaldaemon.com...
> Even better, would be
>
> version(Linux)
> {
> }
> version(Windows)
> {
> }
> else
> {
>   const unrecognised_platform = 0;
>
>   static assert(unrecognised_platform);
> }
>
> I take it that will be accepted by the compiler?

It should work.

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bt79le$1gb0$1@digitaldaemon.com...
> Most excellent!  See, Walter *does* listen to us.  ;)  It's not implicit instantiation, but it's better than it was.  It seems this syntax won't conflict with use of ! as logical not.

What are the common use cases for implicit instantiation? Actually, the only ones I can think of off the top of my head are function templates. The example Walter gave:

> >     template Max(T) { T Max(T a, T b) { return ... ; } }
> >     ...
> >         x = Max!(int)(5,7);

seems pretty compact and readable. The implicit form would be x = Max(5,7); (right? I can't even remember since the times I've used templates recently have been STL container stuff of the form vector<int> etc).

 I'm psyched about 0.77. It is definitely an improvement in the template
support.
-Ben

Ben Hinkle wrote:

> "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message
> news:bt79le$1gb0$1@digitaldaemon.com...
> 
>>Most excellent!  See, Walter *does* listen to us.  ;)  It's not implicit
>>instantiation, but it's better than it was.  It seems this syntax won't
>>conflict with use of ! as logical not.
> 
> 
> What are the common use cases for implicit instantiation? Actually, the only
> ones I can think of off the top of my head are function templates. The
> example Walter gave:
> 
> 
>>>    template Max(T) { T Max(T a, T b) { return ... ; } }
>>>    ...
>>>        x = Max!(int)(5,7);
> 
> 
> seems pretty compact and readable. The implicit form would be x = Max(5,7);
> (right? I can't even remember since the times I've used templates recently
> have been STL container stuff of the form vector<int> etc).
> 
>  I'm psyched about 0.77. It is definitely an improvement in the template
> support.
> -Ben

I've used implicit instantiation as an uber-alias in C++ before.

template <typename A, typename B, typename C, typename D>
Tuple<A, Tuple<B, Tuple<C, Tuple<D, NoneType> > > >
    bind(A a, B b, C c, D d) {
        /* You don't want to see this.  Trust me. */
}

(mostly joking.  mostly)

 -- andy