Hi

I found this interesting google video.

Concepts: Extending C++ Templates For Generic Programming http://video.google.com/videoplay?docid=-1790714981047186825&hl=en

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

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.

"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.

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

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

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

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...

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.