Gene Bushuyev wrote:
>
> void register(const Object&);
> it's an error to store pointers to the temporary objects, but in this
> situation there is no way of distinguishing them.
> I realize that the design could be better, but it's beyond the point.

You've lost me.  It's no more an error to store a pointer to temporary
objects than it is for any object whose lifetime has expired.  The
code sounds fundementally flawed.

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

You are right it would be an error to store pointers to the expired
objects. But I never insisted otherwise.
Original design taking "const Object&" assumed(?) that all objects
including const objects are alive. I don't want to defend that design
but it's too late to make changes in the interface; it's a gruesome
reality. I'm thinking now how to prevent others from trying to pass
temporaries.
-------------------------------------
Gene Bushuyev

In article <3A256BE8.48EF9D47@sensor.com>,
  Ron Natalie <ron@sensor.com> wrote:
>
>
> Gene Bushuyev wrote:
> >
> > void register(const Object&);
> > it's an error to store pointers to the temporary objects, but in
this
> > situation there is no way of distinguishing them.
> > I realize that the design could be better, but it's beyond the
point.
>
> You've lost me.  It's no more an error to store a pointer to temporary
> objects than it is for any object whose lifetime has expired.  The
> code sounds fundementally flawed.


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Gene Bushuyev wrote:
>
> In article <3A23FFB5.CB6879F1@sensor.com>,
>   Ron Natalie <ron@sensor.com> wrote:
> >
> >
> > Gene Bushuyev wrote:
> > >
> > > Current standard doesn't seem to offer the means of distinguishing
> > > const and temporary objects because it allows binding "const T&" to
> > > temporaries.
> > > Since it's important sometimes to distinguish these two cases...
> >
> > I'm not sure why you feel it is necessary to make such a distinction.
> > Can you give an example?
> >
>
> I have inherited some code that tracks objects and keeps pointers in
> its internal list and under certain conditions calls member functions
> of those objects. So the registration function looks something like
> this:
> void register(const Object&);
> it's an error to store pointers to the temporary objects, but in this
> situation there is no way of distinguishing them.
> I realize that the design could be better, but it's beyond the point.

So where's the problem?
The objects need to unregister in the destructor. You need to have this
anyway since the lifetime of non temporary objects may also end.
For this, it might be necessary to change the registration to
object.registerWith(something). Or to implement a callback
object.registeredWith in the register function (which would probably be
easier to do with existing code).

Regards,
Heinz

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Gene Bushuyev wrote:
>
> You are right it would be an error to store pointers to the expired
> objects. But I never insisted otherwise.
> Original design taking "const Object&" assumed(?) that all objects
> including const objects are alive.

But I don't understand, temporary or not, there is no guarantee.
Temporary or otherwise, if you take an address of something (reference
or otherwise), it can be gone.  What happens when someone calls this
interface with an automatic variable.  You haven't given an example
of how this change solves any problem.  The temporary is perfectly
alive at the time it is bound to the reference.

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Current standard doesn't seem to offer the means of distinguishing
const and temporary objects because it allows binding "const T&" to
temporaries.
Since it's important sometimes to distinguish these two cases it would
be nice to have such facility in the language. And I believe it could
be done by slightly modifying the description of "volatile", allowing
temporaries to be bound to "const volatile T&" but not to "const T&".
I wonder if this thought occured to other people and what could be the
other things I'm missing here.
-------------------------------------
Gene Bushuyev


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Gene Bushuyev wrote:
>
> Current standard doesn't seem to offer the means of distinguishing
> const and temporary objects because it allows binding "const T&" to
> temporaries.
> Since it's important sometimes to distinguish these two cases...

I'm not sure why you feel it is necessary to make such a distinction.
Can you give an example?

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

> Current standard doesn't seem to offer the means of distinguishing
> const and temporary objects because it allows binding "const T&" to
> temporaries.
> Since it's important sometimes to distinguish these two cases it would
> be nice to have such facility in the language. And I believe it could
> be done by slightly modifying the description of "volatile", allowing
> temporaries to be bound to "const volatile T&" but not to "const T&".
> I wonder if this thought occured to other people and what could be the
> other things I'm missing here.

This has occured to me aswell, but I was thinking about using the auto
keyword instead. Then, for instance, "const auto T&" could be used for local
and temporary objects. The problem is that it would break a lot of existing
code, but I guess it could be solved with a compiler switch.

Bo-Staffan


---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A23FFB5.CB6879F1@sensor.com>,
  Ron Natalie <ron@sensor.com> wrote:
>
>
> Gene Bushuyev wrote:
> >
> > Current standard doesn't seem to offer the means of distinguishing
> > const and temporary objects because it allows binding "const T&" to
> > temporaries.
> > Since it's important sometimes to distinguish these two cases...
>
> I'm not sure why you feel it is necessary to make such a distinction.
> Can you give an example?
>

I have inherited some code that tracks objects and keeps pointers in
its internal list and under certain conditions calls member functions
of those objects. So the registration function looks something like
this:
void register(const Object&);
it's an error to store pointers to the temporary objects, but in this
situation there is no way of distinguishing them.
I realize that the design could be better, but it's beyond the point.

-------------------------------------
Gene Bushuyev


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Gene Bushuyev wrote:
>
> Ok, I tried to avoid going into details and discuss a general problem. I
> can't reproduce the real program but guess I can contrive a case for
> demonstration purposes.
> class A
> {
>   Object obj;
>   Object& obj_ref;
>   const Object& obj_cref;
>   Object operator +(const Object&);
>   bool some_bool;
>   bool another_bool;
>  ...
>   void f() {
>
>   Register(obj);          // OK
>   Register(obj_ref);   // OK
>   Register(obj_cref); // OK
>   Register(obj+obj); // must fail
>   Register(some_bool); // OK
>   Register(some_bool && another_bool); // must fail
>   }
> };
> In reality it's more convoluted than that and there are dozen of classes and
> templates, but basically the same problem - I need to disallow temporaries
> to be passed to Register() function.

Why? Presumably, there's some function (let's call it use_registry())
which dereferences the registered objects, and will therefore cause
problems if called after Register(obj+obj). However, even if the "must
fail" lines are removed from f(), you can still have the same exact
problem:

void func()
{
  {
    A a;
    a.f();
  }
  use_registry(); // attempts to use no-longer existent registered
objects.
}

You should probably do something to automatically tie your registry to
the lifetime of the objects registered (such as de-registering in the
dtor, which may require making the registered objects be auto_ptr<>-like
wrappers for the objects you're really keeping track of). The only
alternative is to make sure of it by hand - which includes looking for
and removing things like Register(obj+obj), but also involves removing
Register() of automatic objects that might go out of scope, or of
dynamically allocated objects that might be deallocated.

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

> But I don't understand, temporary or not, there is no guarantee.
> Temporary or otherwise, if you take an address of something (reference
> or otherwise), it can be gone.  What happens when someone calls this
> interface with an automatic variable.  You haven't given an example
> of how this change solves any problem.  The temporary is perfectly
> alive at the time it is bound to the reference.

If the concept of cv-qualifiers was extended with an auto-qualifier, it
would be possible to keep track which objects are created on the heap vs.
the stack. An object with automatic storage should only be able to bind to a
pointer/reference with an auto-qualifier. An object with dynamic/global
storage should be able to bind to a pointer/reference with or without an
auto-qualifier, similar to the const/volatile concept. It would be illegal
to create an object with dynamic/global storage if it contains a
pointer/reference with an auto-qualifier. Then it would be possible to
remove the restriction to only be able to bind temporary objects to const
references, which imho is a hack. It would also eliminate the possibility of
binding an object, with automatic storage, to a pointer/reference that has a
lifespan longer than the object.

Bo-Staffan


---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Ok, I tried to avoid going into details and discuss a general problem. I
can't reproduce the real program but guess I can contrive a case for
demonstration purposes.
class A
{
  Object obj;
  Object& obj_ref;
  const Object& obj_cref;
  Object operator +(const Object&);
  bool some_bool;
  bool another_bool;
 ...
  void f() {

  Register(obj);          // OK
  Register(obj_ref);   // OK
  Register(obj_cref); // OK
  Register(obj+obj); // must fail
  Register(some_bool); // OK
  Register(some_bool && another_bool); // must fail
  }
};
In reality it's more convoluted than that and there are dozen of classes and
templates, but basically the same problem - I need to disallow temporaries
to be passed to Register() function.
--
-------------------------
Gene Bushuyev


"Ron Natalie" <ron@sensor.com> wrote in message
news:3A26AFE8.55561F5E@sensor.com...
>
>
> Gene Bushuyev wrote:
> >
> > You are right it would be an error to store pointers to the expired
> > objects. But I never insisted otherwise.
> > Original design taking "const Object&" assumed(?) that all objects
> > including const objects are alive.
>
> But I don't understand, temporary or not, there is no guarantee.
> Temporary or otherwise, if you take an address of something (reference
> or otherwise), it can be gone.  What happens when someone calls this
> interface with an automatic variable.  You haven't given an example
> of how this change solves any problem.  The temporary is perfectly
> alive at the time it is bound to the reference.
>
> ---
> [ 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                ]
> [ Note that the FAQ URL has changed!  Please update your bookmarks.     ]
>


---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]