www.digitalmars.com         C & C++   DMDScript  

D - new version statement

reply "Walter" <walter digitalmars.com> writes:
for conditional compilation:

    www.digitalmars.com/d/statement.html#version
Aug 29 2001
next sibling parent reply Axel Kittenberger <anshil gmx.net> writes:
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) {

} else {

}

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

version(have_alloca) {

} else {

}

version(!have_alloca) {

}

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
Aug 29 2001
parent reply "Walter" <walter digitalmars.com> writes:
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
Aug 29 2001
next sibling parent reply "Richard Krehbiel" <rich kastle.com> writes:
"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)
Aug 29 2001
parent "Walter" <walter digitalmars.com> writes:
"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.
Aug 29 2001
prev sibling parent reply Dan Hursh <hursh infonet.isl.net> writes:
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
Aug 29 2001
parent "Walter" <walter digitalmars.com> writes:
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
Aug 29 2001
prev sibling parent reply Chris Friesen <cfriesen nortelnetworks.com> writes:
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
Aug 29 2001
parent reply "Walter" <walter digitalmars.com> writes:
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
Aug 29 2001
parent reply Phil Brooks <phil_brooks mentor.com> writes:
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
Sep 13 2001
parent reply "Walter" <walter digitalmars.com> writes:
Phil Brooks wrote in message <3BA13EE3.8D8F68B6 mentor.com>...

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?



Not that I've seen. The specification for C++ templates is 56 pages long.
While people have convinced me that templates should be in D, I will find a
simpler way. -Walter
Sep 15 2001
next sibling parent Charles Hixson <charleshixsn earthlink.net> writes:
Walter wrote:


 Phil Brooks wrote in message
 <3BA13EE3.8D8F68B6 mentor.com>...


 One thing I have wished for in C++ was that templates
 weren't so obtuse... 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 ...

 Has any compiler ever done something like that?



 Not that I've seen. The specification for C++ templates is
 56 pages long. While people have convinced me that
 templates should be in D, I will find a simpler way. -Walter


One thing that you might consider would be the use of Python as 
a scripting language, though I really feel that this is more 
properly a part of the IDE than of the language.  If one were to 
consider the language and the IDE to be in some sort of unity, 
then the code that was written could be in some sort of 
"pre-final" form, the code that was emitted could be the D 
language that we have been discussing, and the IDE could have 
all sorts of compile-time options that were basically python 
text processing widgets.  (Ruby might be even better for this, 
but Python is more widely known in the Indo-European speaking 
world.)

But if the idea is that the actual D language be simple to parse 
locally, then this couldn't be a part of the final D language, 
and would need to be an ancillary option. (I.e., one could write 
pure D with a text editor, or with the Netscape Composer.  One 
wouldn't need a special language parser beyond the D compiler.) 
  Still, it could easily be a very nice addition, rather like 
Idle is for Python.  Not necessary, but nice to have.
Sep 17 2001
prev sibling parent reply Phil Brooks <phil_brooks mentor.com> writes:
My assertion is that a scripting language with access to compile-time
state and the ability to generate code would be vastly simpler to spec.
and easier to understand than C++ templates are.  It would also easily
replace the constant definition, conditional compilation, and macro
expansion uses of the pre-processor.

Walter wrote:

 
 Phil Brooks wrote in message <3BA13EE3.8D8F68B6 mentor.com>...

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?


 
 Not that I've seen. The specification for C++ templates is 56 pages long.
 While people have convinced me that templates should be in D, I will find a
 simpler way. -Walter
Sep 17 2001
parent "Walter" <walter digitalmars.com> writes:
"Phil Brooks" <phil_brooks mentor.com> wrote in message
news:3BA6244C.56E8D085 mentor.com...

 My assertion is that a scripting language with access to compile-time
 state and the ability to generate code would be vastly simpler to spec.
 and easier to understand than C++ templates are.  It would also easily
 replace the constant definition, conditional compilation, and macro
 expansion uses of the pre-processor.


Yes, it would. I do not see offhand, however, how it could be interleaved
with D code in a way that the different languages are clearly
distinguishable. One of my beefs with C is that the two languages are
interleaved, but not distinguishable.
Dec 07 2001