April 2004 - Boost - lists.boost.org

Re:RE: [boost] shared pointer serialization
by Robert Ramey 29 Apr '04

29 Apr '04

Gennadiy Rozental wrote: > This is about how I expect it to work. But from this description it's > unclear: > 1. Why would you need to save counter into archive? After all value 10 > has nothing to do with resulting 5. > 2. Why would you need direct access to shared_ptr counter? After all > using regular shared_ptr copy would automatically bump it to proper value. I remember my initial implementation just restored the original state. Thinking better of it I made a change to the current system. Now that you mention it, it wouldn't seem to need the counter anymore. Just for laughs I commented out the serialization of the counter and if failed to build the test. I'll have to look into it. Robert Ramey

2 1

Re:[boost] Re: Serialization Formal Review #2
by Robert Ramey 29 Apr '04

29 Apr '04

Message: 13 Fredrik Blomqvist > * What is your evaluation of the implementation? > As I mentioned in my previous review I would like to see it handle most of > the STL and core boost components "out of the box". I believe all STL is handled. Serialization of other boost components will have to be the responsibility of their authors or others. > In particular I think the smart_ptrs (including auto_ptr) should have > core-support from the serializer, even special cased if necessary (similar > to boost::bind etc). I believe the current library is capable of implementing serialization for all boost components. Much effort was expended to that the library would not have to have special code for any serialization or archive type. In fact, my interest is just the opposite. I would like to see a significant part of the library moved outside. Anyone who wants to volunteer to take responsibility for any of the component please let us know. The library would be improved by making it smaller. > The code to serialize std::auto_ptr could easily be copied to the official > directory for example. There has been some discussion of where the serialization code for other boost libraries should reside. I don't have strong feelings about this other than I would prefer that it reside outside the serialization library itself. The only exception I would make is for the STL serialization which has no where else in boost to reside and it has a "special" status as and official C++ library. > Regarding shared_ & weak_ptr. If the implementation path Robert outlines > in the documentation is to be used I guess an official patch to > shared_count is necessary. Would be interesting to hear what the smart > pointer experts think. I agree - the silence is deafining. I know there are applications that use my smart pointer serialization code right now. I implemented and tested it but I don't really know for a fact that it addresses all aspects that need to be addressed such as exception safety, threading, and who knows what else. > Otherwise, I still think the solution I outlined in my previous review > that doesn't require modifying shared_ptr could be considered. Downside > being that it most likely adds a special-cased codepath to the serializer, > but as I said I think it would be worth it. I would hope that the developer's maintaining shared pointer will address this. putting special case code inside the serialization library would be a serious mistake. Between code, tests, and documentation, its approaching 30,000 lines. > The code is nicely written altough complex. Highly nested template code > and lots of mpl. All compile-time checks and further factorizations are > valuable. > Nitpick: serialization/scoped_ptr.hpp seems to have a typo. An extra > #pragma once is present outside the #ifdef (_MSC..) block. It also > includes serialization/pfto.hpp but doesn't seem to use it. Thanks - I love picking these nits. Its easy and satisfying - really. > * Parts of the library that might become standalone boost libraries > The library already provides good separation of components. tatic_warning, > strong typedef, pfto, stack_allocate etc are all given candidates that > would just need better documentation and (fast-track?) reviews. A little bit more is going to be required. They've been tested in the context of serialization and that's OK. I think they need to be more polished and that's a little more work than it first appears. Also a separate review would probably fine tune their interface, implementation and capability. * What is your evaluation of the documentation? > I would also like to see an improved reference documentation that clearly > states the requirements on the types/concepts involved. Hmmm - that seems pretty unanimous - pretty much a first for boost as far as I know. > I support the separation of documentation (and implementation) of other > boost components that like to support serialization. A simple index with > links would suffice I think but most importantly a _consistent_ structure > should be agreed upon which new components can follow. I followed the boost document on how to write documentation. The only wrinkle I added was the right hand index/contents window. I'm pretty pleased with this. I would appreciate VC7.1 project files for the examples and tests though. > One of my tests added support for the STL container adaptors std::stack, > queue and priority_queue. I think direct support for them could be > convinient since they hide the native containers. I attach my > implementation. Feel free to comment I took a short look. The name stack_hack sort of begs some sort of comment. The main thing is that any component of this type has got to be submitted with a test. Thanks for taking the time to study the library and submit a review. Robert Ramey

3 5

Appology
by Mohammed Iqbal 28 Apr '04

28 Apr '04

Hi.. Sorry because I didn't reply to you about my library. I felt down after three da days from my last message. My head hit the wall. I suffered very much from a headache, pain in my stomach ( ifelt that I need to vomit but I couldn't), and something wrng with my eyes. Till now I still suffer from these things but not very much. I can't tell you about my library now because of many reasons: 1. It is not a library meant for distribution at least for now. Instead, it is a pert of a large project that I am working alone on. 2. It is not complete now because it is going through changing everyday. 3. It is not totally tested. When I told you about context-oriented programming, I didn't mean what Gassassnenko wrote because a context in my technology differs completely from context in his paper. My technology is for video game creation. It consists of many components: 1. A process model for analysis, design, development, and testing. It is very powerfull because it is designed in the first place for this purpose. It is based on experiences of many researches, studies, surveys, etc. But it is not applied for real video game development. 2. A software tool for game creation that let's you develop a complete game without using any external library or software. You can do your animation, develop your code using the integrated language which is based on C++ as the main root but it is not C++ and many changes have been applied to get rid of many features we don't want, etc. The software also uses the above process for game creation. 3. Many other components. My technology is using something that you don't imagine at all. I will not give any information untill I finish eveything. I used Cubism of Picasso. Strange?? The development is done in the Medium ( a 3D space) that contains many contexts. Each context can be anything like, a function, a class, a template, a set of functions, etc. The contexts deals with each other and with the Medium through slots. Slots can accept anything like a function, a type, a class, etc. That's all for now. Mohammed

1 0

[ann] log viewer
by John Torjo 28 Apr '04

28 Apr '04

Dear boosters, Since most of us use some sort of logging, I've developed a free program that allows simple viewing/filtering of log files (for Windows). The really cool thing is that you can monitor files (you can have multiple filters for the same file) while your application is writing to it. I think it's quite simple to use and very useful. Anyway, to make a long story short, if you're interested: http://www.torjo.com/logview/EasyLogView.exe (download) http://www.torjo.com/logview/screenshot1.jpg http://www.torjo.com/logview/screenshot2.jpg It's at a very early stage, so I look forward to your feedback (menu: Help/Send Feedback ;)) Best, John

2 4

RE: [boost] shared pointer serialization
by Rozental, Gennadiy 28 Apr '04

28 Apr '04

> > what if I do not save all of the shared_ptr to the same object? > > Here is a scenario: > > a) a shared_ptr exists and it points to and object which is > pointed by 9 other shared_ptrs. > > b) we create and archive and save some objects. The set > objects saved only includes 5 of the shared_ptrs out of the > possible 10. > > c) later when we load, we create 5 new shared_ptr and one new > object. Object tracking guarantees that only one shared > object is created. As each new shared pointer is loaded, the > shared count is incremented. So the new shared pointer is > not identical to the original - its equal to 5. > > d) the process (almost?) guarantees that all the shared_ptr > are valid in that they all point to shared object and the > shared_count is maintained to be the correct number. The > intention is that this process be exception safe > - I'm not sure that this intention has been realized. This is about how I expect it to work. But from this description it's unclear: 1. Why would you need to save counter into archive? After all value 10 has nothing to do with resulting 5. 2. Why would you need direct access to shared_ptr counter? After all using regular shared_ptr copy would automatically bump it to proper value. Gennadiy.

1 0

A nice library
by Mohammed Iqbal 28 Apr '04

28 Apr '04

This seems like an interesting library: http://www.southern-storm.com.au/libjit.html It isn't even at beta yet, but it is probably something to watch. Mohammed

1 0

shared pointer serialization
by Robert Ramey 28 Apr '04

28 Apr '04

Rozental, Gennadiy wrote: > There is another counter to direct counter using (I just think out loud - > it may be that you ok): what if I do not save all of the shared_ptr to the > same object? What will happened once they will get restored? Wouldn't it > cause memory leak? > I do realize that any other solution would be more complicated, but I > think we should go for it. I don't really understand what's being said here but I can shed a little more light on the way serialization is implemented right now. It's also used as a case study in the documentation and described in detail. > what if I do not save all of the shared_ptr to the same object? Here is a scenario: a) a shared_ptr exists and it points to and object which is pointed by 9 other shared_ptrs. b) we create and archive and save some objects. The set objects saved only includes 5 of the shared_ptrs out of the possible 10. c) later when we load, we create 5 new shared_ptr and one new object. Object tracking guarantees that only one shared object is created. As each new shared pointer is loaded, the shared count is incremented. So the new shared pointer is not identical to the original - its equal to 5. d) the process (almost?) guarantees that all the shared_ptr are valid in that they all point to shared object and the shared_count is maintained to be the correct number. The intention is that this process be exception safe - I'm not sure that this intention has been realized. A fuller explanation can be found at: http://www.rrsd.com/boost/libs/serialization/doc/shared_ptr.html Robert Ramey.

1 0

Re:[boost] Re: serialization and MFC
by Robert Ramey 28 Apr '04

28 Apr '04

Eric Niebler wrote: > Forgive the possibly naive question -- I have never used the > serialization library, but I have used MFC serialization. I am curious > if the boost serialization library can be made backwards-compatible > with MFC serialization; that is, if I have an old application that > uses MFC serialization, would it be possible to switch to the boost > serialization library and still have the ability to read old (MFC) > archives? > > I'd like to know: > - if it's possible > - how hard it would be (would it require reverse-engineering the > MFC archive format? is that format stable? documented?) > - what the advantages of switching are The easiest way to switch from MFC (or any other systems is to do the following): a) add boost serialization to your code. b) when you open an archive - currently MFC, use code like the following: open stream read the first part of the stream if doesn't contain a boost serialization signature invoke MFC de-serialization else invoke boost de-serialization. c) when you save an archive - just invoke boost serialization. In this way, all your old files will be compatible and will gradually be converted to the new system. The new archives can use all the new facilities without compromise. This is much easier, and forward looking than trying to adapt to an old format wich likely isn't rich enough to support the new facilities. Robert Ramey

1 0

[Boost-bugs] [ boost-Support Requests-943555 ] Path.cpp:85: error: `portable_posix_name' undeclared in name
by SourceForge.net 28 Apr '04

28 Apr '04

Support Requests item #943555, was opened at 2004-04-28 01:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=943555&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Path.cpp:85: error: `portable_posix_name' undeclared in name Initial Comment: i am compiling a game and i get thru ./configure but when i goto make i get this error Path.cpp:85: error: `portable_posix_name' undeclared in namespace `boost::filesystem' i get simmilair errors on 85, 99 and 113 saying portable_posix_name is undeclared ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=943555&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

problems with boost::thread
by "Magomed Abdurakhmanov 28 Apr '04

28 Apr '04

Hello. I have some troubles with boost::thread, and think they are important: 1. condition::timed_wait dangerous to use, because waiting delay specified as time when we are will stop waiting. So this is very surprising when system time is changed! I guess that waiting for specified delay is much more safe than waiting until some time arrive. For example try launch the program bellow and change system time backward (to past) when it's working. I have tested this under win32 + msvc7 // ------------------------------- boost::condition cvar; boost::mutex monitor; void thread1() { for(;;) { boost::mutex::scoped_lock lock(monitor); boost::xtime xt; boost::xtime_get(&xt, boost::TIME_UTC); std::cout << "now: " << xt.sec << std::endl; xt.sec += 5; std::cout << "will wait until: " << xt.sec << std::endl; if (!cvar.timed_wait(lock, xt)) std::cout << "timed out!" << std::endl; std::cout << "next step" << std::endl; } } int main(int argc, char* argv[]) { boost::thread thrd1(&thread1); thrd1.join(); return 0; } // ------------------------------- 2. The secound trouble is that the thread function has catch(...) at the root and when unhandled exception in thread thrown, it's just silently eated and thread stopped. But the process stay alive, and now nothing about it. And ever wrong that catch(...) under VC6 will catch OS exceptions. p.s. sorry for so bad english

8 14