I've been using the "?&in" parameter in my c++ interface to accept input of any type, but ? accepts anything and sometimes you only want to accept handles.

Ofcourse you can examine the input in runtime, but that takes runtime cycles and if the input is not to your liking, your error will happen in runtime. I would much like to have this error happen during compilation.

I would like to tell the compiler that I am only interested in handles of any type, maybe using the simple syntax "?@".

Right now the compiler tells me "Object handle is not supported for this type." if I try to say "?@".

I've been coding up some glorious template containers and I could use something like this for the iterators. The iterators' constructor takes a handle to the parent container and right now the only way to code that seems to be

list_iterator<T> constructor(?&in)

Using ?@ would make it cause a compilation error if someone tries to use a primitive or a value type or something here.

Ofcourse it would be glorious to use the template parameter like this

list_iterator<T> constructor(list<T>@)

but that doesn't seem to work either, registering gives no errors but compiling this:

list<Material@> cont;
...
for(list_iterator<Material@> it(@cont);it++;){
  //iterator constructor above causes the error
}

gives me these compilation errors:

No matching signatures to "list_iterator<Material@>(list<Material@>@&)"
Candidates are:
"void list_iterator::factstub(list<T>@)"

that candidate sure sounds like the right one but apparently its not a match

I've been thinking in similar lines. ?@ would be a nice way telling the compiler only to accept handles. Another option that I've thought about would be to have some callback so the application can decide at compile time whether the passed in type should be allowed or not. The latter would require more work by the application developer, but would provide exact control.

The problem with the constructor sounds like a bug in the library. I'll investigate it.

Good stuff man. Compile time callback sounds legit.

I've fixed the bug with the generation of template instances in revision 2008. Now it is perfectly possible for one template type to have methods that take or return another template type, e.g. the list_iterator<T> type being constructed with a list<T> type.

Thanks,

Andreas