Thorsten Ottosen <nesotto@cs.auc.dk> wrote
 > | Cat out of the bag, I might as well tell you that you won't get rid of
 > | all uses of the keyword "static" until the year 2114, and even then we'll
 > | still have that damn comma operator!

 > "Allan W" <allan_w@my-dejanews.com> wrote
 > what's so bad about the comma operator? Afterall, without it we couldn't say
 >
 > vector<int> v;
 > v += 1,2,3,4,5,6,7,8,9;

So long as we can still say
     if ((12,345) > (54,321)) cout << "The world is upside down!\n";


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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                       ]

"Allan W" <allan_w@my-dejanews.com> wrote in message news:7f2735a5.0405111113.76f76382@posting.google.com...

| Cat out of the bag, I might as well tell you that you won't get rid of
| all uses of the keyword "static" until the year 2114, and even then we'll
| still have that damn comma operator!

what's so bad about the comma operator? Afterall, without it we couldn't say

vector<int> v;
v += 1,2,3,4,5,6,7,8,9;

br

Thorsten



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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                       ]

Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message news:<m3fzagp8i3.fsf@uniton.integrable-solutions.net>...
 > jtorjo@yahoo.com (John Torjo) writes:
 >
 > [...]
 >
 > | This came right out of the box (not too much thinking :D)
 > | But I think that keywords like const,volatile,restrict should not have
 > | been keywords at all.
 >
 > [...]
 >
 > | I'm sure there would have been a solution to declare functions as
 > | const or volatile, etc. But I guess it's too late now :(
 >
 > Yep.  Evolving C++ implies living with history -- unless someone finds
 > a time-travel device,  goes back and persuades C designers in the early
 > '70s about the values of C++ (to be born in the '80s) templates ;-)
 >
he he ;) I love C++ most (by far) of all languages, but I think that
someone should sit down and write a new language (in the upcoming 3-5
years), learning from C++ mistakes.


John Torjo
Freelancer
-- john@torjo.com
-- http://www.torjo.com/logview/ - viewing/filtering logs is just too
easy!


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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                       ]

Gabriel Dos Reis <gdr@integrable-solutions.net> wrote
> Evolving C++ implies living with history -- unless someone finds
> a time-travel device,  goes back and persuades C designers in the early
> '70s about the values of C++ (to be born in the '80s) templates ;-)

People in the future have enough problems already.

They have to fix all those problems that would have happened in years
2000 and 2038.

Plus they have to help keep time machines a secret until 2042, which
is exactly 100 years after the first working time machine was built...
Oops, I shouldn't have said that...

Cat out of the bag, I might as well tell you that you won't get rid of
all uses of the keyword "static" until the year 2114, and even then we'll
still have that damn comma operator!


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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                       ]

Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message news:<m3n059kxjm.fsf@uniton.integrable-solutions.net>...
 > Matt Austern <austern@well.com> writes:
 >
 > | llewelly <llewelly.at@xmission.dot.com> writes:
 > |
 > |  > "Peter C. Chapin" <pchapin@sover.net> writes:
 > |  > [snip]
 > |  >  > How the STL would or would not interact with restricted pointers isn't
 > |  >  > entirely clear to me. It is an interesting question, however.
 > |  >
 > |  > restrict_iterator ?
 > |
 > | That's putting the cart before the horse.  First: we don't have
 > | iterators for everything that can go into the type system.  (We have
 > | X::const_iterator but not X::volatile_iterator.)  I certainly hope we
 >
 > /me suggests X::iterator<cv-qualifier> to cut down complexity ;-p
 >
 > | don't need iterators for all eight possible combinations for const,
 > | volatile, and restrict.  But second, and even more important: we

This came right out of the box (not too much thinking :D)
But I think that keywords like const,volatile,restrict should not have
been keywords at all.

They should have been incorporated into the language as templates,
like:

const<some_type> c;
volatile<some_type> v;
volatile<const<some_type> > vc;

A certainly cool advantage of this would be that you would never have
2^n combinations for X::iterator and no more forwarding problem ;)

I'm sure there would have been a solution to declare functions as
const or volatile, etc. But I guess it's too late now :(

Best,
John


John Torjo
Freelancer
-- john@torjo.com
-- http://www.torjo.com/logview/ - viewing/filtering logs is just too
easy!


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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                       ]

jtorjo@yahoo.com (John Torjo) writes:

[...]

| This came right out of the box (not too much thinking :D)
| But I think that keywords like const,volatile,restrict should not have
| been keywords at all.

[...]

| I'm sure there would have been a solution to declare functions as
| const or volatile, etc. But I guess it's too late now :(

Yep.  Evolving C++ implies living with history -- unless someone finds
a time-travel device,  goes back and persuades C designers in the early
'70s about the values of C++ (to be born in the '80s) templates ;-)

--
                                                        Gabriel Dos Reis
                                            gdr@integrable-solutions.net


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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                       ]

kuyper@wizard.net (James Kuyper) wrote in message news:<8b42afac.0404230733.3e508fe@posting.google.com>...
> llewelly <llewelly.at@xmission.dot.com> wrote in message news:<863c73svq7.fsf@Zorthluthik.local.bar>...
> > "Peter C. Chapin" <pchapin@sover.net> writes:
> > [snip]
> >  > How the STL would or would not interact with restricted pointers isn't
> >  > entirely clear to me. It is an interesting question, however.
> >
> > restrict_iterator ?
>
> "restrict" doesn't describe a characteristic of a data type. It is
> called a type qualifier in C only as a matter of syntactic
> convenience. What it describes is a non-aliasing relationship between
> two or more actual objects which are all arguments of the same
> function. There's nothing that should be done about this at the type
> level.

Let me make that a little clearer. In C99, 'restrict' is labeled as a
type qualifier, which puts it in the same group as 'const' and
'volatile'. However, there are very few rules in the C99 standard that
refer to "type qualifiers". Virtually every rule that makes 'const
int' a distinct type from 'int' refers to "cv-qualification". In other
words, those rules apply to 'const' and 'volatile' qualifiers, but not
to the 'restrict' qualifier.

Therefore, it would be a mistake for a future version of the C++
template library to treat 'restrict' as being fully comparable to
'const' and 'volatile'.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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                       ]

Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message news:<m3smen4yqe.fsf@uniton.integrable-solutions.net>...
 > kuyper@wizard.net (James Kuyper) writes:
 >
 > | Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message news:<m3zn8zdek8.fsf@uniton.integrable-solutions.net>...
 > |  > kanze@gabi-soft.fr writes:
 >  ..
 > |  > C++ has overloads, C does not.  How should restrict work with respect
 > |  > to overloading?
 > |  >
 > |  > I'm of the opinion that it would be a mistake to just "feature"
 > |  > C++ with C notion of restrict without a thorough analyzis of the C++
 > |  > type system and how restrict is supposed to work with it.
 > |
 > | Despite being technically classified as a "type qualifier", "restrict"
 > | doesn't really have much to do with types, as such. It renders certain
 > | combinations of arguments to a function an error, and what makes those
 > | combinations errors isn't so much the data type of those arguments,
 > | but rather the their values.
 >
 > I guess it depends on the definition of "type" in use.  If by "type"
 > one means a collection of operations and constraints on set of values,
 > then most certainly "restrict" has everything to do with types as it
 > directly affects how certain kinds of values can be used or combined.

But there's no such thing as a value which is invalid for a single
restrict parameter. The "constraints on the set of values" for a
restrict pointer can be evaluated only by knowing the precise
algorithm that is to be used with that pointer, and the values of all
variables which can influence how that pointer is used by that
algorithm. Specific example:

char array[] = "Hello World!\n";
memcpy(array, array+5, 3);   // legal values for restricted pointers
memcpy(array, array+5, 6);   // Violates restrict qualification

How would you define a restrict_pointer to implement that concept?


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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                       ]

Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message news:<m3zn8zdek8.fsf@uniton.integrable-solutions.net>...
 > kanze@gabi-soft.fr writes:
..
 > C++ has overloads, C does not.  How should restrict work with respect
 > to overloading?
 >
 > I'm of the opinion that it would be a mistake to just "feature"
 > C++ with C notion of restrict without a thorough analyzis of the C++
 > type system and how restrict is supposed to work with it.

Despite being technically classified as a "type qualifier", "restrict"
doesn't really have much to do with types, as such. It renders certain
combinations of arguments to a function an error, and what makes those
combinations errors isn't so much the data type of those arguments,
but rather the their values. Because those combinations are error, it
allows optimizations that would produce unexpected results for those
erroneous combinations.

Since "restrict" isn't really about types, it shouldn't play any role
in determining which overload to use. This will probably require a
re-write of the overloading rules, or classification of "restrict" as
something other than a type-qualifier in C++. Once an overload is
selected, if any of it's parameters are restrict-qualified, the rules
for restrict-qualified parameters apply, and it's the developers
responsibility to obey them.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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                       ]

 > What if you only provided restrict_iterator to std::valarray, which
 > apparently already has some associated anti-aliasing requirements.

std::valarray doesn't have any magical anti-aliasing features,
although once upon a time it was proposed that C++ compilers treat it
specially.

The implementation in gcc (GDR's baby) encapsulates restrict pointers,
but gcc doesn't seem to optimize restrict pointers within structs at
all.

The main promise made by valarray is simply that {v1 and v2 overlap}
is equivalent to {v1 == v2}. Once you go down to the element/iterator
level though, all bets are off: given two valarray references or
pointers to element s1 and s2, they could be from the same valarray
(i.e. are reachable from each other and therefore could alias) or
different valarray (not aliasable), which could be difficult to
determine -- although that is the implicit promise of a restrict
pointer within a struct.

That's why the operations on a valarray are mostly declared at the
"array" level and not at the "element" level. An implementation of a
valarray function could optimize for when its params are equal or
unequal e.g.

valarray <T> add (const valarray <T>& v1, const valarray <T>& v2)
   {
     if (v1 == v2)
       // return 2 * v1
     else
       // perform v1 + v2 safe in the knowledge that v1 and v2 do not
overlap
   }

 > And even in the general case, it seems like the problem could be (at
 > least partially) addressed by defining a new iterator category
 > std::restricted_iterator_tag derived from
 > std::random_access_iterator_tag.  Then a new template specialization
 > could be defined for any STL-feature affected by the anti-aliasing
 > restrictions.  Perhaps I am being naive, since I have no experience
 > with compiler-design or STL implementation, but this doesn't seem
 > unfeasible to me.  Hopefully this will stimulate further discussion
 > which will enlighten me if I am misguided.

We would have to think carefully about the semantics of a restrict
iterator. In C, a restrict pointer promises that only that pointer and
any copies alias, but nothing else within the scope should alias.

Qns:

1. Does a copy of restrict iterator "alias" that iterator? For all
constructors, only copy constructors or what?

2. Do all operations / member functions preserve the restrictiveness
of the pointer? What about operator= ?

3. What is meant by aliasing in the face of overloaded operator* and
overloaded operator== ? e.g. if an iterator is restricted, does it
mean that whatever its operator* yields cannot be aliased? What if it
returns a rvalue? Can this be easily enforced by a compiler?

Cheers,
Glen Low, Pixelglow Software
www.pixelglow.com


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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                       ]

kuyper@wizard.net (James Kuyper) writes:

| Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message news:<m3zn8zdek8.fsf@uniton.integrable-solutions.net>...
|  > kanze@gabi-soft.fr writes:
| ..
|  > C++ has overloads, C does not.  How should restrict work with respect
|  > to overloading?
|  >
|  > I'm of the opinion that it would be a mistake to just "feature"
|  > C++ with C notion of restrict without a thorough analyzis of the C++
|  > type system and how restrict is supposed to work with it.
|
| Despite being technically classified as a "type qualifier", "restrict"
| doesn't really have much to do with types, as such. It renders certain
| combinations of arguments to a function an error, and what makes those
| combinations errors isn't so much the data type of those arguments,
| but rather the their values.

I guess it depends on the definition of "type" in use.  If by "type"
one means a collection of operations and constraints on set of values,
then most certainly "restrict" has everything to do with types as it
directly affects how certain kinds of values can be used or combined.

| Because those combinations are error, it
| allows optimizations that would produce unexpected results for those
| erroneous combinations.

But that is the very basis of the notion tagging data, i.e. types.


--
                                                        Gabriel Dos Reis
                                            gdr@integrable-solutions.net


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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                       ]

llewelly <llewelly.at@xmission.dot.com> wrote in message news:<863c73svq7.fsf@Zorthluthik.local.bar>...
> "Peter C. Chapin" <pchapin@sover.net> writes:
> [snip]
>  > How the STL would or would not interact with restricted pointers isn't
>  > entirely clear to me. It is an interesting question, however.
>
> restrict_iterator ?

"restrict" doesn't describe a characteristic of a data type. It is
called a type qualifier in C only as a matter of syntactic
convenience. What it describes is a non-aliasing relationship between
two or more actual objects which are all arguments of the same
function. There's nothing that should be done about this at the type
level.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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:
 >
 > Personally, I agree with you.  I think that the C committees resources
 > had best been spent elsewhere as well:-).  For reasons of C
 > compatibility, however, I do think we have to at least accept something
 > along the lines of:
 >
 >      #ifdef __cplusplus
 >      extern "C" {
 >      #endif
 >
 >      void f( int * restrict ) ;
 >
 >      #ifdef __cplusplus
 >      }
 >      #endif
 >
 > ...
 >
 > In the mean time: if the above bit of code can appear in a header file
 > without breaking the compile, it's enough for me.
 >

One way to do that is:

#define restrict

--

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

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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 writes:

| Of course, when considering restrict, we should keep in mind that it is
| an optimizing measure, much like inline.

It is not the same thing as inline.  And optimization does not change
the observable behaviour of a program.  Restrict does have a semantics
impact on C programs, it can technically render  the observable bahviour
undefined, and that does happen in practice -- just think about
overlapping arrays and operations on the contained individual elements.

--
                                                       Gabriel Dos Reis
                                           gdr@integrable-solutions.net


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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 writes:

| Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message
| news:<m3u0zemuyp.fsf@uniton.integrable-solutions.net>...
|  > llewelly <llewelly.at@xmission.dot.com> writes:
|
|  > | Matt Austern <austern@well.com> writes:
|
|  > |  > But second, and even more important: we don't have any idea how
|  > |  > restrict would fit into C++'s type system.  We know how it fits
|  > |  > into C's type system, but that's not enough to answer the
|  > |  > question: C++ raises new issues.
|
|  > | But we do have a starting point; C has some things in common with
|  > |      C++,
|
|  > that is also true.  But their type systems are quite different in very
|  > subtle ways that makes Matt's a real issue.
|
|  > Also, when considering features for C++, I believe we should their
|  > interactions with the standard library -- not just the core language
|  > details.  If restrict is going to work only for pointers whereas,
|  > general iterators are treated as second-zone entities then, in my
|  > opinion, that causes sufficient grips not to consider it.
|
| Do you think that we should drop volatile as well?  C++ iterators don't
| support it either.

"volatile" was in the core language before we got "iterators" in the
library, so my statement above does not apply.

But, if you feel like we should drop volatile, I would not stand in
your way.

[...]

| As I said, one option is to allow the keyword, but to not give it any
| semantics.
|
| If giving it the same semantics as in C doesn't cause any problems (and
| I don't think it would), why not?

C++ has overloads, C does not.  How should restrict work with respect
to overloading?

I'm of the opinion that it would be a mistake to just "feature"
C++ with C notion of restrict without a thorough analyzis of the C++
type system and how restrict is supposed to work with it.

| Beyond that, as you say, the committee resources are best spent
| elsewhere (IMHO).

The trouble is that, C notion of restrict was designed for a type
system less richer.  Pulling it in C++ is not just a matter of
extending the set of C++ keywords, IMO.

[...]

| innovations), but if it does, it would be foolish to not take his work
| into account.

I'm not suggesting such a hypothetical contribution should not be
taken into account.  I'm saying that I'm skeptical that it is just a
matter of extending the set of C++ keywords.

--
                                                       Gabriel Dos Reis
                                           gdr@integrable-solutions.net


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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                       ]

Gabriel Dos Reis wrote:
>=20
> Falk Tannh=E4user <falk.tannhauser@crf.canon.fr> writes:
> | While we are at it: Wouldn't allowing const_cast between iterators
> | be useful (for example, for implementing the non-const version of a
> | function using the overloaded const version of the function)?
>=20
> I'm profondly doubtful about the need for such a general type
> perversion facility.  I can see needs for the implicit conversion
>=20
>     iterator -> const_iterator
>=20
> but, I've yet to see real world example of good sofwtare engineering
> where the general cast you're talking about is needed.

I was thinking about situations like this:

class some_container
{
public:
  typedef ... value_type;
  typedef ... iterator;
  typedef ... const_iterator;

  const_iterator find(value_type const&) const; // const correct,
  // returns a const_iterator pointing into the container

  iterator find(value_type const& val)
  { // forward to const 'find' member function to avoid code duplication
    some_container const& const_myself =3D *this;
    return const_cast<iterator>( const_myself.find(val) );
    // const_cast is safe here!
  }
};

Falk

---
[ 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                       ]

llewelly <llewelly.at@xmission.dot.com> wrote in message
news:<86vfjx0yml.fsf@Zorthluthik.local.bar>...
> Matt Austern <austern@well.com> writes:

>  > But second, and even more important: we don't have any idea how
>  > restrict would fit into C++'s type system.  We know how it fits
>  > into C's type system, but that's not enough to answer the question:
>  > C++ raises new issues.

> But we do have a starting point; C has some things in common with
>      C++, and there are C++ implementations which provide C restrict
>      semantics for C++. I can see that it would be a lot of hard work
>      to figure out how well the semantics of a particular restrict
>      extension interacts with the rest of C++, but it's a start.

> I'll admit I didn't look very hard, but I couldn't find anything on
>      the comittee's website about restrict for C++.

One simple solution would be to say that the keyword is allowed where
ever it is allowed in C, but that it has no semantics in C++.  (A C
implementation can legally ignore it, so we are just imposing one of the
legal alternatives.)

My impression is that it can also be taken over "as is"; it can only be
applied to pointers, and pointers in C and C++ are pretty similar.  But
that's a first impression, without having really tried to analyse
anything.  For starters, I suspect that if we can meaningfully apply
restrict to pointers, we would also want to apply it to references.

Of course, when considering restrict, we should keep in mind that it is
an optimizing measure, much like inline.  Very much like inline, in
fact@-- the compiler technology to make it unnecessary (as has happened
to register) is known, it is not widespread, nor is it likely to become
wide spread quickly.  But it probably will become widespread sometime,
so if we procrastinate enough... :-)

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


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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                       ]

Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message
news:<m3n059kxjm.fsf@uniton.integrable-solutions.net>...
> Matt Austern <austern@well.com> writes:

> | llewelly <llewelly.at@xmission.dot.com> writes:

> |  > "Peter C. Chapin" <pchapin@sover.net> writes:
> |  > [snip]
> |  >  > How the STL would or would not interact with restricted
> |  >  > pointers isn't entirely clear to me. It is an interesting
> |  >  > question, however.

> |  > restrict_iterator ?

> | That's putting the cart before the horse.  First: we don't have
> | iterators for everything that can go into the type system.  (We have
> | X::const_iterator but not X::volatile_iterator.)  I certainly hope
> | we

> /me suggests X::iterator<cv-qualifier> to cut down complexity ;-p

Heh, that's cool. A new type of template parameter: a cv-qualifier.
Just imagine what the meta-programming croud will be able to do with
this.

(I'm just joking, of course.  I think that some way of specializing on
cv-qualification probably would be useful in meta-programming, but I
suspect that trying to twist even more out of the already abused
template syntax might not result in the clearest code.)

> | don't need iterators for all eight possible combinations for const,
> | volatile, and restrict.  But second, and even more important: we
> | don't have any idea how restrict would fit into C++'s type system.
> | We know how it fits into C's type system, but that's not enough to

> But does it really fit into the C's type system?
> I really have no idea.
> My impression is that it is more a description of implementation
> detail than anything else...

Quite.  It is part of the type system, but I'm not too sure why, or what
it has to do there.  I rather suspect that it is there simply because
they had to put it somewhere, and anywhere else seemed worse.

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


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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                       ]

Falk Tannh   user <falk.tannhauser@crf.canon.fr> writes:

| Gabriel Dos Reis wrote:
| >
| > Matt Austern <austern@well.com> writes:
| > | That's putting the cart before the horse.  First: we don't have
| > | iterators for everything that can go into the type system.  (We have
| > | X::const_iterator but not X::volatile_iterator.)  I certainly hope we
| >
| > /me suggests X::iterator<cv-qualifier> to cut down complexity ;-p
| While we are at it: Wouldn't allowing const_cast between iterators
| be useful (for example, for implementing the non-const version of a
| function using the overloaded const version of the function)?

I'm profondly doubtful about the need for such a general type
perversion facility.  I can see needs for the implicit conversion

    iterator -> const_iterator

but, I've yet to see real world example of good sofwtare engineering
where the general cast you're talking about is needed.

--
                                                        Gabriel Dos Reis
                                            gdr@integrable-solutions.net


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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                       ]

Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message
news:<m3u0zemuyp.fsf@uniton.integrable-solutions.net>...
 > llewelly <llewelly.at@xmission.dot.com> writes:

 > | Matt Austern <austern@well.com> writes:

 > |  > But second, and even more important: we don't have any idea how
 > |  > restrict would fit into C++'s type system.  We know how it fits
 > |  > into C's type system, but that's not enough to answer the
 > |  > question: C++ raises new issues.

 > | But we do have a starting point; C has some things in common with
 > |      C++,

 > that is also true.  But their type systems are quite different in very
 > subtle ways that makes Matt's a real issue.

 > Also, when considering features for C++, I believe we should their
 > interactions with the standard library -- not just the core language
 > details.  If restrict is going to work only for pointers whereas,
 > general iterators are treated as second-zone entities then, in my
 > opinion, that causes sufficient grips not to consider it.

Do you think that we should drop volatile as well?  C++ iterators don't
support it either.

I can think of at least three approachs to restrict in C++:

   - simply allow the keyword where ever it is allowed in C, without
     giving it any semantics (which is a legal implementation in C),

   - allow it every where that C does (e.g. only on pointers to a POD),
     with the exact same semantics as C,

   - extend its semantics to cover things like pointers to C++ classes,
     etc.

All of these options are valid, and have some value (if only to allow
C++ programs to use `extern "C"' functions which declare their
parameters restrict).

Note that the semantics of restrict can only affect pointers.  And C++
pointers are similar to those in C.  So it probably wouldn't be that
difficult to integrate it.

 > Restrict poses less problem to the C standard library than it poses to
 > the C++ standard library.  The C standard library is almost raw
 > pointer based.  The C++ standard library takes a different route,
 > where emphasis is put on higher-level abstractions (types,
 > parameterized algorithms and data structures, ...) and efficiency.

 > |         and there are C++ implementations which provide C restrict
 > |      semantics for C++. I can see that it would be a lot of hard
 > |      work to figure out how well the semantics of a particular
 > |      restrict extension interacts with the rest of C++, but it's a
 > |      start.

 > There are lots of half-backed extensions in many (popular) compilers,
 > that is acceptable situation, because compilers can always emit
 > "sorry, not yet implemented" and that is usually accepted.  For a
 > language design, it is really different.  And given the benefit (which
 > I do not diminish, but which I consider negligible compared to other
 > functionalities), I would say that committee resource is best spent
 > elsewhere than on this curiously feature.  But, that is just me.

Personally, I agree with you.  I think that the C committees resources
had best been spent elsewhere as well:-).  For reasons of C
compatibility, however, I do think we have to at least accept something
along the lines of:

     #ifdef __cplusplus
     extern "C" {
     #endif

     void f( int * restrict ) ;

     #ifdef __cplusplus
     }
     #endif

As I said, one option is to allow the keyword, but to not give it any
semantics.

If giving it the same semantics as in C doesn't cause any problems (and
I don't think it would), why not?

Beyond that, as you say, the committee resources are best spent
elsewhere (IMHO).

The problem, of course, is that the committee doesn't have any resources
that actually belong to it.  If someone wants to work on restrict, and
doesn't want to work on something that you or I (or even an overwhelming
majority of the committee) thinks is more important, he will, and the
committee can't really do anything about it.  Somehow, I don't expect
this to be the case with restrict (it happens most often with exotic new
innovations), but if it does, it would be foolish to not take his work
into account.

In the mean time: if the above bit of code can appear in a header file
without breaking the compile, it's enough for me.

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


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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                       ]

dtmoore@rijnh.nl (Dave Moore) wrote in news:306d400f.0404140521.758a4046
@posting.google.com:

>     I was hoping there would be some STL-analogue for the "restrict"
> designator allowed by some compilers for raw-pointers.  For compilers
> that implement it, I have found that using "restrict" with raw
> pointers can give significant speed-ups in many cases, which is
> relevant for me as a writer of scientific code.

Restricted pointers are a feature of C99, so C compilers supporting that
standard are supposed to at least acknowledge the "restrict" reserved word
(I believe that providing better optimizations for restricted pointers is
a separate matter). The C++98 standard does not have restricted pointers.
Whether or not restricted pointers become a part of the next revision of
C++ remains to be seen. I'd also be interested to know what the thinking
is on that. I would imagine that some C++ compilers may already implement
restricted pointers... particularly if the vendor has a corresponding C99
compiler.

How the STL would or would not interact with restricted pointers isn't
entirely clear to me. It is an interesting question, however.

Peter


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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                       ]

"Peter C. Chapin" <pchapin@sover.net> writes:
[snip]
 > How the STL would or would not interact with restricted pointers isn't
 > entirely clear to me. It is an interesting question, however.

restrict_iterator ?


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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                       ]

llewelly <llewelly.at@xmission.dot.com> writes:

 > "Peter C. Chapin" <pchapin@sover.net> writes:
 > [snip]
 >  > How the STL would or would not interact with restricted pointers isn't
 >  > entirely clear to me. It is an interesting question, however.
 >
 > restrict_iterator ?

That's putting the cart before the horse.  First: we don't have
iterators for everything that can go into the type system.  (We have
X::const_iterator but not X::volatile_iterator.)  I certainly hope we
don't need iterators for all eight possible combinations for const,
volatile, and restrict.  But second, and even more important: we
don't have any idea how restrict would fit into C++'s type system.
We know how it fits into C's type system, but that's not enough to
answer the question: C++ raises new issues.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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                       ]

Matt Austern <austern@well.com> writes:

| llewelly <llewelly.at@xmission.dot.com> writes:
|
|  > "Peter C. Chapin" <pchapin@sover.net> writes:
|  > [snip]
|  >  > How the STL would or would not interact with restricted pointers isn't
|  >  > entirely clear to me. It is an interesting question, however.
|  >
|  > restrict_iterator ?
|
| That's putting the cart before the horse.  First: we don't have
| iterators for everything that can go into the type system.  (We have
| X::const_iterator but not X::volatile_iterator.)  I certainly hope we

/me suggests X::iterator<cv-qualifier> to cut down complexity ;-p

| don't need iterators for all eight possible combinations for const,
| volatile, and restrict.  But second, and even more important: we
| don't have any idea how restrict would fit into C++'s type system.
| We know how it fits into C's type system, but that's not enough to

But does it really fit into the C's type system?
I really have no idea.
My impression is that it is more a description of implementation
detail than anything else...

| answer the question: C++ raises new issues.

--
                                                        Gabriel Dos Reis
                                            gdr@integrable-solutions.net


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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                       ]

Matt Austern <austern@well.com> writes:

 > llewelly <llewelly.at@xmission.dot.com> writes:
 >
 >  > "Peter C. Chapin" <pchapin@sover.net> writes:
 >  > [snip]
 >  >  > How the STL would or would not interact with restricted pointers isn't
 >  >  > entirely clear to me. It is an interesting question, however.
 >  >
 >  > restrict_iterator ?
 >
 > That's putting the cart before the horse.  First: we don't have
 > iterators for everything that can go into the type system.  (We have
 > X::const_iterator but not X::volatile_iterator.)  I certainly hope we
 > don't need iterators for all eight possible combinations for const,
 > volatile, and restrict.

Maybe we need a way to add qualifiers to iterators. I can see why you
     hope we don't need iterators for all the possible combinations
     (note, I was thinking 16 and not 8, but I was counting
     reverse_iterators), but we do have pointers for all of those
     combinations (but not reverse pointers).

 > But second, and even more important: we
 > don't have any idea how restrict would fit into C++'s type system.
 > We know how it fits into C's type system, but that's not enough to
 > answer the question: C++ raises new issues.

But we do have a starting point; C has some things in common with
     C++, and there are C++ implementations which provide C restrict
     semantics for C++. I can see that it would be a lot of hard work
     to figure out how well the semantics of a particular restrict
     extension interacts with the rest of C++, but it's a start.

I'll admit I didn't look very hard, but I couldn't find anything on
     the comittee's website about restrict for C++.



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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                       ]

Gabriel Dos Reis wrote:
>
> Matt Austern <austern@well.com> writes:
> | That's putting the cart before the horse.  First: we don't have
> | iterators for everything that can go into the type system.  (We have
> | X::const_iterator but not X::volatile_iterator.)  I certainly hope we
>
> /me suggests X::iterator<cv-qualifier> to cut down complexity ;-p
While we are at it: Wouldn't allowing const_cast between iterators
be useful (for example, for implementing the non-const version of a
function using the overloaded const version of the function)?

Falk


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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                       ]

"llewelly" <llewelly.at@xmission.dot.com> wrote in message
news:86vfjx0yml.fsf@Zorthluthik.local.bar...

| I'll admit I didn't look very hard, but I couldn't find anything on
|      the comittee's website about restrict for C++.

I have proposed that an assertion language might be used to specify what
restrict is used for. For example,

template< class T >
bool not_aliasing( const T* t1, const T* t2, size_t sz )
{
   return std::less<T*>( t1 + sz, t2 ) || std::less<T*>( t2 + sz, t1 );
}

// declaration
template< class T >
void fast_xx( const T* from, T* to, size_t n )
precondition { not_aliasing( from, to, n ); };

// definition
template< class T >
void fast_xx( const T* from, T* to, size_t n )
{
    for( size_t i = 0; i < n; ++i )
        // access arrays somehow
        // compiler must deduce (a) that the precondition is not violated
        //                                   (b) whether it can actually
understand the precondition to optimize the loop
}

whether this is feasable for compilers, I don't know.

br

Thorsten



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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                       ]

llewelly <llewelly.at@xmission.dot.com> writes:

| Matt Austern <austern@well.com> writes:
|
|  > llewelly <llewelly.at@xmission.dot.com> writes:
|  >
|  >  > "Peter C. Chapin" <pchapin@sover.net> writes:
|  >  > [snip]
|  >  >  > How the STL would or would not interact with restricted pointers isn't
|  >  >  > entirely clear to me. It is an interesting question, however.
|  >  >
|  >  > restrict_iterator ?
|  >
|  > That's putting the cart before the horse.  First: we don't have
|  > iterators for everything that can go into the type system.  (We have
|  > X::const_iterator but not X::volatile_iterator.)  I certainly hope we
|  > don't need iterators for all eight possible combinations for const,
|  > volatile, and restrict.
|
| Maybe we need a way to add qualifiers to iterators. I can see why you
|      hope we don't need iterators for all the possible combinations
|      (note, I was thinking 16 and not 8, but I was counting
|      reverse_iterators), but we do have pointers for all of those
|      combinations (but not reverse pointers).

that is true.  But do we really want to replicate pointer artifacts at
every higher level os abstractions, e.g. iterator?

|  > But second, and even more important: we
|  > don't have any idea how restrict would fit into C++'s type system.
|  > We know how it fits into C's type system, but that's not enough to
|  > answer the question: C++ raises new issues.
|
| But we do have a starting point; C has some things in common with
|      C++,

that is also true.  But their type systems are quite different in very
subtle ways that makes Matt's a real issue.

Also, when considering features for C++, I believe we should their
interactions with the standard library -- not just the core language
details.  If restrict is going to work only for pointers whereas,
general iterators are treated as second-zone entities then, in my
opinion, that causes sufficient grips not to consider it.
Restrict poses less problem to the C standard library than it poses to
the C++ standard library.  The C standard library is almost
raw pointer based.  The C++ standard library takes a different route,
where emphasis is put on higher-level abstractions (types,
parameterized algorithms and data structures, ...) and efficiency.

|         and there are C++ implementations which provide C restrict
|      semantics for C++. I can see that it would be a lot of hard work
|      to figure out how well the semantics of a particular restrict
|      extension interacts with the rest of C++, but it's a start.


There are lots of half-backed extensions in many (popular) compilers,
that is acceptable situation, because compilers can always emit
"sorry, not yet implemented" and that is usually accepted.
For a language design, it is really different.  And given the benefit
(which I do not diminish, but which I consider negligible compared to
other functionalities), I would say that committee resource is best
spent elsewhere than on this curiously feature.  But, that is just me.


| I'll admit I didn't look very hard, but I couldn't find anything on
|      the comittee's website about restrict for C++.

yes, but that does not mean the issue is not being considered nor
debated on committee reflectors :-)


--
                                                        Gabriel Dos Reis
                                            gdr@integrable-solutions.net


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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                       ]

Matt Austern <austern@well.com> wrote in message news:<m24qritdou.fsf@Matt-Austerns-Computer.local>...
> llewelly <llewelly.at@xmission.dot.com> writes:
>
>  > "Peter C. Chapin" <pchapin@sover.net> writes:
>  > [snip]
>  >  > How the STL would or would not interact with restricted pointers isn't
>  >  > entirely clear to me. It is an interesting question, however.
>  >
>  > restrict_iterator ?
>
> That's putting the cart before the horse.  First: we don't have
> iterators for everything that can go into the type system.  (We have
> X::const_iterator but not X::volatile_iterator.)  I certainly hope we
> don't need iterators for all eight possible combinations for const,
> volatile, and restrict.  But second, and even more important: we
> don't have any idea how restrict would fit into C++'s type system.
> We know how it fits into C's type system, but that's not enough to
> answer the question: C++ raises new issues.
>

What if you only provided restrict_iterator to std::valarray, which
apparently already has some associated anti-aliasing requirements.
And even in the general case, it seems like the problem could be (at
least partially) addressed by defining a new iterator category
std::restricted_iterator_tag derived from
std::random_access_iterator_tag.  Then a new template specialization
could be defined for any STL-feature affected by the anti-aliasing
restrictions.  Perhaps I am being naive, since I have no experience
with compiler-design or STL implementation, but this doesn't seem
unfeasible to me.  Hopefully this will stimulate further discussion
which will enlighten me if I am misguided.

TIA,  Dave Moore


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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                       ]

I was hoping to discover if there exists currently (although I guess
not) or is a plan to add a general way of designating STL-containers
to be non-aliasing, in order to allow the associated optimizations
during compilation.  The only information I have come across regarding
aliasing in the STL is the (rather vague) statement in the standard
about std::valarray being defined to be free of "certain types" of
aliasing.

    I was hoping there would be some STL-analogue for the "restrict"
designator allowed by some compilers for raw-pointers.  For compilers
that implement it, I have found that using "restrict" with raw
pointers can give significant speed-ups in many cases, which is
relevant for me as a writer of scientific code.

    However, now my programs are getting more complicated, and it is
getting increasingly difficult to maintain/adapt my own libraries that
use "restrict" with raw-pointers.  Thus I really want to migrate to
STL-derived/compatible code, but it seems like I will have to give up
using "restrict".

    Or perhaps there is a reason why the STL no longer needs artifactrs
like "restrict" and I am just not aware of it ... I have been
programming in C++ since 1995 or so, but I am not a software
professional ... just a scientist who likes to be able to read his
code without deciphering it (ergo no FORTRAN or C :*).  So it is
entirely possible that I have missed something significant.

    In any case, I would appreciate any light that the gurus out there
can shed on this issue.  Thanks in advance ...


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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                       ]