Peter Dimov wrote:

> Would introducing a data() member function solve this problem, or the
> problem in general?

It would be better. Nevertheless I feel unhappy
with this approach.
I always found that asymmetry of concepts is
the thing that gives a lot of pain in C++.

The normal vector way to contact a fortran library is

std::vector<double> v;
[...]
call_fortran_stuff(&v[0]);


So I think there is no need to complicate the use
of STL again. vector and valarray should be kept
in symmetry for those features that they (could) share.

We should consider the decisison to let
valarray<...>::operator[] const; return a value
as a decisison that had unwanted effects on its
usability and I look forward to a _clean_ fix,
which does not need any further repair in the future.

I fear that with my policy-class approach
there are other problems which may crop up, so this is
why I ask You again to look at it and to find them.


Markus








---
[ 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.research.att.com/~austern/csc/faq.html                ]

Markus Werle <numerical.simulation@web.de> writes:

[...]

| But here we have it: premature optimization.

Or: speculative optimization :-)

| Again and again people who first used std::vector
| fall into the trap of a defect which can be easily avoided.

More importantly, it makes valarray<> unusable in most real world
programs.  There are plenty of numerical routines out there written in
C and passing valarray<> data to them for inspection is not as trivial
as it should have been or intented :-(

FYI, the GCC/g++ changed that operator to return a const reference.

| I for myself can think of a lot of cases in which I wished
| to have all the functionality of valarray, but a return type of
| const reference, (e.g. valarray<map<size_t, double> > for
| compressed matrices)
| and so I propose an extension of valarray which
| I think does not break existing, conformant code.

I have trouble to conceive a real-world program which would be broken
if that operator's return type were changed to const reference.  So
let keep it simple and straight.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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.research.att.com/~austern/csc/faq.html                ]

On Thu, 14 Feb 2002 18:13:39 GMT, Gabriel Dos Reis
<dosreis@cmla.ens-cachan.fr> wrote:

>Markus Werle <numerical.simulation@web.de> writes:
>
>[...]
>
>| But here we have it: premature optimization.
>
>Or: speculative optimization :-)

But it might be a big optimisation. There is no way to get a pointer
or reference to an element in a const valarray, hence there is no way
to alias an element in a const valarray, hence the compiler can
generate code that assumes no aliasing, which means that valarray has
a hope in hell of matching Fortran performance.

>
>| Again and again people who first used std::vector
>| fall into the trap of a defect which can be easily avoided.
>
>More importantly, it makes valarray<> unusable in most real world
>programs.  There are plenty of numerical routines out there written in
>C and passing valarray<> data to them for inspection is not as trivial
>as it should have been or intented :-(
>
>FYI, the GCC/g++ changed that operator to return a const reference.

Why didn't they just use the __restrict__ extension keyword inside all
the const valarray methods, allowing their valarray to be faster than
anyone elses, assuming gcc is good at using its own __restrict__
keyword? Or are compilers good enough without this?

>
>| I for myself can think of a lot of cases in which I wished
>| to have all the functionality of valarray, but a return type of
>| const reference, (e.g. valarray<map<size_t, double> > for
>| compressed matrices)
>| and so I propose an extension of valarray which
>| I think does not break existing, conformant code.
>
>I have trouble to conceive a real-world program which would be broken
>if that operator's return type were changed to const reference.  So
>let keep it simple and straight.

But any implementation that already uses inline assembler or
extensions like __restrict__ and assumes no aliasing will have to be
rewritten and will slow down horribly in the process. Perhaps some
compilers have been written to know that const valarrays can't be
aliased? OTOH, I am unaware of any implementaton that does optimise
valarray in this manner. Which is a shame.

Obviously, if the optimisation has been attempted and shown to have
little benefit, then we should definitely shift to the const reference
return, since that has greater utility.

Tom

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Pete Becker <petebecker@acm.org> writes:

| Markus Werle wrote:
| >
| > I for myself can think of a lot of cases in which I wished
| > to have all the functionality of valarray, but a return type of
| > const reference, (e.g. valarray<map<size_t, double> > for
| > compressed matrices)
|
| valarray was designed to be instantiated with numeric types, not
| composite types.

That doesn't invalide the real problems posed by making that operator
returning a const.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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.research.att.com/~austern/csc/faq.html                ]

tom_usenet@hotmail.com (tom_usenet) writes:

| On Thu, 14 Feb 2002 18:13:39 GMT, Gabriel Dos Reis
| <dosreis@cmla.ens-cachan.fr> wrote:
|
| >Markus Werle <numerical.simulation@web.de> writes:
| >
| >[...]
| >
| >| But here we have it: premature optimization.
| >
| >Or: speculative optimization :-)
|
| But it might be a big optimisation.

Do you have real-world figures?

| There is no way to get a pointer
| or reference to an element in a const valarray, hence there is no way
| to alias an element in a const valarray, hence the compiler can
| generate code that assumes no aliasing, which means that valarray has
| a hope in hell of matching Fortran performance.

There are things you're missing:

  1) An object of type valarray is already supposed to be free of
     aliasing.  So the argument of aliasing is moot -- the axiom is
     already there.

  2) Objects of valarray types are rarely const when they come to
     life.

  3) A valarray can be accessed by a const reference -- as any other
     object -- but just because that reference is const doesn't imply
     aliasness.

[...]

| >FYI, the GCC/g++ changed that operator to return a const reference.
|
| Why didn't they just use the __restrict__ extension keyword inside all
| the const valarray methods, allowing their valarray to be faster than
| anyone elses, assuming gcc is good at using its own __restrict__
| keyword? Or are compilers good enough without this?

I think you're misunderstanding the fundamental problem:  The problem
at hand isn't what is happening inside valarray<>, it concerns what is
happining in the use of valarray<>s.  The following doesn't work:

   // a hook for, say, an external Fortran library
   // The data pointed by the argument as guaranteed not to be
   // modified, just inspected.
   extern "C" void do_somejob(const double*, size_t, double*);

   void f(const valarray<double>& a, valarray<double>& b)
   {
      do_somejob(&a[0], a.size(), &b[0]);
   }

It isn't about __restrict__.

| >| I for myself can think of a lot of cases in which I wished
| >| to have all the functionality of valarray, but a return type of
| >| const reference, (e.g. valarray<map<size_t, double> > for
| >| compressed matrices)
| >| and so I propose an extension of valarray which
| >| I think does not break existing, conformant code.
| >
| >I have trouble to conceive a real-world program which would be broken
| >if that operator's return type were changed to const reference.  So
| >let keep it simple and straight.
|
| But any implementation that already uses inline assembler or
| extensions like __restrict__ and assumes no aliasing will have to be
| rewritten and will slow down horribly in the process.

I think you're confused.  A valarray is already assumed to be free of
alias, and the programmer is expected not to break that assumption.
Not just because that operator will return a const reference means
the free-aliasness assumption is broken.

[...]

| Obviously, if the optimisation has been attempted and shown to have
| little benefit, then we should definitely shift to the const reference
| return, since that has greater utility.

People trying to use valarray<> are not dreaming, they're facing real
problems artificially created by oversights.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Gabriel Dos Reis wrote:

> More importantly, it makes valarray<> unusable in most real world
> programs.  There are plenty of numerical routines out there written in
> C and passing valarray<> data to them for inspection is not as trivial
> as it should have been or intented :-(
>
> FYI, the GCC/g++ changed that operator to return a const reference.

Yes, I fell into the trap when gcc-compliant code did
not compile with intel's C++.
IMHO this is the wrong way to go either. I dislike the freedom
gcc developers took without noticing me in the README.
ISO conformance is a must, so we must change the standard if it
does not fit, not our "private" library.

> | I for myself can think of a lot of cases in which I wished
> | to have all the functionality of valarray, but a return type of
> | const reference, (e.g. valarray<map<size_t, double> > for
> | compressed matrices)
> | and so I propose an extension of valarray which
> | I think does not break existing, conformant code.
>
> I have trouble to conceive a real-world program which would be broken
> if that operator's return type were changed to const reference.  So
> let keep it simple and straight.

I disagree here. Both ways have their pros and cons
and if You are honest they balance quite well.
Those who struggle with connection to fortran and C
need the reference (which speeds code by a factor of 10 or more)
and those who have a Pentium 4 and the intel compiler
need the copy (sometimes), because this may speed up
by a factor of 10 or more due to funny register magic
I do not want to learn about.

Again: both positions are right in some case and
wrong in some others. Face it.

My approach is to be fair: the solution is easy to
achieve, does not strike the innocent and gives
Scott Meyers the opportunity to add the valarray
chapter he forgot in "Effective STL".

Let us stop a never ending fruitless
discussion with a quite elegant whip.

Have You any argument against my approach?
Let me hear. If not, vote for it and stop insisting
on the const reference. You are right and You get what
You want while others may have their copy, too.


Markus

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Pete Becker <petebecker@acm.org> writes:

| Gabriel Dos Reis wrote:
| >
| > Pete Becker <petebecker@acm.org> writes:
| >
| > | Markus Werle wrote:
| > | >
| > | > I for myself can think of a lot of cases in which I wished
| > | > to have all the functionality of valarray, but a return type of
| > | > const reference, (e.g. valarray<map<size_t, double> > for
| > | > compressed matrices)
| > |
| > | valarray was designed to be instantiated with numeric types, not
| > | composite types.
| >
| > That doesn't invalide the real problems posed by making that operator
| > returning a const.
| >
|
| Huh? How does returning a const reference make it reasonable to compute
| the cosine of a valarray<map<size_t,double> >?

I didn't say it makes it reasonable to compute the cosine of a
valarray<map<size_t, double> >.  I said, your remark doesn't
invalidate the problem caused by that operator returning a value
instead of const reference.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Markus Werle <numerical.simulation@web.de> writes:

| Gabriel Dos Reis wrote:
|
| > More importantly, it makes valarray<> unusable in most real world
| > programs.  There are plenty of numerical routines out there written in
| > C and passing valarray<> data to them for inspection is not as trivial
| > as it should have been or intented :-(
| >
| > FYI, the GCC/g++ changed that operator to return a const reference.
|
| Yes, I fell into the trap when gcc-compliant code did
| not compile with intel's C++.
| IMHO this is the wrong way to go either.

I'm disposed to be convinced.

| I dislike the freedom
| gcc developers took without noticing me in the README.
| ISO conformance is a must, so we must change the standard if it
| does not fit, not our "private" library.

ISO conformance isn't a goal in itself.  The tool has no practical
value if it can't be used.  When a strict ISO conformance leads to
unuable tool, then something must be done.  That is why we DR
submissions. I've choosed not to wait -- after several papers and
discussions about the issue. Another example is accessiblity. A strict
conformant implementation makes the helper classes unuable.

| > | I for myself can think of a lot of cases in which I wished
| > | to have all the functionality of valarray, but a return type of
| > | const reference, (e.g. valarray<map<size_t, double> > for
| > | compressed matrices)
| > | and so I propose an extension of valarray which
| > | I think does not break existing, conformant code.
| >
| > I have trouble to conceive a real-world program which would be broken
| > if that operator's return type were changed to const reference.  So
| > let keep it simple and straight.
|
| I disagree here.

If you have concrete real-world examples, I would be very glad to
discuss it.

| Both ways have their pros and cons
| and if You are honest they balance quite well.

I don't know I'm supposed to take that.

| Those who struggle with connection to fortran and C
| need the reference (which speeds code by a factor of 10 or more)

The valarray<> class was primary designed to serve also those people.

| and those who have a Pentium 4 and the intel compiler
| need the copy (sometimes), because this may speed up
| by a factor of 10 or more due to funny register magic
| I do not want to learn about.

I'll ask again: Do you have a real world case where returning a const
reference makes any difference in performance?

[...]

| Let us stop a never ending fruitless
| discussion with a quite elegant whip.
|
| Have You any argument against my approach?

Yes: It ignores reality.  The issue isn't about Stellar Abstract
Algebra.  Would you mind to give us concrete example (i.e. a
program) we can start with?

Also, I find your posting unncessarily personnal and I'm surprised to
fint it passed the moderation filter.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Pete Becker wrote:

> Markus Werle wrote:
>>
>> I for myself can think of a lot of cases in which I wished
>> to have all the functionality of valarray, but a return type of
>> const reference, (e.g. valarray<map<size_t, double> > for
>> compressed matrices)
>
> valarray was designed to be instantiated with numeric types, not
> composite types.

Like vector<bool> was designed for bools?

My example is from numerics. _That_ is what valaray was designed for.
I try to extend it to fit even better.

Generic programming has brought us far beyond what we expected
and if I decide that the slicing in valarray fits my purposes
who is the one to forbid me to use a composite type here?

I still am missing any good argument against my proposal.

> What should the function cos do when passed an argument of type
> valarray<map<size_t, double> >?

Give me an error message. Valarray was designed for values.
Do You expect list<map<size_t, double> >::sort() to work
in the way You need it? Do You sort maps? Do You disallow
list<map<etc>>?


And AFAIK I am allowed to specialize valarray<MyType>::cos, am I?

\begin{flame}
And if the commitee at last would allow
not only the full specialization of STL functions
but also the partial specialization (just another useless
assymetry - it just _happened_, maybe just forgotten to take it in)
then I could specialize valarray::cos for any case I can think of,
even when I inherit from or use STL within my own templates.
\end{flame}


But hey! What I propose is
- cheap or easy to achieve,
- does not invalidate current code,
- only extends valarray towards flexibility



Markus

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Pete Becker <petebecker@acm.org> writes:

| Gabriel Dos Reis wrote:
| >
| > Pete Becker <petebecker@acm.org> writes:
| >
| > | Markus Werle wrote:
| > | >
| > | > I for myself can think of a lot of cases in which I wished
| > | > to have all the functionality of valarray, but a return type of
| > | > const reference, (e.g. valarray<map<size_t, double> > for
| > | > compressed matrices)
| > |
| > | valarray was designed to be instantiated with numeric types, not
| > | composite types.
| >
| > That doesn't invalide the real problems posed by making that operator
| > returning a const.
| >
|
| Huh? How does returning a const reference make it reasonable to compute
| the cosine of a valarray<map<size_t,double> >?

The two issue are orthogonal, aren't they?

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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.research.att.com/~austern/csc/faq.html                ]

> Also, I find your posting unncessarily personnal and I'm surprised to
> find it passed the moderation filter.

I am sorry for this. I wanted to _address_ You personally,
not to attack You.
I will try to get to the nitty-gritty without hurting You again.

> | I dislike the freedom
> | gcc developers took without noticing me in the README.
> | ISO conformance is a must, so we must change the standard if it
> | does not fit, not our "private" library.
>
> ISO conformance isn't a goal in itself.

That is true. I really would like to add some words
about gcc and user information or release policy,
but I feel like going offtrack here
(and of course would become very personal ;-) ).

Since I want to reach another goal which obsoletes
this discussion I will not go into details here.

> The tool has no practical value if it can't be used.

I agree. Valarray is useless without operator[]
returning a reference. Maybe it is even useless without
operator[] returning a value for others.

> When a strict ISO conformance leads to
> unuable tool, then something must be done.

Yes. I agree, but the question is: What must be done.
Let us discuss this thoroughly.

> That is why we DR submissions. I've choosed not to wait --
> after several papers and discussions about the issue.

I have read some of Your submissions to newsgroups via google.
(Where can I read about Your DR?)
You have gone a long way indeed. I think most of what You
propose is reasonable, but I feel others had their arguments,
too. Maybe I am wrong with this. Maybe things change in
the future.

The lecture of the huge threads brought to me the wish to
satisfy both sides at once. The thing I propose seems to
me like a perfect resolution, because it is not a compromise
but perfect satisfaction of both opinions - and even more.

The ISO commitee is trapped through history.
An accident occured and it is always a difficult decision to
change a standard back and forth invalidating existing code.
(even if the change is reasonable and has the strongest
arguments for it).

Now there is a chance. Policy driven implementations
of STL can do both:
- keep valid code valid. (You do not know what
  people do during copy)
- provide a conformant way to heal defects.
- Things stay as they are and become totally different at the
  same time.

So even if I did not find any machine where copying
of doubles is cheaper than taking the reference,
my proposal is attractive because it makes it easier to vote
for a change.

> Another example is accessiblity. A strict
> conformant implementation makes the helper classes unuable.
>
> | > | I for myself can think of a lot of cases in which I wished
> | > | to have all the functionality of valarray, but a return type of
> | > | const reference, (e.g. valarray<map<size_t, double> > for
> | > | compressed matrices)
> | > | and so I propose an extension of valarray which
> | > | I think does not break existing, conformant code.
> | >
> | > I have trouble to conceive a real-world program which would be broken
> | > if that operator's return type were changed to const reference.  So
> | > let keep it simple and straight.
> |
> | I disagree here.
>
> If you have concrete real-world examples, I would be very glad to
> discuss it.

I will not discuss this. For I want, yes really want
valarray to return a reference. But I do not want others
to pay for it, for whatever reason they cling to copy.

My own experience shows exactly no difference
(using the profiler) between copy or reference.
All valarray operations are perfectly erased by the
optimizer in _any_ case, be it STLport::valarray::operator[]
modified to use references or to return by value.


> | Both ways have their pros and cons
> | and if You are honest they balance quite well.
>
> I don't know I'm supposed to take that.

Let Your arguments weigh 95%.
Alas, the standard was wrong and will stay so,
if we do not propose something more flexible,
inteligent and easy to vote for.

> | Those who struggle with connection to fortran and C
> | need the reference (which speeds code by a factor of 10 or more)
>
> The valarray<> class was primary designed to serve also those people.

Yes, maybe. But others take it now and do things with it, too.
Maybe they need the copy, so what? I am not trying to put them on the
right track. I am not the one to foresee caching/register/optimizer
technology of the 22nd century.

> [...]

> The issue isn't about Stellar Abstract Algebra.
> Would you mind to give us concrete example (i.e. a
> program) we can start with?

Examples are easy to find for both. Benchmarks are
always difficult to design.
I saw optimizers optimizing out copy execution in an
expression template for rather large expressions,
You could show via nm they were gone, but now
my expressions are too big and optimization fails.

Tomorrow somebody has another good idea (after fixing
the other 5 gcc bugs) and g++ wins the race again.
Now intel C++ finally may get their global optimization at
linkage stage to work properly (I fear they will not soon),
and code gets faster just by compiler switch.

How do You want to test reference / copy performance
in such a rapid changing world?

Have You followed the fast-string discussion on
comp.lang.c++.moderated? Every day 2 more benchmarks
with diametral different results.

I am most interested in this:
Is there any strong argument I missed until now, why
it would be stupid idea to resolve this issue my way?

- Is the general idea of a policy template which may
  switch on types in an intelligent way or
  choose referece (or value) all the times in itself
  bad. Have I overlooked something?

- Do You dislike this approach, and why?
  (Take into account that the vote about which policy is the
  default one may be separated from the general discussion
  of policy driven behaviour of STL classes.)




Markus



P.S.: Just because I am curious:
There was some discussion about aliasing: Where can I
find dense information about valarray and aliasing issues?

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr> wrote in message news:<flu1sjzwhv.fsf@jambon.cmla.ens-cachan.fr>...
> I think you're misunderstanding the fundamental problem:  The problem
> at hand isn't what is happening inside valarray<>, it concerns what is
> happining in the use of valarray<>s.  The following doesn't work:
>
>    // a hook for, say, an external Fortran library
>    // The data pointed by the argument as guaranteed not to be
>    // modified, just inspected.
>    extern "C" void do_somejob(const double*, size_t, double*);
>
>    void f(const valarray<double>& a, valarray<double>& b)
>    {
>       do_somejob(&a[0], a.size(), &b[0]);
>    }

Would introducing a data() member function solve this problem, or the
problem in general?

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hi!

I refer to
http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/lwg-closed.html#77
a closed issue I would like to see reopened.

The return type of valarray<SomeClass>::operator[](size_t) const;
is - in constrast to std::vector<SomeClass>:::operator[](size_t) const;
a _value_ and not a const reference, which makes pretty much
sense when SomeClass is an integral type or something small to
fit into registers.

But here we have it: premature optimization.
Again and again people who first used std::vector
fall into the trap of a defect which can be easily avoided.

I for myself can think of a lot of cases in which I wished
to have all the functionality of valarray, but a return type of
const reference, (e.g. valarray<map<size_t, double> > for
compressed matrices)
and so I propose an extension of valarray which
I think does not break existing, conformant code.
The proposal may also fit for other containers.

I may be wrong, this is why I post it here, so do not
hesitate to kill my proposal immediately :-)

Proposal: add to valarray an additional template parameter
with a default value, that allows fine grain control on the
behaviour regarding return types of const member functions:

-------------------------------------------------------------
template<class T,
         class DecisionOnReturnType
               = IntegralTypesReturnByValue> class valarray {

  // [...]
  typedef typename DecisionOnReturnType<T>::Type ConstRetType;

  ConstRetType operator[](size_t) const;
  T& operator[](size_t);
  // [...]

};
--------------------------------------------------------------

with the default case being something like

-------------------------------------------------------------
template<typename T>
class IntegralTypesReturnByValue {
private:
  //maybe use sth. like (!Loki::TypeTraits<T>::isStdIntegral)
  static const bool criterion_ = (sizeof(T) > sizeof(double));

  template<typename C, bool IsBig = true>
  struct Decision { typedef const C& Type; };

  template<typename C>
  struct Decision<C, false> { typedef C Type; };

public:
  typedef typename
  IntegralTypesReturnByValue<T>::Decision<T, criterion_>::Type Type;
};
---------------------------------------------------------------

Maybe namespace std; could also contain 2 other Policy classes
1. template <class T> AlwaysReturnByValueLikeInANSI1998;
2. template <class T> AlwaysReturnByReferenceLikeInFortran;

Number 1 is a hot candidate as default policy,
because no existing code should break then.

What I like most with this approach is that it satisfies both,
me and You, no matter which way we need it. No pressure
on the user in any direction, isn't that fine?

Btw: It takes half an hour for every vendor to adapt his/her
library while it enhances valarray's usefulness in
(most STL vendors really have to look at their valarray
implementation anyway :-) ).

What do You think?


Markus

---
[ 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.research.att.com/~austern/csc/faq.html                ]