Re: [boost] thoughts on logging library: orthogonal runtime configuration
Steven Watanabe writes:
AMDG
brass goowy wrote:
This is a good example of the need for compilers that output the code they generate based on templates. If they did that, the library writer could have an online service that spits out the final deliverable rather than users having to maintain different versions of a library.
I don't understand the advantage over preprocessor configuration. I don't really want to have to have a separate boost distribution every time I want a different configuration.
It is a slow and error prone process to rebuild a library/application as suggested here. Alternatively, service providers would have logging versions of their code available for users in the field, in effect eliminating the long and unproductive process of a rebuild.
How is this any better than just providing pre-built binaries.
I think the follow through on pre-built binaries that would be needed is more than the release team currently delivers. It would require branching out to the library level (I think the pre-builts are mostly of the whole of Boost) and then multiplying that times primary configuration options such as logging/non-logging. And then multiplying that total by the various platforms. That gets to be too much work with the various platforms around. The situation could be simplified by having a compiler that applies user code against a library and outputs fully instantiated source code. That seems like it would minimize the platform dimension in the equation. The compiler I'm talking about would be strong in terms of it's implementation of the language and some/most of the platform related preprocessing wouldn't be needed. This approach might make it easier to push C++0x functionality to more platforms without the various compiler implementors having to each incorporate support for all of the changes required by the standard. Brian Wood Ebenezer Enterprises www.webEbenezer.net
AMDG brass goowy wrote:
I think the follow through on pre-built binaries that would be needed is more than the release team currently delivers. It would require branching out to the library level (I think the pre-builts are mostly of the whole of Boost) and then multiplying that times primary configuration options such as logging/non-logging. And then multiplying that total by the various platforms. That gets to be too much work with the various platforms around. The situation could be simplified by having a compiler that applies user code against a library and outputs fully instantiated source code. That seems like it would minimize the platform dimension in the equation. The compiler I'm talking about would be strong in terms of it's implementation of the language and some/most of the platform related preprocessing wouldn't be needed. This approach might make it easier to push C++0x functionality to more platforms without the various compiler implementors having to each incorporate support for all of the changes required by the standard.
I very strongly disagree. First of all I do not think that boost should *require* the use a particular compiler. Building libraries with the correct configuration myself once per release is much less of a burden, IMO, than having to run all my code through a boost specific preprocessor. Further, I think that your idea does not scale to dozens of libraries being instantiated with hundreds of types. It will mean that I have to explicitly specify which templates I'm instantiating. If the instantiation is automatic, then we're back in something very similar to the current C++ model, only we've just inflicted another compilation step on users. In Christ, Steven Watanabe
participants (2)
-
brass goowy -
Steven Watanabe