Sorry about the private message, it was not intended... Did I say already how much I hate email on a tablet?
Concerning whether the backport strategy, I am not convinced that the effort will be so important, but I'll let others with better understanding comment. JMarc Le 14 août 2015 09:21:14 UTC+02:00, Guillaume Munch <ga...@free.fr> a écrit : >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. >> >>
