Boost logo

Boost :

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-09-23 15:16:43

Michael Walter wrote:
> On 9/23/06, Oleg Abrosimov <beholder_at_[hidden]> wrote:

> Anyway, as I remember from D&E book there was a proposal to add named
> params to the language, but it was rejected because of named params
> encourage procedure-style programming and C++ was positionad as a OO
> language. Of course, now it is positioned as a multiparadigm language,
> but priorities remain the same: OO is preferred over procedural in C++.
> or may be I'm missing something?

The entire STL is about as far from OO as one can imagine, so I'd say so.
Smalltalk supports positional parameters and it's about as 'pure OO' as you
can get.

>> The solution with auxiliary structure for parameter bundling is just
>> slightly more verbose, but
>> 1) it is exact (it is hard to interpret in a wrong way)
>> 2) it doesn't pollute namespace with parameter names
>> 3) instance of params structure can be reused many times reducing code
>> duplication/bloating.
>> Sorry for so long opus, but I really wonder why David Abrahams and
>> Daniel Wallin put so great effort in the parameter lib. I can not see
>> it's advantages.
> Problems with your approach include:
> a) parameter values are copied
> b) parameter values need to be default-constructable (into a valid state)
> c) you cannot check whether mandatory parameters are supplied at
> compile-time (I believe)

I'll put it another way. As software complexity has increased the number of
options one might need to configure a particular class or function can become
quite large. Most of these options will typically have appropriate default
values and hence won't need to be user specified. However, making a set of
overloads with positional parameters in combinations that make sense may be
difficult or impossible. Sure, you can make intermediate types, but really
that's just a bit of noise that detracts from the users purpose. Named
parameters provide for code clarity where positional parameters cannot.

As an example, in date-time with the formatting facets there's all sorts of
strings (month names, week names, infinity names) and other options that the
user might want to override the defaults. Typically a user wouldn't override
all of these, just a few. Currently the library doesn't provide constructors
that allow the user to override the options on construction -- it's just not
reasonable with positional parameters and overloading. Rather, they have to
construct and then modify. This is, in my view inferior -- I'd rather have an
immutable facet type which handles all the overrides at time of construction.

This is enough of an issue that other languages have seen fit to incorporate
this directly into the language -- Ada, Smalltalk, Objective-C to name a few.
In other languages this is a proposed feature

In the meantime, perl 5 coders use conventions with hash data structures to
accomplish what the perl 6 language feature would do. It's an extremely
common idiom in perl code. Ruby, Python and other 'hot' languages all have
ways to do this as well.

I, for one, am happy they have made the effort to provide a common way to do
this in C++. It's even more amazing to me that their's virtually no loss of
efficiency. It's only thru this sort of experimentation and effort that
programming practices can be improved. I'd eventually like to see a language
feature, but that's a different discussion....


Boost list run by bdawes at, gregod at, cpdaniel at, john at