for conditional compilation:

    www.digitalmars.com/d/statement.html#version

For generality isn't debug not also a special version?

version(debug) {
   ....
}

where debug is a boolean?

And there are some cases someone wants an else, in example some operating systems offer a more effective interface than the standard one like in example:

version(have_strdup) {
   # use strdup
} else {
   # hand build it with strlen, malloc and strcpy
}

or other example (found principally in example in the bison parser)

version(have_alloca) {
   # allocate on stack
} else {
   # allocate on heap
}
#.... use the memory ...
version(!have_alloca) {
    # free heap
}

To only thing you'll end up is having users to write to ifs with negated expressions. I think the language designer should not try to think for the programmer, that's his task, we can never know what he'll really need, a lot of languages failed cause they tried to do be nurses for mans.

I personally would like the idea from another thread:
'@' identifier  [ '('  identifier ')' ] '{'
  statement
'}' [ else '{'
  statement
'}' ]

I only added @ to be able to be parse it:
like i.e.
@have(strdup) {
  ..
} else {
  ...
}

----
A completly other comment, a lot of people are here suggesting what they would like or not like in the 'next' language.

I find it as impayable resource to investigate what people are whishing today. Will have to find a way to completly download and privatly archieve the whole news group :o)

However one thing, people are generous in offering their ideas when they don't have to fear they are combined with work. Like in an open source project when you as  maintainer says to to them: great idea! There is the source you may implement it :o) Then they'll think: damm :o)  (and vanish).

Also a lot of people here seem to confuse 'D' with the 'next standard' (as
the name implies) as far as I understood the language is just that how you
implement it, and not in contrast to 'C' which is maintained by a standard
comitee.

- Axel

I'm not quite happy with the version statement, for the reasons you state and for others. I've been thinking about falling back to a simple

    if (feature==hoohaw)
    {
            ... hoohaw version...
    }
    else
    {
            ... blah blah ...
    }

Extend this idea so the if statement will work on declarations.

-Walter

"Walter" <walter@digitalmars.com> wrote in message news:9mj4dm$3048$1@digitaldaemon.com...
> I'm not quite happy with the version statement, for the reasons you state and for others. I've been thinking about falling back to a simple
>
>     if (feature==hoohaw)
>     {
>             ... hoohaw version...
>     }
>     else
>     {
>             ... blah blah ...
>     }
>
> Extend this idea so the if statement will work on declarations.
>
> -Walter

Like this?

struct some_struct
{
    int a;
    long b;
    if(feature == debug)
    {
        STACK recent_users[256];
        int sp;
    }
};

Can I write this?

int xmalloc(size_t size
    if(feature == debug)
    {
        , char *caller_file, int caller_line
    }
    ) { ... }

Can I write this?

    newvar = xmalloc(nv.size
    if(feature == debug)
    {
        , __FILE__, __LINE__
    } );

I still want real macros, thank you.

--
Richard Krehbiel, Arlington, VA, USA
rich@kastle.com (work) or krehbiel3@home.com (personal)

"Richard Krehbiel" <rich@kastle.com> wrote in message news:9mj6s7$31hh$1@digitaldaemon.com...
> struct some_struct
> {
>     int a;
>     long b;
>     if(feature == debug)
>     {
>         STACK recent_users[256];
>         int sp;
>     }
> };

Yes, that will work, but the debug attribute would be more apropos there:

 {
     int a;
     long b;
     debug
     {
         STACK recent_users[256];
         int sp;
     }
 };



> Can I write this?
>
> int xmalloc(size_t size
>     if(feature == debug)
>     {
>         , char *caller_file, int caller_line
>     }
>     ) { ... }

No, as it will not parse.


> Can I write this?
>
>     newvar = xmalloc(nv.size
>     if(feature == debug)
>     {
>         , __FILE__, __LINE__
>     } );
> I still want real macros, thank you.

I see what you're trying to do. May I suggest the following:

void *xmalloc(size);
void *xmalloc(size, file, line)
{
    debug return my_malloc(size, file, line);
    return xmalloc(size);
}

Because the compiler will inline such functions, for the non-debug version the extra arguments will go away.

I have an issue with the no else clause in conditional compilation.

Suppose I'm trying to write some processor specific code.  For instance, I have some code where one processor version uses one set of code, while all the other processors use a different set of code.  In C, this looks like:

#ifdef CONFIG_PPC
   #ifdef CONFIG_PPC601
      //use stuff on old powerpc 601 chip
   #else
      //do stuff on every other powerpc chip
   #endif
#endif

Without an else statement in conditional compilation, this means that I have to add something for every single other processor version.  This could get ugly, fast.

Alternately:

#ifdef CONFIG_i386
  //do x86-optimised stuff
#else if defined CONFIG_PPC
  //do ppc-optimised stuff
#else
  //do generic slower stuff
#endif

Similar dilemma.  If I don't have that else clause, I have to write something for every architecture that I add.

-- 
Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

ok, ok!

"Chris Friesen" <cfriesen@nortelnetworks.com> wrote in message news:3B8D52D4.CE7C0D95@nortelnetworks.com...
>
> I have an issue with the no else clause in conditional compilation.
>
> Suppose I'm trying to write some processor specific code.  For instance, I
have
> some code where one processor version uses one set of code, while all the
other
> processors use a different set of code.  In C, this looks like:
>
> #ifdef CONFIG_PPC
>    #ifdef CONFIG_PPC601
>       file://use stuff on old powerpc 601 chip
>    #else
>       file://do stuff on every other powerpc chip
>    #endif
> #endif
>
> Without an else statement in conditional compilation, this means that I
have to
> add something for every single other processor version.  This could get
ugly,
> fast.
>
> Alternately:
>
> #ifdef CONFIG_i386
>   file://do x86-optimised stuff
> #else if defined CONFIG_PPC
>   file://do ppc-optimised stuff
> #else
>   file://do generic slower stuff
> #endif
>
> Similar dilemma.  If I don't have that else clause, I have to write
something
> for every architecture that I add.
>
> --
> Chris Friesen                    | MailStop: 043/33/F10
> Nortel Networks                  | work: (613) 765-0557
> 3500 Carling Avenue              | fax:  (613) 765-2986
> Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

Walter wrote:
> 
> I'm not quite happy with the version statement, for the reasons you state and for others. I've been thinking about falling back to a simple
> 
>     if (feature==hoohaw)
>     {
>             ... hoohaw version...
>     }
>     else
>     {
>             ... blah blah ...
>     }
> 
> Extend this idea so the if statement will work on declarations.

	So compile time command line options would define variables?  I don't
know what I think of that.  Maybe you could put the command line options
in a module of their own?

	if(Config.PalmOS) blah();

Also, would the scoping for an if block behave differently because it has a compiler option in it?  (Maybe the separate module idea won't work?)  For that matter how is this?

version(X && (Y || Z)){

}
version(!(X && (Y ||Z))){

}

No else, positive assertion, same idea?  If requires more maintenance since adding a new variable would require modifying both conditions. Also, if an if block calling an undefined function get compiled out would the compiler gripe about the function never being defined?

	if(substandardOS){
		SubstandardFunc();  // only defined in substandard OS
	}else{
		StandardFunc();     // defined everywhere but substandard OS
	}

Dan

The compiler won't gripe about the function not being defined, because it doesn't do a semantic analysis on a false conditional body. -Walter

Dan Hursh wrote in message <3B8DC1B6.E02270CB@infonet.isl.net>...

> So compile time command line options would define variables?  I don't
>know what I think of that.  Maybe you could put the command line options in a module of their own?
>
> if(Config.PalmOS) blah();
>
>Also, would the scoping for an if block behave differently because it has a compiler option in it?  (Maybe the separate module idea won't work?)  For that matter how is this?
>
>version(X && (Y || Z)){
>
>}
>version(!(X && (Y ||Z))){
>
>}
>
>No else, positive assertion, same idea?  If requires more maintenance since adding a new variable would require modifying both conditions. Also, if an if block calling an undefined function get compiled out would the compiler gripe about the function never being defined?
>
> if(substandardOS){
> SubstandardFunc();  // only defined in substandard OS
> }else{
> StandardFunc();     // defined everywhere but substandard OS
> }
>
>Dan

One thing I have wished for in C++ was that templates weren't so obtuse (all the type stuff that is used to hide information somewhere and dig it out somewhere else etc).

It seems to me that one way to handle this ifdef issue as well as the template issue would
be to have some sort of run-time scripting language that you can break into that
has a well defined interface to the compiler's current state.   It wouldn't be the
brute force type of string substitution of macros since it would obey scoping etc. and it
would be a lot more straight forward than the hide-and-seek with types games that C++
uses.

So you might do something like

compiler.runtime< HARDWARE.CONFIG_PPC601=1; >;

...

void func_A() {
  compiler.runtime<
    if ( CONFIG_PPC601==1 ) {
        compiler.write_code(
          some PPC601 specific code...
        );
    } else {
        compiler.write_code(
          some generic code
    );
  >;
}

and go on to do other interesting things like template, varargs, etc assuming you can get at things like currently defined variables, type arguments to a template, arguments from the call site of a function where a template is being instantiated, etc.

so something like

void template_func_A( ... ) {
    compiler.runtime<
        foreach current_argument in compiler.current_function_arguments {
           compiler.write_code(
              if ( current_argument.type() == A ) {
                 process type A argument
              } else if ( current_argument.type().is_derived_from( A ) {
                 process something derived from A argument
              } else {
                 process generic argument
              }
           );
        }
    >;
}

Has any compiler ever done something like that?

Walter wrote:
> 
> ok, ok!
> 
> "Chris Friesen" <cfriesen@nortelnetworks.com> wrote in message news:3B8D52D4.CE7C0D95@nortelnetworks.com...
> >
> > I have an issue with the no else clause in conditional compilation.
> >
> > Suppose I'm trying to write some processor specific code.  For instance, I
> have
> > some code where one processor version uses one set of code, while all the
> other
> > processors use a different set of code.  In C, this looks like:
> >
> > #ifdef CONFIG_PPC
> >    #ifdef CONFIG_PPC601
> >       file://use stuff on old powerpc 601 chip
> >    #else
> >       file://do stuff on every other powerpc chip
> >    #endif
> > #endif
> >
> > Without an else statement in conditional compilation, this means that I
> have to
> > add something for every single other processor version.  This could get
> ugly,
> > fast.
> >
> > Alternately:
> >
> > #ifdef CONFIG_i386
> >   file://do x86-optimised stuff
> > #else if defined CONFIG_PPC
> >   file://do ppc-optimised stuff
> > #else
> >   file://do generic slower stuff
> > #endif
> >
> > Similar dilemma.  If I don't have that else clause, I have to write
> something
> > for every architecture that I add.
> >
> > --
> > Chris Friesen                    | MailStop: 043/33/F10
> > Nortel Networks                  | work: (613) 765-0557
> > 3500 Carling Avenue              | fax:  (613) 765-2986
> > Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com