From 7944702720157956685 X-Google-Thread: 7894ca11fe,421cd8b98acf7c5 X-Google-Attributes: gid7894ca11fe,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news1.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Fri, 30 Oct 2009 14:40:02 -0500 Return-Path: To: (Usenet) From: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= Newsgroups: comp.std.c++ Subject: Re: Why there are both complex::real and std::real? Organization: http://groups.google.com Sender: cppmods@cs.rpi.edu Approved: stephen.clamage@sun.com Message-ID: <0404642e-2fea-4864-a30a-8928e176d896@k17g2000yqb.googlegroups.com> References: <210ca399-bea2-47bf-b614-f4cef8fe25fd@k26g2000vbp.googlegroups.com> <9f639ca8-87a5-43fe-923f-c62a4bea7cfa@j4g2000yqa.googlegroups.com> Content-Type: text/plain; charset=ISO-8859-1 X-Original-Date: Fri, 30 Oct 2009 12:19:21 -0700 (PDT) X-Submission-Address: std-c++@netlab.cs.rpi.edu Date: Fri, 30 Oct 2009 14:31:44 CST Lines: 70 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-VZhHiEOGB9IGqFy0/bK8Jdg+ca79Q2Koq1AuEK0FuAmoINVdPswJ+yVDSq4YlZeVkwAkupxPs+GeqNj!O7Awp0N9kBY+5ElkPzIUQ9ACbGraXVRqbKF4ooghUIaOUbvRrmqg0olBEzCeu+NUnMKbtw/WhxpR!kaXqhXqkOZA3OJEK7OSWOvpUfQM= X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 Xref: g2news2.google.com comp.std.c++:1611 On 30 Okt., 19:31, "Joe Smith" wrote: > "Daniel Kr= FCgler" wrote in messagenews:aa2d0be1-e9fd-431d-a495-a5adc2b947ed@h40g2000prf.googlegroups.com... > > On 27 Okt., 20:14, Saeed Amrollahi wrote: > > On Oct 27, 12:26 am, Daniel Kr�gler > wrote: > So, the free functions real() and imag() are there just for C/C++ > compatibility. > > Yes, exactly. > > For new abstractions let say run-time rational numbers, we don't need > to such compatibility, because there is no rational number > related functions > in C, then we don't have to worry about these things. Right? > > This is correct. > > 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? I don't know whether a clear answer to that question exists, it depends on whether there is a commonly accepted concept of a complex type. Another perspective to the same problem is that especially complex types are typically near to built-in types (in C they are built-in's) and this may cause implementors to develop them such that no need for a class type exists. This kind of thinking has a long tradition in C++ and if you check out the last draft for decimal support in C++ http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2849.pdf you will observe that the chosen interface corresponds to non-class types or in other words: If the decimal type is implemented as non-class type you won't notice the difference if the type is used "normally", e.g. by not attempting to call operators explicitly. From this POV I would expect that third-party implementations of a complex type would tend to use the same strategy and would provide non-member functions of the real and imag observers as well. The same idiom can be recognized by observing that basically no abs function is realized as a member function. One could also say that it might have been not such a good idea that std::complex did provide real and imag as member functions at all, because they are somewhat redundant in the presence of the free observer functions. Returning to your question: I don't expect that a template code for complex-like types would necessarily attempt to get access to the real and imaginary part of the number by member functions. But a library might consider to use SFINAE tricks to determine whether access is possible by member functions and otherwise might attempt to fall-back to the free function access (or vice versa). HTH & Greetings from Bremen, Daniel Kr�gler -- [ 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 ]