Hello,

Le 13/08/2015 22:32, Jean-Marc Lasgouttes a écrit :
Hi Guillaume,

Please keep technical discussions on the list even if it seems that
we are the only ones concerned. At least Georg will want to chime in
at some point and it is better to keep everything available.


OK. (It was a reply to Jean-Marc's own private message.)


Then, I must translate for people who do not read French. Essentially, if the plan is to use c++11 features starting from 2.3, and 2.2 requires c++98 compatibility, then backporting new code is going to involve unusual efforts, or discourage using the features as long as 2.3 is in master (while these features allow cleaner and more expressive code). Requiring c++11 ahead of time is what seems to guarantee a smoother transition.

For now I am going to adapt my patch for 2.2, and clean it up later, once 2.3 opens.


Jean-Marc kindly wrote below an answer to my remarks, but I do not see him addressing my point about backporting, so I am not convinced by his reply.


Guillaume



I agree that unique_ptr cannot really be implemented without c++11
move semantics.

Compiling both with and without c++11 right now is not a problem IMO
and I believe that any bug that would occur because of this will be
real bugs anyways. If we make c++1 automatic without requiring it, we
still have a way out for people who could need it. I will probably
compile LyX without c++11 for the sake of testing for bugs.

Concerning auto_ptr : I only want to get rid of them to avoid
deprecation warnings. I is important to keep compilation as clean as
possible. Any trick that avoids the warnings would be good, since we
know what the issue is.

In summary, we just want to make a smooth transition to c++11. For
example, LyX 2.1 used TR1 when possible. We have got rid of that in
2.2.

JMarc

Le 8 août 2015 23:21:18 UTC+02:00, Guillaume Munch <ga...@free.fr> a
écrit :
Cher Jean-Marc,


Ce que je retiens de ma lecture du manuel de Boost::Move est qu'il
ne peut pas y avoir de rétroportage complètement transparent de
unique_ptr (ils semblent pourtant avoir vraiment essayé). Et ce
n'est que l'une des fonctionnalités de c++11... Sachant cela, je
ne conseillerais pas de rendre c++11 automatique sans le requérir
officiellement, car ça ouvre la porte à des bugs découverts
tardivement, et requiert du temps afin de rétroporter le code
(sans garantie que ce soit simple, bien qu'il se peut que Boost
aide).

Par exemple, concernant mon code, oui, je peux l'adapter à toutes
les situations, car mon utilisation de unique_ptr n'est vraiment
pas compliquée. Mais ce serait paradoxal de faire beaucoup
d'efforts pour le rendre compatible avec c++98 tout en gardant
l'unique_ptr, car le but de cet emploi est justement de rendre la
programmation plus simple...

Du point de vue du temps de développeur disponible, dont LyX semble
manquer, il semble plus simple, pour une conversion de LyX à c++11
lors d'une version N, de déjà requérir c++11 à la version (N-1)
afin de pouvoir rétroporter les améliorations sans se creuser la
tête... Autrement dit, ce serait plus économe en temps de trouver
une autre solution à la compatibilité avec Mac OS 10.7. Mais tu
avais l'air de sous-entendre qu'il y a d'autres problèmes avec
c++11, et c'est à toi et aux autres développeurs de voir.

Enfin j'ai l'impression que tu trouves urgent de convertir les
auto_ptrs en unique_ptrs. Mais cela peut être fait progressivement
d'ici la 2.3, et cela ne m'a pas l'air plus urgent que de limiter
l'utilisation des pointeurs nus, par exemple.




Reply via email to