http://permalink.gmane.org/gmane.comp.lib.boost.devel/166593

As illustrated by a stupid example.  Or at least overly-simplistic 
example. I mean, really, if your compiler can't generate the best code 
for (x + x) where x is an integer, do you really want to take the time 
to teach the compiler to do so? :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> http://permalink.gmane.org/gmane.comp.lib.boost.devel/166593

> As illustrated by a stupid example.  Or at least overly-simplistic 
> example. I mean, really, if your compiler can't generate the best code 
> for (x + x) where x is an integer, do you really want to take the time 
> to teach the compiler to do so? :-)

  I don't have the slightest clue what the subject of your post has to do
with that article.

  Anyways, the idea of concepts in the new C++ standard is not related to
code generation at all. It's simply related to getting clearer error
messages when using templates.

  One problem with current templates is that template functions implicitly
expect the template type to have certain properties. There's no way to
*explicitly* tell that the template expects, for example, that the given
type supports the operator +, or the operator =, or the functions begin()
and end(), for example. The only way to "tell" it is to simply use them
in the function implementation.
  The problem with this is that if you give some type not meeting those
requirements to the template, the error message will usually be very
cryptic because it will be spawned from somewhere inside the template
function. The problem is worsened by the fact that many template classes
and functions (especially in the standard library) have many template
parameters (some of them with default values), making the error message
longer and more cryptic.

  The idea with concepts is that you can create specify explicitly in the
declaration of a template function all the requirements for the template
type. For example, you can explicitly say "the type requires operator +,
operator = and the member functions begin() and end()". If the user then
calls the template function with a type which does not meet those
requirements, the compiler can then give a very clear and explicit error
message, like "this template parameter requires operator +, but the type
you gave at this line doesn't support it".

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   I don't have the slightest clue what the subject of your post has to do
> with that article.

>   The idea with concepts is that you can create specify explicitly in the
> declaration of a template function all the requirements for the template

That's the basic idea behind Java-style "interface" declarations, you 
see.  Hence, the subject line of the post.

I was more amused by example of picking different operators to aid the 
code generator in generating a more efficient operation for "+" than 
anything, tho.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> >   The idea with concepts is that you can create specify explicitly in the
> > declaration of a template function all the requirements for the template

> That's the basic idea behind Java-style "interface" declarations, you 
> see.  Hence, the subject line of the post.

  Java interfaces have little to do with template requirements.

  Can you, for example, create a function which says "the parameter type
has to support this interface specification of mine" and then give it an
*existing* type (which has never even heard about your requirement
specification)? No, because the existing class would have to explicitly
say "implements <the definition>", which is impossible if it's an existing
class which you can't modify.

  Can you, for example, create in Java a function which expects a parameter
which supports the + operator, and then you can call this function by giving
it an 'int' (the internal type, not the 'Integer' class) or a string? No,
because neither one says "implements <whatever the + operator interface
would be>". And especially no because 'int' has absolutely nothing to do
with a string, and thus you can't create a function in Java which would
accept either one as a parameter. They have nothing in common, not a common
base class, not a common interface, nothing at all.

  That's precisely what makes templates different from inheritance. They
basically accept anything. Want to call the function with an int? Then call
it giving it an int. Want to do the same with a string? Then go ahead. An
'int' and a 'string' don't need to have anything in common (except that both
support the '+' operator).

  Besides, Java interfaces are *implemented*, very specifically, template
parameter requirements are not. You don't have to tell for a type that
"it implements this template parameter requirement". You just give it
to the template function and it can (in the future C++ standard) check
that it indeed does so. Thus for example an internal type can conform
to such a specification (even one written by yourself) even though the
internal type has absolutely no knowledge of that specification.
  With Java interfaces the class must know the specification and must
implement it very explicitly with syntax for that specific purpose. It
has no way of implementing specifications which it cannot see.

> I was more amused by example of picking different operators to aid the 
> code generator in generating a more efficient operation for "+" than 
> anything, tho.

  I don't really understand what's so amusing with that. No compiler is
perfect (regardless of language).

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   That's precisely what makes templates different from inheritance. 

Yes, I know. But I appreciate the explanation. I understand it's merely 
giving more information to the compiler so it can generate error 
messages more easily, without actually changing the language.

(I'll also note there's a bunch of benefits to doing it the way Java 
does that C++ templates can't support, too, having to do with strong 
typing and dynamic loading and all that sort of stuff that C++ doesn't 
do. But that's off topic.)

>> I was more amused by example of picking different operators to aid the 
>> code generator in generating a more efficient operation for "+" than 
>> anything, tho.
> 
>   I don't really understand what's so amusing with that. No compiler is
> perfect (regardless of language).

Sure, but if your compiler for your statically-typed language doesn't 
know that for integral types
(x + x) is the same as (2 * x) is the same as (x << 1),
then I am not sure that writing macros to teach your compiler this is 
the best use of your time, rather than finding a better compiler.

As I said, it was an overly-simplistic example that amused me. Entirely 
appropriate for the article it was presented in. But it just twigged my 
"low-level hackers live here" meme. Someone once asked me how you do a 
"shift right by one byte" in Ada, and I said (x / 256). Someone else 
commented "Wow, you really think in Ada!"  I said "No, I write it the 
same way in C and BASIC and Pascal, too."

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> (I'll also note there's a bunch of benefits to doing it the way Java 
> does that C++ templates can't support, too, having to do with strong 
> typing and dynamic loading and all that sort of stuff that C++ doesn't 
> do. But that's off topic.)

  I don't understand what stops you from writing "interfaces" in C++.
Just create a class with no member variables and with all the member
functions purely virtual, and there you are. (Why you would explicitly
avoid member variables and non-purely virtual functions is beyond my
grasp, but it is possible.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> (I'll also note there's a bunch of benefits to doing it the way Java 
>> does that C++ templates can't support, too, having to do with strong 
>> typing and dynamic loading and all that sort of stuff that C++ doesn't 
>> do. But that's off topic.)
> 
>   I don't understand what stops you from writing "interfaces" in C++.

Nothing. It just doesn't give you the same benefits that doing it with 
Java does, due to the nature of the compilation process and object code 
storage formats.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Warp wrote:
> (Why you would explicitly
> avoid member variables and non-purely virtual functions is beyond my
> grasp, but it is possible.)

Oh, and to clarify: By doing so, you get the things like strongly-typed 
dynamic loading that are difficult to do if you put code or allocation 
of data space in the interface.  I.e., because it lets you do the things 
that you can't do in C++.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> http://permalink.gmane.org/gmane.comp.lib.boost.devel/166593

Actually, this looks really useful.  Not for the example posted, of course,
but in general :)

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> It just doesn't give you the same benefits that doing it with 
> Java does, due to the nature of the compilation process and object code 
> storage formats.

  What benefits are those?

-- 
                                                          - Warp

Post a reply to this message