Boost logo

Boost :

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2003-04-24 16:15:59

>From: "Alisdair Meredith" <alisdair.meredith_at_[hidden]>

> Terje Slettebø wrote:
> > Therefore, I did not miss the point. However, did you get mine? The use
> > const to achieve the same?
> I am not sure I followed that one.
> Are you saying that the variable at the calling side must be declared
> const in order to avoid accidentally being passed to a routine that
> might take parameters by non-const reference? This would seem a highly
> impractical solution, as I suspect in many cases variables are variable,
> well, for a reason!


Yes, a "const variable" may seem like something of an oxymoron. Not to
mention a "const volatile" one. :)

As I said in the reply I just sent to John Swartzentruber, there may be
situations where it's difficult to use this.

> The point of the proposal, as I understand it, is to prevent
> accidentally passing parameters into functions that require modifyable
> references without being aware of it. Given all you see at the
> call-site as a function with a few arguments, there is no clear
> indication of what is happening.
> The proposal allows the library writer to make such usage clear, most
> other opinions seem to be that it is simply up to the library clients to
> pay attention, read their headers and not make mistakes. Most (if not
> all) suggested conventions require you to read the declaration for each
> function that is called before they can be applied. I don't know about
> you, but for me jumping in to maintain an established code-base
> contaiming potentially megabytes of source is a daunting enough task,
> anything the library writer can do to clear up misunderstandings sounds
> like a good thing.
> That's what I understand to be the spirit of the proposal. How
> practical it is to persuade people it is worth typing extra characters
> just to say 'yes I know what I am doing' seems to be more than open to
> debate <g>

I also understand the motivation for this.



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