[C++] Странности в классах

A(const A & a){ i = a.i; } i - приватный член класса, a.i - неправильно.

>bool do()

Как такое скомпилироваться то могло?

>A(const A & a){ i = a.i; } i - приватный член класса, a.i - неправильно.

Стыдоба, лучше бы ты этого не писал

> Подскажите пожалуйста, как локализовать данную ошибку ? Спасибо.

Подозреваю, с помощью valgrind и подобных ему инструментов.

ну, во-первых, неплохо это переписать вот так:

class A {
public: 
	A() : i_(1)
	{}
	
	explicit A(int j) : i_(j)
	{}
	
	A(const A &a) : i_(a.i_)
	{}

	A &operator=(const A &a)
	{
		i_ = a.i_;
		return *this;
	}

	bool doWork()
	{
		return i_ >= 0;
	}

private:
	int i_;
};

за исключением метода, названным зарезервированным словом, особых проблем не вижу

> ... где в дебрях большой программы падаем в методе do() с ошибкой Segmentation fault.

мб метод вызывается по некорректному указателю (не инициализирован, используется после delete итп).

мб метод вызывается по некорректному указателю

Вот это может быть!

точнее - однозначно это

Epic fail.

Не пугай так больше. Я уж подумал это правда.

i_

Лучше уж тогда нормальные имена давать, чем это.

Может сдох объект, метод которого ты вызываешь? Посмотри valgrind-ом, он такие места хорошо показывает.

у него с большой буквы, но да, это <неразборчиво>

сначала было с маленькой :) http://www.linux.org.ru/forum/development/5909285/history

bool Do()
{
    if (i >= 0) 
        return true; 
    else 
        return false;
}

глаза режет. Лучше

bool Do() {
    return i >= 0;
}

Нормально работает код. «i = a.i» работает, т.к. класс является дружественным сам себе (friend), но лучше это не использовать, если возможно, т.к. это нарушение принципов ООП.

Программа у вас явно падает не из-за этого кода, он корректен. Скорее всего где-то удаляется объект этого класса, а потом вы пытаетесь по несуществующему адресу (указателю) получить доступ к объекту (разыменовать несуществующий указатель). Попробуйте запустить под отладкой и посмотреть стек вызовов, когда прога навернется.

Код конечно некрасивый, лучше было бы так:

#include <cstdlib>
#include <iostream>

class A
{
public:
    A();
    explicit A(const A &a);
    explicit A(int i);

    bool test() const;
    int value() const;

private:
    int m_i;
};

A::A()
    : m_i(1)
{
}

A::A(const A &a)
    : m_i(a.m_i)
{
}

A::A(int i)
    : m_i(i)
{
}

bool A::test() const
{
    return m_i >= 0;
}

int A::value() const
{
    return m_i;
}

int main(int argc, char *argv[])
{
    // Hide warning of unused variables
    (void)argc;
    (void)argv;

    A a1(123);
    A a2(a1);

    std::cout << "a2 value is " << a2.value() << std::endl;

    return EXIT_SUCCESS;
}

> Нормально работает код. «i = a.i» работает, т.к. класс является дружественным сам себе (friend), но лучше это не использовать, если возможно, т.к. это нарушение принципов ООП.

Я бы сказал, что это нормально. Ибо конструктор копирования - это не просмот свойст объекта

Точно, не подумал. Для копирующего конструктора это нормально.

реализовал копирующий конструктор и объявил его, как explicit... гениально, че сказать

Ну если нужно иметь возможность сделать:

A a2 = a1;

A a2(a1)

это нарушение принципов ООП

напротив, это как раз святое следование заветам о low coupling/high cohesion

low coupling/high cohesion - это не принципы ООП, это принципы проектирования в целом, которые были известны задолго до возникновения ООП. И не совсем понятно, при чем тут эти 2 принципа? Я согласился уже, что для копирующего конструктора вполне нормально получать доступ к закрытым членам класса переданного объекта, иначе пришлось бы делать геттеры для каждого поля класса, что засоряло бы интерфейс класса. Я имел ввиду, что *в общем* получать доступ к приватным членам другого объекта - это нарушения принципа ООП об инкапсуляции.

это не принципы ООП, это принципы проектирования в целом

но мы же про ООП говорим, не? к тому же, в других областях эти принципы не называются так уродливо

Я имел ввиду, что *в общем* получать доступ к приватным членам другого объекта - это нарушения принципа ООП об инкапсуляции

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

>>A(const A & a){ i = a.i; } i - приватный член класса, a.i - неправильно.

Стыдоба, лучше бы ты этого не писал

Sr. developer, наверное... Так что можно :)

>Нормально работает код. «i = a.i» работает, т.к. класс является дружественным сам себе (friend), но лучше это не использовать, если возможно, т.к. это нарушение принципов ООП.

Смело

Ты знаешь, чего ты себя лишил с explicit'уным конструктором копирования?

Подумаешь, может у человека неприязнь к неявным преобразованиям через конструктор копирования. Несколько раз видел таких людей.

>у человека неприязнь к неявным преобразованиям через конструктор копирования

Суть не в этом. Убивается возможность получать/передавать/возвращать такие объекты по значению

// не узнаю ЛОР.

>не узнаю ЛОР

Ой, я лопух. Читаю/пишу о конструкторе копирования, а думаю о конструкторе преобразования.

На самом деле для копирующего конструктора я explicit не подумав поставил, когда ставил explicit для A(int i). Я знаю к чему это приводит прекрасно, но как я уже написал выше, в данном примере это абсолютно неважно, т.к. я явно вызывал конструктор в main(). В реальном проекте эту ошибку я быстро вычислил бы, написав A a = b; и убрал бы explicit. Короче это просто опечатка, для данного примера ИМХО некритичная.

Про ООП - я имел ввиду по аналогии с доступом в копирующем конструкторе к приватным членам класса, что не стоит использовать механизм френдов без крайней нужды, в копирующем конструкторе конечно же это нормально.

Скажите g++ "-fstack-protector-all" и велика вероятность, что упадет в правильном месте. А если нет, то тогда Valgrind.

называй методы с маленькой буквы, блджад... а то с классами можно спутать.