RE: [boost] Re: Filesystem: create_directories
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of David Abrahams > Sent: Saturday, August 02, 2003 5:36 PM > To: [EMAIL PROTECTED] > Subject: [boost] Re: Filesystem: create_directories > > > "Jeremy B. Maitin-Shepard" <[EMAIL PROTECTED]> writes: > > > On Sat, 02 Aug 2003 15:51:43 +0200 Thomas Witt > > <[EMAIL PROTECTED]> wrote: > > > >> This seems to have slipped by me. I really feal uncomfortable with > >> having two different functions named > >> > >> create_directory > >> and > >> create_directories > >> > > > > Another option might be: "create_directory_and_parents" > > That name is longer than "create_directories" although it better > > describes the function. > > I like "create_directory_path" > > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com That one's good, and captures the essential distinction well. Other possibles: "create_full_directory," or "create_rooted_directory." Dunno. On whole, I might prefer your choice. Although it again lengthens the name, "create_directory_and_path" captures another minor piece of the distinction. You could also play with the distinction (none save semantic in most file systems) between "pathname" and "filename;" a filename is usually just the thing at the leaf-terminal end of the path (and needn't be a "file," save as a directory is often actually implemented as such), while the pathname is the full Monty. In the original scheme, I would think the problem with "create_directories" is that it would seem to imply (to me, at any rate) the creation of multiple directories at the same depth in the file system. Anyway, them's my kibitz's. Reid Sweatman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Filesystem: create_directories
"Jeremy B. Maitin-Shepard" <[EMAIL PROTECTED]> writes: > On Sat, 02 Aug 2003 15:51:43 +0200 Thomas Witt > <[EMAIL PROTECTED]> wrote: > >> This seems to have slipped by me. I really feal uncomfortable with >> having two different functions named >> >> create_directory >> and >> create_directories >> > > Another option might be: "create_directory_and_parents" > That name is longer than "create_directories" although it better > describes the function. I like "create_directory_path" -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Fun PP lib example
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > I was talking about pimpl as described here - > http://www.gotw.ca/gotw/024.htm. > >> I need to be able to plug in different >> runtime-polymorphic implementations behind the handle classes I'm >> defining. > > Sounds like a job for an interface class + a factory function, unless your > objects need to be passed by value. Yes, that's what I wanted. > In any case, IMO the latter one is more > correctly described as "handle/body". I can never keep all these design patterns straight in my mind; many are so similar. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: GUI/GDI template library
E. Gladyshev wrote: --- Edward Diener <[EMAIL PROTECTED]> wrote: As you have pointed out in the rest of your post, it may prove more worthwhile to work with the developers which already exist for a free cross-platform framework like wxWindows, in order to encourage them to use more modern C++ idioms I agree with this suggestion. I am wondering how realistic would it be? Personally I'm not certain I like that idea. WxWindows is much more than just multi-platform GUI. This means when you only need the GUI you'll be linking to everything else in their library, which increases your code size. Plus, all those extra classes in WxWindows will make things like porting to other platforms even tougher, because you can't just port the GUI, but instead you must port all the classes. And would it even be feasible to port WxWindows GUI classes to use SDL, for example? Besides, I believe it would take more effort to change all the existing WxWindows code to use modern C++ techniques (which they would probably be against for backwards compatibility reasons) than it would to create one from scratch. Rob Geiman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Fun PP lib example
David Abrahams wrote: > "Paul Mensonides" <[EMAIL PROTECTED]> writes: > > > Aleksey Gurtovoy wrote: > >> David Abrahams wrote: > >> > Here's an example I just cooked up of using the PP lib to solve a > >> > classic C++ OO problem: repeated boilerplate in the definition of > >> > Pimpl classes. > >> > >> There is another variation of the idiom, sometimes called > >> "hidden state", which doesn't have the shortcoming in the first place: > > > > Dave, do you still think this would be a good example to add to the > > docs? > > Well, yeah. I don't understand how Aleksey's idiom accomplishes the > same things as pimpl (yet). I was talking about pimpl as described here - http://www.gotw.ca/gotw/024.htm. > I need to be able to plug in different > runtime-polymorphic implementations behind the handle classes I'm > defining. Sounds like a job for an interface class + a factory function, unless your objects need to be passed by value. In any case, IMO the latter one is more correctly described as "handle/body". Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Fun PP lib example
Fernando Cacciola wrote: > "Aleksey Gurtovoy" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED] > > David Abrahams wrote: > > > Here's an example I just cooked up of using the PP lib to solve a > > > classic C++ OO problem: repeated boilerplate in the definition of > > > Pimpl classes. > > > > There is another variation of the idiom, sometimes called "hidden state", > > which doesn't have the shortcoming in the first place: > > > A shortcoming of the hidden state idiom compared to the classic delegation > idiom is that only the state is encapsulated, not the behaviour. I am not sure what do you mean by "encapsulated". Hidden in a source file as opposite to the header? > IOWs, if you need to hide the operations, not just the state, you still > need to mirror the interface class member functions into > the impl class. How so? With the hidden state, what would be private member functions becomes free functions at the file scope. You just call those directly from anywhere within the file scope, without the boilerplate forwarding. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: GUI/GDI template library
--- Edward Diener <[EMAIL PROTECTED]> wrote: > As you have pointed out in the rest of your post, it > may prove more > worthwhile to work with the developers which already > exist for a free > cross-platform framework like wxWindows, in order to > encourage them to use > more modern C++ idioms I agree with this suggestion. I am wondering how realistic would it be? Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Filesystem: create_directories
On Sat, 02 Aug 2003 15:51:43 +0200 Thomas Witt <[EMAIL PROTECTED]> wrote: > This seems to have slipped by me. I really feal uncomfortable with > having two different functions named > > create_directory > and > create_directories > Another option might be: "create_directory_and_parents" That name is longer than "create_directories" although it better describes the function. -- Jeremy B. Maitin-Shepard [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: GUI/GDI template library
Terje Slettebø wrote: >> From: "Edward Diener" <[EMAIL PROTECTED]> > >> Add to this the fact that nearly every C++ programmer already works >> with a framework library depending on his implementation of choice. >> On Windows alone I know of WTL, ATL, MFC, OWL, VCL, wxWindows, QT, >> and no doubt > others >> about which I have no knowledde, each tied very closely to a >> particular > C++ >> compiler, IDE, and implementation. > > I just wanted to point out that several of these, Qt and wxWindows, > are cross-platform, so they are not tied to any specific compiler or > platform. wxWindows is also Open Source, and I've good experience > with the little I've used it. It's very easy to get up and running > with it (at least it was on Windows). snipped... I see you are supporting my main point which was that re-inventing a GUI framework for Boost, with both many platform dependent and cross-platform frameworks already in place and very popular with most C++ programmers, will be duplicating functionality which already exists. I do realize that most of these frameworks do not use template techniques but that doesn't make them necessarily any less popular with their many users. Also, as I pointed out, the amount of work necessary to implement an effective GUI framework is enormous, given the differences in GUI controls and GDI-like functionality on the major OSs. I am certainly not against the OP trying to do something like this for Boost but I think that is naive to assume that one can create such a Boost templated cross-platform framework without a tremendous amount of work and time spent invesigating the GUI and graphics APIs of a number of OSs. OTOH if the consensus is that such a framework will work only by having the end user plug-in to it classes with the appropriate functionality for a generic idea, such as a listbox let's say, there will be enormous amount of work for the end-user to do and even then the templated listbox may provide hooks into only a very small amount of functionality which listboxes represent on that user's particular OS. As you have pointed out in the rest of your post, it may prove more worthwhile to work with the developers which already exist for a free cross-platform framework like wxWindows, in order to encourage them to use more modern C++ idioms which will make using their framework easier for end-users, than attempting to recreate one all over again. Boostifying wxWindows and having Boost developers and wxWindows talking to each other about better techniques for making wxWindows easier to program may be much more worthwhile than re-creating yet another GUI/Graphics framework. As someone who has worked with numerous GUI frameworks on the Windows platform, I know that the sophistication of such an interrelated set of classes is enormous even just for the Windows API, let alone cross-platform work, and the effort to create such a framework has almost certainly taken the talents of teams of programmers from such big companies as Microsoft and Borland. That is not to say that the talents of many programmers who have contributed to a free framework should be denigrated in the least, only that one should not in any way underestimate the time and effort involved, and the continuing work it takes to chart changes and additions in OS APIs. In my career I have seen and worked with a few cross-platform frameworks from the past, and many have come and gone to be replaced by others. I am sure people must remember Zinc and Zapp and XVT and I am sure there were many, many others whose names I have forgotten by now. I believe the difficulty of just maintaining cross-platform workability effectively may have sunk most of these commercial efforts, but the general effort and support involved was probably enormous. Of course most all of these frameworks were also going against established GUI frameworks from Microsoft, Borland , and other major corporations. If one just charts the questions on the Borland and Microsoft and Sun NGs and forums regarding VCL and MFC and .NET GUI and Swing and AWT every day, one sees the difficulty even for huge corporations in maintaining an effective framework API. If Boost can create such a templated API which works for a decent number of C++ programmers, without even considering the numbers of C++ programmers who might leave their very comfortable RAD environments for a Boost GUI API, I say bravo. But do not underestimate the difficulties involved and do consider working to improve free frameworks which may already exist like wxWindows instead. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
--- Rainer Deyke <[EMAIL PROTECTED]> wrote: > For a GUI library to be useful to me, it would need > to support custom > physical GUI layers. I would then write my own [...] > full-screen multimedia. I > realize that my needs are unusual, and boost::gui > may be unable to > accomodate them. It seems strange to me, why are you willing to give up on your requirements. What is so unusual about them? I believe boost::gui must accomodate them and it can. Your requirements are very reasonable IMHO. > Nonetheless I also dislike the idea of > PhysicalGUILayer as a template > parameter to all GUI elements. PhysicalGUILayer is great for your requirements. Why do you dislike it? > It violates the > principle of Once and Only > Once. You can use a default template parameter for the PhysicalGUILayer and define it only once in your program. >(and > NativePhysicalGUILayer should be one of the > options). That way the actual structure of the GUI > does not depend on the > physical GUI layer, and the physical GUI layer can > even be selected at > runtime. > Exactly my point. Thanks for your post. Finally we have a set of requirements from someone who is doing custom GUI development. IMO boost::gui must be able to accomodate them. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BJAM help request
Beman Daws wrote: >Robert, if you didn't get a response to this, you might want to try the >jamboost mailing list Rene Rivera responded privately got me all straighened out on this in no time. Thanks Rene. And thanks to you Beman for asking. In the course of investigating this I did come up with another question someone might want to answer. There is a compile option in all versions of VC "Enable Function Level LInking" /Gy That I don't see referenced in the JAM files for MSVC et al. It would seem to me that this should be included in builds - at least for release mode in order that executable built with library don't include any more unused code than necessary. Is there some reason that this isn't included? Robert Ramey . ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: searchable list archive + integer.hpp request
At 12:25 PM 8/2/2003, David Abrahams wrote: >Yep, http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/boost/ is >the one. OK. CVS updated. Thanks, --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Preparing 1.30.1 Release -- Branch Question
> > Sorry to be MIA, but I wanted to add in the libs/date_time/doc/Changes.html > > file in the date-time docs that was not checked in when 1.30 was released... > > thus causing a broken link from the main page in the downloaded docs. I > > believe Dave hacked the website to fix this, but it was still broken in > > the download. > > > > So, which Branch do I add this to? > > RC_1_30_0 Thx -- I've added the file to the branch. Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: GUI/GDI template library
Beman Dawes wrote: > Always hard to tell without seeing a firm proposal, but for me > a PhysicalGuiLayer template parameter would probably evoke an "over > my > dead body" response. I think the reasons Doug gives in his message > are just the tip of the iceberg, but they are plenty good enough to > sink the ship, IMO. For a GUI library to be useful to me, it would need to support custom physical GUI layers. I would then write my own custom physical GUI layer in portable C++ over a crossplatform multimedia API such as SDL (Simple DirectMedia Layer). Access to native GUI widgets is useless for me, as native GUI widgets rarely cooperate with the full-screen multimedia. I realize that my needs are unusual, and boost::gui may be unable to accomodate them. Nonetheless I also dislike the idea of PhysicalGUILayer as a template parameter to all GUI elements. It violates the principle of Once and Only Once. Ideally the user should only have to specify the physical GUI layer at one point in the program (and NativePhysicalGUILayer should be one of the options). That way the actual structure of the GUI does not depend on the physical GUI layer, and the physical GUI layer can even be selected at runtime. -- Rainer Deyke - [EMAIL PROTECTED] - http://eldwood.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: GUI/GDI template library
Bohdan wrote: [...] >> I think that any industry standard TEMPLATE library >> should be designed in terms of modern C++. The >> compilation time should NOT be considred as an issue. >> Compilers are getting better, computers faster... >> boost should be setting programming standards not >> laging behind trying to accomodate some specific h/w >> requirements. > > You forgot one small thing ... development time > is very serious issue for programming. > If my work will be 10% coding/thinking and 90% > drinking coffee ... i prefer change my profession > to coffee taster :) Development speed is even > more important for developing GUI programs. > In most cases GUI program starts as something > small and can be developed/supported during > many years ... > Do you want to write excellent, > scalable, flexible, ... library that nobody wants > to use just because current computer-compiler > technology is not good enough for your lib ? >IMHO (not offensive) your ideas are too tied to > "new ideas" fashion in modern c++. They(ideas) are > good, very good unfortunately not always. > Please have mercy for people using > poor modern compilers :). Yes but by the time the library is finished, reviewed and get standardized (1 year?) I am pretty sure Microsoft & Cie will have released their VC 8 compiler. I also want to enjoy my coffee in the morning only. Not all day ;) If your compiler cannot support template template parameters, partial specializations, etc. and the user is smart enough to stress the compiler at this level, why not replace it with GNU GCC... it is free and if you code properly, you can speed up your application execution time. At some degree, we have to draw a bottom line and go on with development. Philippe ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: GUI/GDI template library
>From: "Edward Diener" <[EMAIL PROTECTED]> > Add to this the fact that nearly every C++ programmer already works with a > framework library depending on his implementation of choice. On Windows > alone I know of WTL, ATL, MFC, OWL, VCL, wxWindows, QT, and no doubt others > about which I have no knowledde, each tied very closely to a particular C++ > compiler, IDE, and implementation. I just wanted to point out that several of these, Qt and wxWindows, are cross-platform, so they are not tied to any specific compiler or platform. wxWindows is also Open Source, and I've good experience with the little I've used it. It's very easy to get up and running with it (at least it was on Windows). wxWindows is a wrapper for the native GUI API, while Qt emulates each GUI, using only the low-level graphics API. wxWindows could have been a candidate for Boost, had it not used "stone age" C++ - no templates, exceptions and namespaces (essentially "C with Classes" stage), to cater for a very broad range of compilers, even compilers such as MSVC 4 (!). There are plans to change this, though (http://www.wxwindows.org/roadmap.htm). To quote: --- Start --- Release 2.6.0 (stable) Release date: end of September 2003 Release 3.0.0 (stable) This release should finally mark the end of support for the antiquated compilers without decent support of the modern C++ features such as templates, exceptions and namespaces. wxWindows containers should be replaced with the corresponding standard library classes and std::basic_string<> should be used instead of wxString. --- End --- wxWindows also has 10 years of experience behind it, and an active developer community. Regarding what Dave Abrahams said in another posting about lack of templates (regarding FLTK) meaning that smart pointers can't be used - well, in this case, there are no exceptions, either, so you avoid problems with leaks from exceptions. :) Another note: The library is not a "lowest common denominator" library when it comes to features. There's a core set of components, such as controls, that are portable, but it also allows controls only available on one platform. Thus, it's up to the user how portable, or platform-specific, they want the application to be. Hopefully, this may give some ideas in the debate. Currently, Windows, Mac and Linux is supported, and an emulated version, wxUniversal (like Qt is doing it) is also worked on, e.g. for embedded use (http://www.wxwindows.org/wxuniv.htm). As to the discussion of encoding the layout in code, or using some sort of resource files, I think resource files may be preferrable for a few reasons: - You don't have to recompile the program for every GUI change, when designing the GUI - It's usually easier to make GUI designing programs for resource files, than ones generating source code. Besides, would you like "wizard-code" in your program, a la MFCs or Javas? - The layout and content may be changed at run-time, for example for localisation or customisation. No need for recompiling a client's code; just replace the resource files. Often, someone else but the programmer, a designer, makes the GUI design, and they should not have to be programmers. The same goes for web GUIs - a typical way of doing it is having a designer create the HTML, which is then used as some sort of template in the system, filling it in and transforming it, e.g. using PHP. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] GUI/GDI template library
At 02:39 AM 8/1/2003, Douglas Gregor wrote: >From: "E. Gladyshev" <[EMAIL PROTECTED]> >[snip] >> template < typename IT, typename PhysicalGuiLayer > >> class ListControl >[snip] > >I'm coming in a bit late into this discussion, but I too am interested in >the outcome of this project. > >I strongly dislike the PhysicalGuiLayer template parameter, for several >reasons... Always hard to tell without seeing a firm proposal, but for me a PhysicalGuiLayer template parameter would probably evoke an "over my dead body" response. I think the reasons Doug gives in his message are just the tip of the iceberg, but they are plenty good enough to sink the ship, IMO. The whole point of a "portable GUI library" is the word "portable", and I meant semantically portable, not just syntactically portable. Thus the sort of examples Brock has been posting are what I would hope to see - no mention of platforms. OTOH, Eugene has posted a series of examples which include "win32" in various names, and I find those pretty repulsive. I don't have and problem with Win32 as a platform and use it as my preferred development environment. But my code must be portable to all modern systems, and a few legacy systems too. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: GUI/GDI template library
At 05:52 AM 8/2/2003, E. Gladyshev wrote: > >--- Bohdan <[EMAIL PROTECTED]> wrote: >> >> "E. Gladyshev" <[EMAIL PROTECTED]> wrote in message >> > but which approach is better for GUI lib. > >I believe that I've made a strong case for ImplTraits >for GUI library. In the win32 case, the compilation >time penalties would be of the same order as including >windows.h Including windows.h is not acceptable in user code, however. That's one of the (many) uses of opaque pointer idioms - avoiding implementation side effects like inclusion of unruly headers. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: searchable list archive + integer.hpp request
Beman Dawes <[EMAIL PROTECTED]> writes: > At 11:56 AM 8/1/2003, David Abrahams wrote: > >"Neal D. Becker" <[EMAIL PROTECTED]> writes: > > > >> I know I (and others) have previously asked about extending > integer.hpp to > > > >> handle 64-bit types. I don't recall the conclusions of the > discussion, >> though, and on visiting the boost archive, I don't > see a search > >> option. > > > >How many options do you want? > > > >http://www.boost.org/more/mailing_lists.htm#archive > > The problem is that the link in the above to "searchable mailing list > archive" is to http://aspn.activestate.com/ASPN/Mail/Archives/boost/ > which is just a list of year/month archives. No "search" option > visible on that page. So there is a real issue here, and it leads > people to think that there is no search option available. OK, but all of those other archives are also searchable. Maybe you'd like to try rewording the page to make that clearer? > Which page on the activestate.com should the link point to? Perhaps > http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/boost? That > would seem to solve the search and most recent posting needs, but > doesn't seem to link to > http://aspn.activestate.com/ASPN/Mail/Archives/boost/. Yep, http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/boost/ is the one. > I keep having the sense that there is (or should be) some third "index > to the Boost archive" page on the ActiveState site that I am somehow > missing, and that is what we really should be linking to. I don't think there's anything else. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Preparing 1.30.1 Release -- Branch Question
"Jeff Garland" <[EMAIL PROTECTED]> writes: > Sorry to be MIA, but I wanted to add in the libs/date_time/doc/Changes.html > file in the date-time docs that was not checked in when 1.30 was released... > thus causing a broken link from the main page in the downloaded docs. I > believe Dave hacked the website to fix this, but it was still broken in > the download. > > So, which Branch do I add this to? RC_1_30_0 -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BJAM help request
At 11:24 AM 7/21/2003, Robert Ramey wrote: >Fellow boosters., > >I hope to be soon uploading a draft of a much evolved version of the >serialization library >reviewed last november. I have been working with BJAM to automate builind >of library and tests, and running the tests. So far so good. > >The system build around BJAM seems to work very well and I am very pleased >with it - BUT. The logic is seems to be spread around different files and >directories and is hard to track down. and the jam language takes some >getting used to. > >I currently have about 30 tests. I would like to run each of the tests >under all the following combinations: > >30 tests >5 3 or 4 compilers I have on my machine >2 modes (release and debug) >5 different compile time defines - for applying each test to each archive > >so that's around 1500 test combinations. > >So I need help in enhancing my jamfile to do this automatically. If any >jam expert wants to help me with this I would be please do here from him >on private email. Robert, if you didn't get a response to this, you might want to try the jamboost mailing list. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: the boost::signal sample crashes
At 11:32 AM 8/2/2003, Douglas Gregor wrote: >- Original Message - >From: "Bohdan" <[EMAIL PROTECTED]> >> Honestly ... i'd like to see such build system in all boost >> non-template libs :) IMHO, it is very convenient. >> >> regards, >> bohdan > >The Boost.Build folks are working on a solution for this. I don't know >quite when it will happen, but a future Boost release will fix all of these >compile/link option problems with a common scheme. Rene has done a preliminary implemenation. See his message to the jamboost list below. What is needed now is someone to test his solution to see how it works in practice with various boost libraries, platforms, and compilers. Then give him feedback (on the jamboost list). Once it is ready for primetime, we need some brief docs explaining what Boost developers need to do to enable the solution for their libraries. --Beman [2003-07-16] Rene Rivera wrote: >The way to handle the maintainance aspect is to standardize what the naming >behaviour is for libraries and dlls and codify that into either the stage >rule, or preferably another rule which better describes the intent. OK I've done some of the work on this. I did some additions and modifications to the default build, what you get when running bjam at the boost_root. The changes are... In boost_root/Jamfile: Has two default stage targets. One for the built libraries, and another for the include directory. The targets build to what one would consider "install" locations. Specifically C:\Boost, or /usr/local. The libraries are installed to a subdirectory according to the platform. For example /usr/local/lib/x86-linux on Linux systems. This supports multi-system nature of installs. The libraries are tagged with a build specific tag with the addition of the "common-stage-tag" rule (see below). The includes are searched in the boost/.. tree and copied to a version specific subdirectory. Example, C:\Boost\include\boost-131\boost. Added some command options to control install locations, and a --help option. They are in the style of configure options. Do a "bjam --help" to see docs for those. In boost_root/tools/build/boost-base.jam: Added various options to stage rule to handle the above functionality: , adds a single level subdir to the stage that encode the architecture and OS of the build. TREE-ROOT, attempts to mirror the given rooted tree. Any source files that have the root will be created within the subdir(s) where the source is, but within the stage dir. DIR, roots the stage at the given dir instead of placing it at the project location (or ALL_LOCATE_TARGET). Added the "common-stage-tag" rule, which generates the common tag when used in the requirements section of a stage. The tag generated is documented in the rule, but I'll quote the docs here: # Common rules for generating a single stage tag based on the # variant, build properties, and the toolset used to build. # To use place this rule name in the requirementes section of # a stage target. # # The tag is constructed as such: # # [-][-][-] # #maps to an abbreviated name of the toolset # and when possible and applicable the version of the toolset. # #"mt" when multi-threading is enabled. # #adds these single letter tags: # "s" when static linking to runtime # "g" when linking to debug runtime # "d" when building debug variants # "p" when building with stlport libraries # # The tag added is a to allow for additional tags # in the stage. For example the version tag. # rule common-stage-tag ( toolset variant : properties * ) *** The changes to the two files are in the "build_for_distribution" branch. Only the two files are tagged to the branch so only get the files not the whole tree. Questions, comments, whatever? -- grafik - Don't Assume Anything -- rrivera (at) acm.org - grafik (at) redshift-software.com -- 102708583 (at) icq ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Preparing 1.30.1 Release
"Douglas Gregor" <[EMAIL PROTECTED]> writes: > - Original Message - > From: "Lars Gullik Bjønnes" <[EMAIL PROTECTED]> >> David Abrahams <[EMAIL PROTECTED]> writes: >> >> | I have put a diff of the changes between Version_1_30_0 and RC_1_30_0 >> | at http://www.boost-consulting.com/diffs-1-30-1.txt. >> >> These are the changes we (LyX Developers) have made to boost 1.30.0 to >> make it compile with gcc 3.3 without warnings, as well as using a >> different string class than std::string¹. >> >> If appropriate, please include these changes in 1.30.1. > > I think we should apply these changes for 1.30.1. They aren't going to break > anything, and GCC 3.3 is an important compiler. At the very least, we need > the config changes. I've applied the first two; I'm not comfortable applying the regex patches myself; it takes someone who knows the library to verify that they're OK. John can do it, though, as far as I'm concerned. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Preparing 1.30.1 Release
- Original Message - From: "Lars Gullik Bjønnes" <[EMAIL PROTECTED]> > David Abrahams <[EMAIL PROTECTED]> writes: > > | I have put a diff of the changes between Version_1_30_0 and RC_1_30_0 > | at http://www.boost-consulting.com/diffs-1-30-1.txt. > > These are the changes we (LyX Developers) have made to boost 1.30.0 to > make it compile with gcc 3.3 without warnings, as well as using a > different string class than std::string¹. > > If appropriate, please include these changes in 1.30.1. I think we should apply these changes for 1.30.1. They aren't going to break anything, and GCC 3.3 is an important compiler. At the very least, we need the config changes. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: the boost::signal sample crashes
- Original Message - From: "Bohdan" <[EMAIL PROTECTED]> > "E. Gladyshev" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > > Have you built the signals library multi-threaded or > > > single threaded and > > > > Whatever the default build is. > > > > > > > are you building an application of the same sort? > > > > The application is set to use multi-thread run-time > > libraries and MFC.DLL. > > Check boost::signal library compile/link options as well. > > It looks like commons source of problems. Would it > be difficult to add automatic library selection for > boost::signal ? I mean library suffixes and comment > pragmas as in boost::regex. > Honestly ... i'd like to see such build system in all boost > non-template libs :) IMHO, it is very convenient. > > regards, > bohdan The Boost.Build folks are working on a solution for this. I don't know quite when it will happen, but a future Boost release will fix all of these compile/link option problems with a common scheme. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] GUI/GDI template library
- Original Message -
From: "E. Gladyshev" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Friday, August 01, 2003 7:49 PM
Subject: RE: [boost] GUI/GDI template library
>
> --- Brock Peabody <[EMAIL PROTECTED]>
> wrote:
>
> > > Anyway I think I got the basic idea. The idea is
> > that
> > > the GUI elements are classes defined on top of a
> > > pImpl. Someone else creates the pImpl object and
> > > passes it to the GUI elements classes. The GUI
> > > elements then call pImpl methods do the real job.
> > > Did I get it right?
> >
> > Yes, and you're confused because I left part out.
> > Sorry!
> >
>
> I personally don't see any significant benefits in
> using pImpl here but there are lot of disadvantages.
>
> For example you would have to make sure that all pImpl
> functions use a set predefined data types. It means
> that the pImpl functions will have to convert the data
> between native format and pImpl.
> In the case of ImplTraits you can use native data
> types directly.
> Example:
>
> class win32
> {
> typedef WHND WinHnd;
> };
>
> template
> class window
> {
> public:
> ImplTraits::WinHnd m_hnd;
> ...
> };
>
> The bad list about pImpl goes on an on.
I think you missed the fact that the pImple itself was parameterized on the
traits class:
template struct edit_imp {...};
The pImpl is necessary in this case because of the fact that there is no way
to easily deduce the result type of a complex template expression (short of
a typeof operator). In my library, for instance the result type of:
row(column(edit(), "text"), row(mapped_combo_box(), .)
Would be pages long typed out. If you want to store it somewhere you have
to use some sort of wrapper, which is going to depend on a pimpl. Check out
the rule<> template in Spirit.
>
>
> [...]
> > They would typically all be part of (or a sub part
> > of) the same gui
> > object.
>
> My personal preference is to have two kinds of
> groupings.
> 1. Visual/behaviour grouping
> 2. Data groping.
>
> Using the first the first option, you can group GUI
> elements into one presentation group. The visual
> grouping would be managed by gui managers.
>
> The second option is similar to the MFC document/view
> architecture. You could connect a data item in a list
> control to an edit box (even in different dialogs) on
> the data level. If one control changes the data, all
> connected controls get updated automatically. This
> kind of grouping will have to be independent from the
> gui managers.
You are certainly right in that there are relations that cannot be expressed
within the GUI manager as I've been talking about it. It's really difficult
to describe the relation between two controls this way when defining them
inline. One example of such a relationship is having a check box that
enables and disables a group of controls as it is checked and unchecked.
This seems fairly common to me. Here is how you express it in my library
(toy example):
struct employee {
bool has_a_name;
std::string name;
};
gui_manager has_a_name_box = check_box("Has a name?",
&employee::has_a_name);
gui_manager name_controls = row("Name:",
edit(&employee::name));
tie_to_enabler(has_a_name_box, name_controls);
gui_manager app = column(has_a_name_box, name_controls);
Now when the program is running the "Name:" static text control and the edit
box following it will only be enabled when the "Has a name?" check box is
checked. When the user un-checks it, they will become disabled.
Does that seem reasonable? I don't know if the code to do this is in the
part of the library that I posted, if you want to see it I can post it too.
Actually in my library it is data_manager<>, but someone earlier used the
term 'gui_manager', which seems better to me.
Brock
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
It's obviously wrong to say that compile time performance does not matter. On the other hand, it's not wise to optimize the compile or run time performance of a library prematurely - start with the most beautiful design and make it more ugly as necessary :) I think we're drifting far from the topic with the whole traits (hidden or templatized) discussion. Does anyone remember the message Mr. Dawes posted where he described three levels of sophistication for the library (http://aspn.activestate.com/ASPN/Mail/Message/boost/1752449)? In my opinion, if we try to create anything beyond a simplistic, level (1) library on our first try, we're going to fail. The problem that Eugene is trying to solve with the ImplTraits mechanism may be legitimate, but I don't feel that it is part of the simplistic level 1 solution. We need to start talking about what the interface to this library should like like (a domain specific sub-language, as Mr. Abrahams said), and worry about the implementation details (a pimpl is certainly an implementation detail) afterwards. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Preparing 1.30.1 Release -- Branch Question
Sorry to be MIA, but I wanted to add in the libs/date_time/doc/Changes.html file in the date-time docs that was not checked in when 1.30 was released... thus causing a broken link from the main page in the downloaded docs. I believe Dave hacked the website to fix this, but it was still broken in the download. So, which Branch do I add this to? Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Filesystem: create_directories
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Abrahams wrote: | The documentation for create_directories makes no sense. It says | only: | | void create_directories( const path & ph ); | | Precondition: ph.empty() || | forall p: p == ph || is_parent(p, ph): is_directory(p) || !exists( p ) | | Postcondition: exists(ph) && is_directory(ph) | | It looks as though this is the same as create_directory, but has a | weird precondition. I swear I was *completely* baffled by its | purpose until I looked at the header file. This seems to have slipped by me. I really feal uncomfortable with having two different functions named create_directory and create_directories Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/K8Hu0ds/gS3XsBoRAuYTAJ9HRfJPfW2k/Od4TZIX94bYiLA2kQCdH+OK NmJUgQDA6XGun2t3drJSX8s= =HHVF -END PGP SIGNATURE- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: GUI/GDI template library
"E. Gladyshev" <[EMAIL PROTECTED]> writes: > --- David Abrahams <[EMAIL PROTECTED]> wrote: >> "E. Gladyshev" <[EMAIL PROTECTED]> writes: >> >> Is MPL a modern TEMPLATE library, in your opinion? >> I ask because compilation time is a very serious >> issue in the design >> of MPL. > > In my opinion MPL is a great example of a tool for > creating modern C++ programs/libraries. > The h/w and compiler designers will have to deal with > the compilation time issues. It is their job. > When you are writing music the last thing that you > should be thinking about is how these guys are going > to play it :). Then I suppose you regularly use O(N^3) algorithms without bothering to look for an O(log N) version? Sitting through a five-hour symphony, no matter how beautifully written, still makes me tired. People press MPL into service for all kinds of compute-intensive tasks at compile-time. If eventually things get slow enough to make development impractical, MPL is of no use to them. If they are building libraries (e.g. Boost.Python) and the libraries are too slow for their clients to compile, the clients get upset (yes, this is a real-world scenario). The clients don't often have the ability to acquire a faster compiler in a reasonable time-frame (none may be available). >> IMO it's nutty to think that people won't use every bit of >> compilation bandwidth they can stand, once they start to do >> computation at compile time. Why should it be any different from >> cycles at runtime? > > By people you mean developers. The developer's time is > a tricky issue. If you have a better library with a > long compilation time and not so good library with a > better compilation performance, which one do you > choose? If you choose the bad library, you can be > saving on the compilation time but loosing on the > development time. How do you count it? Do you care > how much effort/time did it take to build you car? I > don't. You would if it meant you were phoning the dealership every day for a year trying to find out why it hadn't arrived yet. > Personally I care about creating a beauty, not the compilation time. A luxury most working programmers can't afford. >> In many ways, the more modern a C++ library is, the more of a >> concern compilation times have to be. > > I agree, but the other guys have to deal with it. However you still > can be saving on the development time. By the development time, I > mean the average development time of the industry. Maybe. If the library is slow to compile on popular platforms, it won't see much adoption either. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Fun PP lib example
"Fernando Cacciola" <[EMAIL PROTECTED]> writes: > Yep, I've noticed. I actually voiced that opinion even though your > macro _in particular_ seemed OK just to set the records for the kind of > trouble that can ocurr if code repetition tasks are replaced by macros > without properly balancing the drawbacks and implied subtelties. > > For instance, many of the complains I've received were because invalid > macro arguments led to impossible to understand error messages. Even > if the macro just adds a declaration, figuring out the source of the > error can be impossible without knowing the expanded text of the > macro. We even tried to code-up some sort of utility to expand macros > on-the-fly with the given arguments, but that was impractical for us > because the complete macro expansion could depend on many other macros > and so on, so the "utility" must have access to the entire source and > include tree. I have just such a utility. It's called "g++ -E". Then I have some emacs code which roughly reformats the results so that I can read them. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] searchable list archive + integer.hpp request
At 10:34 AM 8/1/2003, Neal D. Becker wrote: >I know I (and others) have previously asked about extending integer.hpp to >handle 64-bit types. I don't recall the conclusions of the discussion ... Someone already started a year or so ago, but then got sidetracked by non-boost time pressures. >(I would really like to see 64bit support in integer.hpp. Perhaps I should >attempt a patch?) That would be great! Would like to start from the prior work? It would take me a bit of effort, but I could probably dig it out from an old hard drive. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Re: GUI/GDI template library
"E. Gladyshev" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > --- Bohdan <[EMAIL PROTECTED]> wrote: > > > > "E. Gladyshev" <[EMAIL PROTECTED]> wrote in message > > > but which approach is better for GUI lib. > > I believe that I've made a strong case for ImplTraits > for GUI library. In the win32 case, the compilation > time penalties would be of the same order as including > windows.h > Agree, but only for simple gui library. Look at other c++ GUI libs working with win32api... they internal implementation isn't as simple as you might think. Win32 "C" API doesn't propose too much modern functionality. More modern boost::gui tends to have even more complicated implementation. Possibly if you hide traits implementation in cpp files it can work. Unfortunately in this case you will be forced to include platform specific headers in your header files. This can lead to compilation errors if you are using more than one platform in your application. PImpl has no such drawback. BTW, do you/we really want to deal with more than one platform (win32,Qt,Gtk...) within one application ? I've seen few applications doing so and i don't think i'd ever like to create similar fat-garbage-applications. IMHO such possibilty has more drawbacks than goodies. More useful can be possiblity to use native api directly along with boost::gui. Ideas ? regards, bohdan regards, bohdan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: searchable list archive + integer.hpp request
At 11:56 AM 8/1/2003, David Abrahams wrote: >"Neal D. Becker" <[EMAIL PROTECTED]> writes: > >> I know I (and others) have previously asked about extending integer.hpp to > >> handle 64-bit types. I don't recall the conclusions of the discussion, >> though, and on visiting the boost archive, I don't see a search >> option. > >How many options do you want? > >http://www.boost.org/more/mailing_lists.htm#archive The problem is that the link in the above to "searchable mailing list archive" is to http://aspn.activestate.com/ASPN/Mail/Archives/boost/ which is just a list of year/month archives. No "search" option visible on that page. So there is a real issue here, and it leads people to think that there is no search option available. Which page on the activestate.com should the link point to? Perhaps http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/boost? That would seem to solve the search and most recent posting needs, but doesn't seem to link to http://aspn.activestate.com/ASPN/Mail/Archives/boost/. I keep having the sense that there is (or should be) some third "index to the Boost archive" page on the ActiveState site that I am somehow missing, and that is what we really should be linking to. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] minor nitpick: why signal.hpp instead of signals.hpp? (no text)
At 02:48 AM 7/8/2003, Dave Gomboc wrote: > >minor nitpick: why signal.hpp instead of signals.hpp? It is following the practice of the C++ Standard Library. Which in turn was following the practice of the C Standard Library. That being said, those libraries were developed in the days when filenames were limited to very short lengths, and no concerns over header name collisions. Today our concerns are different. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: string conversion methods
At 04:37 AM 7/7/2003, Russell Hind wrote: >I'm not saying replace all the _string methods with a str() but >jshould we have > >str() >native_file_str() >to_simple_str() > >or > >string() >native_file_string() >to_simple_string() > >just to commonise things. > >Filesystem has a string() method. stringstreams use str(). I also >agree that boost libraries don't need a c_str() method since this can >come from the string() (or str()) method. There are obvious advantages to common naming conventions. But "str" vs "string" isn't as clear-cut as it would be if we were starting with an empty page. "string" is better because it is more explicit and less prone to misunderstanding. But many existing libraries (boost and non-boost) use "str". Actually, that's one of the problems with "str". It is not uncommon to see it used for functions which return char*'s, std::strings, or homebrewed types, and that's confusing. That was part of my rationale for chosing "string" as the name in the filesystem library. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: tokenizer comments
At 01:58 PM 6/20/2003, Alisdair Meredith wrote: >Another comment on the docs is that around half the examples do not >indicate the expected result, which makes it hard for me when look >between the examples to quicky find the variation I am after. The >examples are well chosen to use a similar data set, but trying to work >out which iterators will skip whitespace, which only return values, >feels very 'try it and see'. Care to suggest a docs patch? --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS and gcc
>I've just written the following. It (correctly) fails for MSVC 6.5 and gcc 3.2 for >cygwin, >but I cannot test it in a conforming compiler. I had to modify it a little to make it conforming code, but it's now in cvs. Thanks, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Preparing 1.30.1 Release
> I have put a diff of the changes between Version_1_30_0 and RC_1_30_0 > at http://www.boost-consulting.com/diffs-1-30-1.txt. These will be > the changes that go into the Boost 1.30.1 release. Will the > authors/maintainers of the following libraries please post a brief > summary of the fixes that were applied? > > smart_ptr > lexical_cast > function > lambda > MPL > type_traits The one type_traits change is hardly worth mentioning - it just updates the EDG version number for which a specific fix is required (is_base_and_derived fix for EDG versions prior to 243). John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Preparing 1.30.1 Release
David Abrahams <[EMAIL PROTECTED]> writes:
| I have put a diff of the changes between Version_1_30_0 and RC_1_30_0
| at http://www.boost-consulting.com/diffs-1-30-1.txt.
These are the changes we (LyX Developers) have made to boost 1.30.0 to
make it compile with gcc 3.3 without warnings, as well as using a
different string class than std::string¹.
If appropriate, please include these changes in 1.30.1.
¹ Actually we are using both a lyx::string and std::string at the same
time only one of which is brought into the global namespace.
Index: boost/config/compiler/gcc.hpp
===
RCS file: /cvsroot/boost/boost/boost/config/compiler/gcc.hpp,v
retrieving revision 1.15
diff -u -p -r1.15 gcc.hpp
--- boost/config/compiler/gcc.hpp 30 Jan 2003 18:13:55 - 1.15
+++ boost/config/compiler/gcc.hpp 2 Aug 2003 11:10:34 -
@@ -58,8 +58,8 @@
# error "Compiler not configured - please reconfigure"
#endif
//
-// last known and checked version is 3.2:
-#if (__GNUC__ > 3) || ((__GNUC__ == 3) && (__GNUC_MINOR__ > 2))
+// last known and checked version is 3.3:
+#if (__GNUC__ > 3) || ((__GNUC__ == 3) && (__GNUC_MINOR__ > 3))
# if defined(BOOST_ASSERT_CONFIG)
# error "Unknown compiler version - please run the configure tests and report the results"
# else
Index: boost/format/parsing.hpp
===
RCS file: /cvsroot/boost/boost/boost/format/parsing.hpp,v
retrieving revision 1.16.2.1
diff -u -p -r1.16.2.1 parsing.hpp
--- boost/format/parsing.hpp 19 Mar 2003 17:05:20 - 1.16.2.1
+++ boost/format/parsing.hpp 2 Aug 2003 11:10:34 -
@@ -361,7 +361,7 @@ void basic_format ::parse(co
// A: find upper_bound on num_items and allocates arrays
i1=0;
-while( (i1=buf.find(arg_mark,i1)) != string::npos )
+while( (i1=buf.find(arg_mark,i1)) != string_t::npos )
{
if( i1+1 >= buf.size() ) {
if(exceptions() & io::bad_format_string_bit)
@@ -385,7 +385,7 @@ void basic_format ::parse(co
typename string_t::size_type i0 = i1;
bool special_things=false;
int cur_it=0;
-while( (i1=buf.find(arg_mark,i1)) != string::npos )
+while( (i1=buf.find(arg_mark,i1)) != string_t::npos )
{
string_t & piece = (cur_it==0) ? prefix_ : items_[cur_it-1].appendix_;
Index: libs/regex/src/c_regex_traits.cpp
===
RCS file: /cvsroot/boost/boost/libs/regex/src/c_regex_traits.cpp,v
retrieving revision 1.36
diff -u -p -r1.36 c_regex_traits.cpp
--- libs/regex/src/c_regex_traits.cpp 21 Feb 2003 12:43:49 - 1.36
+++ libs/regex/src/c_regex_traits.cpp 2 Aug 2003 11:10:50 -
@@ -514,9 +514,9 @@ void BOOST_REGEX_CALL c_traits_base::do_
if(std::isxdigit(i))
class_map[i] |= char_class_xdigit;
}
- class_map['_'] |= char_class_underscore;
- class_map[' '] |= char_class_blank;
- class_map['\t'] |= char_class_blank;
+ class_map[(unsigned char)'_'] |= char_class_underscore;
+ class_map[(unsigned char)' '] |= char_class_blank;
+ class_map[(unsinged char)'\t'] |= char_class_blank;
for(i = 0; i < map_size; ++i)
{
lower_case_map[i] = (char)std::tolower(i);
Index: libs/regex/src/cpp_regex_traits.cpp
===
RCS file: /cvsroot/boost/boost/libs/regex/src/cpp_regex_traits.cpp,v
retrieving revision 1.30
diff -u -p -r1.30 cpp_regex_traits.cpp
--- libs/regex/src/cpp_regex_traits.cpp 16 Sep 2002 11:54:41 - 1.30
+++ libs/regex/src/cpp_regex_traits.cpp 2 Aug 2003 11:10:50 -
@@ -241,7 +241,7 @@ message_data::message_data(const s
#endif
for(std::size_t j = 0; j < s.size(); ++j)
{
- syntax_map[s[j]] = (unsigned char)(i);
+ syntax_map[(unsigned char)s[j]] = (unsigned char)(i);
}
}
--
Lgb
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: GUI/GDI template library
--- Bohdan <[EMAIL PROTECTED]> wrote: > > "E. Gladyshev" <[EMAIL PROTECTED]> wrote in message > > but which approach is better for GUI lib. I believe that I've made a strong case for ImplTraits for GUI library. In the win32 case, the compilation time penalties would be of the same order as including windows.h Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: the boost::signal sample crashes
"E. Gladyshev" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Have you built the signals library multi-threaded or > > single threaded and > > Whatever the default build is. > > > > are you building an application of the same sort? > > The application is set to use multi-thread run-time > libraries and MFC.DLL. Check boost::signal library compile/link options as well. It looks like commons source of problems. Would it be difficult to add automatic library selection for boost::signal ? I mean library suffixes and comment pragmas as in boost::regex. Honestly ... i'd like to see such build system in all boost non-template libs :) IMHO, it is very convenient. regards, bohdan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: GUI/GDI template library
--- Bohdan <[EMAIL PROTECTED]> wrote: > "E. Gladyshev" <[EMAIL PROTECTED]> wrote in message > > > I think that any industry standard TEMPLATE > library > > should be designed in terms of modern C++. The > > compilation time should NOT be considred as an > issue. > > Compilers are getting better, computers faster... > > boost should be setting programming standards not > > laging behind trying to accomodate some specific > h/w > > requirements. > > You forgot one small thing ... development time > is very serious issue for programming. > If my work will be 10% coding/thinking and 90% > drinking coffee ... i prefer change my profession > to coffee taster :) Development speed is even > more important for developing GUI programs. > In most cases GUI program starts as something > small and can be developed/supported during > many years ... > Do you want to write excellent, > scalable, flexible, ... library that nobody wants > to use just because current computer-compiler > technology is not good enough for your lib ? >IMHO (not offensive) your ideas are too tied to > "new ideas" fashion in modern c++. They(ideas) are > good, very good unfortunately not always. > Please have mercy for people using > poor modern compilers :). > Cool, Bohdan! It is a great reply. I enjoyed it I really did. I agree, but we should be pushing these compiler guys a bit, should not we? :) Ok, I am going to get some beer... Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: GUI/GDI template library
"E. Gladyshev" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > --- Edward Diener <[EMAIL PROTECTED]> wrote: > > E. Gladyshev wrote: > > > The pImpl technique is an idiom for hiding the > > private methods and data > > members of a class from the view of the user of that > > class. > > By using a predefined ImplTraits you are actually > achiving the same pImpl hiding effect. The user can > just use a predefined ImplTraits class w/o any idea > about its methods. He didn't mean just user interest , but completely hiding platform dependent implementation and even interface from compiler. Less dependencies and yes ... again less compile time. With your approach you can hide only implementation of traits in cpp file. PImpl and ImplTraits approaches both have pros and cons. Question is not "what is good for modern c++" but which approach is better for GUI lib. regards, bohdan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
--- David Abrahams <[EMAIL PROTECTED]> wrote: > "E. Gladyshev" <[EMAIL PROTECTED]> writes: > > Is MPL a modern TEMPLATE library, in your opinion? > I ask because compilation time is a very serious > issue in the design > of MPL. In my opinion MPL is a great example of a tool for creating modern C++ programs/libraries. The h/w and compiler designers will have to deal with the compilation time issues. It is their job. When you are writing music the last thing that you should be thinking about is how these guys are going to play it :). > IMO it's nutty to think that people won't use every > bit of > compilation bandwidth they can stand, once they > start to do > computation at compile time. Why should it be any > different from > cycles at runtime? By people you mean developers. The developer's time is a tricky issue. If you have a better library with a long compilation time and not so good library with a better compilation performance, which one do you choose? If you choose the bad library, you can be saving on the compilation time but loosing on the development time. How do you count it? Do you care how much effort/time did it take to build you car? I don't. Personally I care about creating a beauty, not the compilation time. > In many ways, the more modern a C++ library is, the > more of a concern > compilation times have to be. I agree, but the other guys have to deal with it. However you still can be saving on the development time. By the development time, I mean the average development time of the industry. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: GUI/GDI template library
"E. Gladyshev" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Are you aware that the pImpl idiom is used for many > > different things > > I think that any industry standard TEMPLATE library > should be designed in terms of modern C++. The > compilation time should NOT be considred as an issue. > Compilers are getting better, computers faster... > boost should be setting programming standards not > laging behind trying to accomodate some specific h/w > requirements. You forgot one small thing ... development time is very serious issue for programming. If my work will be 10% coding/thinking and 90% drinking coffee ... i prefer change my profession to coffee taster :) Development speed is even more important for developing GUI programs. In most cases GUI program starts as something small and can be developed/supported during many years ... Do you want to write excellent, scalable, flexible, ... library that nobody wants to use just because current computer-compiler technology is not good enough for your lib ? IMHO (not offensive) your ideas are too tied to "new ideas" fashion in modern c++. They(ideas) are good, very good unfortunately not always. Please have mercy for people using poor modern compilers :). regards, bohdan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: GUI/GDI template library
--- Edward Diener <[EMAIL PROTECTED]> wrote: > E. Gladyshev wrote: > The pImpl technique is an idiom for hiding the > private methods and data > members of a class from the view of the user of that > class. By using a predefined ImplTraits you are actually achiving the same pImpl hiding effect. The user can just use a predefined ImplTraits class w/o any idea about its methods. > appeal for me. It makes the user of the class see > only what is relevant in > the class, The reason of hiding something from the user is not enough to throw away all the benefits of the ImptTraits idiom. See my discussion with Douglas Gregor about boost::thread library. I strongly believe that it needs to be overwritten. >while putting the implementation details > of the class interface > somewhere else. That it also speeds up compilation > by not having the class, > as the compiler sees it, change when the internal > class as represented by > its private pImpl pointer changes, is a side benefit > to it but not one I > consider overridingly important. I agree that it > achieves little other than > an aesthetic view of class internals and a speed up > in build times when a > class's implementation, as opposed to its end-user > interface, changes. As > such there is no pragmatic design reason why it is > necessary. These are the > major reasons, as I understand it, why the pImpl > idiom is generally used and > why I have used it. But there may be other reasons. Again see my discussin with DG. > I don't understand what this has to do with modern > C++ as you see it. But I > think that your view of modern C++, a term perhaps > taken from Mr. > Alexandrescu's fine book on template programming and > metaprogramming > techniques, It is a very good example or modern C++. > I only hope > that you don't get into > the habit of seeing all of modern C++ programming as > template programming > only, and view all other programming and design > idioms from that > perspective. In my view, modern C++ is template programming plus programming data types for these templates. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
