"Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote in message news:d55hn9$4c5$1@sea.gmane.org... |> | In addition eliminating rvalues support will signicantly simplify | > | implementation and as a result speed up compilation. | > | > hm...that won't save you anything AFAICT. | | Why, It saves me rvalue detection and suuport logic. I do not need one now: | now parcing, now template instanciations yes, it might slow down compilation, so what? | > | 2. Usage of Boost.Range | > | | > | I understand why FOREACH is using Boost.Range, but: | > | a) In many (most) cases I (and any other developer now) working with stl | > | containers and wouldn't need any extra help from boost.range for FOREACH | > to | > | work properly. | > | > things like pair<iterator,iterator> are very common...just look at BGL. | > | > besides, you need a way to make your own collection work with foreach. | | Not in my development. Anyway I do not propose to eliminate it completely. | Just provide the way to disable this. ok. | > | b) Usage of Boost.Range introduces an extra dependency on ... | > Boost.Range | > | and everything it depends on in its' turn (including all portability | > | limitations). I for one couldn't afford this dependency, | > | c) Usage of Boost.Range adding a level of indiration and slightly | > | complicate am implementation | > | > so.? the standard containers part of it is pretty portable. | | Try to compile with all compilers we support. In some cases It just fails | somewhere within Boost.Range headers. Also why would I need to include all | there headers if I am not really need them. maybe you should put some effort into making those compilers work? -Thorsten