Topic: Where next for Standard C++? what about task and parallelism
Author: "Alain Coetmeur" <acoetmeur@icdc.caissedesdepots.fr>
Date: 1997/11/27 Raw View
--MimeMultipartBoundary
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
One point where C++ could evolve
could be to support a multi-thread model
like ADA or Java, or some other language...
Like the STL it have to be:
- as efficient as possible for a given
functionality
- open to any implementation
(any OS)
why not
- really support coprocedure in C++ (not setjmp)
- propose a template for a scheduler
in a way similar to STL container, so
that you have standard scheduler, but can build your own...
- add locking primitives or critical section
like in java (lock on method, lock on block, lock on object...)
, but fully open to any implementation of
lock or of scheduler, either home made, OS made...
- make all fully plugable on a
NT-thread/NTkernel/Posix-thread/Real-Time Monitor...
without user change... in a way similar to Allocator in STL
the STL seems to be a model for such implementation,
with a strong theorical definition, total openness
and extensibility, and a good reference implementation...
with this, there should be a fully reentrant
STL implementation...
why not a Standard Multi Thread Library (SMTL) .
smile 8)
--
Alain Coetmeur. Informatique-CDC , mailto:acoetmeur@icdc.caissedesdepots.fr
<<Mes propos n'engagent que moi. #8*). my words are only mine. >>
--MimeMultipartBoundary--
---
[ comp.std.c++ is moderated. To submit articles: try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]