On Saturday 24 September 2005 12:51, David Abrahams wrote:
bjorn@4roald.org writes:
On Saturday 24 September 2005 01:09, David Abrahams wrote:
Bjørn Roald <bjorn@4roald.org> writes:
- configuration management issues in general for us and our customers
Such as?
mostly a concern if we have to maintain other brances of boost than the library maintainers on boost.org.
Ah.
I may have been a little quick here. It really concerns me that I sell a library were I have to send with it a description with a long list of libraries-versions my customers configuration management will have to deal with. One of the items on the long list is me telling the customers configuration manager to ensure that if they use boost directly or indirectly through other libraries, they better use 1.32.0 compiled with the following compiler std lib and options.... Configuration Nightmare -- and it is assured to come back to me and haunt me. My library may have to support many versions of boost, with potential API changes. Ideally the list should be empty, at least as short as possible.
- platform support in Boost ( or if the platform support Boost if you like ;-)
Sorry; what do you mean?
Just trying to be funny, sorry... the pun was that if boost is standard conformant, then the platforms are to blame. However, there are often some truth in what I try to joke about.
I understand, but I don't even understand the first part. In what way is "platform support in Boost" a concern?
Sun compilers come to mind. I have had to massage boost code every time I used it with sun compilers. And I have to admit I usually avoid trying :-( I believe Steve Clamage of Sun recently announced that the Sun CC would be boost compatible soon. Anybody have an update on that? I have not tried with any of the newest versions of SunStudio and I don't believe they are in the regression tests either. Also, I believe ACE have a much longer bragging list when it comes to platforms supported. I am not saying the portability is bad, just that it still may be a concern for some.
Use of dlopen/dlsym and the win32 equallents is sertainly possible. Good point -- I will think more about that one. This could be appropriate if internal use of boost can be statically linked into a loadable library, and that module's services can be accessed through simple methods, alternatively through some framework - component hook-up. Interfaces to the module have to be Boost less.
Yes. I can even imagine a nice tool or library for wrapping these interfaces up into isolated components so you and your clients don't have to deal with the entry point/type erasure nitty-gritty. That might be an excellent candidate for a Boost library that supports namespace renaming.
Funny, I have a colleague battering me about the same general idea in a completely different context. This is part of some work we do on a component framework. His approach was using some pretty advanced macro stuff, and I am always skeptical to that, probably to skeptical some times. He is a Java Guru really, and relatively new to C++. He thought WOW preprocessor -- powerful. I am trying to moderate, and point at other features in the language. But there may be more to this, I need to pay more attention :) Are you thinking about connecting this to some sort of new library abstraction feature in form of a library? And possibly combined with something generating code based on macros, templates or just some other tool/model/pattern? How does this tie to work on the Boost Interface Library proposal?
I just meant that we're probably fully committed to having ugly workarounds, at least in some parts of Boost, so what does one more hurt?
While cross country skiing in the Norwegian mountains we have a saying: "It is never too late to turn around". It refers to the prospect of bad weather ahead.
But I feel like you missed one important point I tried to make. What I try to propose is something requiering no change in the way boost source code is written or maintained. I propose tool support for a _production_step_ ensuring namespace renaming in a subset of boost selected with the bcp tool.
Yes, I noticed that. It's a really neat idea, but I have no clue whether it's practical. Actually I do at least have a _clue_. Depending on the level of PP usage in a Boost header, it could be very difficult to identify all the places that symbols need to be changed. And even then a naive "replace the boost identifier" strategem is not guaranteed to work unless we all maintain an agreement that "boost" is never to be used as an identifier other than for the outer boost namespace. I'm not sure what other issues are lurking in there; these are just the two that popped into my head immediately.
Well you are right, in the tests I have done I quickly I had to add special treatment for "boost.org" in the license. There will be more. ---- Bjørn