Организация общих данных в модуле

[Dale]

Конструкция

Код:

 (A&)b=a; 

прекрасно работает.
Огромное спасибо. Ты вернул мне веру в себя, в ООП, и даже в С++.

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

Оно понятно, что истинная вера не требует и не признает аргументов, но все же...

[ezus]

Опять путаница.
Начиная с №19 - это копирование.
Может лучше перенести эти посты в ветку копирования, оставив здесь только дизайн?

[Dale]

Чем

Код:

(A)b = a;

не C++? Только тем, что Вы его не используете?(Пардон не удержался )

Да я-то тут при чем? Хоть разок полистайте Страуструпа, что ли... Он это тоже не использует, и другим настоятельно не советует. Или он тоже не указ?

[ezus]

Конструкция

Код:

 (A&)b=a; 

прекрасно работает.

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

Опять одни эмоции и география.

Оно понятно, что истинная вера не требует и не признает аргументов, но все же...

Так дайте, дайте аргументы. Аргументы на сцену. А эмоции пусть будут в зале.

По делу. Снова:
Есть дерево, есть береза, и есть осина.
Когда я пилю обычной деревенской пилой (оставим в стороне профессиональный подход к заточке пилы) мне все-равно что это - береза или осина - я пилю ДЕРЕВО, а не железо или воду. Разница будет важна только когда я буду заталкивать поленья в печь.
И что? Один и тот же кусок я не могу рассматривать в одном случае как ДЕРЕВО, а в другом как БЕРЕЗА?
Если Вы действительно утверждаете это, то мы, так и да, понимаем ООП по разному.

[Dale]

Раскрываем книгу: Бьерн Страуструп, "Язык программирования C++. Специальное издание".

Читаем.

Стр. 49: "Знание C не является обязательным для изучения C++. Программирование на С поощряет многие технические трюки, которые становятся ненужными благодаря С++. Например, явное преобразование типов в С++используется реже, чем в С ($1.6.1)".

Стр 50: "Чем лучше вы знаете С, тем труднее вам будет избежать программирования на С++ в стиле С, теряя при этом потенциальные преимущества С++.
...
Вот некоторые вещи, с которыми С++ справляется лучше, чем С:
...
[4] Пытайтесь избегать void*, арифметических операций над указателями, объединений и приведений типов, за исключением разве что глубоко спрятанных в реализацию функций или классов. В большинстве случаев приведение типа означает ошибку на этапе проектирования." (выделение мое - Dale).

Не аргумент?

[Алексей++]

ezus, непонятно, на что ты оскорбляешься. Даже не учитывая того, что Dale даже и не пытался оскорблять

[ezus]

Да я-то тут при чем? Хоть разок полистайте Страуструпа, что ли... Он это тоже не использует, и другим настоятельно не советует. Или он тоже не указ?

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

Я придерживаюсь взгляда, что детальное ЗНАНИЕ матчасти и строгое ей следование относится только к ИНСТРУМЕНТУ. Что же касается МЕТОДИКИ, то тут важно ПОНИМАНИЕ и вполне допустимы интерпретации и эксперименты. А просто ссылки на ... очень напоминают мне требование "Знать первоисточник" - 23 строка на 78 странице 17 тома Полного Собрания Сочинений товарища ....

Вы мне можете просто объяснить - чем плоха конструкция (A)b? Если можно, то с учетом моих замечание про березу и осину.

[Dale]

Вы мне можете просто объяснить - чем плоха конструкция (A)b? Если можно, то с учетом моих замечание про березу и осину.

Извольте. "Продолжаем разговор" (С)

Там же, стр. 172:
"С++ унаследовал от С форму записи (T)e, означающую любое преобразование, которое может быть выражено комбинацией static_cast, reinterpret_cast и const_cast, для получения значения типа T из выражения e($Б.2.3). Такой стиль намного опаснее, чем именованные операторы преобразования, потому чтоприведенную форму записи сложнее отслеживать в большой программе и вид преобразования, который имел в виду программист, не очевиден. Ведь (T)e можетосуществлять и переносимое преобразование между близкими типами, и непереносимое преобразование между несвязанными типами, и, наконец, аннулировать действие модификатора const для указателя."

Хотя действительно, что он понимает в ООП и С++, этот щенок Страуструп... И откуда у него истинная вера.

[ezus]

В большинстве случаев приведение типа означает ошибку на этапе проектирования." (выделение мое - Dale).

Не аргумент?

Принимаю как аргумент.

И все-таки. Вы отрицаете необходимость в ряде случаев представлять порожденный класс как базовый?

[Dale]

И все-таки. Вы отрицаете необходимость в ряде случаев представлять порожденный класс как базовый?

Это апофеоз, тут даже не сразу найдешь, что сказать...

- Знаете ли, профессор,  -  заговорила девушка, тяжело вздохнув, - если бы  вы  не  были европейским светилом, и  за вас  не  заступались  бы  самым возмутительным   образом  (блондин  дернул   ее  за   край  куртки,  но  она отмахнулась) лица,  которых,  я уверена, мы еще разьясним,  вас следовало бы арестовать.
- А за что? - с любопытством спросил Филипп Филиппович.
- Вы ненавистник пролетариата! - гордо сказала женщина.

В свое оправдание могу лишь сказать, что я НЕ отрицаю необходимость в ряде случаев представлять порожденный класс как базовый (если бы отрицал, меня действительно следовало бы арестовать). По крайней мере, не был в этом замечен. По крайней мере, на этом форуме. Но какое отношение это имеет к нашему случаю? Нет здесь никакого базового класса. И никогда не будет, судя по всему. Есть структура C, не более того.

[Dale]

ezus, непонятно, на что ты оскорбляешься. Даже не учитывая того, что Dale даже и не пытался оскорблять

Алексей, тут никакой реальной обиды нет. Это обычный ораторский прием: когда убедительных аргументов нет, всегда можно придумать зацепку для обиды. Ведь далеко не каждый может сказать: да, ребята, теорию не почитал, программу не продумал, спасибо, что подсказали, в каком направлении двигаться дальше. Проще упереться на своем, каким бы оно ни было, и парировать: "Зато все вы тут дураки некультурные, о чем с такими хамами вообще говорить!". И пускай потом оправдываются за то, чего не было.

[Алексей++]

Да уж, воистину непонятны действия товарисча ezus. Хотя, в принципе, он не складывал о себе мнения как о тупом. Но ТАКИЕ странности могут даже до увольнения с работы довести (если есть работа)

[Dale]

ТАКИЕ странности могут даже до увольнения с работы довести (если есть работа)

Ошибаетесь, коллега.

У меня совсем недавно начальник отдела IT одной очень крупной организации потребовал некоторые данные, которые я, вообще говоря, обязан отправить по требованию. Я отправил их в формате XML (мы их именно в этом виде обрабатываем). Через некоторое время раздался возмущенный звонок:

- Что вы нам прислали?
- Запрошенные файлы.
- Но файлов не было, пришли отчеты!

Затем по телефону мне был преподан краткий курс информатики, после чего я наконец-то понял, что XML - это отчет, CSV - это файл, а DBF - это база данных. Занавес.

А вы говорите - увольнение... Да мы как раз первыми и вылетим. За то, что не знаем, чем файл от базы и отчета отличается, то есть полную профнепригодность.

[Вад]

Конструкция

Код:

 (A&)b=a; 

прекрасно работает.
Огромное спасибо. Ты вернул мне веру в себя, в ООП, и даже в С++.

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

Какой же это Си? В Си ссылок никогда не было, разве нет? Про копирование структур тоже сомневаюсь, хотя точно не помню уже. Да и хак не настолько уж низкоуровневый: здесь же тип не к void* приводится, а вверх по иерархии. Контроль соответствия типов в этом случае криминал не даст совершить (присвоить "камню" "дерево")

"С++ унаследовал от С форму записи (T)e, означающую любое преобразование, которое может быть выражено комбинацией static_cast, reinterpret_cast и const_cast, для получения значения типа T из выражения e($Б.2.3). Такой стиль намного опаснее, чем именованные операторы преобразования, потому чтоприведенную форму записи сложнее отслеживать в большой программе и вид преобразования, который имел в виду программист, не очевиден. Ведь (T)e можетосуществлять и переносимое преобразование между близкими типами, и непереносимое преобразование между несвязанными типами, и, наконец, аннулировать действие модификатора const для указателя."

Почти весь криминал (если не весь) связан с преобразованием указателей. Хотя я тоже предпочитаю static_cast, в данном случае он не так чтобы нужен. Ошибка была совсем в другом - в том, что (Т)е является lvalue только для ссылочных типов. В случае работы с указателями это, в общем-то, безразлично, а вот в случае присваивания значений переменным - даёт то, что даёт.

[Антон (LogRus)]

Вад, уже всё сказал, ну не стирать же сообщение

Код:

(A)b=a; 

И так что тут происходит? Компилятор всеми силами старается b к типу A для этого он вполне логично делает его копию (для меня это выглядит именно так), далее мы модифицируем временный объект.

Вот цитата из стандарта касающаяся static_cast (который скорее всего и используется)

Otherwise, an expression e can be explicitly converted to a type T using a static_cast of the form static_-
cast<T>(e) if the declaration T t(e); is well-formed, for some invented temporary variable t (8.5). The
effect of such an explicit conversion is the same as performing the declaration and initialization and then
using the temporary variable as the result of the conversion. The expression e is used as a glvalue if and
only if the initialization uses it as a glvalue.

конструкция

Код:

(A&)b=a; 

приводит нас к ссылке на объект без создания временного объекта, что кстати тоже описано в стандарте

[Dale]

Какой же это Си? В Си ссылок никогда не было, разве нет?

И структуру от структуры в чистом C нельзя произвести наследованием, само собой. Компилятор С такую программу не воспримет. Однако такая мелочь не делает приведенный фрагмент объектно-ориентированной программой на С++.

Кстати, вот еще у Страуструпа попалось на глаза:

"Ключевое понятие в С++ - это класс. Класс - это тип, определяемый пользователем. Классы обеспечивают сокрытие информации, гарантированную инициализацию данных, неявное преобразование определяемых пользователем типов, динамическое определение типа, контроль пользователя над управлением памятью и механизм перегрузки операторов".

Давайте попытаемся найти хотя бы одно из перечисленных свойств в структуре, которая гордо именуется "базовым классом". Разве что "тип, определяемый пользователем", тут уж не поспоришь.

В той же программе на С можно, например, перегрузить определение функции с другими аргументами, после чего она перестанет быть корректной программой на С. Но говорить, что она была переписана на С++, как-то смешно.

[Вад]

Dale, возможно, кощунственно прозвучит, но C++ - не объектно-ориентированный язык. В пользу этого говорит хотя бы частичная (почти полная) совместимость с С и поддержка процедурно-модульного подхода.
C++ лишь поддерживает ООП-парадигму.

Поэтому в структуре нет ничего такого особенного. А учитывая некоторые сложности с реализацией ООП средствами C++ (нужно заботиться о корректном копировании и вручную управлять всеми динамическими объектами), часто структура является даже более естественным типом. Когда есть только данные, а манипуляции над ними каждый модуль делает свои, и нет ничего такого, что можно было бы выделить в качестве общих методов для этих данных и запихать в класс (кроме геттеров, которые тут становятся скорее помехой)

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

[Dale]

Dale, возможно, кощунственно прозвучит, но C++ - не объектно-ориентированный язык.

Тут нет кощунства. Если бы он был объектно-ориентированным, он бы просто не позволил подобные выкрутасы в принципе, и данная тема не могла бы возникнуть. Речь как раз о том и идет, что аморфность языка позволяет программирующему на нем пребывать в искреннем заблуждении, что он пишет объектно-ориентированные программы, которые реально таковыми не являются.

[Вад]

Dale, возможно, кощунственно прозвучит, но C++ - не объектно-ориентированный язык.

Тут нет кощунства. Если бы он был объектно-ориентированным, он бы просто не позволил подобные выкрутасы в принципе, и данная тема не могла бы возникнуть. Речь как раз о том и идет, что аморфность языка позволяет программирующему на нем пребывать в искреннем заблуждении, что он пишет объектно-ориентированные программы, которые реально таковыми не являются.

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

Просто я не стал бы говорить, что "это не C++" или что "так нельзя". На C++ - в силу его аморфности - можно программировать множеством способов, и, на мой взгляд, неправильными являются не те, которые используют какие-то хаки, трюки или ещё что-то. А те, которые приводят к малопонятным и плохо поддерживаемым решениям - то есть, дают в целом менее качественный код.

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

[Dale]

Но даже заблуждение насчёт объектно-ориентированных программ криминалом само по себе не является Другое дело - когда мотивация решения базируется на таких заблуждениях.

А тут уже виной моя невнимательность. Я проглядел небольшую, но важную деталь:

Я сторонник ИДЕЙ ООП, но не самого ООП, особенно в исполнении С++. Поэтому аргументы типа "так принято в ООП" для меня не аргументы.

Это автоматически делает все мои предыдущие аргументы несостоятельными.

Вот представьте себе, садитесь вы играть в шахматы. Точнее, это вы думаете, что в шахматы. А противник берет вашего ферзя за фука, а потом идет ладьей по диагонали через всю доску. На ваши робкие потесты отвечает: "А я сторонник идей шахмат, но не самих шахмат, особенно по правилам ФИДЕ. Я экспериментирую, творчески развиваю идею".

Я примерно так же вижу ситуацию. Вроде знакомая доска, знакомые фигуры, а игра, вопреки ожиданиям, идет почему-то в "Чапаева"... Причем вовсе не факт, что я могу претендовать на правоту в данном вопросе, игру каждый волен выбирать себе сам.

[Dimka]

Вы можете привести мне примеры предложенных приемов без использования поэлементного присвоения?

Конечно могу.

Пример со специальным конструктором копирования (по сути аналогичный предложенному LogRus):

Код: (C++)

#include <iostream>

struct A
{
    int a;
    A(): a(0) {}
};

struct B: public A
{
    int b;
    B(): A(), b(0) {}
    B(const A &other): A(other), b(0) {}
};

int main()
{
    A a;
    a.a = 123;
    B b(a);
    std::cout << b.a << " " << b.b << std::endl;
}

Чем
Код:
(A)b = a;
не C++? Только тем, что Вы его не используете?

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

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

Совершенно верно! Именно так это и оценивается.

И все-таки. Вы отрицаете необходимость в ряде случаев представлять порожденный класс как базовый?

Никто не отрицает. Только ты делаешь наоборот! Экземпляр базового пытаешься присвоить переменной порождённого со всеми вытекающими.

[Антон (LogRus)]

что докопались до человека, никакого хата, обычный код
привести к базовому и присвоить, совершено штатное поведение, другое дело, что используется C стиль

[Dale]

что докопались до человека, никакого хата, обычный код

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

[Антон (LogRus)]

Я вообще спокоен сижу работаю иногда пишу всякую хрень сюда (типа у меня есть мне по любому поводу и без )

[ezus]

что докопались до человека, никакого хата, обычный код
привести к базовому и присвоить, совершено штатное поведение, другое дело, что используется C стиль

Спасибо за сочувствие.
При всем моем немалом опыте программирования -  в С++ я новичек - всего 3 года, причем первый был 20 лет назад, а последние 2 приходится работать с системой, которой тоже около 20 лет и в ней С больше чем С++.

Пример со специальным конструктором копирования (по сути аналогичный предложенному LogRus):

Код: (C++)

#include <iostream>

struct A
{
    int a;
    A(): a(0) {}
};

struct B: public A
{
    int b;
    B(): A(), b(0) {}
    B(const A &other): A(other), b(0) {}
};

int main()
{
    A a;
    a.a = 123;
    B b(a);
    std::cout << b.a << " " << b.b << std::endl;
}

Это именно то, что мне более всего подходит. Спасибо.

Только ты делаешь наоборот! Экземпляр базового пытаешься присвоить переменной порождённого со всеми вытекающими.

А можно поподробнее о "со всеми вытекающими"? Очень хочется понять.

[Dimka]

А можно поподробнее о "со всеми вытекающими"? Очень хочется понять.

Мне уже утомило повторять о последствиях. Что именно подробнее? Трижды я в этой и исходной темах говорил, что в такой операции присваивания не задействуются поля производной структуры. Неочевидным образом заполняется лишь часть полей, и никакой код (будь то метод или оператор присваивания) не контролирует целостность данных.

[sss]

ezus, вот пример :

Код:

  DWORD    dw;
  dw = dw | 0xFF;

или

Код:

  WORD      w = 0xFFFF;
  DWORD    dw;
  CopyMemory( &dw, &w, sizeof( w));

Чему равно dw ? 

[ezus]

вот пример :

Код:

  DWORD    dw;
  dw = dw | 0xFF;

или

Код:

  WORD      w = 0xFFFF;
  DWORD    dw;
  CopyMemory( &dw, &w, sizeof( w));

Чему равно dw ? 

К чему этот пример?
Разве WORD  наследует DWORD,  или наоборот?
Или вы проверяете меня на вшивость - знаю ли я представление данных в разных процессорах? А вы знаете?
Где в этом примере связь с поставленным вопросом?

[ezus]

При обсуждение данной проблемы со свои сыном он назвал меня  "старым хреном". С таким аргумент трудно было не согласиться. Посему признаю свою тупость или отсталость.
ВСЕМ СПАСИБО за потраченное время.

[Алексей++]

ezus, сыну - надрать задницу за неуважение!