www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Google video about consepts

reply Knud Soerensen <4tuu4k002 sneakemail.com> writes:
Hi 

I found this interesting google video.

Concepts: Extending C++ Templates For Generic Programming
http://video.google.com/videoplay?docid=-1790714981047186825&hl=en
Apr 05 2007
next sibling parent reply Downs <default_357-line yahoo.de> writes:
Knud Soerensen wrote:
 Hi 
 
 I found this interesting google video.
 
 Concepts: Extending C++ Templates For Generic Programming
 http://video.google.com/videoplay?docid=-1790714981047186825&hl=en
Somewhat related to that, if you want to check if a template type implements some function without requiring interfaces, here's a quick template:
 template funcmatch(T, char[] name, RetType, Parameters ...) {
   mixin("static assert(is(typeof(T."~name~")), \""~T.stringof~": Function
"~name~" not implemented!\");");
   mixin("static assert(is(ReturnType!(T."~name~")==RetType), \""~T.stringof
     ~": Return type is \"~ReturnType!(T."~name~").stringof~\", should be
\"~RetType.stringof);");
   mixin("static assert(is(ParameterTypeTuple!(T."~name~")==Parameters),
\""~T.stringof
     ~": Function parameters are
\"~ParameterTypeTuple!(T."~name~").stringof~\", "
     ~"should be \"~Parameters.stringof);");
 }
use it like template foo(T) { mixin funcmatch!(T, "mustImplement", int, float, char[]); } This will make sure T implements a int mustImplement(float, char[]) and output a helpful error message if it doesn't. greetings -- downs
Apr 05 2007
parent reply Dan <murpsoft hotmail.com> writes:
I've never understood some of the Java introduced things in programming
languages.  For example, classes.  I can understand localizing algorithms and
data together, but I can't understand how big a class is, or what it's layout
is.  It's a black box.  I don't believe in creating black boxes - so I don't
like classes or interfaces or templates.

Downs Wrote:
 This will make sure T implements a int mustImplement(float, char[]) and output
a helpful error message if it doesn't.
Wow... my solution for Simple Data Type "Interfaces" was to use an array of function's. The "function" type in D is really a pointer to the entry point of the function AFAIK.
Apr 05 2007
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Dan" <murpsoft hotmail.com> wrote in message 
news:ev3hjl$26p4$1 digitalmars.com...
 I've never understood some of the Java introduced things in programming 
 languages.  For example, classes.  I can understand localizing algorithms 
 and data together, but I can't understand how big a class is, or what it's 
 layout is.  It's a black box.  I don't believe in creating black boxes - 
 so I don't like classes or interfaces or templates.
You believe Java came up with those things?
 Downs Wrote:
 This will make sure T implements a int mustImplement(float, char[]) and 
 output a helpful error message if it doesn't.
Wow... my solution for Simple Data Type "Interfaces" was to use an array of function's. The "function" type in D is really a pointer to the entry point of the function AFAIK.
Apr 05 2007
prev sibling next sibling parent reply janderson <askme me.com> writes:
Knud Soerensen wrote:
 Hi 
 
 I found this interesting google video.
 
 Concepts: Extending C++ Templates For Generic Programming
 http://video.google.com/videoplay?docid=-1790714981047186825&hl=en
My Quick Summary: Concepts as restrictions: Essentially this is a static contract. Static assert if you will. It could probably be done in other ways. However it does bring attention to template verification helper functions. Concept_Maps Convert one thing to another so that it can be used in a template. Foreach Concepts. There seems to be some special compiler concepts that you can't define inside the library. I'm not 100% clear on these. Somehow the InputIterator is defined such that the compile knows it can work with the new foreach. Can someone explain? I wonder how close we can get to a simple D version with current syntax. And if we can't how can we improve D's syntax so we can. -Joel
Apr 05 2007
parent Lutger <lutger.blijdestijn gmail.com> writes:
janderson wrote:
 Knud Soerensen wrote:
 Hi
 I found this interesting google video.

 Concepts: Extending C++ Templates For Generic Programming
 http://video.google.com/videoplay?docid=-1790714981047186825&hl=en
This is interesting, I (tried to) read the proposal, but this video makes it clear. Very inspiring.
 My Quick Summary:
 
 Concepts as restrictions:
 
 Essentially this is a static contract.  Static assert if you will.  It 
 could probably be done in other ways.  However it does bring attention 
 to template verification helper functions.
The cool thing, as I understand it, is that it works like interfaces: it's not only that such and such must be available by T, but that the implementation is restricted to using these only - which the compiler must check. The latter seems more important. I don't see how one is going to do this with current D in a clean way, though it should be possible to come close.
 Concept_Maps
 Convert one thing to another so that it can be used in a template.
 
 Foreach Concepts.
 There seems to be some special compiler concepts that you can't define 
 inside the library.  I'm not 100% clear on these.  Somehow the 
 InputIterator is defined such that the compile knows it can work with 
 the new foreach.  Can someone explain?
As I understand it, you can write a concept map that the compiler looks up so any type that can be made to fit the requirements can be converted. In the same way pointers can be made to adhere to the iterator concept. I guess it is similar to how you can iterate over delegates in D.
 I wonder how close we can get to a simple D version with current syntax. 
  And if we can't how can we improve D's syntax so we can.
 
 -Joel
Me too. At first I thought most could be achieved by current features, but I'm not so sure now. I think at least the macro feature is needed, and then someone with a solid understanding could implement most of it in a library. Although perhaps eventually some kind of language support may go a long way to achieve a sane syntax, which is a thing I think Walter Bright is very good at...
Apr 09 2007
prev sibling parent reply Reiner Pope <reiner none.com> writes:
Knud Soerensen wrote:
 Hi 
 
 I found this interesting google video.
 
 Concepts: Extending C++ Templates For Generic Programming
 http://video.google.com/videoplay?docid=-1790714981047186825&hl=en
I've made an implementation of concepts (just declares methods and allows some inheritance), which is attached. It is quite clean overall -- I think it has the potential to do most of C++0x Concepts, except for overloading (which is a big lack). It already allows two main features, though: checking it is instantiated correctly (and it even gives very nice error messages like static assert "Type 'MyFourthInterface' has no method with signature 'char[] anotherMethod(bool)'.") and checking that you haven't cheated when writing your templates, expecting things you haven't documented. It does the former with static if and is(), and it does the latter by constructing a minimalistic implementation and instantiating the template; the compiler then will pick up any errors. Enjoy! Reiner
Apr 08 2007
parent reply Reiner Pope <reiner none.com> writes:
I forgot to say that I've given some thought to overloading and 
concept_maps.

You could implement concept_maps quite easily. Basically you introduce a 
  concept_map template, and you request the map from that at the 
beginning of your template, instead of checking that your given type 
matches the concept. So, your template would look like:

void someFunc(T)(ConceptMap!(MyConcept, T) t) {...}

You would define in your concepts library a very general ConceptMap 
implementation:

template ConceptMap(alias Concept, T)
{
     static if (Concept.AreRequirementsMet!(T)) alias T ConceptMap;
     else static assert(false);
}

and then, to implement the maps in userland, you create your own 
specializations:

template ConceptMap(alias Concept : MyConcept, T : MyType)
{
    // Define the map
}

Unfortunately, this breaks IFTI.


Overloading:
There's the possibility of writing a forwarder function which chooses 
the best overload. It could be made quite nice and automated with 
templates and perhaps some AST magic. Basically, the 
automatically-generated forwarder would find the concepts that your 
parameter matches (how? I'm not so sure...) and then list them as 
parameters in order of increasing specialisation. You would allow D's 
overloading rules to take control again:

    template Foo(T, alias a : LowestRequiredConcept, alias b : 
NextRequiredConcept, c...) {...}
    template Foo(T, alias a : LowestRequiredConcept, b...) {...}


The compiler would then choose the second overload of 
NextRequiredConcept isn't specified (by your forwarder) and the first if 
it is.
But this ordering only works for single template parameters.

I've thought about some kind of syntax to say, "Don't use this template 
-- choose a different overload;" or "prefer this template to that" but 
it seems a bit tricky for user code. It seems that if we really wanted 
it, and expected it to be used, there would have to be *some* 
substantial change to the language to introduce it; either make it 
native to the language, or allow library code to explicitly assist with 
overloading.

Cheers,

Reiner
Apr 08 2007
parent Georg Wrede <georg nospam.org> writes:
Reiner Pope wrote:
 I've thought about some kind of syntax to say, "Don't use this template 
 -- choose a different overload;" or "prefer this template to that" but 
 it seems a bit tricky for user code. It seems that if we really wanted 
 it, and expected it to be used, there would have to be *some* 
 substantial change to the language to introduce it; either make it 
 native to the language, or allow library code to explicitly assist with 
 overloading.
I think we should have both. It's not hard to imagine that the language can assist up to a certain point, but often the more delicate stuff simply has to be left to the template author.
Apr 09 2007