## Glas :## Re: [glas] Skalar-Like concepts from GLAS and MTL |

**From:** Toon Knapen (*toon.knapen_at_[hidden]*)

**Date:** 2005-05-23 07:01:24

**Next message:**Toon Knapen: "Re: [glas] Skalar-Like concepts from GLAS and MTL"**Previous message:**Karl Meerbergen: "Re: [glas] Skalar-Like concepts from GLAS and MTL"**In reply to:**Peter Gottschling: "Re: [glas] Skalar-Like concepts from GLAS and MTL"**Next in thread:**Toon Knapen: "Re: [glas] Skalar-Like concepts from GLAS and MTL"

Peter Gottschling wrote:

> Notice that T can model AdditiveGroup without the existence of a

> functor. Furthermore, every type models AdditiveGroup in my definition

> _iff_ it models AdditiveGroup in the GLAS definition.

First I did not see this. E.g. the current glas-proposal requires that

an AdditiveGroup has an operator+. But since you always derive the

functor from a global operator there is indeed an operator+ too.

>

> The type requirements are not more complicated than in the other

> proposal, only the concept definitions are. Why?

But should the concept talk about the functor or just talk about the

operator. The latter would make the concept definition easier to

understand (for people that start looking at the concept definitions).

>

> The answer is that this style of definition provides consistency between

> the additive concepts and the pure algebraic concepts, which is

> absolutely needed to consider the additive concepts as refinements of

> pure algebraic concepts. If there is another way to guarantee this

> consistency, we should discuss it. The definition in the GLAS concept

> was for my personal taste a little bit to general to lead the

> implementing in sufficient detail. The technique (or trick if you want)

> with the default functor nails down the consistency.

IIUC it is the idea that 'this style of definition provides consistency'

what you retract. Right?

As Karl mentioned in his reply, operator+ and operator* are the most

important. And if we want the glas models to be intuitive, these models

should support these operators. The only problem is than that we have

not enough operators available in C++. E.g. operator* on a matrix can

mean a matrix-matrix product or an element-wise product. This is for me

the main reason that we need to be cautious with operator overloading

and try to use functors instead.

toon

**Next message:**Toon Knapen: "Re: [glas] Skalar-Like concepts from GLAS and MTL"**Previous message:**Karl Meerbergen: "Re: [glas] Skalar-Like concepts from GLAS and MTL"**In reply to:**Peter Gottschling: "Re: [glas] Skalar-Like concepts from GLAS and MTL"**Next in thread:**Toon Knapen: "Re: [glas] Skalar-Like concepts from GLAS and MTL"