Gabriel Dos Reis <g...@integrable-solutions.net> writes: >> I.e., I can choose between various types of ugliness -- wrong namespace, >> funny syntax, or (currently) gcc-dependence. I used to choose gcc- >> dependence, but then switched to funny syntax. In the future when c++0x >> support is more widespread, of course, I won't have to make such an >> annoying choice any more... > > hmm, that sounds like an awful lot of effort put into something that looked > to me as simple code to write using standard functionalities. Though > I have to confess I do not understand why the class must be right and the > namespace must be wrong. (Maybe I have not seen the real code, I > don't know.)
Exactly. Which is "right" or "acceptable" depends on the details and programming style, and is subjective to some degree. Anyway, what's important is whether existing code _may_ have chosen to use this gcc feature, and may not consider pre-c++0x alternatives palatable. The point was made that this feature was already deprecated -- but I think given that a more-palatable option will be available in c++0x[*], it would be nice to give users a certain amount of overlap during which both the old (deprecated) and new features are both supported. That would suggest keeping this feature for a while still... [If there were no such c++0x feature coming, I guess it would matter less when the deprecation actually changed to removal.] [*] "more palatable" because only definitions need be updated, not uses, all attributes of the existing gcc-only code are maintained (inheritance by subclasses, etc), and there's no need for a change in programming style. -Miles -- Learning, n. The kind of ignorance distinguishing the studious.
