From 320814203390905791 X-Google-Thread: 7894ca11fe,308ef4b41a1062df X-Google-Attributes: gid7894ca11fe,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!newsfeed.stanford.edu!news.kjsl.com!news.alt.net!frodo.cs.rpi.edu!not-for-mail From: SG Newsgroups: comp.std.c++ Subject: Re: Dynamic Concepts Date: Tue, 5 May 2009 14:08:48 CST Organization: http://groups.google.com Lines: 80 Sender: cppmods@cs.rpi.edu Approved: james.dennett@gmail.com Message-ID: <20ab35d3-55ed-4f28-8406-75775e377150@e14g2000vbe.googlegroups.com> References: <49fb63a8$0$32671$9b4e6d93@newsspool2.arcor-online.net> NNTP-Posting-Host: netlab.cs.rpi.edu Content-Type: text/plain; charset=ISO-8859-1 To: (Usenet) Return-Path: X-Original-Date: Mon, 4 May 2009 10:40:16 -0700 (PDT) X-Submission-Address: std-c++@netlab.cs.rpi.edu Xref: g2news2.google.com comp.std.c++:545 On 2 Mai, 06:58, Ben Strasser wrote: > I've been playing with concepts lately and I am really excited about > seeing them used in the wild. > > There is however one thing that bothers me. With their introduction we > now have 2 notions of interfaces: The traditional one with virtual > functions and inheritance and the new concept system. This seems to bother a lot of people with a Java background at first (I'm not excluding myself here). Interfaces and late binding are pretty much the only abstraction mechanism they are familiar with. But runtime polymorphism is a different form of abstraction and not always interchangable with template-based generic programming. Concepts is about improving support for generic programming. > [...] > I think there should be some way to dynamically bind concepts. > > Let me illustrate this with an example. Consider the common InputStream > hierarchy. Traditionally one would implement this with one base class > InputStream and derive lots of classes like FileInputStream, > SocketInputStream, ... > > Another method of realizing this would be to create a concept > InputStream and make the FileInputStream, ... classes be a model of it. > > The traditional way provides a lot of flexibility by allowing you to > dynamically interchange different stream types, but comes at the price > of virtual function calls, that are nearly impossible to optimize. There > are situations where this flexibility is needed. The C++ features are pretty low level. If you want to be able to program more "dynamically" you can do that by combining C++ features in a smart way. For example, Adobe's Software Technology Lab has this library called "Poly". It basically allows you to use value types polymorphically without requiring any inheritence relationships. I believe they even call it "dynamic concepts". In C++0x you would do this by writing both, a concept C and an abstract base class A along with a templated wrapper class W that inherits from the abstract base class A and forwards any requests to the wrapped object of type T. The handle class Poly would manage a pointer to A and the life- time of its pointee. Something like this goes under the name "type erasure" and is also used in boost::function, boost::any, etc. However, you do have a point. It's tedious to have to write the definitions of "class A", "template class W" and "template class Poly". Maybe it's worth considering a language extension that can make the compiler generate such boiler plate code automatically ("automated type erasure"). But I have my doubts about its usefulness in C++ because it's "syntactic sugar" that only helps in rather special cases. Maybe this is something that new language designers should consider (throwing away inheritence in favor of mixins + generic programming + automated type erasure via compiler magic for your runtime polymorphism needs). > However there are also other situations, where I know that I'll just > open a file, read a few things and close it directly afterwards. Here I > pay for the virtual function calls but have no gain at all. Not necessarily. If you create an object on the stack ("automatic storage") of a class that has virtual functions, the compiler doesn't need dynamic dispatching because it already knows the exact type and can invoke the correct functions directly (it can even be inlined). Also, this dynamic dispatch is usually not a big problem performance- wise. I don't think it's significantly slower than calling "normal" functions. "char get()" should not be the only function in the interface, though, you may want to add a function that reads a whole block so that the function call overhead is reduced. Cheers! SG -- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]