"Hibou57 (Yannick Duch�ne)" wrote in message news:4e959c35-34d1-49fb-b1eb-5b298e42610f@z19g2000yqk.googlegroups.com... >On 9 f�v, 15:47, Robert A Duff wrote: >> I agree that it's good to avoid heap management when possible. >> But why can't you declare local variables of type My_Interface'Class, >> initialized with build-in-place function calls? > >Synchronized-and-the-like interface types are limited, so the built-in- >place is indeed really built-in-place (no kind of conversion allowed >at any stage). The initializer function have to return a class wide >and return it using an extended return statement which is required to >return the same exact type/subtype as the one function returns. > >This way of doing thing is not compatible with the implementation- >hiding requirement, as it would require the implementation type to be >exposed in the public part, so that I could define a public function >returning this exact type. I don't buy this at all. The exact types to create can be selected by many means (presumably by the parameters). You can use a dispatching constructor function in the concrete types, using the factory pattern (Generic_Dispatching_Constructor), and roughly organized as Bob noted. Note that you have this problem with *any* constructor of any tagged type if you have any interest at all in allowing future extensions. It would be nice to have a container for Classwide limited types as the problem comes up frequently. We made some initial efforts in that direction but had problems with finalization and readability of the results. We then turned our attention to those building-block problems and never did come back to the limited containers themselves. I suspect that we could do a very usable job with the new syntax magic for iterators, accessors, and the like. (Presuming that we got those to work out, not there yet.) Randy.