SG wrote:
> On 15 Jan., 08:53, Ken Camann <kjcam...@gmail.com> wrote:
>> I've seen several old messages saying that concept_maps cannot be used
>> to implement member function associated requirements.  That appears to
>> still be true today
>
> That's not true.
>
>[snip]
>
> I see basically two good reasons for prefering the free function
> syntax:
> (1) Support for built-in types. Since built-in types have no member
> functions these types could never satisfy your concept.
> (2) Support for retroactive modelling. You may not be able to change a
> class definition and add a member function so that the class type
> satisfies your concept.

What the OP was talking about is adding a member function in the
concept_map.
Such a member function would not be a true member function in so far as it
would have no access to any non-public member, but it would be definined as
though it were a member function, allowing access to public members by
name,
and supporting the use of the this keyword.

Then inside a constrained template these functions could be used via
member-function call syntax, even though they are not real member functions.

What would really happen is that the compiler would internally translate
the
functions to be standalone functions, via the same kind of transformation
cfront would use to support member functions (the implicit object paramter
transformation).

It would also tranform the member function call to a frestanding function
call via the implied object argument transformation.

With such a system it really would not matter if the type was a builtin,
since these would not be real member functions anyway.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jan 15, 4:50 pm, "Joe Smith" <unknown_kev_...@hotmail.com> wrote:
> SG wrote:

<snip>

> What the OP was talking about is adding a member function in the
> concept_map.
> Such a member function would not be a true member function in so far as it
> would have no access to any non-public member, but it would be definined as
> though it were a member function, allowing access to public members by
> name,
> and supporting the use of the this keyword.
>
> Then inside a constrained template these functions could be used via
> member-function call syntax, even though they are not real member functions.
>

<snip>
> With such a system it really would not matter if the type was a builtin,
> since these would not be real member functions anyway.

This reminds me of a discussion that had been had by some of the C++
progressives back in my earlier days (~1998-2003 i think) where there
was a camp that felt strongly that all operations/functions/methods on
objects should be represented syntactically as free function calls,
thus allowing for uniformity of use (especially helpful when writing
generic code) and a certain symmetry across one's code - two desirable
qualities.
What the OP proposes/requests is something that would allow uniformity
of use with member function syntax and I would expect that this would
strongly appeal to members of the aforementioned camp. I do not see
any clear disadvantages.




--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

I've seen several old messages saying that concept_maps cannot be used
to implement member function associated requirements.  That appears to
still be true today, I'm just wondering (from those who are on the
committee or might know) if anyone plans to revisit this / there is
any interest in discussing it or if it was even a contested decision.
I understand the issues involved are pretty complicated.

Although it's quite late in the evolution of C++0x and probably
nothing significant can change now, I would at least like to express
my disappointment that this is not possible.

I was looking forward to concepts in the new standard because:

1. I liked the idea of putting constraints on types, in general

2. I wanted to use concept_maps in conjunction with refined concepts
and concept-based overloading to reuse my "storage classes" but write
optimized algorithms when data is known to be of a special form.

Now it seems like concepts don't really let you do very much with
types themselves.  If you want to use concept_maps, rather than
constrain types they instead communicate a requirement that a free
function must exist.  Granted, that free function probably has T& or
const T& as the first argument, so the type is "in there somewhere"
and its not that big of a difference technically.

Stylistically though, the whole free function thing feels a bit like
the 1980s style ANSI C you see in the UNIX world.  The advantage of a
higher level language over a lower level one should be that you can
read it and it just seems to "make sense".

Although you can certainly figure out what both of these do:

refresh(webPage);
webPage.refresh();

when an entire program starts to look more the former than the latter
it makes a big psychological difference.  Or it does to me, at least.
When doing things/verbs becomes the syntactic focus (as opposed to
what objects are significant) I think its hard to see the "big
picture" of how anything is supposed to be put together.  Perhaps its
a side effect of being a native English speaker and preferring an SVO
type language.  I'd like to think its universal, but I don't know.

For example, I don't know very much about compilers, but clang (the
new open source C/C++ compiler) makes much more sense to me than GCC.
clang is clean, modern C++/OOP style.  I can just read it and say
"yeah, I can see what that does".  GCC, well, I have no idea what any
of it does.

For me, the nicest thing about C++ was that you could keep the speed
of C and (if you were clever enough) you could keep the code still
"reading" like it was very high level.

I'm familiar with the argument that free functions are better for
encapsulation.  It's a decent argument, so I'll just accept it.  But
consider for a moment what happens if I make a point of always using
the same variable name "x" in my concept_map to pass in my object, as
in the following:

concept_map C<T>
{
 void a(T& x, ...);
 void b(T& x, ...);
 void c(T& x, ...);
};

And then (to make the point even more obvious) suppose that the
keyword "this" was not a keyword, so I could call "x" "this" instead
of "x".  Does it seem like I am effectively doing by hand what the
original Cfront compiler did automatically?  In some small way, we've
traveled back to 1978.

-Ken

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 15 Jan., 08:53, Ken Camann <kjcam...@gmail.com> wrote:
> I've seen several old messages saying that concept_maps cannot be used
> to implement member function associated requirements.  That appears to
> still be true today

That's not true.

See N2800.pdf, section 14.9.1.1 paragraph 5:
"Associated functions may specify requirements for static and non-
static member functions, constructors, and destructors."

Here' the example from paragraph 5. The comments are mine:

   concept Container<typename X> {
     X::X(int n); // constructor requirement
     X::~X(); // destructor requirement
     bool X::empty(); // non-static member function requirement
     static size_t X::max_size(); // static member function requirement
   }

I see basically two good reasons for prefering the free function
syntax:
(1) Support for built-in types. Since built-in types have no member
functions these types could never satisfy your concept.
(2) Support for retroactive modelling. You may not be able to change a
class definition and add a member function so that the class type
satisfies your concept.

Cheers!
SG


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]