On Mon, 08 Oct 2012 09:25:18 -0700, Lorenzo Caminiti wrote:
On Mon, Oct 8, 2012 at 9:00 AM, Paul Mensonides <pmenso57@comcast.net> wrote:
On Sun, 07 Oct 2012 15:49:40 -0400, Edward Diener wrote:
2) For a macro library, do we still need to have a BOOST_ prefix or could I just keep the CHAOS_PP_ prefix? I cannot use BOOST_PP_ without bending over backwards to find contrived names for everything, and the namespace of brief names beginning with BOOST_ is tiny--especially when a library provides hundreds of user-interface (i.e. not implementation detail macros).
BOOST_CHAOS_PP_... seems normal to me.
It seems *way* to long to me.
I don't think so, it's not long. However, "chaos" doesn't mean anything so I'd prefer a more descriptive name... maybe for pp meta-programming:
"Chaos" does mean something. It was a reference to chaos theory, where things look random but are ultimately following rules. There are plenty of other "terms" I used in Chaos that I look at now and think "where on Earth did that come from?" Regardless, the name must be short. Unlike normal code, there are no "say it once" scenarios. I.e. there is no namespace chaos { void f(int); inline void g() { f(123); } } -or- using namespace chaos; Instead, it must be qualified everywhere--even throughout the implementation--thousands and thousands of times. What if every name defined by Boost had boost::library:: on it throughout the implementation? In Chaos, I use CHAOS_PP_ for an interface prefix and CHAOS_IP_ for implementation macros (where the distinction is sometimes helpful when debugging). I suppose BOOST_CP_ and BOOST_CI_ aren't too bad if they aren't taken, though I actually think CHAOS_PP_ is better. The best name would be BOOST_PP_ but that is, surprisingly, already taken. There is another issue I have with submitting Chaos to Boost. Boost currently requires the use of .hpp file suffixes. However, like Boost.Preprocessor, but unlike all of the rest of Boost, Chaos is a C library also. The rule should be amended to allow for headers which are not specifically C++ headers. Chaos uses the generic .h for precisely this reason. Note that if .hpp is required, I simply will not submit the library. No hacks--including those introduced to workaround rules which should not apply. You have to understand my point of view: I do not really care whether Chaos becomes part of Boost or not. It is just that people keep asking me for that. That is fine unless doing so makes the library inferior according to my subjective or objective opinion. If I change the prefix, from CHAOS_PP_ to BOOST_CHAOS_ or similar, I have to make all of the libray source code longer, and all of my other present and future code which uses it longer--for no benefit to me. Why would I do that? I don't really care how many people use the library. Perhaps that's too strong. I don't mind if lots of people use it, but not if gaining users requires compromising the purpose of the library. I also don't require the Boost stamp of approval. I have internal motivations to do the work that I do. Not that I mind it, but I do not need the approval of others--otherwise I would never have gotten involved in extensive preprocessor usage. That's just asking for controversy and has garnered plenty of it. As Chaos is defined by a no-compromise approach, it isn't a question of whether Chaos is suitable for Boost. It's a question of whether Boost is suitable for Chaos. That's not simply arrogance. It's about the *purpose* of the library. I gave up on VC++ for lots of reasons including its preprocessor, so I don't really care whether the library's presence in Boost somehow causes VC ++'s preprocessor to be fixed--which it probably wouldn't anyway. Even if it was fixed, it likely wouldn't be for the right reasons, and that will just lead to a similar situations with different issues. If the library became part of Boost, and MS subsequently fixed their preprocessor, I still wouldn't touch VC++ with a ten foot pole unless I somehow became convinced of a radical change in MS's philosophy (unlikely)--which would require proving it, not just saying it. The language should be implemented correctly because it is an ISO standard and the future portability goals that give that weight--not because some popular library needs it or a large enough portion of the user base wants it. Generally speaking (not WRT Chaos), I'm willing to work with compilers that are trying to implement the standard--not just the parts of the standard that they agree with or want to. If a compiler does not have 100% conformance (in the limit) as a primary design goal, I'd rather that compiler fail. In the case of VC++, I no longer want the preprocessor to be fixed. Instead, I want VC++ to fall into disuse and die however likely or unlikely that is. Developing, implementing, and using a standard is about the future of computing. Look at Boost itself. It is an enormous mess of workarounds. The barrier to entry is enormously high almost entirely due to an edifice of compiler-dependent workarounds. With Boost, you don't target C++, you target the union (not intersection) of MS C++, GCC C++, clang C++, Sun C+ +, and so on. That's okay for something intended to be portable and practical at a specific point in time, but it stunts innovation even more than backwards compatibility requirements do. For me, Boost.Preprocessor is an ugly-but-practical solution that exists at a certain point of time. It has nowhere to go of technological significance given its requirements. Not that I'm suggesting this, but what would Boost look like if it was written to target *C++* in the theoretical case where such compilers existed? I believe it again would be a platform for innovative (in the technical C++ sense) which is something I think has been lost to some degree. At the very least, it would be clean and often elegant code. When either backward compatibility or compiler compatibility are fundamental design goals, eventually a library reaches a critical mass, can no longer innovate, and can barely be maintained. Not that I'm opposed to the modularization work (though I'd take hg over git any day of the week), but I'm not convinced that a lack of modularization is what is causing the majority of the underlying maintenance issues. (Perhaps modularization is an effective way to shelve those sub-libraries to make room for those sub-libraries that have not yet reached critical mass.) WRT Chaos, the library was and is supposed to be a technical exercise used to explore what a preprocessor metaprogramming library could be in theory via the creation, development, and usage of advanced technique. As a preprocessor metaprogramming library, it *happens* to be practical in all situations where Boost.Preprocessor would be practical and the preprocessor *happens* to be good enough. Those cases (that I know of) include gcc, *almost* includes clang, and EDG-based compilers (last time I checked). I haven't checked any others recently, so there may be more. So what motivation is there for me to make things more obnoxious to both implement and use given the fundamental purpose of the library? Chaos being in Boost gains me nothing which I consider worthwhile. It would only be altruistic work--which I don't mind, but I will not subvert the purpose of the library. Regards, Paul Mensonides