Ошибка при запросе метода класса

[profi]

Bow test();

Объявление функции.

[Red_Line]

Я канеш не сведущ, но просто логически так подумать, компилятор разве не должен различать функцию и объявление объекта? Имя класса каГ бЭ намекает... сорри, если пургу несу, интересно просто разобраться ))

[alex_x_x]

Red_Line
Bow test() можно интерпретировать как функцию test возвращающую объект Bow, а по стандарту такие конструкции интерпретируются как объявления функций

[veniside]

функция ведь может возвращать объект типа Bow

[Red_Line]

Эх глупый я, глупый... спасибо за разъяснения, ребята ))

[Obey-Kun]

Ошибку уже поправили, но хотелось бы отметить пару косяков. Во-первых, srand ты используешь в конструкторе класса. Там это ни к чему, ибо эту функцию достаточно использовать один раз за всё программу.

Во-вторых, названия методов charging и shooting не сразу дают понять, что именно они понять. Вот, сравни: мой_лук.стреляет() и мой_лук.выстрелить(). Ясен пень, второе понятней. То есть лучше методы назвать charge и shoot. И именования булевых лучше делать не как ready, а как is_ready (а также can_do_smth, в общем чтобы сразу было понятно, что это может быть только правда/неправда), ведь так сразу понятно, что это булева.

В-третьих, конструктор можно бы было бы определить и снаружи класса.

В-четвёртых, void в качестве параметров писать ни к чему.

В-пятых, насчёт getStatus. Что понятней — лук.взятьСтатус или лук.готовСтрелятьСейчас? Ясен пень, второй, ибо «статус» смысловой нагрузки не несёт в данном случае. А вот если бы был, скажем, enum Bow::Status { Ready, Shooting, Charging, Broken } или типа того, то можно бы было возвращать статус, и тогда бы было понятно, о чём речь, но у тебя ведь дело в другом. Да и вообще, геттерам слово get ни к чему.

В-шестых, лучше экономить пространство и перенос строки перед открывающей { делать только для: определений функций (исключение: определения метода внутри тела класса, но такого лучше избегать), классы, структуры и пространства имён. Для всего остального лучше писать в той же строке.

В-седьмых, поля класса лучше именовать как m_ready или _ready. Так ты сможешь отличить локальные переменные/аргументы функции от полей. Также это поможет избежать variable shadowing.

Ну и последнее, скобки лучше открывать всегда. А то возможна такая ошибка:

else cout<<"Вы попали в "<<score<<".\n";

Когда-нибудь можешь заменять на.

else
    cout<<"Вы попали в "<<score<<".\n";

А потом на

else
    cout<<"Вы попали в "<<score<<".\n";
    cout << "Теперь у вас " << total_score << " очков." << endl;

А ведь это ошибка. Другое дело, если бы там сразу были скобки.

Да, вот ещё что, у тебя зачем-то описан пустой деструктор (можно вообе без него обойтись) и сделан пустой return в конце shooting(). А ещё число «10» ты используешь в двух местах и лучше бы его объявить как константу. А в getStatus лучше просто написать return return (условия).

Ох, вот ещё что. Используй константные методы! У тебя метод getStatus должен быть константным.

В общем, писал бы я код, он был бы таким:

#include <iostream>
#include <cstdlib>

class Bow
{
public:
    Bow();
    void shoot();
    void charge();
    bool canShoot() const;
private:
    static const int m_quiver_size = 10;
    int m_arrows_num;
    bool m_is_ready;
};

Bow::Bow(): m_arrows_num(m_quiver_size), m_is_ready(true)
{
}

void Bow::shoot()
{
    int score;
    score = rand() % 11;
    if(!m_is_ready) {
        std::cout << "Лук не готов к стрельбе, натяните тетеву!" << std::endl;
        return;
    }
    if(score == 0) {
        std::cout << "Вы промахнулись!" << std::endl;;
    } else {
        std::cout << "Вы попали в " << score << "." << std::endl;
    }
}

void Bow::charge()
{
    m_arrows_num = m_quiver_size;
}

bool Bow::canShoot() const
{
    return (m_is_ready && m_arrows_num > 0);
}

Обрати внимание на реализацию canShoot:
1) m_is_ready == true писать не к чему.
2) m_arrows_num > 10 проверять дольше, чем значение m_is_ready, так что лучше m_is_ready писать первым пунктом. Ибо если оно false, то ему не придётся сравнивать числа.

Вот полезное чтиво по стилю:
http://doc.qt.nokia.com/qq/qq13-apis.html
http://qt.gitorious.org/qt/pages/QtCodingStyle
http://google-styleguide.googlecode....k/cppguide.xml (но в последнем мне несколько пунктов не нравится)

[Red_Line]

Спасибо за внимание к моей проблеме!! Обязательно учту всё вышеописанное Вами... часть стиля, кот. у меня присутствует в описании класса честно взят из книг, по кот. я учусь, а часть сам придумал )) вообще это мой первый класс, я просто старался вникнуть в синтаксис/семантику, не особо уделяя внимание читаемости/универсальности кода ))