On Mon, Nov 22, 2004 at 09:34:32PM +0100, Lars Gullik Bjønnes wrote: > >> this->~SomeClass(); > >> new (this) SomeClass(foo); > >> > >> Does this work as intended? Or am I just way off? > > > | Maybe. > > I just had a look in my books and Mr. Sutter calls this the > "anti-idom" and says to never use it :-)
Oh happy day... > Just to explain what I am trying to do: I am trying to setup the whole > inset hierarchy so that we avoid wrong usage, slicing in particular. > (I wrote splicing earlier, but really meant slicing.) > > What I am going to do first is to make InsetBase::clone use the NVI > pattern, and make the copy constructor protected. > > (And assert on some typeid checking takes care of the rest.) Well, from what I can see, using insets in LyX it fairly straight- forward and not error prone. There might be areas where the compiler could be employed to be even safer, but I seriously doubt it is worthwhile to spend even a thought on that issue - not to mention real time in front of a computer - as long as there are real problems in the current code. And there are quite a few of them, numbered #3 through #1700 or so on bugzilla.lyx.org. To be even more blunt: This kind of work does not help us to get 1.4.0 out of the door. The small good it does is outweighed by distracting people as seen e.g. in the XML discussion. > But I also think that code like > > "*this = SomeClass(foo)" > > of > > "this->operator=(SomeClass(foo))" > > is bad. Yes, it is, I don't like it myself. But current HEAD does not crash in this particular line. > >> (the best would of course be if neither of these constructs were used, > >> and that we had more simple code in the first place) > > > | Sure. A 'setCursorButNotAnchor' method might do the same. > > Right. The actuall code in question is not from Cursor or from the > DocIterator but from f.ex. the read function in math_hullinset. One could assign all members there manually and start swearing the next time somebody adds a member without adjusting read(). This assignment is actually more robust than any alternative coming to my mind right now. The cause of the general uglyness there is the fact that MathHullInset is the old border fortification of mathed's interna vs the outside world and 'inset unification' is not yet fully finished. Most notably, input/output is not yet unified and this particular assignment is part of the glue code. Andre'
