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

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

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

Зачем что-либо говорить ради что-либо сказать? Я посмотрел, даже понял, как работает, ожидания подтвердились.

Добавлено 13.02.14, 05:22

Цитата MyNameIsIgor @ 12.02.14, 19:36

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

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

Цитата jack128 @ 13.02.14, 05:15

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

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

Сообщение отредактировано: korvin - 13.02.14, 05:45

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

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

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

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

Гмм... Как это выглядит в жизни? Т.е. пример бы какой-нибудь.

Сообщение отредактировано: MyNameIsIgor - 13.02.14, 09:44

Цитата MyNameIsIgor @ 13.02.14, 09:42

Гмм... Как это выглядит в жизни?

Ну например беру из базы нужные записи(структуры) и на их основе создаю новую структуру (с другими полями) или массив структур и отправлю ее/их по HTTP клиенту. То же самое и в обратном порядке. Сам сервис никаких «объектов с состоянием» не имеет, всё состояние в записях БД. Т.е. всё больше в функциональном стиле.

Сообщение отредактировано: korvin - 13.02.14, 12:54

Цитата korvin @ 13.02.14, 12:53

Ну например беру из базы нужные записи(структуры) и на их основе создаю новую структуру (с другими полями) или массив структур и отправлю ее/их по HTTP клиенту. То же самое и в обратном порядке.

Так вместо функций сериализации каждого типа у тебя есть функции преобразования данных, полученных от модуля взаимодействия с БД, в данные, пригодные для простой сериализации. Так какая разница?

Цитата MyNameIsIgor @ 13.02.14, 17:52

Так вместо функций сериализации каждого типа у тебя есть функции преобразования данных, полученных от модуля взаимодействия с БД, в данные, пригодные для простой сериализации. Так какая разница?

Разница в том, что функции обработки мне нужны в любом случае, это не просто «преобразование данных», а некоторая бизнес-логика. В простых случаях этих функций нет и данные напрямую передаются клиенту и обратно, безо всякой обработки. Так зачем мне еще описывать функции сериализации/десериализации для каждого типа?

А обязательно для каждого? Разве нельзя описывать только исключения, для остальных предложив единый метод?

Цитата Qraizer @ 14.02.14, 05:07

А обязательно для каждого? Разве нельзя описывать только исключения, для остальных предложив единый метод?

Ну так у меня так и получается, только в этих «исключительных» случаях вместо одной большой структуры с данными для БД и данными для клиента используются две небольшие структуры — одна для БД, другая для клиента.

Вспомнил про затихший холиворчик. Продолжу продвижение D.

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

http://dpaste.dzfl.pl/d09ce6ded86b

template packTuple(ARGS...) {
    template Decls(alias value, ARGS...) {
        mixin("typeof(value)" ~ __traits(identifier, value) ~ ";");
        static if(ARGS.length) mixin Decls!ARGS;
    }
    struct Tuple {
        mixin Decls!ARGS;
    }
    auto packTuple() { return Tuple(ARGS); }
}
 
 
auto foo() {
    int fieldInt = 10;
    string fieldString = "test";
    return packTuple!(fieldInt, fieldString);
}
 
void main() {
    auto result = foo();
    assert(result.fieldInt == 10);
    assert(result.fieldString == "test");
}

Цитата applegame @ 30.03.14, 13:12

Структура объявляется внутри функции (кстати, а плюсы так умеют?)

Уметь-то умеют, но эта структура будет видна только внутри этой функции, так что выдать её в качестве результата не получится, поскольку в точке вызова она не будет существовать.

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

Цитата amk @ 30.03.14, 13:30

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

Конечно с auto. Без auto и в D невозможно. ЕМНИП в след версии плюсов, появился полноценный auto, а не инвалид который есть в C++11.

Сообщение отредактировано: applegame - 30.03.14, 13:41

А что такого инвалидного в С++ auto?

Цитата amk @ 30.03.14, 13:45

А что такого инвалидного в С++ auto?

Опять же, ЕМНИП, там запутанный и неприятный синтаксис для auto - возвращаемых типов. Просто вот так написать не получится:

template<typename A, typename B>
auto foo(A a, B b) {
  return a + b;
}

Вроде Qraizer говорил, что в C++14, уже можно будет писать и так.

Добавлено 30.03.14, 13:53
Кстати еще вот некоторым не нравится, что в D для объявления шаблонов используются круглые скобки. А мне вот, наоборот, нравится, благодаря этому, инстанцирование шаблона выглядит похожим на вызов функции.

Сообщение отредактировано: applegame - 30.03.14, 13:53

Да, выглядит как недоделка. Если над объекты типов A и B можно сложить, то тип результата а этой точке известен, значит ничего не должно мешать и определению типа возвращаемого значения.

Цитата amk @ 30.03.14, 13:56

Да, выглядит как недоделка. Если над объекты типов A и B можно сложить, то тип результата а этой точке известен, значит ничего не должно мешать и определению типа возвращаемого значения.

Это возможно, но вот таким странным образом:

template<typename A, typename B>
auto hellSum(A a, B b) -> decltype(a + b) {
  return a + b;
}

Зачем там нужен этот дурацкий decltype непонятно.