Google Summer of Code -- Call for Participation / Schedule
All - (cross-posted to the user list so the larger Boost community sees this) Readers of the developer list may have seen that Boost has been accepted as a participating organization. See http://code.google.com/soc/boost/about.html for the initial Boost Summer of Code page. Now for the hard part. We have a fairly tight schedule to get organized on project proposals and student applications: May 1, 2006: - Application period opens for student proposals May 8, 2006: -Student proposals due by 17:00 Pacific Daylight Time If you are interested in mentoring or doing a project please let us know as soon as possible. If you have project ideas, please update: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summer... If you want to mentor or are planning a student application please either post to the list or to the moderators list (see http://www.boost.org/more/moderators.html for details). Thx! Jeff
The Associative Containers project can refer also to Shmem, since Shmem has implemented the full ordered vector family (flat_map, flat_set, flat_multimap and flat_multiset) for shared memory (these containers work also with std::allocator). Another option is to take those containers out of Shmem (they have minor dependencies with Shmem framework) and present them as general purpose containers that also are useful for shared memory/memory mapped files. Like boost::unordered_xxx family, I would like to have just one container in Boost without duplicating it in other libraries. The bad news is that Shmem flat_xxx containers are not documented, but it's not difficult to do it since they have the same interface as std::map/set family. The hard part is the portability to non-conforming compilers like VC6, but I think there are utilities in Boost to workaround these problems. Regards, Ion
Ion Gaztañaga wrote:
The Associative Containers project can refer also to Shmem, since Shmem has implemented the full ordered vector family (flat_map, flat_set, flat_multimap and flat_multiset) for shared memory (these containers work also with std::allocator).
Please update the pagen then.
Another option is to take those containers out of Shmem (they have minor dependencies with Shmem framework) and present them as general purpose containers that also are useful for shared memory/memory mapped files. Like boost::unordered_xxx family, I would like to have just one container in Boost without duplicating it in other libraries.
But doesn't Shmem (why is this not called Boost.Shared Memory?) duplicate all containers?
The bad news is that Shmem flat_xxx containers are not documented, but it's not difficult to do it since they have the same interface as std::map/set family. The hard part is the portability to non-conforming compilers like VC6, but I think there are utilities in Boost to workaround these problems.
It's not good use of student time to do porting work. People need to move away from ancient compilers. -Thorsten
Thorsten Ottosen(e)k dio:
Ion Gaztañaga wrote:
The Associative Containers project can refer also to Shmem, since Shmem has implemented the full ordered vector family (flat_map, flat_set, flat_multimap and flat_multiset) for shared memory (these containers work also with std::allocator).
Please update the pagen then.
Done.
Another option is to take those containers out of Shmem (they have minor dependencies with Shmem framework) and present them as general purpose containers that also are useful for shared memory/memory mapped files. Like boost::unordered_xxx family, I would like to have just one container in Boost without duplicating it in other libraries.
But doesn't Shmem (why is this not called Boost.Shared Memory?) duplicate all containers?
It's called Boost.Interprocess now, but the I have still a lot of work to do to publish the first version. It duplicates all the containers but normal STL-like containers can be made compatible with shared memory only using the allocator::pointer typedef internally and using allocator::contruct/destroy to create elements. The last version of boost::unordered_xxx is compatible with shared memory.
The bad news is that Shmem flat_xxx containers are not documented, but it's not difficult to do it since they have the same interface as std::map/set family. The hard part is the portability to non-conforming compilers like VC6, but I think there are utilities in Boost to workaround these problems.
It's not good use of student time to do porting work. People need to move away from ancient compilers.
I agree. Regards, Ion
Ion Gaztañaga wrote:
Thorsten Ottosen(e)k dio:
Ion Gaztañaga wrote:
The bad news is that Shmem flat_xxx containers are not documented, but it's not difficult to do it since they have the same interface as std::map/set family. The hard part is the portability to non-conforming compilers like VC6, but I think there are utilities in Boost to workaround these problems. It's not good use of student time to do porting work. People need to move away from ancient compilers.
I agree.
And more than that, by the time interprocess is included I think we will be dropping support for VC6 as an overall 'Boost policy'. And even now it's your option not to support non-compliant compilers for your library. My view is that for new libraries, if someone is really motivated to have your library, they can help put in the labor to help port it to a brain-dead compiler. Jeff
Jeff Garland wrote:
If you want to mentor or are planning a student application please either post to the list or to the moderators list (see http://www.boost.org/more/moderators.html for details).
FYI... Mentors sign up here: http://code.google.com/soc/mentor_step1.html And...
Hello Administrators,
Please go through your mentor apps and accept/reject all pending applications. If you haven't accepted a particular mentor for your organization, s/he will not be able to review and rank student applications once they start coming in on Monday.
Cheers, LH
Leslie Hawthorn Open Source Program Coordinator Google Inc.
So if you want to be a mentor you need to sign up ASAP. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Hi there I've just added another project idea: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summer... I guess this needs to be approved somehow. Feel free to comment/suggest/bash... Thanks, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
participants (5)
-
Andreas Huber -
Ion Gaztañaga -
Jeff Garland -
Rene Rivera -
Thorsten Ottosen