D vs C++ , почти сурковская пропаганда: не пора ли C++ потихоньку готовиться к пенсии?

Цитата MyNameIsIgor @ 12.02.14, 10:28

Цитата D_KEY @ 12.02.14, 10:20

Если для составного типа не задана функция сериализации, то он не сериализуем вообще

fixed.
Да и я спрашиваю вообще, а не про именно сейчас.

Описывать метод сериализации для каждого своего типа как-то не очень удобно. Обычно это довольно рутинный copy-paste код.

Кстати маршалинг/демаршалинг в xml/json структур в Go не затрагивает скрытые поля структур. ЕМНИП до них и через рефлексию не достучаться.

Цитата korvin @ 12.02.14, 11:05

Обычно это довольно рутинный copy-paste код.

Это смотря какой движок сериализации. Например, в boost.serialization ты фактически просто указываешь, что хочешь сериализовать.
Для сериализации/десериализации:

    template<class Archive>
    void serialize(Archive & ar, const unsigned int version)
    {
        ar & x;
        ar & y;
        ar & z;
    }

Так же есть возможность разделить сохранение и загрузку(определив методы save и load, а не serialize)

Цитата D_KEY @ 12.02.14, 11:22

Например, в boost.serialization ты фактически просто указываешь, что хочешь сериализовать.

Кстати, это тоже интересный момент: как указать поля которые нужно сериализовать, или наоборот не нужно. В D есть фича, которую можно для этого применить. Это так называемые UDA - user defined attribute. По сути - это что-то вроде пометок, которые ни на что не влияют, но которые можно читать (compile time) и предпринимать в зависимости от этого какие-то действия. Пример: http://dpaste.dzfl.pl/120ff9a20956

Сообщение отредактировано: applegame - 12.02.14, 11:46

Цитата D_KEY @ 12.02.14, 11:05

Ну тебя же не смущает дефолтный конструктор копирования, например

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

Цитата D_KEY @ 12.02.14, 11:05

Если все поля у объекта сериализуемы

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

Цитата korvin @ 12.02.14, 11:05

Описывать метод сериализации для каждого своего типа как-то не очень удобно

Меня больше волнует правильность, а не удобство поведения по умолчанию, чреватого детскими грабельками.

Цитата korvin @ 12.02.14, 11:05

Обычно это довольно рутинный copy-paste код.

Это зависит от библиотеки сериализации. Я не замечал копипасты. Кроме того, метаинформацию никто не отменял. Вон и applegame её для себя открыл.

Сообщение отредактировано: MyNameIsIgor - 12.02.14, 12:13

Цитата applegame @ 12.02.14, 05:57

Тут не важно виртуальный базовый класс или нет. Виртуальность ничего не меняет:

А тут и не должно, т.к. как уже говорилось, Base не реализует IFoo. Но вот так должно:

class IFoo {
    virtual void f() = 0;
    virtual void g() = 0;
};
 
class Base : virtual IFoo {
    void g() {}
};
 
class Derived : public Base, public virtual IFoo {
    void f() {}
};
 
int main() {
    Derived derived; // нет ошибки, Derived собирает в себе реализации обоих методов единственного абстрактного класса aka интерфейса
}

Сообщение отредактировано: Qraizer - 12.02.14, 12:20

Кстати, о птичках. В примере на D мы видим рефлексию времени компиляции по типу, а не времени исполнения по объекту, следовательно, если подпихнуть наследника под видом предка, шаблон инстанцируется для предка и сериализует не всё - fail.

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

Цитата MyNameIsIgor @ 12.02.14, 12:12

Цитата D_KEY @ 12.02.14, 11:05

Ну тебя же не смущает дефолтный конструктор копирования, например

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

Тут согласен, да. Но это же пример, можно будет дать возможность запретить сериализацию для типа или еще как-то решить данную проблему.

Цитата MyNameIsIgor @ 12.02.14, 12:12

Меня больше волнует правильность, а не удобство поведения по умолчанию, чреватого детскими грабельками.

Цитата MyNameIsIgor @ 12.02.14, 12:12

Для мьютекс эта чудо-сериализация запишет его дескриптор.

А зачем вообще может понадобиться сериализовать такое значение? Я не храню в данных, предназначенных для передачи во вне/приеме извне какие-то служебные объекты, только "plain data".

Цитата D_KEY @ 12.02.14, 12:49

Но это же пример, можно будет дать возможность запретить сериализацию для типа

Да пусть так. Я о другом говорю: чуть заходит разговор за рефлексию, как кричат "сериализация!". Я же говорю, что рефлексия при сериализации чаще всего вредна.

Цитата korvin @ 12.02.14, 12:51

Я не храню в данных, предназначенных для передачи во вне/приеме извне какие-то служебные объекты, только "plain data"

Погоди, plain data - это детали реализации. Если ты выставил их наружу так, что их видит библиотека сериализации, то я уже считаю это ошибкой проектирования.

Сообщение отредактировано: MyNameIsIgor - 12.02.14, 12:56

Цитата

- встроенные ассоциативные массивы.

Не знаю, звучала ли тут уже эта мысль. std::map и std::hash_map - вполне себе встроенные в язык C++.
Метапрограммирование говоришь? Можете закапывать - не нужно.
Рефлекшн... ну, бывает полезен.

Цитата Бобёр @ 12.02.14, 13:35

Метапрограммирование говоришь? Можете закапывать - не нужно.

Цитата Бобёр @ 12.02.14, 13:35

Не знаю, звучала ли тут уже эта мысль. std::map и std::hash_map - вполне себе встроенные в язык C++.

Взаимоисключающие параграфы

Добавлено 12.02.14, 18:32

Цитата Qraizer @ 12.02.14, 12:27

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

Вообще, кто-то просил сериализацию, получил сериализацию, но ни одного комментария на эту тему так и не сделал.

Цитата applegame @ 12.02.14, 18:31

Вообще, кто-то просил сериализацию, получил сериализацию, но ни одного комментария на эту тему так и не сделал

А вы ошибку то исправлять не собираетесь?

Цитата MyNameIsIgor @ 12.02.14, 12:55

Погоди, plain data - это детали реализации. Если ты выставил их наружу так, что их видит библиотека сериализации, то я уже считаю это ошибкой проектирования.

Ты вообще о чем? У меня просто в тех местах, где требуется маршалинг/демаршалинг, нет «объектов» с закрытыми полями, только структуры с открытыми.

Цитата korvin @ 13.02.14, 04:43

У меня просто в тех местах, где требуется маршалинг/демаршалинг, нет «объектов» с закрытыми полями, только структуры с открытыми.

прикольно. то есть если бы ты писал excel, то у тебя бы документ представлял бы собой такую вот огромную структуру с открытыми полями?