I have a question about complex numbers in standard library. Why there
are both complex::real/imag
member functions and std::real/imag global funcctions? consider:
complex<double> cd(1,2);
double r = cd.real();
r = real(cd);
double i  = cd.imag();
i = imag(cd);

Thanks,
 -- Saeed Amrollahi

HTH & Greetings from Bremen,

Daniel Krügler

So, the free functions real() and imag() are there just for C/C++
compatibility.
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?

Thanks in advance,
 -- Saeed Amrollahi

HTH & Greetings from Bremen,

Daniel Krügler

"Daniel Kr= FCgler" <daniel.krueg...@googlemail.com> wrote in message
news:aa2d0be1-e9fd-431d-a495-a5adc2b947ed@h40g2000prf.googlegroups.com...

    On 27 Okt., 20:14, Saeed Amrollahi <amrollahi.sa...@gmail.com> wrote:

        On Oct 27, 12:26 am, Daniel Krügler <daniel.krueg...@googlemail.com>
        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?

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

And you can also add a default free impl that calls the member impl:

template <typename T> double real(T t)
{
    return t.real();

Tony

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<typename T>
T conj(T& t)
{ return T(std::real(t), -std::imag(t)); }

The other form is as follows.

namespace soemthing{
template<typename T>
T conj(const T& t)
{ return T(real(t), -imag(t)); }

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.

[..]

"[..] A program may add a template specialization for any standard
library template to namespace std only if the declaration depends
on a user-defined type of external linkage and the specialization
meets the standard library requirements for the original template
and is not explicitly prohibited."

There exists no permission regarding adding overloads to
namespace std and the truncated first sentence of
[namespace.std]/1 is very strict here:

"The behavior of a C++ program is undefined if it adds declarations
or definitions to namespace std or to a namespace within
namespace std unless otherwise specified.[..]"

  namespace soemthing{
  template<typename T>
  T conj(const T& t)
  {
     using std::real;
     using std::imag;
     return T(real(t), -imag(t)); }
  }

and ensuring that both free functions are in scope during
instantiation.

HTH & Greetings from Bremen,

Daniel Krügler

    return T(real(t), -imag(t));

I agree with you that, in general, the right thing to do is to
overload std::real(), as that is the context of what you are
implementing.  Otherwise a function like real(t) could be anything -
not related to complex numbers at all...

Tony