If you pass them by reference you can't do a SendControl(1) because that is passed by copy.<br>So, i got confused with your mail.<br>Read:<br>
> > out.SendControl(1); won't work because the signature wants a<br> > > reference<br> > > to a non-constant var! And we need it to work, for backwards<br> > > compatibility among other reasons.<br>
<br>So, i think what pau meant is that the class is passed by copy.<br>If you pass it by reference you can't do a SendControl(1).<br>So please talk with each other and tell me what to do :(<br>Thanks!<br>Francisco <br>
<br><div class="gmail_quote">On Sat, May 10, 2008 at 9:25 AM, David García Garzón <<a href="mailto:dgarcia@iua.upf.edu">dgarcia@iua.upf.edu</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I fully agree with pau but Francisco's comment make me think that he<br>
missunderstood the point. Pau did not said passing parameters by value but<br>
storing copied values in the receiver. Values should be passed and returned<br>
to functions as const references. But the processing should store a copy. I<br>
guess you already do that but Pau suggested a test on it. That is, after<br>
sending a control, modify the sent object, the receiver should still have the<br>
old value because it was a copy.<br>
<div><div></div><div class="Wj3C7c"><br>
<br>
On Divendres 09 Maig 2008, Pau Arumí wrote:<br>
> On dv, 2008-05-09 at 16:36 -0300, Francisco Tufró wrote:<br>
> > Passing a class by copy may bring performance issues on realtime i<br>
> > think, that's why i did it by reference.<br>
> > If you want it to be by copy, i have no problem to do it by copy.<br>
><br>
> Yes because a reason, let me explain:<br>
> As you say, copies can be expensive. It depends on the object size. And<br>
> things could be MUCH worst if a user makes a TypedControl class of<br>
> hierarchic objects with deep-copy semantics requiring memory allocation.<br>
> But using such (deep or big) objects as controls is a bad use of<br>
> controls, and this should be documented (at least at the doxygen class<br>
> doc)<br>
><br>
> But the alternative of keeping a pointer to the original object is much<br>
> worst. Picture this we have a processing A sending controls to B.<br>
> A::Do((<br>
> MyType value = someVal();<br>
> outcontrol.SendControl(value);<br>
><br>
> This would cause a segfault when B reads the received control, because<br>
> it points to non-existing var (it is out of scope).<br>
><br>
> Restricting to send only attributes would solve this, but can not be<br>
> enforced. And it would also be a bad solution, it totally breaks<br>
> encapsulation (A and B shares the same variable).<br>
><br>
> Some alternatives i'm thinking on now:<br>
> 1. Passing a copy-on-write smart-pointer. I think would be over-design<br>
> at this stage. Maybe later.<br>
> 2. Do not save the received value by default. Just provide a callback<br>
> method and the class decides if the value needs to be copied, to be<br>
> read, or to be sent out to another linked control (cascading events)<br>
><br>
> Maybe it would be worth to do 2. But if in most cases the receiver just<br>
> needs to keep a copy (and wait for its Do) then it's over-design. I<br>
> would first implement the "copy" version.<br>
><br>
> I'm interested to hear more opinions on 2, (David, specially)<br>
><br>
> Pau<br>
><br>
> > For the next patch i'll change it and add the IsConnected test and<br>
> > pass it.<br>
> > that's all for now<br>
> ><br>
> ><br>
> > On 5/9/08, Pau Arumí <<a href="mailto:parumi@iua.upf.edu">parumi@iua.upf.edu</a>> wrote:<br>
> ><br>
> > On dj, 2008-05-08 at 14:43 -0300, Francisco Tufró wrote:<br>
> > > After some hours of work i have done 2 tests and passed<br>
> ><br>
> > them.<br>
> ><br>
> > > Just check them and tell me if they're ok (and if the patch<br>
> ><br>
> > is well<br>
> ><br>
> > > done ^^)<br>
> > ><br>
> > > :)<br>
> ><br>
> > Good start! I see the code checked in by Hernan.<br>
> > It's is good to go in small steps. Even this simple test<br>
> > brings out some<br>
> > issues:<br>
> ><br>
> ><br>
> > + {<br>
> > + CLAM::TypedInControl<int><br>
> > in("IntInControl");<br>
> > + CLAM::TypedOutControl<int><br>
> > out("IntOutControl");<br>
> > + out.AddLink(in);<br>
> > + int number=1;<br>
> > + out.SendControl(number);<br>
> > + CPPUNIT_ASSERT_EQUAL( 1 ,<br>
> > in.GetLastValue() );<br>
> > + }<br>
> > +<br>
> ><br>
> > out.SendControl(1); won't work because the signature wants a<br>
> > reference<br>
> > to a non-constant var! And we need it to work, for backwards<br>
> > compatibility among other reasons.<br>
> ><br>
> > So change the test passing a constant, and pass the test by<br>
> > changing<br>
> > SendControl and DoControl arguments to be const references.<br>
> > <br>
> > We want controls to be passed by copy (or maybe in the future:<br>
> > copy-on-write smart pointers), but keeping a reference to the<br>
> > original<br>
> > object is bad.<br>
> ><br>
> > I was considering a new "sent by copy" test (e.g. send a var,<br>
> > change the<br>
> > var, check that the received value has not changed) but i<br>
> > realize it is<br>
> > not necessary, once we have changed the previous test: if you<br>
> > save a a<br>
> > const argument it necessarily implies doing copy.<br>
> ><br>
> > > When you give me the ok, i'll continue with the<br>
> > > "TypedInControl::IsConnected(out)" test.<br>
> > > Bye!<br>
> ><br>
> > Yes<br>
> ><br>
> > Pau<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > Clam-devel mailing list<br>
> > <a href="mailto:Clam-devel@llistes.projectes.lafarga.org">Clam-devel@llistes.projectes.lafarga.org</a><br>
> ><br>
> > <a href="https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel" target="_blank">https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel</a><br>
> ><br>
> > _______________________________________________<br>
> > Clam-devel mailing list<br>
> > <a href="mailto:Clam-devel@llistes.projectes.lafarga.org">Clam-devel@llistes.projectes.lafarga.org</a><br>
> > <a href="https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel" target="_blank">https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel</a><br>
><br>
> _______________________________________________<br>
> Clam-devel mailing list<br>
> <a href="mailto:Clam-devel@llistes.projectes.lafarga.org">Clam-devel@llistes.projectes.lafarga.org</a><br>
> <a href="https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel" target="_blank">https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel</a><br>
<br>
<br>
<br>
</div></div><font color="#888888">--<br>
David García Garzón<br>
(Work) dgarcia at iua dot upf anotherdot es<br>
<a href="http://www.iua.upf.edu/%7Edgarcia" target="_blank">http://www.iua.upf.edu/~dgarcia</a><br>
</font><br>_______________________________________________<br>
Clam-devel mailing list<br>
<a href="mailto:Clam-devel@llistes.projectes.lafarga.org">Clam-devel@llistes.projectes.lafarga.org</a><br>
<a href="https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel" target="_blank">https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel</a><br>
<br></blockquote></div><br>