"Team Hyer" <teamhyer@yahoo.com> wrote in message news:20020226135132.28760.qmail@web12406.mail.yahoo.com...

> (This is loosely based on an earlier post I made,
> proposing the use of "const" as a verb to requalify
> local variables in the current scope.

That was also discussed in length, look around subjects containing `~using`.

First thought ~using was supposed to remove or hide names introduced by using, but it can be extended to other names as well.

Paul

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Wesley J Landaker" <wjl@ee.byu.edu> wrote in message news:eh8f8.28$t33.54909@news.uswest.net...

> I think const_cast<> pretty much solves this: you create a "const"
> variable, then populate it once, using const_cast<>. After that point,
> const access is enforced as usual.

Really?

> const int myVar;
> MyFunc(..., const_cast<int *>(&myVar));
> // myVar can't be messed with here,
> // and the const_cast has made it clear
> // that we are initializing a constant
> // value

Casting avay constness of an originally const object and modifying it is a clear-case undefined behavior. And it it is a simple type, you'll see  a GPF or coredump with most of today's compilers on protected systems.

Paul

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

(This is loosely based on an earlier post I made,
proposing the use of "const" as a verb to requalify
local variables in the current scope.  Based on
feedback to that post, I have realized that it is a
restrictive special case of something more valuable.)

I propose adding a way to "remove from circulation"
a local variable, so that later statements within
the same scope cannot access it.  I envision the use
of a new keyword, such as "without", though I
imagine that "void" could be hijacked for the same
purpose.

Let me begin with two examples:

1)  I instantiate a variable, then populate it
somehow, and wish to prevent non-const access.

 int myMutableVar;
 MyFunc(..., &myMutableVar);
 const int& myVar = myMutableVar;
 without myMutableVar;

Following the "without" declaration, myMutableVar
would not be a valid variable name.  (Though it
would still be in scope, so myVar would remain
valid.)


2)  I compute an offset into a vector, and ensure
that all access is offset:

 vector<T> myBaseVector;
 vector<T>::iterator myEnd = myBaseVector.end();
 vector<T>::iterator myBegin = myBaseVector.begin() +
ComputeOffset(...);
 without myBaseVector;

Now access with myBegin[j] is still valid, but
inadvertent use of myBaseVector is illegal.



The variables named in the "without" declaration
would be hidden for the remainder of the scope
of that declaration.

I have not thought yet about whether we should
be able to "do without" functions or member data.
Even this form of without, though, would let me
(at least) write safer programs.


-- TMH




__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

You can wrap your variables in local classes:

Team Hyer wrote:
[...]
> 1)  I instantiate a variable, then populate it
> somehow, and wish to prevent non-const access.
>
>         int myMutableVar;
>         MyFunc(..., &myMutableVar);
>         const int& myVar = myMutableVar;
>         without myMutableVar;

 struct Init {
   Init() { MyFunc(...,var); }
   int var;
 };
 const Init MyMutable;
 MyMutable.var = 2; // ERROR!!
 int i = MyMutable.var; // OK

More complex needs may require more complex local classes or even
separate helpers.

Cheers,
Nicola Musatti

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

On Tuesday 26 February 2002 08:47 pm, in comp.std.c++ Team Hyer wrote:

> Let me begin with two examples:
>
> 1)  I instantiate a variable, then populate it
> somehow, and wish to prevent non-const access.

I think const_cast<> pretty much solves this: you create a "const"
variable, then populate it once, using const_cast<>. After that point,
const access is enforced as usual.

> int myMutableVar;
> MyFunc(..., &myMutableVar);
> const int& myVar = myMutableVar;
> without myMutableVar;

What about simply using:

const int myVar;
MyFunc(..., const_cast<int *>(&myVar));
// myVar can't be messed with here,
// and the const_cast has made it clear
// that we are initializing a constant
// value

> 2)  I compute an offset into a vector, and ensure
> that all access is offset:
>
> vector<T> myBaseVector;
> vector<T>::iterator myEnd = myBaseVector.end();
> vector<T>::iterator myBegin = myBaseVector.begin() +
> ComputeOffset(...);
> without myBaseVector;
>
> Now access with myBegin[j] is still valid, but
> inadvertent use of myBaseVector is illegal.

Similarly,

const vector<T> myBaseVector;
vector<T>::iterator myEnd = const_cast<vector<T> >(myBaseVector).end();
vector<T>::iterator myBegin = const_cast<vector<T> >(myBaseVector).begin() +
ComputeOffset(...);

--
Wesley J. Landaker - wjl@ee.byu.edu

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]