"Steven T. Hatton" wrote:
> Earl Purple wrote:
>
> > - Standard multi-threading would be a good place to start. Make
> > operator++ (both post and pre-increment) for basic types atomic by
> > default.
>
> In general, the idea of easy to use, robust and efficient threading support
> in C++ is attractive. It also seems hazardous. These are a couple of my
> observation on the matter. I'm not sure what it means to make a basic type
> atomic under operator++().  It does, however, sound like something that
> could potentially incur a cost even for single threaded applications.  That
> would violate the zero-overhead principle.

Ignore post-increment - there is no need for that to be atomic. But if
pre-increment on a basic type were atomic, it would mean, for example,
that if I have a variable x of value 3 and two threads simultaneously
call ++x, one of them will get a value 4 and one a 5. If you're really
worried about this affecting performance then enforce this only when x
is declared volatile. The same would be the case for pre-decrement,
thus if two threads are decrementing a reference count which was
originally 2, exactly one of them will get a 0 return and the pointer
will be deleted exactly once.

Many processors already have an atomic decrement.

Having reference-counted pointers using a template for
reference-counting (thus using simple increment/decrement in a
single-threaded environment and atomic increment/decremeent where an
object will have references in multiple threads) is an optimal way to
implement them, though of course it puts more into the programmers
hands to ensure they select the right one. (You'd probably have a
default).

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Earl Purple" <earlpurple0@yahoo.com> skrev i meddelandet
news:1122392650.953953.80200@f14g2000cwb.googlegroups.com...
>
>
> "Steven T. Hatton" wrote:
>> Earl Purple wrote:
>>
>> > - Standard multi-threading would be a good place to start. Make
>> > operator++ (both post and pre-increment) for basic types atomic by
>> > default.
>>
>> In general, the idea of easy to use, robust and efficient threading
>> support
>> in C++ is attractive. It also seems hazardous. These are a couple of
>> my
>> observation on the matter. I'm not sure what it means to make a basic
>> type
>> atomic under operator++().  It does, however, sound like something
>> that
>> could potentially incur a cost even for single threaded applications.
>> That
>> would violate the zero-overhead principle.
>
> Ignore post-increment - there is no need for that to be atomic. But if
> pre-increment on a basic type were atomic, it would mean, for example,
> that if I have a variable x of value 3 and two threads simultaneously
> call ++x, one of them will get a value 4 and one a 5. If you're really
> worried about this affecting performance then enforce this only when x
> is declared volatile. The same would be the case for pre-decrement,
> thus if two threads are decrementing a reference count which was
> originally 2, exactly one of them will get a 0 return and the pointer
> will be deleted exactly once.

Why just basic types? Why would ++p be atomic by default for some types
and not for others?

>
> Many processors already have an atomic decrement.

Which is often extremely expensive.

>
> Having reference-counted pointers using a template for
> reference-counting (thus using simple increment/decrement in a
> single-threaded environment and atomic increment/decremeent where an
> object will have references in multiple threads) is an optimal way to
> implement them, though of course it puts more into the programmers
> hands to ensure they select the right one. (You'd probably have a
> default).
>

One very popular compiler http://msdn.microsoft.com/visualc/ doesn't
have single/multi threaded environments anymore. Then what?

How popular will single-threaded programs be on the current multi-core
processors?


The optimization is performed on the wrong level, because the compiler
doesn't know which variables are to be shared between threads, and which
are not. Synchronization has to be performed at the user code level,
where this is known, not at the library level.

How would the smart pointer know if it is passed between threads?


Bo Persson




---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Bo Persson wrote:
>
> How popular will single-threaded programs be on the current multi-core
> processors?
>

Very popular. Many programs will not benefit from being multi-threaded.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"P.J. Plauger" wrote:
> ""Steven T. Hatton"" <hattons@globalsymmetry.com> wrote in
> message news:_vCdnQ9mHrDNJEDfRVn-2g@speakeasy.net...

> > Would it make sense to divide the C++ Standard Library into
> > two levels, one being more fundamental and "essential" than
> > the other?  There seem to be some items on peoples'
> > wishlists that are further removed from the 'orthogonal
> > basis' formed of primitive library components which
> > constitute the current Standard Library.  For example, I
> > noticed Bjarne has an XML library in his letter to Santa.
> > That, to my mind, does not seem to be the kind of feature
> > that has traditionally been part of the carefully selected
> > offerings of Standard C++.  It seems to be more of a "nice
> > to have available", non-essential.

> > My preference would be for something more fundamental such
> > as a lexer, parser, and AST toolkit from which an XML
> > library could be built. (I could be way off the mark here -
> > and I'm certainly off my original topic).

> > Would it make sense to have an "implementor shall" library, and an
> > "implementer aught to" library?

> You mean, like:

> -- the C++ Standard, which is mandatory, and

> -- TR1, which is non-normative, and hence advisory only?

> Good idea.

I think he was thinking more along the lines of minimal library,
which could be used on embedded systems, without an OS, or with
just a real time kernal, and no classical IO devices, as opposed
to the works, appropriate for general purpose systems like Unix
or Windows.  Maybe we should make such a distinction; I propose
the names free standing and hosted. :-).

Seriously, I think there is some point where "optional" sections
becomes interesting.  I'd sort of like to see a standard GUI,
for example, and a standard interface to a data base would be
nice as well.  But I don't think that they should be imposed on
all hosted implementations.  They idea is that either you don't
support a GUI at all, or you conform to the standard.

Having said that, I don't see very many other candidates.  And
given that nobody seems ready and willing to spend the time and
effort to create a standard GUI interface or data base interace,
optional or not, the question is rather moot.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kanze@gabi-soft.fr wrote:

> "P.J. Plauger" wrote:
>> ""Steven T. Hatton"" <hattons@globalsymmetry.com> wrote in
>> message news:_vCdnQ9mHrDNJEDfRVn-2g@speakeasy.net...
>
>> > Would it make sense to divide the C++ Standard Library into
>> > two levels, one being more fundamental and "essential" than
>> > the other?  There seem to be some items on peoples'
>> > wishlists that are further removed from the 'orthogonal
>> > basis' formed of primitive library components which
>> > constitute the current Standard Library.  For example, I
>> > noticed Bjarne has an XML library in his letter to Santa.
>> > That, to my mind, does not seem to be the kind of feature
>> > that has traditionally been part of the carefully selected
>> > offerings of Standard C++.  It seems to be more of a "nice
>> > to have available", non-essential.
>
>> > My preference would be for something more fundamental such
>> > as a lexer, parser, and AST toolkit from which an XML
>> > library could be built. (I could be way off the mark here -
>> > and I'm certainly off my original topic).
>
>> > Would it make sense to have an "implementor shall" library, and an
>> > "implementer aught to" library?
>
>> You mean, like:
>
>> -- the C++ Standard, which is mandatory, and
>
>> -- TR1, which is non-normative, and hence advisory only?
>
>> Good idea.
>
> I think he was thinking more along the lines of minimal library,
> which could be used on embedded systems, without an OS, or with
> just a real time kernal, and no classical IO devices, as opposed
> to the works, appropriate for general purpose systems like Unix
> or Windows.  Maybe we should make such a distinction; I propose
> the names free standing and hosted. :-).

That wasn't the distinction I was trying to draw, but there may be merit in
your suggestion.

> Seriously, I think there is some point where "optional" sections
> becomes interesting.  I'd sort of like to see a standard GUI,
> for example, and a standard interface to a data base would be
> nice as well.  But I don't think that they should be imposed on
> all hosted implementations.  They idea is that either you don't
> support a GUI at all, or you conform to the standard.

I assume you mean to say that, as a C++ implementer you should not include
non-standard libraries as part of the package you treat as the C++
implementation.  IOW, there should be no requirement that a C++ user must
use, e.g., a standar GUI library if he or she is creating a GUI.

> Having said that, I don't see very many other candidates.

Encryption;  Naming and directory services;  Network I/O;  Hardware
abstraction; XML; HTTP;

> And
> given that nobody seems ready and willing to spend the time and
> effort to create a standard GUI interface or data base interace,
> optional or not, the question is rather moot.

It may be a chicke and egg problem.  If people don't see a potential for
having their work incorporated into an approved standard, they would have
little motivation for producing it.  If people don't perceive the potential
for such standard libraries being produced, they may have little motivation
for defining a formal means of standardizing such extensions.
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

- Standard multi-threading would be a good place to start. Make
operator++ (both post and pre-increment) for basic types atomic by
default.
- Standard smart pointers other than auto_ptr (not so essential as we
can use boost as an extension, apart from the thread-safety problems
caused by non-atomic increment/decrement).
- Directory manipulation.
- A standard "networking" interface.
- A standard method of dynamic library loading. You would need two
different symbol-loading functions, one for objects and one for
functions. Or you could force them to all be objects that inherit from
a common base class. (That wouldn't mean your classes must inherit from
this base-class, just that your exported symbols must. Your exported
symbols could be factory-objects that create instances of your class,
or simple object "getters" that embed your class). After all, an
exported symbol "is a" something (i.e. it "is an" exported symbol).

Basically, get around an situations where we need to put in
pre-processors according to what platform we are programming for.

Obviously if you are writing for deivce-drivers or mobile phones or
something that lack a certain feature you won't be able to use those
features in your own C++.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Earl Purple wrote:
> - Standard multi-threading would be a good place to start. Make
> operator++ (both post and pre-increment) for basic types atomic by
> default.
> - Standard smart pointers other than auto_ptr (not so essential as we
> can use boost as an extension, apart from the thread-safety problems
> caused by non-atomic increment/decrement).

Thread safety requires more than atomicity. That's sufficient on a
single-processor system, but on a multi-processor system you also have
to worry about making sure the change is visible to other processors,
and that can be very expensive.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Earl Purple wrote:

> - Standard multi-threading would be a good place to start. Make
> operator++ (both post and pre-increment) for basic types atomic by
> default.

In general, the idea of easy to use, robust and efficient threading suppo=
rt
in C++ is attractive. It also seems hazardous. These are a couple of my
observation on the matter. I'm not sure what it means to make a basic typ=
e
atomic under operator++().  It does, however, sound like something that
could potentially incur a cost even for single threaded applications.  Th=
at
would violate the zero-overhead principle.

For templates, it may make sense to come up with a way of parameterising
threading support through template arguments.  A thought just occurred to
me that this might somehow be treated as a parameterized interface simila=
r
in concept to Java interfaces. =20

One way of viewing an interface, which I often find useful, is to treat i=
t
as an ability.  Threadable, constructable, serializable, printable, etc.=20
This may fit into the realm of template concepts (which I don't understan=
d
well).  There may also be a place for providing a cooresponding ABC for
some types of functionality. Not everything can, or should be a template.=
=20
Perhaps the ABC could be used in both class types and templates?

> - Standard smart pointers other than auto_ptr (not so essential as we
> can use boost as an extension, apart from the thread-safety problems
> caused by non-atomic increment/decrement).

for myself, I like the idea of a smart proxy with reference counting and =
a
corresponding and cooperating reference counted smart pointer.  Move
semantics, and immutable strings are nice, but they are not the whole
solution.

> - Directory manipulation.

Define "directory".  That could mean many things, from that thing they ca=
ll
a folder in Windows, to an LDAP server.  I believe this can fall under th=
e
general category of "naming and directory services".  I will observe that
such services have often seemed overly general, and therefore complex, wh=
en
I have encountered them. =20

And to contradict myself, there may be a place for the same underlying
infrastructure that would support a directory service in an XML library.=20
I'm thinking in particular of XPath.  I will also tell you with bold
confidence that the conceptula model treated with Boost.Graph is of
relevance here.

> - A standard "networking" interface.

This should be, as much as possible, congruent with the existing I/O
facilities.  Writing to a file across a network should not differ - anymo=
re
than is necessary - from writing to a local harddrive.  But there is a
_lot_ involved in "networking", such as protocol support, addressing,=20
connection management, error recovery, concurrency.... RPC...


> - A standard method of dynamic library loading. You would need two
> different symbol-loading functions, one for objects and one for
> functions. Or you could force them to all be objects that inherit from
> a common base class. (That wouldn't mean your classes must inherit from
> this base-class, just that your exported symbols must. Your exported
> symbols could be factory-objects that create instances of your class,
> or simple object "getters" that embed your class). After all, an
> exported symbol "is a" something (i.e. it "is an" exported symbol).

I agree with the objective.  However, in TC++PL(SE) =A724.3.1 we find a
humorous example of the author evading the obvious conclusion that all
things are indeed things.  His list of "levels of abstraction" for a hous=
e
would better be described as levels of detail.  I have discovered a bette=
r
escape from the dilemma.  There is a universal base class in C++, it is,
however, a pure abstractions. :)  I almost commented above regarding
operator++(), that a wrapper class may be useful for synchronizing these
operations. All that being said, the notion of treating all symbols as
objects seems both costly, and unnecessary. =20

I suspect the modules proposal by Daveed van de Voorde points to a better
solution. =20

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1778.pdf
=20
> Basically, get around an situations where we need to put in
> pre-processors according to what platform we are programming for.

"Furthermore, I am of the opinion that Cpp must be destroyed. - Cato the
Elder (Marcus Porcius Cato)" D&E =A718

> Obviously if you are writing for deivce-drivers or mobile phones or
> something that lack a certain feature you won't be able to use those
> features in your own C++.

That's the where distinction between "hosted" and an "freestanding"
implementations comes into play.
--=20
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Would it make sense to divide the C++ Standard Library into two levels, one
being more fundamental and "essential" than the other?  There seem to be
some items on peoples' wishlists that are further removed from the
'orthogonal basis' formed of primitive library components which constitute
the current Standard Library.  For example, I noticed Bjarne has an XML
library in his letter to Santa.  That, to my mind, does not seem to be the
kind of feature that has traditionally been part of the carefully selected
offerings of Standard C++.  It seems to be more of a "nice to have
available", non-essential.

My preference would be for something more fundamental such as a lexer,
parser, and AST toolkit from which an XML library could be built. (I could
be way off the mark here - and I'm certainly off my original topic).

Would it make sense to have an "implementor shall" library, and an
"implementer aught to" library?
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Steven T. Hatton"" <hattons@globalsymmetry.com> wrote in message
news:_vCdnQ9mHrDNJEDfRVn-2g@speakeasy.net...

> Would it make sense to divide the C++ Standard Library into two levels,
> one
> being more fundamental and "essential" than the other?  There seem to be
> some items on peoples' wishlists that are further removed from the
> 'orthogonal basis' formed of primitive library components which constitute
> the current Standard Library.  For example, I noticed Bjarne has an XML
> library in his letter to Santa.  That, to my mind, does not seem to be the
> kind of feature that has traditionally been part of the carefully selected
> offerings of Standard C++.  It seems to be more of a "nice to have
> available", non-essential.
>
> My preference would be for something more fundamental such as a lexer,
> parser, and AST toolkit from which an XML library could be built. (I could
> be way off the mark here - and I'm certainly off my original topic).
>
> Would it make sense to have an "implementor shall" library, and an
> "implementer aught to" library?

You mean, like:

-- the C++ Standard, which is mandatory, and

-- TR1, which is non-normative, and hence advisory only?

Good idea.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

P.J. Plauger wrote:
> ""Steven T. Hatton"" <hattons@globalsymmetry.com> wrote
>>Would it make sense to have an "implementor shall" library, and an
>>"implementer aught to" library?
>
> You mean, like:
> -- the C++ Standard, which is mandatory, and
> -- TR1, which is non-normative, and hence advisory only?
> Good idea.

The Ada standard has this. They call it "implementation advice".

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

P.J. Plauger wrote:


> You mean, like:
>
> -- the C++ Standard, which is mandatory, and
>
> -- TR1, which is non-normative, and hence advisory only?
>
> Good idea.
>
> P.J. Plauger
> Dinkumware, Ltd.
> http://www.dinkumware.com

The wording in the introductory comments of TR1 suggests it is of an
experimental nature, and subject the possibility to significant future
modification.  IOW, it has qualities of a draft standard.

1 This technical report describes extensions to the C++ standard library
that is described in the International Standard for
the C++ programming language [14].
2 This technical report is non-normative. Some of the library components in
this technical report may be considered for
standardization in a future version of C++, but they are not currently part
of any C++ standard. Some of the components
in this technical report may never be standardized, and others may be
standardized in a substantially changed form.
3 The goal of this technical report it to build more widespread existing
practice for an expanded C++ standard library. It
gives advice on extensions to those vendors who wish to provide them.


I am suggesting a truly standard specification which has a degree of
stability close to that of the current ISO/IEC 14882.  Such a standard
could be modularized so that an implementor could meaningfully create a
fully conforming implementation of a specific feature, without implementing
the entire extension library.  To that extent, the document /would/ be
normative.  It would simply not be a requirement of a core C++
implementation.

--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Steven T. Hatton" schreef:
> Would it make sense to divide the C++ Standard Library into two levels, one
> being more fundamental and "essential" than the other?

We already have those. Read the library introduction. E.g. type_info is
in
the first category, vector in the second.

Regards,
Michiel Salters

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]