Any new feature in any language is bound to break a
small amount of legacy code.

However, there are some very real situations where a
feature of this sort makes would make sense and, in
fact, could even be a life-saver.

Consider the following code.

void f ()
{
 freeze int i = 0;

 ...

 while (1) {
  ...
  thaw ++i;
  if (i = some_val) // Error! Cannot
                    // modify a frozen
      // without thawing
   break;
 }

 return 0;
}

To implement these keywords, one merely has to modify
any variable that acts as an iterator within a loop
(like i above) to freezable. Next compile that
(compilation) unit and check for syntax errors, which
the (supporting) compiler is sure to generate. One has
to run through the code to next see where i has to be
actually thawed and modified: all other errors are
bugs. A very simple feature; a feature however that
makes life easier for the programmer.

The whole issue is about choice, letting the
programmer use a type that is modifiable when he wants
it to be modifiable, and a const when it should be a
const. Another way of looking at this feature is a way
of extending data hiding to primitive types (though
this feature would be available to non-primitives
too). "thaw" is nothing except the equivalent of a
mutator without the overhead of a mutator call (all
right, agreed that mutators can be inlined; however,
there are other benefits, too; for example, there's no
need for the programmer to create his own mutators for
immediate assignment since they are built into the
language).

It could even be considered as a "shortcut mutator."
For example,

 struct Bar
 {
  int i;
  freeze double d;

  Bar () : d(10.0) {}
 };

 ...

 void f () {
  freeze Bar b;

  b.i = 10; // Error!
  thaw b.i = 10; // Works fine
  thaw b.d = 3.14; // Error! Though object b has
thawed, Foo::d hasn't
  thaw (b.d) = 3.14; // thaw both simultaneously and
assign
 }

The basic idea of a freezable is that the compiler
prevents the user code from modifying the bitwise
layout of a frozen object, unless it is modified by
thaw.

It could also be used for read-only access in a class,
like a property.

 class Bar
 {
 public:
  freeze bool isActive;

  Bar () : isActive(true) {}

  ...
 };

 void f () {
  Bar bar;

  if (bar.isActive) {
   ...
  }
 }

However, since Bar::isActive is a frozen within Bar,
it can be safely exposed without any associated risk
of inadvertent modification by the client code.
(Recall from my previous posting that a freezable can
be referenced only by a more restrictive type outside
its block.)

 void e (int x) {
  // ...
 }

 void f (int& x) {
  // ...
 }

 void g (freeze int& x) {
  // ...
 }

 void h (const int& x) {
  // ...
 }

 void caller () {
  freeze int v = 10;
  e(v); // Works fine, since only passing by value
  f(v); // Error! Cannot read into lower restriction
  g(v); // Error! Not restrictive enough
  h(v); // Works fine, since const is more restrictive
 }

 // ...

I look forward to more comments and suggestions.
Omar

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <20040123123254.47354.qmail@web20901.mail.yahoo.com>, Omar
Shaikh <omarshaikh71@yahoo.com> writes
>Any new feature in any language is bound to break a
>small amount of legacy code.

It isn't just the breaking of existing code but the cost of new
compilers, validation routines and in the case of high-integrity code,
the cost of re-validation of the code.

It isn't just conservatism that makes us reluctant to introduce new
keywords but an understanding of many of the hidden costs.

>
>However, there are some very real situations where a
>feature of this sort makes would make sense and, in
>fact, could even be a life-saver.
>
>Consider the following code.
>
>void f ()
>{
>       freeze int i = 0;
>
>       ...
>
>       while (1) {
>               ...
>               thaw ++i;
>               if (i = some_val) // Error! Cannot
>                                 // modify a frozen
>                                 // without thawing
>                       break;
>       }
>
>       return 0;
>>
Now rewrite that as:

void f() {
   int i(0);
   int const & i_ref(i);
   ....
   while(true){
      ...
      ++i;
      if(i_ref = some_val)  // error
etc.

With sensible naming you can easily grep for all the places that use the
underlying object rather than a const reference to it.

Of course any form of programming requires a modicum of self-discipline
which goes against the grain for those who think that fixing mistakes
are always someone else's problem. (I expect my coffee to be hot, so why
should someone else compensate me if I injure myself because it is?)

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Hello, all

I have a suggestion to make that I believe should be a
very useful addition to the C++ programming language.
Please do let me know if what I have to suggest makes
sense, and any suggestion would be definitely welcome.
The whole purpose of this addition to the language is
to prevent _accidental_ over-writing of a value, since
this facility allows one to over-write only explicitly
(explicit modification). I have faced the need for a
feature of this sort many times; thus this suggestion.

Sometimes, a constant should be modifiable, though
this may sound like a contradiction. A const is too
"stiff," while a variable is too unsafe.  A middle
path is, therefore, called for. I would like to
suggest two keywords: freeze and thaw, which should
fill in that need. Consider the following example to
see how these two keywords work.

main ()
{
 freeze int i =3D 10; // Declaring a "frozen" variable,
=93freeze int i at 10=94
 freeze j =3D 20;  // Implicitly an int
 freeze int k(30); // Constructor syntax also works

 // what won't work
 freeze int m; // ERROR -> Freeze m at what value?
Initialization is necessary!
 double arr[i]; // ERROR -> A freezable variable is
NOT a constant,
   // so cannot be used for array declarations

 i =3D 40;  // ERROR -> i is "frozen,=94 you cannot change
it!
 thaw i =3D 50; // Ok to "thaw" a frozen variable and
immediately change it
 i =3D 60;  // Oops! i is frozen again!
}

We could simulate this behaviour in a class using
methods to "thaw" the frozen value. This method,
however, turns out to be very cumbersome since
overloaded operators would have to be defined not just
for every conceivable operation, but also for all the
primitive types in the language. Secondly, any attempt
to modify a frozen value should immediately give a
syntax error. In the case of a class, however, only a
run-time exception would be possible, defeating the
concept of early error detection.

Another feature of a freezable is that it should be
thawable only within its own block or any underlying
block. Outside its own block, its reference can only
be read into a "more severe" type like a const. Take
the following example:

class Foo
{
 freezable int x;
public:
 Foo () : x(10)
 {}

 freezable int& GetRef () {
  return x;
 }

 void Changex (int);
};

int main ()
{
 Foo f;
 int& i =3D f.GetRef();  // Error! Cannot read into a
modifiable variable.
 freezable int& j =3D f.GetRef(); // Error! Not enough
"severity."
 const int& k =3D f.GetRef(); // Works fine since k is a
const
}

void Foo::Changex (int new_val)
{
 // ok to thaw and change a frozen here since
 // this block is within x's declaration block
 thaw x =3D new_val;
}

The reason that a freezable reference can only be read
into a const is that freezable data - for all=20
practical purposes - is a constant to outsiders, and
is meant to be thawed and modified only by its=20
owner.

I would appreciate any further suggestions / remarks
on this.

Thank you
Omar

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <20040119114736.63476.qmail@web20904.mail.yahoo.com>, Omar
Shaikh <omarshaikh71@yahoo.com> writes
>Hello, all
>
>I have a suggestion to make that I believe should be a
>very useful addition to the C++ programming language.
>Please do let me know if what I have to suggest makes
>sense, and any suggestion would be definitely welcome.

Adding keywords always needs a very  substantial value and is never
undertaken lightly. I do not think you have shown sufficient value to
make it worth breaking legacy  code.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]