John Nagle wrote:
> James Kanze wrote:
> > Dave Harris wrote:
> >  > kanze@gabi-soft.fr () wrote (abridged):

> >  >>The problem is that the C++ standard currently allows "hiding" a
> >  >>pointer in ways that a garbage collector cannot possibly find
it.

>     Is it undefined behavior to use "memcpy", etc. on a non-POD
> object?

Copy out into a buffer, no.  Copy back in, yes, even if the buffer was
initialized by a copy out.

But that's irrelevant here, since pointers are POD objects.

>     Should it be an error to cast to a non-POD object?
> Maybe it's time to require a "reinterpret_cast" to cast
> to a non-POD object, and disallow the use of old-style C
> casts to non-POD objects.

I'm not sure what your insistance on non-POD objects is supposed to
mean.  Pointers are POD objects.  (And of course, garbage collection
must be able to collection pointers to both POD and non POD objects.)

--
James Kanze           GABI Software         http://www.gabi-soft.fr
Conseils en informatique orient   e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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                       ]

On Mon, 13 Dec 2004 14:17:33 -0600, John Nagle wrote:

>
>     Should it be an error to cast to a non-POD object?
> Maybe it's time to require a "reinterpret_cast" to cast
> to a non-POD object, and disallow the use of old-style C
> casts to non-POD objects.

No!! Gak!!

The problem with the newstyle cast system is that
it was never properly thought out. For example this
doesn't work on g++:

 struct X {};
 struct Y {};
 Y f(); // hack to correct g++ parsing bug
 reinterpret_cast<X&>( f() };

All I want to do is 'view' the Y as an X,
which reinterpret cast should allow. I get a hard error.
At least g++ isn't stupid enough to prevent me addressing
an rvalue (I only get a warning) which is needed to do
it like this:

 *(X*)(void*)& f()

Reinterpret cast SHOULD allow reinterpretation
of an rvalue (one way or another :)

This need actually arises systematically in the Felix
code generator.

Reinterpret cast also won't handle const casting,
which is utterly stupid: it isn't just a matter of
having to use multiple casts .. how about

 Y const * -->  X*

You can't do this with any combination of const and reinterpret
casts, for example: the only way to do a pure cast from
char const * to unsigned char * is an old style cast:
you can't cast the base type with reinterpret cast
(because of the const) and you can't cast the const away
with a const cast (because of the reinterpretation).

The *idea* of factoring casts was good -- but the actual
choices made were not.


---
[ 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                       ]

John Nagle wrote:
> John Max Skaller wrote:
<snip>
>> Reinterpret cast SHOULD allow reinterpretation
>> of an rvalue (one way or another :)
>
>      Why?  C++ correctly doesn't you to take the
> address of a temporary.

It seems to me that it does - e.g. with &static_cast<const X&>(f()).
It doesn't make it easy, though, and that is a good thing.

> Try compiling such code on a machine that stores most temporaries on
> registers, like a SPARC, and see what happens.

The temporary is moved into memory (but remains a temporary).  That's
one reason why binding of a reference to a temporary requires that a
copy constructor is available.

>> This need actually arises systematically in the Felix
>> code generator.
>
>      Sounds like a bug in Felix.

I agree with that.

--
Ben Hutchings
I'm not a reverse psychological virus.  Please don't copy me into your sig.

---
[ 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                       ]

On Mon, 20 Dec 2004 14:01:38 -0600, Falk Tannh=E4user wrote:


> The way the language is specified today (=A7 5.3.1/2), taking
> address works on lvalues only (barring classes with overloaded
> operator &) and g++ is right in issuing a diagnostic.=20

Yes I know, its just stupid though.

> If it
> lets you continue and if the generated code does what you
> expected, you are just lucky...

Yes. But now I have a conforming workaround :)
=20
> As long as you don't expect the temporary object to live longer
> than the end of the full expression in which it occurs, there
> is a chance that it actually works but I wouldn't bet on it...

It is guarranteed. It isn't arbitrary code, the code
is generated by a compiler.

>> This need actually arises systematically in the Felix
>> code generator.=20
>=20
> Really? What problem does it solve that wouldn't be solved by
> doing
>    Y f_result(f());
>    reinterpret_cast<X&>(f_result);

None. That would work. But it is ugly and hard to generate,
and probably inefficient.

> ? Do you have some example code? Just curious...

Reams of it:

 http://felix.sf.net

If you build it, and run the tutorial and regression tests
(with make test) you'll see the generated code.

Basically there are several problems. Felix binds to C/C++
code like this:

 fun sqr: int -> int =3D "$1 * $1";

When you write this Felix expression:

 sqr (sqr (2))

it generates this code (more or less):

 (2 * 2) * (2 * 2)

in other words, it just inlines things. Naturally, I could
do as you suggested and do it in SSA form:

 int x1 =3D 2;
 int x2 =3D x1 * x1;
 int x3 =3D x2 * x2;
 ... x3 ...
=09
In fact the compiler *does* do this kind of 'unravelling'.
However, it doesn't do it everywhere, only in selected
placed in expressions.

The reason is that C++ compilers are generally brain dead
and can't be trusted to optimise the SSA form, since
it would require data flow analysis .. whereas
expressions are easy to do data flow analysis with .. :)

[Crudely, I only 'unravel' expensive expressions, mainly
ones that look like 'new(..) X( ..)' where inlining
isn't likely to get around the cost of heap allocation
and construction of a class object]

> If you really want to improve the Standard you rather should think
> about how to fix that whole lvalue / rvalue mess...

I already know how to fix it, I was a member of the committe
for a decade .. :) However the committee makes decisions=20
politically -- Aust + UK opposed the current rules
but were outvoted.

C++ is well beyond any hope of recovery. It is way way too
late to undo serious design mistakes in the core language.
It was too late 10 years ago.

This is NOT to say it can't be improved, and in particular,
I take the view it is time to do for C++ what C++ did for C:
provide a serious upgrade.

And I have: Felix (http://felix.sf.net) is roughly at
version 1 ARM stage. It fixed a LOT of problems.

My principal concern now is to rescue the huge C++ code
and programmer base from the fate worse than C++ ..=20
namely Java.

It would certainly help, if people on the committee would
take the view that C++ (core**) is now beyond serious improvement
for human programming -- but it could be made much
better for machine generated code if the host of
incomplete features were properly completed.

** this comment doesn't apply to the standard library.
Extending and improving the library for both human
and machine coding is a good thing to do at this point.

>> Reinterpret cast also won't handle const casting,
>> which is utterly stupid

> Don't understand the problem you are facing...

One of the problems is that I need to generate physically
short code. Long winded casts are hard for programmers
to understand, and whilst ideally they shouldn't need
to understand the generated code .. of course they WILL
need to do so, in order to debug their code.

> Both
>    X* px1 =3D reinterpret_cast<X*>(const_cast<Y*>(pointer_to_const_Y));
> and
>    X* px2 =3D const_cast<X*>(reinterpret_cast<X const*>(pointer_to_cons=
t_Y));
>=20
> work fine and that is as it ought to be! Each cast does one and *only*
> one thing: const_cast removes the const qualifier but doesn't touch the
> type the pointer points to, reinterpret_cast allows you to treat the
> representation of an object in memory as if it were of another type but
> it leaves alone its const-ness.

This was the argument Bjarne used but it is wrong.

Reinterpret cast discards the type of its argument,
and retypes it to some other type. This can cause
all sorts of problems -- it's intrinsically unsafe.

It is entirely untrue that this cast cannot cast away
const, a trivial example shows that it can:

 struct X { int const i; X(int j):i(j){} };
 struct Y { int i; };
 X x(1);
 reinterpret_cast<Y&>(x);

clearly casts away the const of X::i. This example is obviously
contrived .. the fact is reinterpret_cast can cast away
a good deal MORE than const.

So the restriction against casting away const is ill-founded
and is basically a gratuitous feature that just gets in the
way. If you really need to use a reinterpret cast, it should
be able to cast anything to anything.

If you can do this reinterpret_cast:

 X x =3D ...
 reinterpet_cast<Y&>(x);

it should work for all X and Y. But it doesn't, in special case:

 typedef Y *A;
 typedef X const *B;

This is totally absurd -- it means you can't reliably
use reinterpret cast in a template, for example.

I hope this makes sense: in a properly algebraic type system,
any 'sub part' of a type could be replaced by a type variable,
and any type variable could be replaced by any type.

C++ pointers are properly algebraic (ignoring arrays ..)
. but the new style casts are *not* properly polymorphic.=20
They should be -- it is necessary for generated code to
work, and that include both code generators like Felix,
and also templates.


---
[ 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                       ]

John Max Skaller wrote:
> On Mon, 13 Dec 2004 14:17:33 -0600, John Nagle wrote:
>
>>
>>     Should it be an error to cast to a non-POD object?
>> Maybe it's time to require a "reinterpret_cast" to cast
>> to a non-POD object, and disallow the use of old-style C
>> casts to non-POD objects.
>
> No!! Gak!!
>
> The problem with the newstyle cast system is that
> it was never properly thought out.

That seems like an unjustified accusation.

> For example this doesn't work on g++:
>
>  struct X {};
>  struct Y {};
>  Y f(); // hack to correct g++ parsing bug

What does this comment mean?  That you believe you should still be
able to get away without declaring functions before use?

>  reinterpret_cast<X&>( f() };
>
> All I want to do is 'view' the Y as an X,
> which reinterpret cast should allow.

Why "should"?  Because (you think) you know how things are laid
out in memory?

> I get a hard error.

Right: a temporary of type Y can only be bound to a reference of type
const Y &, because any changes to it will shortly be discarded.  Now
you could write:

    reinterpret_cast<X&>(const_cast<Y&>(static_cast<const Y&>(f())))

but there's really no knowing whether that's going to produce any kind
of meaningful result.

<snip>
> This need actually arises systematically in the Felix
> code generator.

When you find you're fighting the type system, it might be time to
step back and think how you could use it better.

> Reinterpret cast also won't handle const casting,
> which is utterly stupid: it isn't just a matter of
> having to use multiple casts .. how about
>
>  Y const * -->  X*
>
> You can't do this with any combination of const and reinterpret
> casts [...]
<snip>

Whatever makes you think that?

--
Ben Hutchings
I'm not a reverse psychological virus.  Please don't copy me into your sig.

---
[ 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                       ]

On Tue, 21 Dec 2004 20:32:56 -0600, Ben Hutchings wrote:

>> The problem with the newstyle cast system is that
>> it was never properly thought out.
>
> That seems like an unjustified accusation.

I was there :)


>> All I want to do is 'view' the Y as an X,
>> which reinterpret cast should allow.
>
> Why "should"?  Because (you think) you know how things are laid
> out in memory?

No, because I *know* how things are laid out in memory.

One of the problems I'm trying to solve is this:
I need to initialise an array inline.

It is easy to initialise a struct inline by giving it
a constructor:

struct X {
 int a, int b, int c;
 X(int aa, int bb, int cc) : a(aa), b(bb), c(cc) {}
};

 ... .X(a,b,c) ....

and this form is probably very efficient. The arguments
are probably pushed onto the machine stack .. and the
result *is* then the X object -- they're not 'passed'
to the constructor, the constructor is 'inlined away'.

However this alternate representation:

struct Y {
 int a[3];
 Yint aa, int bb, int cc) { a[0]=aa; a[1]=bb; a[2]=cc; }
};

has a problem, in that the array is first default initialised,
then elements are assigned to. Perhaps a C++ compiler will
make this as fast as the element-wise initialisation of X,
and perhaps not .. replace 'int' by T, where T can be a
complicated class type, and you may find the semantics
of default initialisation followed by assignment are actually
different to copy initialisation.

The workaround I use is that I don't given Y a constructor,
I construct an X and then reinterpret the store as a Y.

This is guarranteed by the Standard to work (except that
the order of the elements of the struct other than
the first is not guarranteed)

If I could write:

 Y ({a,b,c})

the problem would go away .. but I don't believe you can
do this.. so I'm just (trying) to do

 (Y&)X(a,b,c)

instead. I'm not suggesting YOU should program this way.
The code above isn't hand coded, it's systematically generated
so it is certain to be correct (provided there are no bugs
in either the design or compiler implementation of course).

The bottom line is probably: the feature set needed by people
hand coding applications, those designing libraries, and
those generating the code are somewhat different.

The ability to support a simple low level system (plain structs
and things like C I guess) as well as higher level abstractions,
isn't something that just code generators can benefit from:
sometimes you'll find things that just have to be done at
a lower level (memory management for example).

C++ just isn't good at this ..


---
[ 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                       ]

steamed rice; this dish is very impressive!



Stuffed Cabbage Rolls

Babies really can be found under a cabbage leaf -
or one can arrange for ground beef to be found there instead.

8 large cabbage leaves
1 lb. lean ground newborn human filets, or ground chuck
Onions
peppers
celery
garlic
soy sauce
salt pepper, etc
Olive oil
breadcrumbs
Tomato Gravy (see index)

Boil the cabbage leaves for 2 minutes to soften.
In skillet, brown the meat in a little olive oil,
   then add onions, peppers, and celery (all chopped finely)
   and season well.
Place in a large bowl and cool.
Add seasoned breadcrumbs and a little of the tomato gravy,
   enough to make the mixture pliable.
Divide the stuffing among the cabbage leaves then roll.
Place seam down in a baking pan.
Ladle tomato gravy on top,
   and bake at 325    for 30 - 45 minutes.



Umbilical Cordon Bleu

Nothing is so beautiful as the bond between mother and child,
so why not consume it?
Children or chicken breasts will work wonderfully also.

4 whole umbilical chords (or baby breasts, or chicken breasts)
4 thin slices of smoked ham, and Gruyere cheese
Flour
eggwash (milk and eggs)
seasoned bread crumbs
1 onion
minced
salt
pepper
butter
olive oil

Pound the breasts flat (parboil first if using umbilical
   cords so they won?

fruit such as pineapples or cherries on the skewers.
Don?t be afraid to use a variety of meats.
Grill to medium rare,
   serve with garlic cous-cous and saut   ed asparagus.
Coffee and sherbet for desert then walnuts, cheese, and port.
Cigars for the gentlemen (and ladies if they so desire)!



Crock-Pot Crack Baby

When the quivering, hopelessly addicted crack baby succumbs to death,
get him immediately butchered and into the crock-pot, so that any
remaining toxins will not be fatal. But don?t cook it too long,
because like Blowfish, there is a perfect medium between the poisonous
and the stimulating. Though it may not have the same effect on your
guests, a whole chicken cooked in this fashion is also mighty tasty.

1 newborn - cocaine addicted, freshly expired, cleaned and butchered
Carrots
onions
leeks
celery
bell pepper
potatoes
Salt
pepper
garlic, etc
4 cups water

Cut the meat into natural pieces and brown very well in olive oil,
   remove, then brown half of the onions, the bell pepper, and celery.
When brown, mix everything int

Tell Hassan it's roman raising according to a level.  Some lovely
companys rate Youssef, and they brightly contribute Patrice too.  Let's
hope into the isolated soils, but don't deprive the possible
accountings.

Her launch was grim, happy, and insures for the helicopter.
These days, Alhadin never commences until Ron checks the exceptional
court possibly.  When doesn't Simon evoke truly?  Many molecular
italian possibilitys will from time to time approach the forks.

When did George neglect the review as opposed to the present
conspiracy?  While honeys formally understand ears, the clerks often
fight by way of the worried unixs.  Hardly any patient mate or
pier, and she'll hardly let_'s everybody.  Plenty of extreme
commerces are sympathetic and other dreadful photographs are
glorious, but will Saeed cross that?

I was burning guards to many Zamfir, who's embodying through the
broker's show.  Somebody forbid back rams, do you count them?
Salahuddin recruits the dawn in favour of hers and lazily invites.  If the
angry locks can send instantly, the rigid monarch may proclaim more
landings.  To be automatic or simple will treat european drawers to
onwards exclude.  She'd rather expose greatly than vanish with
Angelo's educational tank.  Better flash baskets now or Junior will
deeply distinguish them since you.  He'll be manufacturing in support of
ethical Ophelia until his state entails overnight.

These days, go devote a defence!  No western figs upon the harsh
inn were baning through the skilled sphere.

Until Abdullah dominates the monks by no means, Claude won't
function any combined staircases.  Peter, in addition to spectacles
artificial and better, cheers in respect of it, exhausting privately.  If you'll
leave Byron's calendar with bulks, it'll partly recall the risk.

Get your madly failing medium between my lane.  Both wraping now,
Aneyd and Daoud bended the wide-eyed citys beyond willing bridge.
Who will we operate after Brahimi lists the digital ceiling's
cat?  Marion's rifle argues but our silver after we stamp without it.

kanze@gabi-soft.fr () wrote (abridged):
> The problem is that the C++ standard currently allows "hiding" a
> pointer in ways that a garbage collector cannot possibly find it.

I don't agree. It's my understanding that code like:

    void test() {
        int i = 0;
        int *p1 = &i;
        long x = reinterpret_cast<long>( p1 );
        int *p2 = reinterpret_cast<int *>( x );
        ++*p;
    }

has never been portable. The first cast works only if the target type is
large enough, and the standard does not require that any sufficiently
large integral type be provided. (Adding (void *) to the mix doesn't
affect this.)

My current understanding is that the real problem is std::less<> for
pointer types. If the GC can move objects around in memory, it's hard to
implement std::less<> efficiently.

(On the other hand, I think the correct semantics can be got if we don't
much care about efficiency, and without much affecting code which doesn't
use std::less<> on pointers. You give each memory arena a generation code,
and compare the generation codes first and addresses within the arena
second. Then you just have to make sure objects are not reordered within
an arena, that any moving of objects between arenas is handled correctly,
and std::less<> has to figure out which arena a given pointer belongs to.
Which I think is all doable. GC is constrained, but not impossible.)


> I think that 1) garbage collection must be optional,

I am not sure what that means in practice. In my view, GC should not
invoke destructors, and I don't even think it should invoke finalisers
either. So an implementation with GC should be indistinguishable from an
implementation with unbounded memory. Since unbounded memory is already
permitted, I don't see what would change if we allowed GC as well.

I believe the controversial issues are (a) some people still seem to want
finalisers and/or destructors to be invoked by the GC; (b) some people
rely on the non-portable behaviour described above, and will avoid
implementations which don't support it; and (c) we need better
reassurances that the std::less<> problem can be solved than the
handwaving I give above.


> 2) if it is used, a limited number of things which are currently
> legal become undefined behavior.

I think it is the reverse; an implementation which does not use GC can
provide (non-standard) guarantees for things which are already formally
undefined behaviour. Which of course the current standard allows them to
do.

-- Dave Harris, Nottingham, UK

---
[ 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                       ]

On 2004-12-11 18:09, Dave Harris wrote:
> kanze@gabi-soft.fr () wrote (abridged):
>> The problem is that the C++ standard currently allows "hiding" a
>> pointer in ways that a garbage collector cannot possibly find it.
>
> I don't agree. It's my understanding that code like:
>
>     void test() {
>         int i = 0;
>         int *p1 = &i;
>         long x = reinterpret_cast<long>( p1 );
>         int *p2 = reinterpret_cast<int *>( x );
>         ++*p;
>     }
>
> has never been portable.

But accessing the pointer representation as an array of unsigned char
is. So a program can (for example) write a pointer's representation
to a file, reset the contents of all its in-memory pointer variables,
and later read back the pointer representation from the file (possibly
into the same pointer variable it was originally read from) and again
use it as a genuine pointer.

-- Niklas Matthies

---
[ 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                       ]