From 8939712222508419786 X-Google-Thread: 7894ca11fe,421cd8b98acf7c5 X-Google-Attributes: gid7894ca11fe,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!news.glorb.com!news.alt.net!frodo.cs.rpi.edu!not-for-mail From: "Joe Smith" Newsgroups: comp.std.c++ Subject: Re: Why there are both complex::real and std::real? Date: Sun, 1 Nov 2009 21:26:58 CST Organization: Mixmin Lines: 96 Sender: cppmods@cs.rpi.edu Approved: stephen.clamage@sun.com Message-ID: References: <210ca399-bea2-47bf-b614-f4cef8fe25fd@k26g2000vbp.googlegroups.com> <9f639ca8-87a5-43fe-923f-c62a4bea7cfa@j4g2000yqa.googlegroups.com> <1858197e-a472-4036-8716-bf96f5a0bb34@k4g2000yqb.googlegroups.com> NNTP-Posting-Host: netlab.cs.rpi.edu Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original To: (Usenet) Return-Path: X-Original-Date: Sun, 1 Nov 2009 11:23:28 -0500 X-Submission-Address: std-c++@netlab.cs.rpi.edu Xref: g2news2.google.com comp.std.c++:1631 "frege" wrote in message news:1858197e-a472-4036-8716-bf96f5a0bb34@k4g2000yqb.googlegroups.com... > > >> That does imply that it would be better to use the member functions in >> templates than the free functions, since other complex-like classes >> that the template may be useful for are likely to have the member >> functions, but not free function overloads, right? >> > > The general trend I'm seeing (for all templates, not just things like > complex) is to use free functions. That way, your template can cover > all types - even those without member functions. Because I can always > add free functions, but I can't always add member functions (ie to > classes that aren't 'mine', etc). > And here again we get back to the classic debate of what belongs as member functions of a class and what belongs as free functions. In many cases, for those who understand basic OO concepts, member functions often syntacticly make more sense than free functions. Microsoft's Intellesense system, and others like it make it easier to use member functions when available. There are however a few big problems with member functions. One is that those functions that really do not benefit from having direct access to private members have such access anyway. For code maintenence reasons, it is usually preferable if only functions that need such acess have it, so that fewer functions actually use the private members, making it far easier to change them later if needed. Obviously, there is a tradeoff here, and needs is somewhat subjective. If a function can be implemented without acess, but it is far more complicated than if it had access to the private members, then perhaps it should have that access, etc. If there were a nice way to make pseudo-member functions that did not have private acess, that would aleviate the problem. It may also potentially aleviate the other problem, that third party extentions cannot add member functions without using inheirtance. This is both good and bad. On one hand letting everybody inject additional functions as member functions sounds like it would become problematic, as all such functions are effectively in the same namespace. But it prevents third parties from adding new functions access like member functions even if they syntactically would make sense as them. When I first heard of the concept proposal, I was under the impression that at least for deduced contexts this problem could be solved. I was under the impression that except for some operators, all functions in a concept would be pseudo-member functions, becoming calls to the real member function or to the definition in the concept_map. This made good sense to me. through this mechanism, one could add pseudo-member functions to any existing class, or even to built-in types, and things would just work, at least in contrained contexts. But apparently others seem to think that many functions in concepts should be pseudo-free functions instead, mapping to the real free function, or to the definition in the concept_map as applicable. I also have some namespacing concerns with free functions. Free functions can be used in two different ways. I'll show these by example. namespace complex_utils{ template T conj(T& t) { return T(std::real(t), -std::imag(t)); } } That sort of does not cause namespace issues. When I define my new complex-like type that is comaptible enough that many templates designed for std::complex can use it, I simply inject a new overload into namespace std, which I am explicitly permitted to do. The other form is as follows. namespace soemthing{ template T conj(const T& t) { return T(real(t), -imag(t)); } } Here, ADL is being used. Injecting an overload into namespace std will do nothing here, since the compiler will be looking in my namespace for real and imag. Thus in some sense, now I need a my_ns::real(my_complex) function, when it is conceptually an overload of std::real, and thus ought to belong there. In some sense then my namespace is being infringed upon. I would not be objecting to the infringment upon the ::my_ns::my_complex namespace of member functions, since my goal is compaibilty, but infringing the ::my_ns namespace so that ::my_ns::my_complex can be compatible seems wrong. Even a template that autocalls member functions being present in namespace std would not prevent the polluting of ::my_ns, since that template function would never even be considered if ADL style is being used. -- [ 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 ]