www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Red Code, Green Code (nwcpp video)

reply sergk <why.you.need my.email> writes:
I've just noticed a Northwest C++ Users Group presentation
"Red Code, Green Code:  Generalizing const" by Scott Meyers, and found it quite
interesting.

So here it is:
http://nwcpp.org/Meetings/2007/04.html


PS./OT: seems Scott do not really enjoying C++ template meta programming =)

-- serg.
May 07 2007
next sibling parent Stephen Waits <steve waits.net> writes:
sergk wrote:

 PS./OT: seems Scott do not really enjoying C++ template meta programming =)


Well, he *is* a pretty smart guy.

--Steve
May 07 2007
prev sibling next sibling parent reply janderson <askme me.com> writes:
sergk wrote:

 I've just noticed a Northwest C++ Users Group presentation
 "Red Code, Green Code:  Generalizing const" by Scott Meyers, and found it
quite interesting.
 
 So here it is:
 http://nwcpp.org/Meetings/2007/04.html
 
 
 PS./OT: seems Scott do not really enjoying C++ template meta programming =)
 
 -- serg.


The next time some tries to argue library over language, or that 
templates in C++ are perfect, we should point them to that video.

PS - What would be the nicest way to do this in D using current syntax?
May 07 2007
parent reply Pragma <ericanderton yahoo.removeme.com> writes:
janderson wrote:

 sergk wrote:

 I've just noticed a Northwest C++ Users Group presentation
 "Red Code, Green Code:  Generalizing const" by Scott Meyers, and found 
 it quite interesting.

 So here it is:
 http://nwcpp.org/Meetings/2007/04.html


 PS./OT: seems Scott do not really enjoying C++ template meta 
 programming =)

 -- serg.


 
 The next time some tries to argue library over language, or that 
 templates in C++ are perfect, we should point them to that video.
 
 PS - What would be the nicest way to do this in D using current syntax?


Well, we can trans-literate from the C++ code to get the same results.  Here I
have an example that replaces the 
functionality from the vector template with tuples, and some additional
template namespaces and operations to make it 
all come together.  The actual example is in the bottom third of this snippet.

(Mucking with code from
http://herbsutter.spaces.live.com/blog/cns!2D4327CC297151BB!207.entry)

// This is placed in the Public Domain

template Tuple(V...){
	alias V Tuple;
}

template InTuple(Item){
	const bool InTuple = false;
}

template InTuple(Item,First,V...){
	static if(is(Item == First)){
		const bool InTuple = true;
	}
	else alias InTuple!(Item,V) InTuple;
}

template TupleRemoveAll(Item){
	alias Tuple!() TupleRemoveAll;
}

template TupleRemoveAll(Item,First,V...){
	static if(is(Item == First)){
		alias TupleRemoveAll!(Item,V) TupleRemoveAll;
	}
	else alias Tuple!(First,TupleRemoveAll!(Item,V)) TupleRemoveAll;
}

// use template 'struct' to prevent tuple flattening when passing constraints
around
template Constraints(V...){
	alias V list;
}

template ConstraintRemove(alias Constraints){
	alias Constraints.list list;
}

template ConstraintRemove(alias Constraints,First,V...){
	alias Cosntraints!(TupleRemoveAll!(First,Constraints.list)) newConstraints;
	alias Tuple!(newConstraints,ConstraintRemove!(newConstraints,V)) list;
}

struct IgnoreConstraints {}

template ConstraintCheck(alias Local,Caller:IgnoreConstraints){
	const bool ConstraintCheck = true;
}

// ensure that all local constraints are satisfied by caller
template ConstraintCheck(alias Local,alias Caller){
	static if(Local.list.length > 0){
		static if(Caller.list.length > 0){
			alias Local.list[0] first;
			static if(InTuple!(Local.list[0],Caller.list)){
				alias Constraints!(TupleRemoveAll!(first,Local.list)) newLocalConstraints;
				alias ConstraintCheck!(newLocalConstraints,Caller) ConstraintCheck;
			}
			else{
				const bool ConstraintCheck = false;
			}
		}
		else{ // nothing left to check
			const bool ConstraintCheck = false;
		}		
	}
	else{ // nothing left to check
		const bool ConstraintCheck = true;
	}
}

// Here's the useful part:
struct ExceptionSafe {}
struct LGPLed {}
struct Reviewed {}

void f(alias CallerConstraints)(Params params){
     alias Constraints!(ExceptionSafe) MyConstraints;
     static assert(ConstraintCheck!(MyConstraints,CallerConstraints));
     /* do something */
}

void g(alias CallerConstraints)(){
     alias Constraints!(ExceptionSafe,Reviewed) MyConstraints;
     static assert(ConstraintCheck!(MyConstraints,CallerConstraints));

     // try to call the other function
     f!(MyConstraints)();  // error, trying to call unreviewed code from
reviewed code
     f!(ConstraintRemove!(MyConstraints,Reviewed))(); // ok, ignore Reviewed
constraint
     f!(IgnoreConstraints)(); // ok, explicitly ignore constraints entirely
}

void main(){
     alias Constraints!(ExceptionSafe,Reviewed) MyConstraints;
     g!(MyConstraints)();
}

This won't compile under DMD 0.012 and later - Bug 1196 keeps operations like
InTuple!() from operating correctly.  So 
this is only half-tested.  There are also a few different ways one could
implement this.  I opted for this particular 
definition of Constraints!() to allow for the ConstraintCheck!() operation to
work for comparing two tuple lists 
(otherwise, they'd collapse into a single tuple).

Aside from the advantages that tuples offer, I'm having a hard time seeing a
clear advantage over the C++ version.  We 
still get template bloat, and namespace concerns, plus it's not much more
readable.  At a minimum, the lack of a need 
for a heavy amount of compile-time code is a clear advantage and I think (not
sure here) the concerns about virtual 
methods are also addressed thanks to D's design.  So I think this edges out the
C++ version rather invisibly.

-- 
- EricAnderton at yahoo
May 08 2007
parent reply janderson <askme me.com> writes:
Pragma wrote:

 janderson wrote:

 sergk wrote:

 I've just noticed a Northwest C++ Users Group presentation
 "Red Code, Green Code:  Generalizing const" by Scott Meyers, and 
 found it quite interesting.

 So here it is:
 http://nwcpp.org/Meetings/2007/04.html


 PS./OT: seems Scott do not really enjoying C++ template meta 
 programming =)

 -- serg.


 The next time some tries to argue library over language, or that 
 templates in C++ are perfect, we should point them to that video.

 PS - What would be the nicest way to do this in D using current syntax?


 
 Well, we can trans-literate from the C++ code to get the same results.  
 Here I have an example that replaces the functionality from the vector 
 template with tuples, and some additional template namespaces and 
 operations to make it all come together.  The actual example is in the 
 bottom third of this snippet.
 
 (Mucking with code from 
 http://herbsutter.spaces.live.com/blog/cns!2D4327CC297151BB!207.entry)
 
 // This is placed in the Public Domain
 
 template Tuple(V...){
     alias V Tuple;
 }
 
 template InTuple(Item){
     const bool InTuple = false;
 }
 
 template InTuple(Item,First,V...){
     static if(is(Item == First)){
         const bool InTuple = true;
     }
     else alias InTuple!(Item,V) InTuple;
 }
 
 template TupleRemoveAll(Item){
     alias Tuple!() TupleRemoveAll;
 }
 
 template TupleRemoveAll(Item,First,V...){
     static if(is(Item == First)){
         alias TupleRemoveAll!(Item,V) TupleRemoveAll;
     }
     else alias Tuple!(First,TupleRemoveAll!(Item,V)) TupleRemoveAll;
 }
 
 // use template 'struct' to prevent tuple flattening when passing 
 constraints around
 template Constraints(V...){
     alias V list;
 }
 
 template ConstraintRemove(alias Constraints){
     alias Constraints.list list;
 }
 
 template ConstraintRemove(alias Constraints,First,V...){
     alias Cosntraints!(TupleRemoveAll!(First,Constraints.list)) 
 newConstraints;
     alias Tuple!(newConstraints,ConstraintRemove!(newConstraints,V)) list;
 }
 
 struct IgnoreConstraints {}
 
 template ConstraintCheck(alias Local,Caller:IgnoreConstraints){
     const bool ConstraintCheck = true;
 }
 
 // ensure that all local constraints are satisfied by caller
 template ConstraintCheck(alias Local,alias Caller){
     static if(Local.list.length > 0){
         static if(Caller.list.length > 0){
             alias Local.list[0] first;
             static if(InTuple!(Local.list[0],Caller.list)){
                 alias Constraints!(TupleRemoveAll!(first,Local.list)) 
 newLocalConstraints;
                 alias ConstraintCheck!(newLocalConstraints,Caller) 
 ConstraintCheck;
             }
             else{
                 const bool ConstraintCheck = false;
             }
         }
         else{ // nothing left to check
             const bool ConstraintCheck = false;
         }       
     }
     else{ // nothing left to check
         const bool ConstraintCheck = true;
     }
 }
 
 // Here's the useful part:
 struct ExceptionSafe {}
 struct LGPLed {}
 struct Reviewed {}
 
 void f(alias CallerConstraints)(Params params){
     alias Constraints!(ExceptionSafe) MyConstraints;
     static assert(ConstraintCheck!(MyConstraints,CallerConstraints));
     /* do something */
 }
 
 void g(alias CallerConstraints)(){
     alias Constraints!(ExceptionSafe,Reviewed) MyConstraints;
     static assert(ConstraintCheck!(MyConstraints,CallerConstraints));
 
     // try to call the other function
     f!(MyConstraints)();  // error, trying to call unreviewed code from 
 reviewed code
     f!(ConstraintRemove!(MyConstraints,Reviewed))(); // ok, ignore 
 Reviewed constraint
     f!(IgnoreConstraints)(); // ok, explicitly ignore constraints entirely
 }
 
 void main(){
     alias Constraints!(ExceptionSafe,Reviewed) MyConstraints;
     g!(MyConstraints)();
 }
 
 This won't compile under DMD 0.012 and later - Bug 1196 keeps operations 
 like InTuple!() from operating correctly.  So this is only half-tested.  
 There are also a few different ways one could implement this.  I opted 
 for this particular definition of Constraints!() to allow for the 
 ConstraintCheck!() operation to work for comparing two tuple lists 
 (otherwise, they'd collapse into a single tuple).
 
 Aside from the advantages that tuples offer, I'm having a hard time 
 seeing a clear advantage over the C++ version.  We still get template 
 bloat, and namespace concerns, plus it's not much more readable.  At a 
 minimum, the lack of a need for a heavy amount of compile-time code is a 
 clear advantage and I think (not sure here) the concerns about virtual 
 methods are also addressed thanks to D's design.  So I think this edges 
 out the C++ version rather invisibly.
 



someone has asked for this before).
May 08 2007
parent reply Pragma <ericanderton yahoo.removeme.com> writes:
janderson wrote:

 Pragma wrote:
 

 someone has asked for this before).


I'm pretty sure I have on a few occasions. ;)

One way I can see this working is to use a custom pragma() - I think I managed
to talk Gregor into trying it out in 
Rodin, at some point or another.  The suggestion isn't a personal bias, it's
just that they're pretty much the ideal 
construct in D for supporting attributes.

struct ExceptionSafe{
   static ExceptionSafe opCall(){
     ExceptionSafe_this;
     return _this;
   }
}

// attach the ExceptionSafe attribute to the function f()
pragma(attr,ExceptionSafe()) void f(){
   /* do something */
}

But there are a few problems with using reflection to accomplish constraint
checks.  The most obvious of which is that 
we're now checking things at runtime rather than at compile-time; so you have
to run a full test suite in order to make 
sure you coded things up correctly.  Also, without being able to get the
attributes for the current function, or even 
the calling function, there's no way to check the constraints without wrapping
the call with a template.

The mess from using templates for this comes from the fact that the constraints
can be thrown into a list in any order, 
so it defies the built-in specialization and overloading mechanisms provided by
D.  If there were some way to specialize 
function declarations and calls, via an unordered property set (or by
compile-time attributes), then it would be very 
easy to do.

-- 
- EricAnderton at yahoo
May 09 2007
parent reply "David B. Held" <dheld codelogicconsulting.com> writes:
Pragma wrote:

 [...]
 One way I can see this working is to use a custom pragma() - I think I 
 managed to talk Gregor into trying it out in Rodin, at some point or 
 another.  The suggestion isn't a personal bias, it's just that they're 
 pretty much the ideal construct in D for supporting attributes.
 
 struct ExceptionSafe{
   static ExceptionSafe opCall(){
     ExceptionSafe_this;
     return _this;
   }
 }
 
 // attach the ExceptionSafe attribute to the function f()
 pragma(attr,ExceptionSafe()) void f(){
   /* do something */
 }
 [...]


Interestingly enough, this may well be only the second reasonable 
application of AOP that I've encountered. ;)  The problem here is that 
we want to perform a certain check *on every function*, but we don't 
want to make it *look* like we are performing the check.  Implementing 
these attributes as aspects actually makes a lot of sense.  I wonder 
whether D should try to support AOP somehow...

Dave
May 09 2007
parent Pragma <ericanderton yahoo.removeme.com> writes:
David B. Held wrote:

 Pragma wrote:

 [...]
 One way I can see this working is to use a custom pragma() - I think I 
 managed to talk Gregor into trying it out in Rodin, at some point or 
 another.  The suggestion isn't a personal bias, it's just that they're 
 pretty much the ideal construct in D for supporting attributes.

 struct ExceptionSafe{
   static ExceptionSafe opCall(){
     ExceptionSafe_this;
     return _this;
   }
 }

 // attach the ExceptionSafe attribute to the function f()
 pragma(attr,ExceptionSafe()) void f(){
   /* do something */
 }
 [...]


 
 Interestingly enough, this may well be only the second reasonable 
 application of AOP that I've encountered. ;)  The problem here is that 
 we want to perform a certain check *on every function*, but we don't 
 want to make it *look* like we are performing the check.  Implementing 
 these attributes as aspects actually makes a lot of sense.  I wonder 
 whether D should try to support AOP somehow...
 
 Dave



feature, which is really just to help enrich 
reflection.  I could easily see a pragma being used for AOP, though something
like AOP (read: function-wrapping) should 
really be a first-class construct IMO.  I have no clue what that would look
like, since there's so many different ways 
developers would expect AOP to work (i.e. explicit meshing of aspects,
cross-cutting, etc).

You should drop a message in the "python style decorators thread".  It has
morphed into an AOP for D discussion.

-- 
- EricAnderton at yahoo
May 10 2007
prev sibling parent reply Knud Soerensen <4tuu4k002 sneakemail.com> writes:
On Mon, 07 May 2007 10:58:24 -0400, sergk wrote:


 I've just noticed a Northwest C++ Users Group presentation
 "Red Code, Green Code:  Generalizing const" by Scott Meyers, and found it
quite interesting.
 
 So here it is:
 http://nwcpp.org/Meetings/2007/04.html
 


Very good idea.

I am wondering if it is possible to extend the idea to ensure layering in
code.

I normally use 5 layers.

Interface layer.
Application layer.
Domain layer.
Technical layer.
Platform layer.

The constrain on the code is that it should only make call in it own layer
or the layer below.

I think it could be very useful.

Knud
May 08 2007
parent Stephen Waits <steve waits.net> writes:
Knud Soerensen wrote:

 
 The constrain on the code is that it should only make call in it own layer
 or the layer below.
 
 I think it could be very useful.


I think this is a really interesting idea.

--Steve
May 08 2007