thread_id value not exported.

[Michael Soliman. <boost@…>]

Moin Moin.

Trying to write programmes, using unique ids per thread and only per thread, recommend themselves to be numbered by this_thread:get_id(). Unfortunately, the data-member (in "boost\boost\thread\detail\thread.hpp":line 50.) is both.:

0. declared private (not protected),
1. not exported by an access-function.

Right now, in order to maintain maximum compatibility as well as the emission of the same old error-messages, I just added the missing access-functions.: const thread_data&const_Wert(void)const{return thread_data;};

thread_data& Wert(void) {return thread_data;};

Similarly I moved "typedef ... super_t;" in "boost\boost\iterator\filter_iterator.hpp":line 50 to the public-scope, as I needed it for my typedefs and did not see a point in deplaring any typedef as an unpublican(ian)^{n (for an appropriate n>=0).}

Hence my request to.:

1. generally use the keyword private only iff public/protected access-functions-to the underlying data exist.
2. To put typedefs in the public/protected area only, or at least to put typedefs in there, allowing acces to all types that might be needed (somewhen.).
3. To typedef all template-parameters like class Predicate, class Iterator in the aforementioned "filter_iterator.hpp", where, later on I did write a less restricted version of this class (But did not invest the same amount of work, just to add some access-functions.).

Tschuess,

Michael.

P.S.: I did append the ammended version of "Filter_iterator" in order to illustrate, what I meant (sorry for the partly German names.). P^{2.S.: As I am not a "TeX"-guy, does anyone know how to switch off the superspript mode..}

[Michael Soliman. <boost@…>]

I did append the ammended version of "Filter_iterator" in order to illustrate, what I meant (sorry for the partly German names.).

[Michael Soliman. <boost@…>]

P^{3_.S.: Cut & Paste errors prevail. The access-functions should be.: const detail::thread_data_ptr&const_Wert(void)const{return thread_data;};}

detail::thread_data_ptr& Wert( void) {return thread_data;};

, of course. _Tschuess, Michael.

[Anthony Williams]

The details of thread::id are private for a purpose. The internal contents are not intended for public consumption, and providing such access would break encapsulation.

thread::id is suitable for use as a key in an associative container, so can be used directly as e.g. a map index.

[Michael Soliman. <boost@…>]

Moin Moin. Ok.: "not intended for public consumption" does mean, that the authors did not have the plan to do so. My proposal now implies, that a sensible application to do so arose and can be satisfied without removing any degrees of implementing future functionality from the authors' sphere of influence. My proposal just contains

[Anthony Williams]

I disagree that a sensible application for exposing the internals of thread::id has arisen.

I will not be changing thread::id to expose the internals. If you wish to use thread::id as an index, create an associative container such as std::map<boost::thread::id,some_data>.

[Michael Soliman. <boost@…>]

Moin Moin.

I disagree that a sensible application for exposing the internals of thread::id has arisen.

Hm. Sorry, I did not mean to be pert. My intention was just to remove a circumventable restriction. As it is a small change, I shall be implementing it within the sources all by myself at anytime I am using a new distribution.

Tschuess,

Michael.