Folks - I have found that there are several classes in boost, namely the OS constructs (thread, mutex, etc.) do not provide me w/some of the features I'm looking for (and that is ok with me). As an embedded developer I deal with all kinds of operating systems which are not in the main stream, however C++ is very common in the embedded world, and is growing. With that note, I would like to assert the following: - It would be "uber-useful" to design OS constructs, or libraries for that matter, with extensibility in mind. By providing a couple of guidelines, developers could then port to any OS under the sun, or add the features they desire. Instead, I'm left with writing yet another wrapper (ohh joy). Cheers, -Tim
Tim St. Clair wrote:
Folks -
I have found that there are several classes in boost, namely the OS constructs (thread, mutex, etc.) do not provide me w/some of the features I'm looking for (and that is ok with me). As an embedded developer I deal with all kinds of operating systems which are not in the main stream, however C++ is very common in the embedded world, and is growing.
With that note, I would like to assert the following: - It would be "uber-useful" to design OS constructs, or libraries for that matter, with extensibility in mind. By providing a couple of guidelines, developers could then port to any OS under the sun, or add the features they desire.
Instead, I'm left with writing yet another wrapper (ohh joy).
Nobody can really do anything with this feedback until you tell us specifically which classes you experienced problems with, what the problems were exactly, and what a better design would be, in your opinion. -- Eric Niebler Boost Consulting www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
Eric -
The thread class is a good example, by having the handles private
instead of protected there is no way to extend the class. If it were
#defined wrapped for extensibility that would be groovy too.
I'm looking to extend an interface which presents a pthread-esk
interface, while supporting multiple OS's (VxWorks, Linux, Windows,
Other Embedded OS's ). So our application code can agnostic.
-Tim
p.s. - BOOST_FOREACH is a jem!
On 9/6/07, Eric Niebler
Tim St. Clair wrote:
Folks -
I have found that there are several classes in boost, namely the OS constructs (thread, mutex, etc.) do not provide me w/some of the features I'm looking for (and that is ok with me). As an embedded developer I deal with all kinds of operating systems which are not in the main stream, however C++ is very common in the embedded world, and is growing.
With that note, I would like to assert the following: - It would be "uber-useful" to design OS constructs, or libraries for that matter, with extensibility in mind. By providing a couple of guidelines, developers could then port to any OS under the sun, or add the features they desire.
Instead, I'm left with writing yet another wrapper (ohh joy).
Nobody can really do anything with this feedback until you tell us specifically which classes you experienced problems with, what the problems were exactly, and what a better design would be, in your opinion.
-- Eric Niebler Boost Consulting www.boost-consulting.com
The Astoria Seminar ==> http://www.astoriaseminar.com _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Regards, Timothy St. Clair [timothysc@gmail.com]
participants (2)
-
Eric Niebler -
Tim St. Clair