|
|
Home » U++ Library support » U++ Core » Value: no deep copy support?
|
|
|
|
Re: Value: no deep copy support? [message #29440 is a reply to message #29438] |
Wed, 20 October 2010 16:55 |
|
kohait00
Messages: 939 Registered: July 2009 Location: Germany
|
Experienced Contributor |
|
|
back to the topic:
offering a somehow optional way to be able to deepcopy the content of a Value would make it an appealing refcount based container for polymorphic stuff as well. Array<T> still needs some info about type.
Value doesnt.
i dont mean copy-on-write or something, which would be implicit, so the user does not get an idea of behaviour. he still can expect Value to be one (of many) references to the content.
but wanting to internally clone it without knowing type or anything about it would be great as well. enabling the user to 'edit' later 2 distinct copies in an abstract handler.
it could maybe rely on DeepCopyNew somehow. but this might need to introduce a Copy function in the Value::Void interface, returning Void*.
virtual Void* Copy() const { return new Void(); }
the RawValueRep<T> would add sth like:
virtual RawValueRep* Copy() const { return new RawValueRep(*this); }
//the value could then be MoveableAndDeepCopyOption
Value(const Value& v, int)
{
ptr = v.ptr->Copy();
//ptr->Retain(); //we are first owner
}
this would enable the approach described above
Value v = (int)123;
Value v2(v,0); //indicate to use the deep copy to duplicate the values
//v and v2 are now unrelated anymore..can be edited/overwritten individually
//using const_cast..clone has been produced without knowing content type.
Value v3;
vs <<= v; //same as with constructor, more intuitive, as from Containers :)
these are only very basic ideas, maybe it is of interest. i'll try to play with it a bit..maybe i can find sth usefull.
[Updated on: Wed, 20 October 2010 17:29] Report message to a moderator
|
|
|
Re: Value: no deep copy support? [message #29445 is a reply to message #29440] |
Wed, 20 October 2010 23:16 |
|
mirek
Messages: 14105 Registered: November 2005
|
Ultimate Member |
|
|
kohait00 wrote on Wed, 20 October 2010 10:55 | back to the topic:
offering a somehow optional way to be able to deepcopy the content of a Value would make it an appealing refcount based container for polymorphic stuff as well. Array<T> still needs some info about type.
Value doesnt.
i dont mean copy-on-write or something, which would be implicit, so the user does not get an idea of behaviour. he still can expect Value to be one (of many) references to the content.
but wanting to internally clone it without knowing type or anything about it would be great as well. enabling the user to 'edit' later 2 distinct copies in an abstract handler.
|
Nonsense. You can NEVER 'edit' Value.
Quote: |
it could maybe rely on DeepCopyNew somehow. but this might need to introduce a Copy function in the Value::Void interface, returning Void*.
virtual Void* Copy() const { return new Void(); }
the RawValueRep<T> would add sth like:
virtual RawValueRep* Copy() const { return new RawValueRep(*this); }
//the value could then be MoveableAndDeepCopyOption
Value(const Value& v, int)
{
ptr = v.ptr->Copy();
//ptr->Retain(); //we are first owner
}
this would enable the approach described above
Value v = (int)123;
Value v2(v,0); //indicate to use the deep copy to duplicate the values
//v and v2 are now unrelated anymore..can be edited/overwritten individually
//using const_cast..clone has been produced without knowing content type.
Value v3;
vs <<= v; //same as with constructor, more intuitive, as from Containers :)
these are only very basic ideas, maybe it is of interest. i'll try to play with it a bit..maybe i can find sth usefull.
|
Sorry, but this is just misunderstanding. There is zero value in deep copy for Value.
Please think about Value like it is an 'int' - with "assignment" time always O(1).
That implies Value is principally immutable - you can never change what is inside. Only assign another value.
[Updated on: Wed, 20 October 2010 23:18] Report message to a moderator
|
|
|
Re: Value: no deep copy support? [message #29446 is a reply to message #29445] |
Thu, 21 October 2010 08:47 |
|
kohait00
Messages: 939 Registered: July 2009 Location: Germany
|
Experienced Contributor |
|
|
thanks mirek, got to rethink the concept.
i'm a more or less a freshy in all that, programming idioms and tricks in c++. graduated not to a sowftware engeneer, but technical and hardware but happened to begin to work in software engeneering. where i need to teach my self a lot.
thanks upp speeds up all of that. thanks
EDIT: just a question aside:
why is then ValueArray there, which is sort of a container? and why the possibility to 'hide' own custom data inside Value, using RawValue or RichValue..
isnt Value meant to be a ref count based reference to some abstract data (not only the intrinsic ones), and to even be able to edit it as presented in one of the Value tutorials, using const_cast? i think the content is meant to be editable, under well known conditions..
[Updated on: Thu, 21 October 2010 09:37] Report message to a moderator
|
|
|
Re: Value: no deep copy support? [message #29453 is a reply to message #29446] |
Thu, 21 October 2010 19:06 |
|
mirek
Messages: 14105 Registered: November 2005
|
Ultimate Member |
|
|
kohait00 wrote on Thu, 21 October 2010 02:47 | thanks mirek, got to rethink the concept.
i'm a more or less a freshy in all that, programming idioms and tricks in c++. graduated not to a sowftware engeneer, but technical and hardware but happened to begin to work in software engeneering. where i need to teach my self a lot.
thanks upp speeds up all of that. thanks
EDIT: just a question aside:
why is then ValueArray there, which is sort of a container? and why the possibility to 'hide' own custom data inside Value, using RawValue or RichValue..
|
Why not?
Quote: |
isnt Value meant to be a ref count based reference to some
|
That is just implementation detail. In fact, I was thinking that certain types will be stored differently.
Quote: |
abstract data (not only the intrinsic ones), and to even be able to edit it as presented in one of the Value tutorials, using const_cast?
|
Ops, where?
Surely, you can use const_cast brute force there, but that is very very bad idea. If this is in any example, it should be removed quickly.
|
|
|
Re: Value: no deep copy support? [message #29454 is a reply to message #29453] |
Thu, 21 October 2010 20:17 |
|
kohait00
Messages: 939 Registered: July 2009 Location: Germany
|
Experienced Contributor |
|
|
it was sort of retorical question anyway. RawValue / RichValue / ValueArray in any case do represent data 'container' and not only the information it has. and as a container one wants to have access modify access to the container.. (int 123 is information, int& 123 references a *container* which happens to have 123 as information).
it's difficult to explain actually.
actually, i dont see much of the point to have Value reference anything else than the intrinsic datatypes, if they are immutable. maybe i need some time to wrap my mind around Value fully
maybe i need to think of it as a reference to a bit of very volatile readonly data..that is created somewhere in the dust, and if it ceases to be of importance it becomes dust again..
you actually never need to reference the same data packet inside to rely on its information. if its content (or better the information it represents) is about to be altered, this info is created. so Value is not about the place to store sth. but about to represent some information, speeded up by ref count. sorry, trying to understand by describing for the purpose of referencing a container maybe one should use Ptr<T>..
you asked about the const thing:
http://www.ultimatepp.org/srcdoc$Core$UserValue$en-us.html
Quote: |
Note that the function ValueTo returns a constant reference. This is consistent with default Value behaviour, according to which data once put into Value should never change afterwards. This is necessary because, upon copying, multiple variables of type Value can hold the same data "packet" and changing its contents would affect all these copies, which is normally undesirable. If you break the const-ness using a mutable member or by a const_cast, you should not forget that.
|
this actually adds to understand Value as a container for sth. ("packet", "contents").
BTW: maybe you could help me with the ValueArray understanding in another thread here in Core++
|
|
|
Re: Value: no deep copy support? [message #29461 is a reply to message #29454] |
Thu, 21 October 2010 23:23 |
|
mirek
Messages: 14105 Registered: November 2005
|
Ultimate Member |
|
|
kohait00 wrote on Thu, 21 October 2010 14:17 | it was sort of retorical question anyway. RawValue / RichValue / ValueArray in any case do represent data 'container' and not only the information it has. and as a container one wants to have access modify access to the container.. (int 123 is information, int& 123 references a *container* which happens to have 123 as information).
it's difficult to explain actually.
actually, i dont see much of the point to have Value reference anything else than the intrinsic datatypes, if they are immutable. maybe i need some time to wrap my mind around Value fully
maybe i need to think of it as a reference to a bit of very volatile readonly data..that is created somewhere in the dust, and if it ceases to be of importance it becomes dust again..
you actually never need to reference the same data packet inside to rely on its information. if its content (or better the information it represents) is about to be altered, this info is created. so Value is not about the place to store sth. but about to represent some information, speeded up by ref count. sorry, trying to understand by describing for the purpose of referencing a container maybe one should use Ptr<T>..
you asked about the const thing:
http://www.ultimatepp.org/srcdoc$Core$UserValue$en-us.html
Quote: |
Note that the function ValueTo returns a constant reference. This is consistent with default Value behaviour, according to which data once put into Value should never change afterwards. This is necessary because, upon copying, multiple variables of type Value can hold the same data "packet" and changing its contents would affect all these copies, which is normally undesirable. If you break the const-ness using a mutable member or by a const_cast, you should not forget that.
|
this actually adds to understand Value as a container for sth. ("packet", "contents").
|
Sorry, but what I read in that paragraph is "do not do this. If you insist to do, be prepared to shot your leg off". And it is more about mutable members used to caching information than anything else.
Quote: |
BTW: maybe you could help me with the ValueArray understanding in another thread here in Core++
|
I guess you are using bad approach here. Why do not you just check for what Value, ValueArray and ValueMap are actually used?
Here are some good examples:
http://www.ultimatepp.org/reference$ArrayCtrl$en-us.html
http://www.ultimatepp.org/reference$Display$en-us.html
http://www.ultimatepp.org/reference$SQL_Sqlite3$en-us.html
http://www.ultimatepp.org/reference$Switch$en-us.html
http://www.ultimatepp.org/reference$Chameleon$en-us.html
|
|
|
|
Goto Forum:
Current Time: Fri Nov 01 01:59:22 CET 2024
Total time taken to generate the page: 0.02015 seconds
|
|
|