#include<iostream>
#include<math.h>

class real
{
  double value;
  double error;
public:
  real(const double,const double);
  double get_value();
  double get_error();
  friend bool operator<=(const real&,const double);
};

real::real(const double val, const double err) : value(val), error(fabs(err)) {}

double real::get_value()
{
  return value;
}

double real::get_error()
{
  return error;
}

bool operator<=(const real& x1, const double x2)
{
  return x1.get_value() + x1.get_error() < x2;
}

int main()
{
  return 0;
}

Compiler error:
passing 'const real' as 'this' argument of 'double real::get_alue()' discards qualifiers

However since operator <= is a friend x1.value or x1.error is valid!

Dani AI

Generated

This is a const-correctness issue rather than a syntax bug. The compiler message means a const-qualified object (the const real& argument) can only call member functions that promise not to modify the object. is correct: mark accessor functions as const so they can be called on const references. See the language notes on member functions for details: cppreference: member functions.

A few practical points that expand on the thread:

  • Trailing const can only appear on non-static member functions. You cannot write ... ) const on a free (non-member) function; that’s why the friend signature you tried is illegal. If you make the comparison an actual member, a trailing const is valid. Example (new example, different from the thread):

    class real {
        double value;
        double error;
    public:
        bool operator<=(double rhs) const { return value + error < rhs; }
    };

    That implements real <= double and is allowed to be const. If you need double <= real as well, prefer a non-member operator (possibly friend) or provide a converting constructor so implicit conversions work; see operator overloading rules: cppreference: operators.

  • Don’t return built-in types as const (e.g. const double get_value()) — it’s useless and can inhibit optimizations. Small accessors are good candidates for constexpr or noexcept when appropriate, and prefer <cmath>/std::abs over C headers.

Summary: make the getters const, decide whether the comparison should be a member or non-member based on symmetry of conversions, and avoid const on return-by-value. These choices keep intent clear and avoid the qualifier-discard error.

Recommended Answers

All 3 Replies

Didn't we already go over this with you? If you want to call a member function through a const object, the member function should be qualified as const too:

#include<iostream>
#include<math.h>

class real
{
  double value;
  double error;
public:
  real(const double,const double);
  double get_value() const;
  double get_error() const;
  friend bool operator<=(const real&,const double);
};

real::real(const double val, const double err) : value(val), error(fabs(err)) {}

double real::get_value() const
{
  return value;
}

double real::get_error() const
{
  return error;
}

bool operator<=(const real& x1, const double x2)
{
  return x1.get_value() + x1.get_error() < x2;
}

int main()
{
  return 0;
}

In fact, any member functions that don't modify the state of the object should be qualified as const.

And the syntax is always

double get_value() const;

or can be

const double get_value() const;

?

I also have to write const after the operator<= ? like this:

bool operator<=(const real& x1, const double x2) const

>And the syntax is always
>double get_value() const;

Yes.

>or can be
>const double get_value() const;

That's different. The leading const is applied to the return type and means you want to return a const double. The trailing const is applied to the member function and means the member function doesn't modify an object's state.

>I also have to write const after the operator<= ?
No, because that's illegal. const can only be applied to member functions.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.