Hello everyone, Since the generated documentation isn't currently included in the snapshots, I've temporarily made it available here: http://www.calamity.org.uk/1.36/ Hopefully, the documentation should be integrated with the beta site soon after the beta release. Daniel
Hi, I came across this wiki discussion: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSpiritCX... Did this every move forward or materialize? Thanks in advance. Regards, Bruce
I'm noticing that the exception lib does not appear in the categorized list of libraries, only in the alphabetical list. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode On Sat, Jul 26, 2008 at 4:34 AM, Daniel James <daniel_james@fmail.co.uk> wrote:
Hello everyone,
Since the generated documentation isn't currently included in the snapshots, I've temporarily made it available here:
http://www.calamity.org.uk/1.36/
Hopefully, the documentation should be integrated with the beta site soon after the beta release.
Daniel _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
2008/7/26 Emil Dotchevski <emil@revergestudios.com>:
I'm noticing that the exception lib does not appear in the categorized list of libraries, only in the alphabetical list.
Sorry, I assumed you'd add it to whatever categories you thought best. I've added it to the miscellaneous section (you won't see it online until tomorrow). If you want to change this, go ahead (as long as you do it before the deadline). Daniel
Thanks Daniel! Actually, I am not sure what's the best category for this library. It's a low level lib, so perhaps it should go under utility, miscellaneous doesn't seem descriptive enough. Any thoughts? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode On Sat, Jul 26, 2008 at 11:48 AM, Daniel James <daniel_james@fmail.co.uk> wrote:
2008/7/26 Emil Dotchevski <emil@revergestudios.com>:
I'm noticing that the exception lib does not appear in the categorized list of libraries, only in the alphabetical list.
Sorry, I assumed you'd add it to whatever categories you thought best. I've added it to the miscellaneous section (you won't see it online until tomorrow). If you want to change this, go ahead (as long as you do it before the deadline).
Daniel _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 26/07/2008, Emil Dotchevski <emil@revergestudios.com> wrote:
Thanks Daniel!
Actually, I am not sure what's the best category for this library. It's a low level lib, so perhaps it should go under utility, miscellaneous doesn't seem descriptive enough. Any thoughts?
I'm really not sure. Possibly 'Programming Interfaces'? Maybe also 'Concurrent Programming', although that might be stretching it. Daniel
I think utility would be fine. Concurrent Programming is in my opinion too "restrictive". On Sun, Jul 27, 2008 at 1:52 AM, Daniel James <daniel_james@fmail.co.uk>wrote:
On 26/07/2008, Emil Dotchevski <emil@revergestudios.com> wrote:
Thanks Daniel!
Actually, I am not sure what's the best category for this library. It's a low level lib, so perhaps it should go under utility, miscellaneous doesn't seem descriptive enough. Any thoughts?
I'm really not sure. Possibly 'Programming Interfaces'? Maybe also 'Concurrent Programming', although that might be stretching it.
Daniel _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Alp Mestan --- http://blog.mestan.fr/ --- http://alp.developpez.com/ --- In charge of the Qt, Algorithms and Artificial Intelligence sections on Developpez
On 26/07/2008, Emil Dotchevski <emil@revergestudios.com> wrote:
Actually, I am not sure what's the best category for this library. It's a low level lib, so perhaps it should go under utility, miscellaneous doesn't seem descriptive enough. Any thoughts?
On Sun, Jul 27, 2008 at 1:52 AM, Daniel James <daniel_james@fmail.co.uk>wrote:
I'm really not sure. Possibly 'Programming Interfaces'? Maybe also 'Concurrent Programming', although that might be stretching it.
2008/7/27 Alp Mestan <alpmestan@gmail.com>:
I think utility would be fine.
But there currently isn't such a category. I'm not against creating one, although it might be a little confusing since there's the utility library.
Concurrent Programming is in my opinion too "restrictive".
It can be in more than one category. Daniel
Where is the current category list ? On Sun, Jul 27, 2008 at 6:16 AM, Daniel James <daniel_james@fmail.co.uk>wrote:
On 26/07/2008, Emil Dotchevski <emil@revergestudios.com> wrote:
Actually, I am not sure what's the best category for this library. It's a low level lib, so perhaps it should go under utility, miscellaneous doesn't seem descriptive enough. Any thoughts?
On Sun, Jul 27, 2008 at 1:52 AM, Daniel James <daniel_james@fmail.co.uk
wrote: I'm really not sure. Possibly 'Programming Interfaces'? Maybe also 'Concurrent Programming', although that might be stretching it.
2008/7/27 Alp Mestan <alpmestan@gmail.com>:
I think utility would be fine.
But there currently isn't such a category. I'm not against creating one, although it might be a little confusing since there's the utility library.
Concurrent Programming is in my opinion too "restrictive".
It can be in more than one category.
Daniel _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Alp Mestan --- http://blog.mestan.fr/ --- http://alp.developpez.com/ --- In charge of the Qt, Algorithms and Artificial Intelligence sections on Developpez
2008/7/27 Alp Mestan <alpmestan@gmail.com>:
Where is the current category list ?
http://www.boost.org/libs/libraries.htm#Category It's mostly used for local documentation. Daniel
I think the lib can be added in Concurrent Programming, Programming Interfaces and maybe Misc. It isn't worth creating a category for it. On Sun, Jul 27, 2008 at 6:41 AM, Daniel James <daniel_james@fmail.co.uk>wrote:
2008/7/27 Alp Mestan <alpmestan@gmail.com>:
Where is the current category list ?
http://www.boost.org/libs/libraries.htm#Category
It's mostly used for local documentation.
Daniel _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Alp Mestan --- http://blog.mestan.fr/ --- http://alp.developpez.com/ --- In charge of the Qt, Algorithms and Artificial Intelligence sections on Developpez
On Sat, Jul 26, 2008 at 9:52 PM, Alp Mestan <alpmestan@gmail.com> wrote:
I think the lib can be added in Concurrent Programming, Programming Interfaces and maybe Misc. It isn't worth creating a category for it.
If we create utility group, I'm sure other libraries would be added to it. The variant library comes to mind, I see it in containers now but it isn't really a container. Other libs that can go in utility: tokenizer, static_assert, etc. The real issue is that "utility" isn't very descriptive, this is the main reason I don't like it. Maybe we can create "error handling" group? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
That's not a bad idea. And static_assert would be fine for "error handling" too as it's about compile-time errors. On Sun, Jul 27, 2008 at 7:14 PM, Emil Dotchevski <emil@revergestudios.com>wrote:
On Sat, Jul 26, 2008 at 9:52 PM, Alp Mestan <alpmestan@gmail.com> wrote:
I think the lib can be added in Concurrent Programming, Programming Interfaces and maybe Misc. It isn't worth creating a category for it.
If we create utility group, I'm sure other libraries would be added to it. The variant library comes to mind, I see it in containers now but it isn't really a container. Other libs that can go in utility: tokenizer, static_assert, etc. The real issue is that "utility" isn't very descriptive, this is the main reason I don't like it.
Maybe we can create "error handling" group?
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Alp Mestan --- http://blog.mestan.fr/ --- http://alp.developpez.com/ --- In charge of the Qt, Algorithms and Artificial Intelligence sections on Developpez
On Sun, Jul 27, 2008 at 10:20 AM, Alp Mestan <alpmestan@gmail.com> wrote:
That's not a bad idea.
And static_assert would be fine for "error handling" too as it's about compile-time errors.
Good point! Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Daniel James wrote:
Hello everyone,
Since the generated documentation isn't currently included in the snapshots, I've temporarily made it available here:
Thanks for doing this, Daniel. The docs look good to me. Even the LaTeX formulas in the Accumulators doxygen comments were rendered correctly, which seems like a small miracle. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Daniel James schrieb:
Hello everyone,
Since the generated documentation isn't currently included in the snapshots, I've temporarily made it available here:
http://www.calamity.org.uk/1.36/
Hopefully, the documentation should be integrated with the beta site soon after the beta release.
The getting starting sections all still refer to boost 1.35 (like "Download boost_1_35_0.tar.bz2"). Norbert
Hi Anthony, It should be great if the Thread library documentation included a History section and include the changes since 1.35 that we can already found in the Version 1.36.0 page (http://beta.boost.org/users/news/version_1_36_0) The create_thread interface evolution is not present in the doc. Replace thread* create_thread(const function0<void>& threadfunc); by template<typename F> thread* create_thread(F threadfunc); BTW, as you have enhanced the interface for the thread construction template <class F,class A1,..., class An> thread(F f,A1 a1,..., An an); why not to apply the same schema to the create_thread function of the thread_group class? Just one minor sugestion: The guard on the create_thread function should be declared after the thread creation to limit the scope of the mutex lock. template<typename F> thread* create_thread(F threadfunc) { std::auto_ptr<thread> new_thread(new thread(threadfunc)); { boost::lock_guard<mutex> guard(m); threads.push_back(new_thread.get()); } return new_thread.release(); } Reading the code we see that the thread_group class is thread safe using an internal mutex. Is this is part of the contract it is not documented? In addition an application creating/adding all the threads of a group in one thread do not needs this thread safety. Following the C++ phylosophy "don't pay for what you don't use", should't this class be parameterized by a synchronization policy. Best, Vicente
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
It should be great if the Thread library documentation included a History section and include the changes since 1.35 that we can already found in the Version 1.36.0 page (http://beta.boost.org/users/news/version_1_36_0)
Good idea.
The create_thread interface evolution is not present in the doc. Replace thread* create_thread(const function0<void>& threadfunc); by template<typename F> thread* create_thread(F threadfunc);
Oops.
BTW, as you have enhanced the interface for the thread construction
template <class F,class A1,..., class An> thread(F f,A1 a1,..., An an);
why not to apply the same schema to the create_thread function of the thread_group class?
There's a trac issue for that. I haven't got round to it yet.
Just one minor sugestion: The guard on the create_thread function should be declared after the thread creation to limit the scope of the mutex lock.
template<typename F> thread* create_thread(F threadfunc) { std::auto_ptr<thread> new_thread(new thread(threadfunc)); { boost::lock_guard<mutex> guard(m); threads.push_back(new_thread.get()); } return new_thread.release(); }
That's a good idea.
Reading the code we see that the thread_group class is thread safe using an internal mutex. Is this is part of the contract it is not documented? In addition an application creating/adding all the threads of a group in one thread do not needs this thread safety. Following the C++ phylosophy "don't pay for what you don't use", should't this class be parameterized by a synchronization policy.
Maybe. It's been thread-safe with an internal lock for as long as I've been aware of it though. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
--------------------------- Vicente Juan Botet Escriba ----- Original Message ----- From: "Anthony Williams" <anthony.ajw@gmail.com> To: <boost@lists.boost.org> Sent: Friday, August 01, 2008 8:47 AM Subject: Re: [boost] 1.36 thread library
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
It should be great if the Thread library documentation included a History section and include the changes since 1.35 that we can already found in the Version 1.36.0 page (http://beta.boost.org/users/news/version_1_36_0)
Good idea.
The create_thread interface evolution is not present in the doc. Replace thread* create_thread(const function0<void>& threadfunc); by template<typename F> thread* create_thread(F threadfunc);
Oops.
BTW, as you have enhanced the interface for the thread construction
template <class F,class A1,..., class An> thread(F f,A1 a1,..., An an);
why not to apply the same schema to the create_thread function of the thread_group class?
There's a trac issue for that. I haven't got round to it yet.
Just one minor sugestion: The guard on the create_thread function should be declared after the thread creation to limit the scope of the mutex lock.
template<typename F> thread* create_thread(F threadfunc) { std::auto_ptr<thread> new_thread(new thread(threadfunc)); { boost::lock_guard<mutex> guard(m); threads.push_back(new_thread.get()); } return new_thread.release(); }
That's a good idea.
Reading the code we see that the thread_group class is thread safe using an internal mutex. Is this is part of the contract it is not documented? In addition an application creating/adding all the threads of a group in one thread do not needs this thread safety. Following the C++ phylosophy "don't pay for what you don't use", should't this class be parameterized by a synchronization policy.
Maybe. It's been thread-safe with an internal lock for as long as I've been aware of it though.
Surely. Maybe to be added in the todo list. Vicente
participants (9)
-
Alp Mestan -
Anthony Williams -
Bruce Trask -
Daniel James -
daniel_james＠fmail.co.uk
-
Emil Dotchevski -
Eric Niebler -
Norbert Unterberg -
vicente.botet