f



Left hand operators vs right hand operators

Consider we have a template class A templated over a type Type. We 
create a member operator+(const Type& value). Then we create an non-
member template operator+(const Type& value, const A<Type>& a) to take 
care of the left hand side summation. These two functions have a big 
difference: the former is a normal member function, while the latter is 
a template function. What this means is that implicit conversions are 
not available for calling the templated function.

For example, consider:

(1) A<float> a;
(2) a = a + 1; 
(3) a = 1 + a;

While (2) is ok, (3) does not compile, because of the template function 
omitting the implicit conversion int->float.

Now, one can simulate the implicit conversion by giving the template 
function extra freedoms over the left hand parameter type, call it Type2 
and then explicitly computing it inside the template function (Type 
converted = value;). Then the left-hand operator+ works like the right-
hand operator+, except that the former creates code-bloat. The need for 
simulation also seems a bit like reverse-engineering.

One can see that there clearly is a non-symmetry between the left-hand 
and right-hand operators. Now, my question is, whether there has been 
any considerations on solving this non-symmetry?

In a nutshell, the goal would be to make it easy to describe a left-hand 
operator+ (or any other binary operator) that works equivalently to a 
member right-hand operator+ with templates (with non-template classes 
that is naturally the case).

A first-thought that solves this problem is:
- you could get the wanted behaviour by creating a mechanism to restrict 
the template deduction mechanism: no deduction for 'const Type& value', 
just for 'const A<Type>& a'. In effect, using a flag to denote 'used in 
deduction' or 'not used in deduction' for each parameter. A default 
would be that all parameters are used in the deduction.

Illustrating code of the words above:

template <typename Type>
class A
{
public:
   A<Type> operator+(
      const Type& that) const
   {
      A<Type> result;
      // Do something
      return result;
   }
};

template <typename Type>
A<Type> operator+(const Type& that, 
                  const A<Type>& vec)
{
   A<Type> result;
   // Do something
   return result;
}

template <typename Type, typename Type2>
A<Type> operator-(const Type2& that, 
                  const A<Type>& vec)
{
   A<Type> result;
   // Do something
   return result;
}

template <typename Type, typename Type2>
A<Type> operator*(const Type2& that, 
                  const A<Type>& vec)
{
   // Simulate implicit conversion in the
   // function call.
   Type2 converted = that;

   A<Type> result;
   // Do something using 'converted'
   return result;
}

template <typename Type>
A<Type> operator/(no_decuction: const Type& that, 
                  const A<Type>& vec)
{
   A<Type> result;
   // Do something.
   return result;
}


int main()
{
   A<float> a;

   // Ok, normal member function, implicit conversion to float
   a = a + 1;

   // Does not compile. Not matched by the function template.
   //a = 1 + a;

   // Ok. Matches, but produces code bloat and possibly
   // wrong behavior.
   a = 1 - a;

   // Ok. Matches, but produces code bloat. The simulated
   // conversion also seems a bit lame.
   a = 1 * a;

   // Ok. Just a first-thought, not part of C++.
   a = 1 / a;

   return 0;
}

-- 
Kalle Rutanen
http://kaba.hilvi.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.comeaucomputing.com/csc/faq.html                      ]

0
Kaba
10/8/2006 12:29:23 PM
comp.std.c++ 2720 articles. 1 followers. Post Follow

8 Replies
784 Views

Similar Articles

[PageSpeed] 2

Kaba ha scritto:
> Consider we have a template class A templated over a type Type. We=20
> create a member operator+(const Type& value). Then we create an non-
> member template operator+(const Type& value, const A<Type>& a) to take=20
> care of the left hand side summation. These two functions have a big=20
> difference: the former is a normal member function, while the latter is=
=20
> a template function. What this means is that implicit conversions are=20
> not available for calling the templated function.
>=20
> For example, consider:
>=20
> (1) A<float> a;
> (2) a =3D a + 1;=20
> (3) a =3D 1 + a;
>=20
> While (2) is ok, (3) does not compile, because of the template function=
=20
> omitting the implicit conversion int->float.
>=20
> Now, one can simulate the implicit conversion by giving the template=20
> function extra freedoms over the left hand parameter type, call it Type=
2=20
> and then explicitly computing it inside the template function (Type=20
> converted =3D value;). Then the left-hand operator+ works like the righ=
t-
> hand operator+, except that the former creates code-bloat. The need for=
=20
> simulation also seems a bit like reverse-engineering.

Code bloat? Assuming your "addition" operations is commutative, you can=20
define your left-hand operator as:

template <typename T1, typename T2>
inline A<Type> operator+(const T1& that, const A<T2>& vec)
{
    return vec.operator+(that);
}

Given a reasonable optimizing compiler, you won't get any code bloat=20
from that. Just compile and look at the assembler output. (Notice that=20
the conversion moved from the caller to the callee, but it doesn't=20
matter, you have to make the conversion anyway).

> One can see that there clearly is a non-symmetry between the left-hand=20
> and right-hand operators. Now, my question is, whether there has been=20
> any considerations on solving this non-symmetry?

Good design rules (at least good according to some people, including=20
myself) says that a binary operator is best implemented through free=20
functions. So I would not use one member function + one free function,=20
but two free functions. Voil=E0: asymmetry disappeared.

Just my opinion,

Ganesh

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

0
AlbertoBarbati
10/8/2006 10:41:58 PM

On Oct 8, 3:41 pm, AlbertoBarb...@libero.it (Alberto Ganesh Barbati)
wrote:
> Kaba ha scritto:
> > One can see that there clearly is a non-symmetry between the left-hand
> > and right-hand operators. Now, my question is, whether there has been
> > any considerations on solving this non-symmetry?
> Good design rules (at least good according to some people, including
> myself) says that a binary operator is best implemented through free
> functions. So I would not use one member function + one free function,
> but two free functions. Voil�: asymmetry disappeared.

The asymmetry being described is not due to the difference between
member and a free function implementations of a binary plus operator.
In fact there really is little difference between the two. Because any
global function whose first parameter is a class object can be
reformulated as a class method. To effect the transformation, the first
parameter is is replaced by an implicit "this" pointer to its value. So
in essence, an overloaded binary plus operator class method is simply a
more convenient package for the free function version of the same
routine.

The asymmetry that the sample progam aims to demonstrate is that a
member function that overloads the binary plus operator means that "a +
1" becoms a valid expression. A matching routine of the same operator
that has the two parameter types reversed, however, appears not to not
attain the equivalent result: "1 +a", for example, remains an invalid
expression.

The program itself produces this asymmetry by mistakenly implementing a
free function operator+() in a way that does not match the member
operator+(). The free operator+() function after all is a function
template - whereas the member function operator+() is not a member
function template. Granted, the member operator+() belongs to a class
template - but once the class template A<int> is instantiated, the
operator+ method itself is not further parameterized. So the assymmetry
the program demonstrates simply derives from comparing a non-template
function with a function template - so naturally their behaviors
differ.

It is possible to declare an operator+() with the parameters reversed
that does match the member function. To do so, let's first examine the
member operator+() as if it were implemented as a free function:

      A<int> operator+(const A<int>& lhs, int rhs);

So a corresponding version of this function that reversed the two
parameter types would look like this:

     A<int> operator+( int lhs, const A<int>& rhs);

So the program just needs a function with the above declaration to
attain the symmetrical behavior for the binary plus operator for all
A<int> objects.

So far so good. Now, there is a practical obstacle that must be
overcome. When the template class A<int> is instantiated, its member
operator()+ is ready to be instantiated for A<int> objects just as soon
as it is needed. So its matching operator+ needs to have this same,
on-demand availability for A<int> objects (and for any other A template
class objects). How can that by done? The answer is by implementing the
second operator+() routine as a friend of the class template<A>:

    template <typename Type>
    class A
    {
    public:
        A operator+(const Type& that) const
        {
            A result;
            // Do something
            return result;
        }

        friend A operator+(const Type& lhs, const A& rhs)
        {
            A result;
            // Do something
            return result;

            // or if commutative
            return rhs + lhs;
        }
    };

With the friend operator+() function now implemented, the goal of
symmetry for the overloaded binary plus operator has been realized::

    A<int> a
     
    1 + a; // OK
    a + 1; // OK

Greg


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

0
Greg
10/9/2006 11:20:18 AM
> Code bloat? Assuming your "addition" operations is commutative, you can=
=20
> define your left-hand operator as:
>=20
> template <typename T1, typename T2>
> inline A<Type> operator+(const T1& that, const A<T2>& vec)
> {
>     return vec.operator+(that);
> }
>=20
> Given a reasonable optimizing compiler, you won't get any code bloat=20
> from that. Just compile and look at the assembler output. (Notice that=20
> the conversion moved from the caller to the callee, but it doesn't=20
> matter, you have to make the conversion anyway).

Because we are talking about the general case, not always is the=20
addition commutative and despite of the possible optimizations, the=20
different instantiations are not the same function. So yes, in general=20
there is code bloat. Logically, there should be no need for code bloat=20
to start with.

> Good design rules (at least good according to some people, including=20
> myself) says that a binary operator is best implemented through free=20
> functions. So I would not use one member function + one free function,=20
> but two free functions. Voil=E0: asymmetry disappeared.

Asymmetry disappeared, but in the wrong direction. You generalized the=20
more specific normal function member operator+ to get equally working=20
binary operators: now they are both templates and thus they lose the=20
possibility of using implicit conversions in the calling process. While=20
implicit conversions are bad in general, with native types they are most=20
convenient (int->float etc).

The problem in this case is that to be able to express your intent, you=20
have to over-generalize (by introducing another template parameter, and=20
then doing the implicit conversion explicitly).

As another point of view, consider that you are not able to express=20
something with template classes that is possible with normal classes=20
(similarly working lh- and rh-binary operators w.r.t some type, one=20
function per handedness per class)

--=20
Kalle Rutanen
http://kaba.hilvi.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.comeaucomputing.com/csc/faq.html                      ]

0
none
10/9/2006 4:17:09 PM
> With the friend operator+() function now implemented, the goal of
> symmetry for the overloaded binary plus operator has been realized::

Impressive! It works just like required. I wouldn't have thought it to 
be possible. What in the world is the interpretation? First of all, the 
friend function as declared cannot be part of the class, so it must mean 
a function outside the class. Furthermore, no class is specified, so it 
must mean a free function. Then again, the function is parametrized by 
the enclosing class, which means the function must be itself templated. 

But, alas, defining the function as a free template function does not 
work, as shown, so in general the only option is to both declare and 
define the function inside the class definition as a friend?

If this is true, then I'd like to raise two things of interest:
1) There are functions that must be *defined* inside the class 
definition to work as desired.
2) To find a way to express the left-hand binary operator this way might 
require a lot of years (for me, 12). This is too much for such a trivial 
desire!

-- 
Kalle Rutanen
http://kaba.hilvi.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.comeaucomputing.com/csc/faq.html                      ]

0
Kaba
10/9/2006 11:17:49 PM
Uzytkownik "Kaba" <none@here.com> napisal w wiadomosci 
news:MPG.1f950d9f2d9ffcc09897c2@news.cc.tut.fi...
>> With the friend operator+() function now implemented, the goal of
>> symmetry for the overloaded binary plus operator has been realized::
>
> Impressive! It works just like required. I wouldn't have thought it to
> be possible. What in the world is the interpretation? First of all, the
> friend function as declared cannot be part of the class, so it must mean
> a function outside the class. Furthermore, no class is specified, so it
> must mean a free function. Then again, the function is parametrized by
> the enclosing class, which means the function must be itself templated.
>
> But, alas, defining the function as a free template function does not
> work, as shown, so in general the only option is to both declare and
> define the function inside the class definition as a friend?
>
> If this is true, then I'd like to raise two things of interest:
> 1) There are functions that must be *defined* inside the class
> definition to work as desired.
> 2) To find a way to express the left-hand binary operator this way might
> require a lot of years (for me, 12). This is too much for such a trivial
> desire!
>

In general, if you want the compiler to instantiate an ordinary function
along with the class template it works upon,
you can define it as a friend.
However, there is one exception: placement operator new(size_t, A<T> &).
If you define it as a friend to A<T>,
you can call it explicitly to return void *, but the new expression 
new(A<T>) T does not work.
Sad but true, C++ lacks support for custom object pools.
When we have an intermediate allocator class,
it would be tempting to use placement new to create new objects;
but there is no context-free placement delete and there is no way to 
generate the operator new in a generic way.
It is a very strange phenomenon
that such a basic and intuitive feature as operator new and delete has to be 
deprecated and wrapped in allocators.
I think it is because operator new came long before the templates
and therefore the two do not work well together.

Chris


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

0
Kri
10/10/2006 12:16:37 PM

On Oct 9, 10:17 pm, Kaba <n...@here.com> wrote:
> But, alas, defining the function as a free template function does not
> work, as shown, so in general the only option is to both declare and
> define the function inside the class definition as a friend?

No, it's not the only option - but it is the most convenient. As I
noted, the program could implement the overloaded plus operator (with
the parameters reversed) for A<int> itself. The drawback of course is
that because the overloaded operator when implemented as a function
template will not implicitly convert its parameters, the program would
have to implement the plus operator as an ordinary, non-template
function - and remember to do so for all other A specializations.

Declaring the overloaded plus operator a friend of the A class template
essentially writes an overloaded plus operator for each A
specialization and does so automatically; Because even though the
friend operator plus overload is parameterized by type, it is not a
template function - which is why it works and the original function
template version does not. More information about templates and their
friends can be found in �14.5.3 of the latest draft C++ Standard.

> If this is true, then I'd like to raise two things of interest:
> 1) There are functions that must be *defined* inside the class
> definition to work as desired.

I believe that is the case. Still, it seems a small price to pay to
accomplish the impossible.

> 2) To find a way to express the left-hand binary operator this way might
> require a lot of years (for me, 12). This is too much for such a trivial
> desire!

I'm not sure that I understand. You've been wanting this support for
the last 12 years? I'll admit the  use of a friend function in a class
template is one of the more obscure corners of the C++ language (I
think it even has a special name which I don't recall). In fact I had
almost forgotten that declaring a friend function in this way was even
possible. And to be honest, I wasn't even sure that it would work until
I tried it.

Greg


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

0
Greg
10/12/2006 10:40:42 AM
> No, it's not the only option - but it is the most convenient. As I
> noted, the program could implement the overloaded plus operator (with
> the parameters reversed) for A<int> itself. The drawback of course is
> that because the overloaded operator when implemented as a function
> template will not implicitly convert its parameters, the program would
> have to implement the plus operator as an ordinary, non-template
> function - and remember to do so for all other A specializations.

Yep, that is a solution, while not automatic. This would be a problem=20
with 3rd party code, which you are not allowed to touch: you can't then=20
add the specializations for new types. And, of course, that would also=20
be a bit inelegant and cause some maintenance burden.

> Declaring the overloaded plus operator a friend of the A class template
> essentially writes an overloaded plus operator for each A
> specialization and does so automatically; Because even though the
> friend operator plus overload is parameterized by type, it is not a
> template function - which is why it works and the original function
> template version does not. More information about templates and their
> friends can be found in =A714.5.3 of the latest draft C++ Standard.

Understood.

> > If this is true, then I'd like to raise two things of interest:
> > 1) There are functions that must be *defined* inside the class
> > definition to work as desired.
>=20
> I believe that is the case. Still, it seems a small price to pay to
> accomplish the impossible.

Agreed. Other than the nonuniformity of this functionality, the=20
important thing here is, in my opinion, the difficulty of finding this=20
way. I don't remember having read about this particular problem of left-
hand operators anywhere, nor having seeing a solution, until now (has=20
anyone else?).

Especially the following conventions easily hide finding this solution:
- it is good style to write class function definitions separate from=20
class definition.
- in general, it is good to avoid 'friends', while they do have their=20
uses.
- friends are mostly associated dealing with class access, not=20
generation of code.

> I'm not sure that I understand. You've been wanting this support for
> the last 12 years? I'll admit the  use of a friend function in a class
> template is one of the more obscure corners of the C++ language (I
> think it even has a special name which I don't recall). In fact I had
> almost forgotten that declaring a friend function in this way was even
> possible. And to be honest, I wasn't even sure that it would work until
> I tried it.

Well, I don't remember how many years I have wanted it, but the thing=20
is, if it was even a one year, that would be too much for a single=20
answer (for such a 'simple' problem).

The question is a simple "how do I make left-hand operators work exactly=20
like the right-hand operators?", and that makes even experts stumble.=20
Making the solution easier would certainly fit many of the desired=20
properties of the wanted proposals for the next standard.

And of course, there is still the nonuniformity that for style reasons=20
I'd want to write the function definition out of the class definition,=20
but the language does not allow it (in the general case).

--=20
Kalle Rutanen
http://kaba.hilvi.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.comeaucomputing.com/csc/faq.html                      ]

0
none
10/13/2006 3:24:12 PM
I came up with the same solution myself after reading the relevant sectio=
ns=20
of the standard.
However, my solution failed because my target was placement new operator.
=3D(;-O (crying aloud and stomping my feet)
Chris

Uzytkownik "Kaba" <none@here.com> napisal w wiadomosci=20
news:MPG.1f99da5bcabdbbf49897c6@news.cc.tut.fi...
> No, it's not the only option - but it is the most convenient. As I
> noted, the program could implement the overloaded plus operator (with
> the parameters reversed) for A<int> itself. The drawback of course is
> that because the overloaded operator when implemented as a function
> template will not implicitly convert its parameters, the program would
> have to implement the plus operator as an ordinary, non-template
> function - and remember to do so for all other A specializations.

Yep, that is a solution, while not automatic. This would be a problem
with 3rd party code, which you are not allowed to touch: you can't then
add the specializations for new types. And, of course, that would also
be a bit inelegant and cause some maintenance burden.

> Declaring the overloaded plus operator a friend of the A class template
> essentially writes an overloaded plus operator for each A
> specialization and does so automatically; Because even though the
> friend operator plus overload is parameterized by type, it is not a
> template function - which is why it works and the original function
> template version does not. More information about templates and their
> friends can be found in =A714.5.3 of the latest draft C++ Standard.

Understood.

> > If this is true, then I'd like to raise two things of interest:
> > 1) There are functions that must be *defined* inside the class
> > definition to work as desired.
>
> I believe that is the case. Still, it seems a small price to pay to
> accomplish the impossible.

Agreed. Other than the nonuniformity of this functionality, the
important thing here is, in my opinion, the difficulty of finding this
way. I don't remember having read about this particular problem of left-
hand operators anywhere, nor having seeing a solution, until now (has
anyone else?).

Especially the following conventions easily hide finding this solution:
- it is good style to write class function definitions separate from
class definition.
- in general, it is good to avoid 'friends', while they do have their
uses.
- friends are mostly associated dealing with class access, not
generation of code.

> I'm not sure that I understand. You've been wanting this support for
> the last 12 years? I'll admit the  use of a friend function in a class
> template is one of the more obscure corners of the C++ language (I
> think it even has a special name which I don't recall). In fact I had
> almost forgotten that declaring a friend function in this way was even
> possible. And to be honest, I wasn't even sure that it would work until
> I tried it.

Well, I don't remember how many years I have wanted it, but the thing
is, if it was even a one year, that would be too much for a single
answer (for such a 'simple' problem).

The question is a simple "how do I make left-hand operators work exactly
like the right-hand operators?", and that makes even experts stumble.
Making the solution easier would certainly fit many of the desired
properties of the wanted proposals for the next standard.

And of course, there is still the nonuniformity that for style reasons
I'd want to write the function definition out of the class definition,
but the language does not allow it (in the general case).

--=20
Kalle Rutanen
http://kaba.hilvi.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.comeaucomputing.com/csc/faq.html                      ]


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

0
giecrilj
10/16/2006 5:09:32 PM
Reply:

Similar Artilces:

string::operator+ vs. string::operator+= vs. ostringstream::operator<<
Konichiwa! Quite a while ago I was porting code form g++ 2.95 to gcc 3.x and encountered some problems with expressions like string s = string("a") + string("b") + string("c") + ... which appeared to be very slow not only when executed but also during the compile. I found this was due to template instantiation and temporary creations. I replaced most of the above expressions by the better performing form: string s = string("a"); s += string("b"); s += string("c"); .... This was quite an improvement in both compile and runti...

Left hand and right hand coordinate systems
Is there any way in Solidworks to create a coordinate sytem that follows a different rule to the origin? eg right hand rule origin and a left hand rule coordinate system? My first thought is that you are coming from some other system that requires you to establish the coordinate system first. In SW, you can just put the stuff where you want it. If you want to do this in a part file, start your part on the desired plane, and then reset your standard views to make "front" look like you want it. If you want this change in an assy, mate the parts to the system planes and rese...

std::operator<<(basic_ostream&, type) vs. std::basic_ostream::operator(type) ... ?
Hello. I tried to overload the operator<< for implicit printing of wchar_t string on a char stream. Normally using it on a ostream will succeed as std::operator<<<std::char_traits<char> >(std::basic_ostream<char,std::char_traits<char> > & _Ostr={...}, ___) will be called. However, I am using the boost::format library that internally makes use of a string stream to store the formatted string. There: std::basic_ostream<char,std::char_traits<char> >::operator<<(___) will always be called. On what basis will the compiler choose which...

error C2679: binary '<<' : no operator found which takes a right-hand operand of type 'std::string' (or there is no acceptable conversion)
Hi, I have written this code, and at the end, I am trying to write a vector of strings into a text file. However, my program is nor compiling, and it gives me the following error when I try to write to the file: error C2679: binary '<<' : no operator found which takes a right-hand operand of type 'std::string' (or there is no acceptable conversion) I don't know what I am doing wrong. I have posted my entire program here. Thank you #include <iostream> #include <fstream> #include <iterator> #include <algorithm> #include <vector> #include...

Left hand operators revisited
About a month ago we had discussion about implementing a symmetric left hand binary operator. The discussion can be seen at: http://groups.google.fi/group/comp.std.c++/browse_thread/thread/e158df32 9d2cfce7 Following that, I wrote an article that essentially summarizes the issue and its solutions: http://kaba.hilvi.org/project/mycents/mycents3.htm As the article reads, I credit Greg Herlihy for bringing the solution to my knowledge. (Related, I posted a short "thank you" message to Greg in this newsgroup, but that was apparently filtered away. So, here goes along with this message: thank you!:)). Now on to the beef. As I note in the discussion and in the article, I'd like to raise a cat on the table with the following issues: * The in-class template class-type dependent friend functions do not have a syntax to be defined outside the class definition => This is a style problem, cluttering interface description with implementation details. * The symmetric left hand operator behaviour with template classes is a trivial need, but the solution requires deep knowledge of the language. => This is kind of an embarrassment. On this part C++ should clearly make the solution more simple to make it tractable for novices. My questions are the following: * How do I raise the cat on the table? If the issue is not logged in some list, it has a possibility of being forgotten, thus possibly missing the next standard. * Ar...

mouse: problem with left-handed, right-handed works
Hi, I'm using KDE 3.3.2 under Linux 2.6.8-2-686 with a 5-button mouse. The mouse works fine in right-handed mode. But if I set it to left-handed (KDE Control Center -> Pheripherals -> Mouse), it appears as if the right-handed and the left-handed mode is mixed. It is hard to describe: Using the index button (in left-handed mode the right one) seems to initiate the actions for both the left and the rigth button (e.g., a menu opens). On the next click, the mouse appears to be right-handed. Then the behaviour repeats. Any ideas? Ulrich Ulrich Scholz wrote: > Hi, > > I&...

Covert PBRT left-hand coordsys to OpenGL right-hand
Hi, i am working with a programme to render the PBRT scene with OpenGL. Unfortunately i found PBRT is based on left-hand coordinate system. i need convert all primitives and transform data to right-hand format. point.z -= point.z can convert all point data in the primitives presentation correctly. my question is how to convert a 4x4 transform matrix correctly which contain some basic transform matrix product. (eg. translate, rotate, scale, lookat etc.,) i google it and havent found a exact explanation. so i seek help here. it would be appreciated for some advice or discussion. mljack &l...

Keeping left-hand and right-hand 'columns' in step.
Maybe some kind person can help with a suggestion or two ;-) I want to construct a banner on a number of pages in the format: LHS: Text (variable content) RHS. Logo ..... each with a different background colour. The following test page shows what I'm trying to achieve (borders put in for diagnostic purposes). http://www.gododdin.demon.co.uk/ng/testpage2.htm It seems to work OK in IE6/Opera/Mozilla/Netscape -- except for one thing. When I adjust the size of the text to make it larger than 'normal', the left-hand container expands downwards, to acc...

Expression as the left-hand side of an assignment operation
I found the following statement in [1], section 6.5: "A reference to a pointer function is treated as a variable and is permitte= d in any variable-definition context. For example, this function might calc= ulate where to store values depending on a key function storage(key) result(loc) integer, intent(in) :: key real, pointer :: loc loc=3D>... end function which would allow a value to be set thus: storage(5)=3D0.5" Neither gfortran or ifort won't compile the mentioned code (or any variatio= n of it) and warn about "statement function" being obsolete. Is this actua= lly a valid Fortran 2008 code? If yes, are there any compilers supporting = this feature or any variation of it? [1] "The new features of Fortran 2008" John Reid Pawe=C5=82 Biernat Pawe? Biernat <pawel.biernat@uj.edu.pl> wrote: > function storage(key) result(loc) > integer, intent(in) :: key > real, pointer :: loc > loc=>... > end function > > which would allow a value to be set thus: > > storage(5)=0.5" > > Neither gfortran or ifort won't compile the mentioned code (or any > variation of it) and warn about "statement function" being obsolete. Is > this actually a valid Fortran 2008 code? Insuficient context is provided to tell. Context matters *A LOT*. John's cited paper was no doubt omitting such contex...

Precision of C++ left/right shift operator..
I am using this type of code to do right-shifting, B = 3; data1 = (data + (1 << (B-1))) >> B; data1 seems incorrect when data = -4-8*i.. which means it rounds -1.5 to -1 instead of -2. On the positive side, 1.5 is rounded to 2, which ic correct. For left-shift, it's simply as follows, no pitfalls, am I right? data1 = data << B; Thanks. G Iveco wrote: > I am using this type of code to do right-shifting, > > B = 3; > data1 = (data + (1 << (B-1))) >> B; > > data1 seems incorrect when data = -4-8*i.. which means it > rounds -1.5 to...

increment operator at left hand side of equation.
Hi all, Is this valid in as per C standard ? --> *(pt++) = temp; int *ptr; int temp = 0; *(pt++) = temp; Would there be any confusion to compiler about which operation should it do first? increment or assignment ? Thanks, Nishu On May 4, 9:33=A0am, Nishu <naresh.at...@gmail.com> wrote: > *(pt++) =3D temp; Can I treat the above statement as invalid in accordance to below faq ? http://c-faq.com/expr/evalorder2.html Thanks, Nishu In article <51514726-2803-447b-9639-e84d16564a58@z13g2000prk.googlegroups.com>, Nishu <naresh.attri@gmail.com> wrote: > Hi all, ...

convert a 4x4 affine matrix from left handed to right handed coordinate system
Hello, Does anyone know how I can convert a 4x4 matlab matrix that encodes a full affine transformation matrix in the right handed coordinate system to a left handed coordinate system? Would simply negating one of the axes do? I somehow have a feelin that will only work for scaling and translation matrices... Any help would be appreciated, Luca Luca <luca.pamparana@gmail.com> wrote in message <900b3d36-95ee-4889-8f4e-e25c3415218a@i9g2000yqe.googlegroups.com>... > Hello, > > Does anyone know how I can convert a 4x4 matlab matrix that encodes a > full affi...

Is there a concatention operator on the Left Hand Side of '='?
I am reading something from the Altera website example. http://vader.ece.ucsb.edu/digilab-fpga/pdfs/Quartus-Verilog-tutorial.pdf Around pages 10-12 there is are 3 modules with the last one as follows: // k-bit adder module adderk (carryin, X, Y, S, carryout); parameter k = 8; input [k?1:0] X, Y; input carryin; output [k?1:0] S; output carryout; reg [k?1:0] S; reg carryout; always @(X or Y or carryin) {carryout, S} = X + Y + carryin; endmodule what I am not clear on is the last line: {carryout, S} = X + Y + carryin; What are the Curly Braces on the Left Hand Side of the Equal Sign doing here? Is it Concatention? or is it Add then Assignment? Or Multiple Assignment? Looking at the logic circuit on page 10 gives me some idea, but I am not 100% sure. Not sure how the outputs look to the world outside the module I know the use of Curly Braces on the Right Hand side is Concatenation, but not the Left hand side. Looked at a Verilog book but nothing like that or on Google Search. Any help would be appreciated? Thanks. Concatenation works on both sides of assignments Raban wrote: > I am reading something from the Altera website example. > > http://vader.ece.ucsb.edu/digilab-fpga/pdfs/Quartus-Verilog-tutorial.pdf > > > Around pages 10-12 there is are 3 modules with the last one as follows: > > // k-bit adder > module adderk (carryin, X, Y, S, carryout); > ...

Logical indexing of cellarray: The right hand side of this assignment has too few values to satisfy the left hand side.
I use Matlab 2010b and trying to extract a subset cellarray into another cellarray: >>index=logical(zeros(1,4)) >>index(1)=1; >>index(3)=1; >>vv={'aa','ddd','ccc','e'} Typing: >>vv{index} returns: ans = aa ans = ccc Which I am happy about. Now I am trying to use this result: >>rez=vv{index}; >> rez rez = aa understandable Now I want to use whole sellarray: >>rez=cell(1,2) rez = [] [] =================== OFFENDING COMMAND: >>rez{:}=vv{index} ??? The right hand side of ...

Is the right-hand side of a comma operator expression fully evaluted?
I was reading the C++ standard (2003), and I was looking at sequence points. I went to the comma operator and read up on it. The standard clearly states that all side effects on the left-hand side of the comma expression are fully-evaluated before the right-hand side is executed. As a reference to my question, here is 5.18: A pair of expressions separated by a comma is evaluated left-to-right and the value of the left expression is discarded. The lvalue-to-rvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3) standard conversions are not applied to the left expression. All side effects (1.9) of the left expression, except for the destruction of temporaries (12.2), are performed before the evaluation of the right expression. The type and value of the result are the type and value of the right operand; the result is an lvalue if its right operand is. Is the right-hand side of a comma expression fully evaluated (hence, all side effects have occured)? As far as I can tell, it is definately not guaranteed that the right hand side of a comma expression is fully-evaluated. --- [ 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 ] The comma operator has left to right associativity. The use of the co...

std::string::push_back vs. std::string::operator+=
Hi, I just browsed libstdc++6-doc and stumbled over a string operation I haven't noticed before: string::push_back. If for example I want to append single characters to an std::string, which one would be better, or is there any difference at all: mystr.push_back( c ); or mystr += c; Any ideas? I used to use the latter one. Regards, Matthias Matthias K�ppler wrote in news:cntj5d$ooa$03$1@news.t-online.com in comp.lang.c++: > Hi, > > I just browsed libstdc++6-doc and stumbled over a string operation I > haven't noticed before: string::push_back. push_back() is there so that std::string conforms as "Back Insertion Sequence". Because its there you can use std::back_inserter with std::string for example. Or any other generic algorithm that requires a back insertion sequence. > If for example I want to append single characters to an std::string, > which one would be better, or is there any difference at all: > > mystr.push_back( c ); > > or > > mystr += c; > > Any ideas? I used to use the latter one. > Whichever you want, they both do the same thing. Rob. -- http://www.victim-prime.dsl.pipex.com/ > I just browsed libstdc++6-doc and stumbled over a string operation I haven't > noticed before: string::push_back. > If for example I want to append single characters to an std::string, which > one would be better, or is there any difference at all: > > mystr.push_back( c ); > ...

Implementing operator<, std::mismatch vs. std::lexicographical_compare
I implemented operator== for my container type with std::equal. I was about to use std::lexicographical_compare for my operator<, but I realized it may be inefficient: 1. Return special-case value if one or both lists end early. 2. You do *l < *r and return TRUE if this comparison does so. 3. Else, do *r++ < *l++ and return FALSE if this comparison returns true. 4. Otherwise, you're currently equal and go back to (1). The lexicographical compare makes its decision at the first unequal pair of elements (or FALSE if all are equal). Instead of two calls to operator< to determine equality, just use one call to operator==, then return the comparison at the mismatch point. Now, I know this plan would require carrying two different comparators for the non-operator variants (and hoping that their comparison philosophies are in sync); that's probably why the standard versions just call operator< twice. But for my private code, where I pre- condition the element type to have both operators, would it be better to just use std::mismatch & one operator< call instead of std::lexicographical_compare? (BTW, my structure has all containers have the same size, so I don't do that check.) Daryle W. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Am 06.05.2013 18:37, schrieb Daryle Walker: > The lexicographical compare makes ...

LEFT + LEFT vs LEFT + RIGHT
In order to do a full outer join in MySQL one must use a union. Is there any good reason to do SELECT ... LEFT JOIN UNION SELECT ... RIGHT JOIN rather than SELECT ... LEFT JOIN UNION SELECT ... LEFT JOIN with the tables swapped on the latter LEFT JOIN? Paul Lautman wrote: > In order to do a full outer join in MySQL one must use a union. > Is there any good reason to do > > SELECT ... > LEFT JOIN > > UNION > > SELECT ... > RIGHT JOIN > > rather than > > SELECT ... > LEFT JOIN > > UNION > > SELECT ... > LEFT JOIN > ...

Is the behaviour of * operator an example of operator oveloading in c?
The * operator behaves in 2 different ways. It is used as the value at address operator as well as the multiplication operator. Does this mean * is overloaded in c? karthik wrote: > The * operator behaves in 2 different ways. It is used as the value at > address operator as well as the multiplication operator. Does this mean > * is overloaded in c? Which one? Either way, you decide... http://en.wikipedia.org/wiki/Operator_overloading Note: your question is probably better suited to comp.programming. -- Peter karthik schrieb: > The * operator behaves in 2 different ways. ...

I have to invoke operator bool () by hand. Why?
Hello newsgroup, I have an app that works with COM servers, that should be used from the main UI thread and from worker threads. To be able to use interface pointers I declared a parameterized class CCustomSmartPointer that provides a kind of ..., well, smart pointer. The only difference to a common smart pointer is, that this class will return a different pointer depending on whether it is called from the UI thread or not. I also tried to provide a cast operator for bool. I defined it this way: template<typename t_SmartPointerType> class CCustomSmartPointer { typedef typename t_Sma...

overloaded * operator and *= operator
Can anyone help me complete this program? It is almost finished except for the multiplication of Polynomials algorithms. I can't seem to correctly implement the process. Thanks. #include < iostream.h > #include < iomanip.h > class Polynomial { friend istream &operator>>( istream &, Polynomial & ); friend ostream &operator<<( istream &, Polynomial & ); public: Polynomial::Polynomial(); Polynomial operator+(Polynomial &); Polynomial operator-( Polynomial &); Polynomial operator+=(Po...

OPERATOR(7) ?: left to right?
Hi I noticed OpenBSD's man stating the associatively for OPERATOR(7) ?: as right to left. I think it should be left to right, unless there's something I don't know about. Other BSD man references have the same entry. // Please remove f in address to reply. In article <3FAF6B93.4F0D26CD@shaw.ca>, Tom wrote: > Hi > > I noticed OpenBSD's man stating the associatively for OPERATOR(7) > ?: > > as right to left. I think it should be left to right, unless there's > something I don't know about. Other BSD man references ...

Greater than operator Vs Equal to operator : Which one is efficient?
Hello All, Which one is an expensive operation? '>' or '==" ? I know this won't matter much. However, if I'm executing this operation million times, I would prefer the better choice. My gut feeling is that '>' should be efficient. However, when translated to assembly code all it generates is "cmpl" instruction (gcc -S <prog.c>). So, my question here is :: how is "cmpl" instruction executed by the cpu? Ex: (1) if (n == 0) vs if (n > 0) (2) if (len == 12) vs if (len < 13) Thanks in advance. Regards, Vivek web: htt...

~ operator not operating as expected
I need a bool to toggle between true and false every time it is called - easy I thought bool flag = false // ie 0 .... cout << (int)flag << "\n"; flag = ~flag;. .... what I 0 1 1 1 1 OK I can implement the functionality with a couple of if's but I thought the above was more elegant and am mystified as to why it fails, Can anyone enlighten me ? Dave -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] jk@pusspaws.net wrote: > I need a bool to toggle between true and false...

Web resources about - Left hand operators vs right hand operators - comp.std.c++

Operator - Wikipedia, the free encyclopedia
Text is available under the Creative Commons Attribution-ShareAlike License ;additional terms may apply. By using this site, you agree to the ...

Horse-drawn carriage operator filmed hurling violent threats and racial abuse
Melbourne's angriest carriage driver appears to have again been caught on camera venting his spleen, this time hurling racial abuse and violent ...

Horse-drawn carriage operator filmed hurling violent threats and racial abuse
[ The Age - Text-only index ] Horse-drawn carriage operator filmed hurling violent threats and racial abuse Date: February 18 2016 Patrick Hatch ...

Low loonie a 'silver lining' for province's tourism operators
Several industries in Newfoundland and Labrador are seeing a silver lining in the low Canadian dollar, including the province's tourism operators. ...

Drone operator unwittingly films new Top Gear shoot
Filed under: TV/Movies , Videos , Ford , Driving , UK A Scotsman driving through the Highlands stumbled on a new Top Gear shoot and filmed it ...

Comcast et al. Will Have to Buy Mobile Operators to Survive, Says BTIG
... threat of wireless, writes BTIG ’s Walter Piecyk today, warning that faster and faster cellular network connections will allow the mobile operators ...

Mobile operator Three to block ads at the network level
... with advertisers recently too and is looking to discover just why people block ads on the web . In an interesting move, mobile network operator ...

Congressmen Have No Idea Why Special Operators Have To Pay Out Of Pocket For Basic Gear
By Jonah Bennett For reasons still unclear, elite special operators are often let down by their respective services and have to pay out of pocket ...

Brooklyn's krauty Operator released 'Materielmusik' EP (listen), playing Palisades tonight
by Bill Pearis Operator: can they help you with this call? Brooklyn's Operator (no "s," so not to be confused with Dan Boeckner's band Operators) ...

Global Operators, Google and the GSMA Align Behind Adoption of Rich Communications Services
Global operators and Google today announced the launch of a mobile industry initiative to accelerate the availability of Rich Communications ...

Resources last updated: 3/6/2016 4:35:42 PM