- Boost - lists.boost.org

[ptr_container] metrowerks problems
by Thorsten Ottosen 02 May '05

02 May '05

Hi All, I haven't got a metrowerks compiler and can't fix the problems easily; so I *need* somebody to help me. The alterantive is that I will have to mark them as unusable. Please contact me if you would like to help and need directions. Thanks -Thorsten -- Thorsten Ottosen ---------------------------- www.dezide.com http://www.cs.aau.dk/index2.php?content=Research/mi www.boost.org www.open-std.org/JTC1/SC22/WG21/

3 18

libs/libraries.htm
by Stefan Strasser 02 May '05

02 May '05

I'm reading about the libs that got accepted into 1.33 and noticed that ptr_container is missing from libs/libraries.htm -- Stefan Strasser

1 0

Re: [boost] Re: Re: Formal Review: FOREACH macro
by brangdon＠cix.compulink.co.uk 02 May '05

02 May '05

In-Reply-To: <d55ii6$74o$1(a)sea.gmane.org> gennadiy.rozental(a)thomson.com (Gennadiy Rozental) wrote (abridged): > 1. Not to mention the collection type > As Eric pointed out - you may not know one. But even if you do writing > std::vector<mytypes<my_param> > several types for every loop I need is > tidies. I generally solve that problem with a typedef. Most of the time the collection is a class, the typedef is a member of that class, and the iterating code is a member function of that class. So the word "iterator" is all I need. If your loops are so complex you would benefit from BOOST_FOREACH, I think you'd also benefit from simplifying them, separating concerns a bit more, etc. > Since you agree that looping is quite basic need - simplifying it is a > worthy task. I agree it's a worthy ambition, but this doesn't simplify them. It makes them much more complex and then tries to hide the complexity behind a macro. > As for the complexity it's required to support some corner > cases situation. You could always disable it with defines (that what I > am going to do). Adding #defines is adding complexity. -- Dave Harris, Nottingham, UK.

2 1

RE: [boost] Boost Logging Library ( + Mini Update on proposed boost.profile )
by Brian Braatz 02 May '05

02 May '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of James Fowler > Maksym Motornyy wrote: > > > During development of last product I was missing good C++ logging > > library like one available in Java. I had to write it myself. Does > > somebody think that it will be useful to have it in Boost? Or there is > > such one in development? > > Several projects related to logging have been mentioned recently (see > message below). I'm about to throw another in the ring which could be > used for primitive logging, although it's primary focus lies elsewhere. > [James Fowler Writes:] > The basic concept of logging is simple enough, but the wide range of > useful implementation variations makes it really hard to envision a > solid "one-size-fits-all" system. It may make sense to start working on > a common set of patterns for a logging system interface, which could be > used to consistently encapsulate many different implementations. This > same issue came up in a discussion with Brian Baatz on profiling. > Developing such an interface should be challenging enough, even without > specifying implementation, but it's a more manageable first step. It > also seems like a good way to foster cooperation among the various > projects while allowing a healthy level of diversity, ideally > improving the consistency over time for "early-adopters" of specific > projects. [Brian Braatz Writes:] (Thank you James for remembering I was working on this :) ) Sorry guys, have been OFF LIST for awhile here. Was busy integrating profiling into a very large application. I am working towards getting a status report out to this list here (hopefully) within this week. This will include What I added to the profiler What production tests we did What was learned by doing that Next steps for proposed boost.profile What I have learned in this process: Profiling EVENTS and LOGGING those events together is what is necessary to get the whole picture "Programmer" level logging is different from profile event logging What I see the Logging Library doing is connecting the dots with programmer supplied information Logging events and connecting them (mentally) with the profile report fills in the missing blanks for the developer for performance centered thinking Logging programmer detailed messages is more for finding bugs Logging events relative to the profiler, is more for performance related analysis What is also interesting, while I have not done a detailed review of the logging library, we seem to have done some things similarly. (there is about 5-10% overlap) Again, what profiling \ event tracing is trying to do is different I think than what the Logging Library is trying to do, there is some overlap. My State: I have integrated the profiler and things I have added to the profiler into our application In doing so, the library on top of that is using our internal (not boost) libraries for support My next step here is to take what I learned from doing this and combine them into one library that is boostified Additionally, I need to (this week) keep everyone in the loop by submitting a report.

1 0

RE: [boost] Boost Logging Library
by Brian Braatz 02 May '05

02 May '05

Questions: (in a nutshell) how does the one in Java work? What do you like about it? Thanks Brian > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Maksym Motornyy > Sent: Wednesday, March 16, 2005 3:56 AM > To: boost(a)lists.boost.org > Subject: [boost] Boost Logging Library > > During development of last product I was missing good C++ logging > library like one available in Java. I had to write it myself. Does > somebody think that it will be useful to have it in Boost? Or there is > such one in development? > > Sincerely yours, > Maksym Motornyy. > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

FOREACH review - last day
by Gennadiy Rozental 02 May '05

02 May '05

Hi, Today is a last day for the FOREACH macro review submissions. So if you have anything to say on the subject you just may catch this train. I will accept votes till 23:59 EST Monday. Gennadiy

1 0

RE: [boost] Re: [website] Oh the fun..
by Martin Bonner 02 May '05

02 May '05

----Original Message---- From: Rene Rivera [mailto:grafik.list@redshift-software.com] Sent: 28 April 2005 03:37 To: boost(a)lists.boost.org Subject: Re: [boost] Re: [website] Oh the fun.. > Eelis van der Weegen wrote: >> I think this layout makes unreasonable assumptions about the browser > > Unreasonable for whom? > >> window width, and looks terrible when viewed in a slightly less wide >> browser window. >> >> Here's an example screenshot: http://www.xs4all.nl/~weegen/ss.png >> >> Note that this does not just affect people who use 800x600 or smaller >> resolutions. > > 1. That screenshot is less than 800 pixels wide. So? Eelis explained WHY he uses less than 800 pixels for his browser. > 2. I think just about all web designers agree that 800x600 is the > minimum one should design for at this time. Hmm. How about all (boost) USERS? >> As for the links, I agree with Victor; changing link formatting is >> yet another symptom of overly eager webdesigners' trying to control >> every last pixel on the screen because their precious design >> "depends" on it, while breaking usability for users who use a less >> common configuration. > > As I said in the other post.. It's not. It's just not a possibility to > accommodate user level settings without also abandoning design almost > completely. The best we can hope for is to design in enough > flexibility to make the majority of users happy. So why do you need to specify the background colour? I haven't looked at the source, but it looks white on my machine which is the default for my browser. If you don't specify the background colour or the font colour, then the link colour will match nicely. >> The website should just provide structured content and leave it up to >> the user's browser and preferences to do the final formatting. > > That's a nice dream.. And with the current arrangement you can attain > it. The current design is entirely CSS based. Which means that you > can turn it off, or use your own design. -- Of course that's assuming > your browser will let you. It's a lot of work to define a new CSS for boost - why not just use the user's defaults? -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

6 6

[python] missing image in docs.
by John Maddock 02 May '05

02 May '05

The python tutorial references the image libs/python/doc/tutorial/doc/images/jam.png which is not in cvs, any chance of a fix? Thanks, John.

2 1

[property_map] Broken style sheet in property_map docs.
by John Maddock 02 May '05

02 May '05

The property_map docs reference the style sheet libs/property_map/doc/default.css, which does not actually exist in cvs, should this use the boost.css, or is there a missing library specific style sheet waiting for checkin? Thanks, John.

2 1

BGL documentation bugs
by Felipe Magno de Almeida 02 May '05

02 May '05

in the file: http://www.boost.org/libs/graph/doc/quick_tour.html there's an extra comma at the end of the declaration: Edge edge_array[] = { Edge(A,B), Edge(A,D), Edge(C,A), Edge(D,C), Edge(C,E), Edge(B,D), Edge(D,E), }; And a little after appears this line: Graph g(edge_array, edge_array + sizeof(edge_array) / sizeof(E), num_vertices); but I think the correct should be: Graph g(edge_array, edge_array + sizeof(edge_array) / sizeof(Edge), num_vertices); Since the first gives a segmentation faul and I think doesnt make too much sense to use sizeof(E)... -- Felipe Magno de Almeida UIN: 2113442 email: felipe.almeida at ic unicamp br, felipe.m.almeida at gmail com, felipe at synergy com I am a C, modern C++, MFC, ODBC, Windows Services, MAPI developer from synergy, and Computer Science student from State University of Campinas(UNICAMP). To know more about: Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br current work: http://www.mintercept.com "There is no dark side of the moon really. Matter of fact it's all dark."

2 1