Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Self-overwriting class - is 'volatile' needed for field keepers?

Reply
Thread Tools

Self-overwriting class - is 'volatile' needed for field keepers?

 
 
Ole Nielsby
Guest
Posts: n/a
 
      10-10-2006
I have objects that sometimes overwrite themselves by something else,
using placement new.

I will spare you for the details, but the objects serve as stack frames
and are placed contiguosly, and the overwriting happens when a frame
gets popped and something else gets pushed. This is a much simplified
version:

class Frame {...}

class Frame1 : Frame {...}

class Frame2 : Frame {
private:
int /*volatile?*/ f;
public:
void m() {
int ff = f;
new ((void*)this) Frame1(...);
doSomething(ff);
}
}

This seems to work so far. What bugs me is: could a smart
optimizer decide that f can't be modified because it is private
and no Frame2 methods modify it, and then postpone the
fetching until after the placement new? Is the volatile
keyword sufficient/required to prevent this? If I don't want
to make all such fields volatile (since this may prevent some
valid optimizations), can I achieve the same effect by:

int ff = *((int *volatile)&f);

or whatever the syntax? Or:

int volatile ff = f;

Or should I expose dummy methods that modify the fields?

class Frame2 ...{... void dummy(){f = 0;} ....}


 
Reply With Quote
 
 
 
 
Gianni Mariani
Guest
Posts: n/a
 
      10-10-2006
Ole Nielsby wrote:
> I have objects that sometimes overwrite themselves by something else,
> using placement new.
>
> I will spare you for the details, but the objects serve as stack frames
> and are placed contiguosly, and the overwriting happens when a frame
> gets popped and something else gets pushed. This is a much simplified
> version:
>
> class Frame {...}
>
> class Frame1 : Frame {...}
>
> class Frame2 : Frame {
> private:
> int /*volatile?*/ f;


Volatile is only needed to tell the compiler not to cache the value.
i.e. when the program references the value, it should be read from that
location. However, this only happens in very special circumstances,
e.g. multi threaded programs, system interrupts, signals, devices etc.

> public:
> void m() {
> int ff = f;
> new ((void*)this) Frame1(...);
> doSomething(ff);
> }
> }
>
> This seems to work so far. What bugs me is: could a smart
> optimizer decide that f can't be modified because it is private
> and no Frame2 methods modify it, and then postpone the
> fetching until after the placement new?


A compiler would be wrong to assume that so you're probably safe without it.
....

It seems like you're doing somthing pretty crazy anyway so you're
probably doing somthing that is implementation dependant.


 
Reply With Quote
 
 
 
 
tomthemighty@googlemail.com
Guest
Posts: n/a
 
      10-10-2006
> This seems to work so far. What bugs me is: could a smart
> optimizer decide that f can't be modified because it is private


No, only a dumb one.

volatile indicates that the variable might change for reasons
undetectable to the compiler. It is implementation-defined what that
means, but it is intended to cover writes from outside the program at
run-time (eg memory-mapped hardware registers). It is not intended to
cover situations where the compiler's left hand doesn't know what its
right hand is doing.

If your placement new call causes f to change, then it will be
compiler-generated code that makes the change. As long as your code is
standard-compliant (a big if, considering what you are doing), then it
is up to the compiler to ensure that it generates object code that does
what it should.

I thought you had undefined behaviour because you aren't calling the
destructor of the object you are replacing, but 3.8 para 4 in the
standard indicates that is ok.

 
Reply With Quote
 
Ole Nielsby
Guest
Posts: n/a
 
      10-11-2006
Gianni Mariani <(E-Mail Removed)> wrote:
> Ole Nielsby wrote:
>> I have objects that sometimes overwrite themselves by something else,
>> using placement new.

>
> A compiler would be wrong to assume that [private fields won't change]
> so you're probably safe without it.


I take your word and feel probably safe.

> It seems like you're doing somthing pretty crazy anyway so you're probably
> doing somthing that is implementation dependant.


C++ wasn't meant for writing fast interpreters for functional languages
using vtable-based stack frames... so I have to bend it a bit and hope
it doesn't break. Anyway, I understand from the answers that 'volatile'
is not for this kind of situation.

Regards/Ole Nielsby



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
javascript validation for a not required field, field is onlyrequired if another field has a value jr Javascript 3 07-08-2010 10:33 AM
1.Enter space bar for field names and save the field.The field shoud not get saved and an alert should be there as"Space bars are not allowed" Sound Javascript 2 09-28-2006 02:43 PM
Class A contains class B, class B points to class A Joseph Turian C++ 5 12-30-2005 03:24 PM
Nested Class, Member Class, Inner Class, Local Class, Anonymous Class E11 Java 1 10-12-2005 03:34 PM
A parameterized class (i.e. template class / class template) is not a class? christopher diggins C++ 16 05-04-2005 12:26 AM



Advertisments