Здравствуйте, DiPaolo, Вы писали:

DP>Шымж, вот я например пишу видео-енкодер: тот кусок, где голая математика, числодробилка. Надо макси-переносимо на более чем 3 платформы. Плюс свести все с SIMD-ами. Мне вот твои хипстотошно-модные паттерн в пень не уперлись. Мне процедурно нужно все запрограммить. Нафейхоа, еще раз спрашиваю, мне там ООП и прочее???

Я бы предпочёл наличие стандартной очереди. Близкая задача, имплементация на С (не моя, конечно). Делают очередь вручную:

static int packet_queue_put(PacketQueue *q, AVPacket *pkt)
{
    AVPacket *pkt1;
    int ret;

    pkt1 = av_packet_alloc();
    if (!pkt1) {
        av_packet_unref(pkt);
        return -1;
    }
    av_packet_move_ref(pkt1, pkt);

    SDL_LockMutex(q->mutex);
    ret = packet_queue_put_private(q, pkt1);
    SDL_UnlockMutex(q->mutex);

    if (ret < 0)
        av_packet_free(&pkt1);

    return ret;
}

Тут же в файле делают вторую чередь вручную:

static Frame *frame_queue_peek(FrameQueue *f)
{
    return &f->queue[(f->rindex + f->rindex_shown) % f->max_size];
}

static Frame *frame_queue_peek_next(FrameQueue *f)
{
    return &f->queue[(f->rindex + f->rindex_shown + 1) % f->max_size];
}

static Frame *frame_queue_peek_last(FrameQueue *f)
{
    return &f->queue[f->rindex];
}

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

Здравствуйте, Shmj, Вы писали:

S>И ни тебе классов ни тебе виртуальных методов ни тебе шаблонов.

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

В первую очередь, Линус говорит, что использование C++ неизменно приводит программиста к плохим решениям вроде использования библиотек STL или Boost, которые считаются прекрасными.

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

Также Торвальдс заявил, что код на C++ построен на абстракциях, которые не работают как следует. Программист может легко обнаружить, что использованная им абстракция неэффективна, и захочет заменить ее, но для этого ему потребуется переписать все приложение.

Если же программист захочет написать хорошее, эффективное и портируемое приложение на C++, он будет ограничен рамками, которые уже хорошо реализованы на языке Си.

Кроме того, использование Си страхует программистов от ошибок, и они не смогут «облажаться» на проекте, а сам язык учит кодеров разбираться в низкоуровневых проблемах. По версии Торвальдса, сплошные плюсы.

Линус признался, что в 1992 году они уже пытались использовать C++ для написания Linux. С тех пор, по его мнению, мало что изменилось.

Нельзя не согласиться. Для такого монстра как Linux уже написаны базовые вещи типа списка и переписывание в С++ парадигме ломает совместимость и кучу кода.

Также бесспорно, что для нового проекта использовать С не имеет смысла. Хотя я бы попробовал: интересно. Язык с челенжем. Как раз после универа была возможность, но я её упустил, потому как мозг был засран ООП.

Здравствуйте, Shmj, Вы писали:

S>ни тебе классов
зачем?

S>ни тебе виртуальных методов
зачем?

S>ни тебе шаблонов
зачем?

S>списков (динамических массивов)
зачем?

S>словарей
зачем?

S>А ведь без этого практически ни один проект не обходится.
какой проект? не стоит писать на Си перекладывание из базы в ДЖСОН и обратно, вот не стоит. просто поиграться для себя, поизвращаться, устроить себе боль, страдания и мучения, БДСМ и вот это вот все... да пожалста! писать такое в проде – нафейхоа бы оно надо было?!?!?

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

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

DP>>не ООП единым и иже с ними депенденсями ижекшнами и прочими паттернами живет мир разработки... ну так, к сведению
П>К сведению, ООП так или иначе везде применяется, просто если в языке нет его нативной поддержки, то изобретают свой ООП через костыли, боль и страдание
Хуже того они даже исключения сделали в glibc в коде динамического линковщика (который грузит .so), сделано оно так:
код который вызывает функцию которая может вызвать исключение, вызывает _dl_catch_exception, передавая ту функцию в качесте колбэка, выглядит это так:

      THREAD_GSCOPE_SET_FLAG ();
      struct dl_exception exception;
      int err = _dl_catch_exception (&exception, call_dl_lookup, &args);
      THREAD_GSCOPE_RESET_FLAG ();
      if (__glibc_unlikely (exception.errstring != NULL))
        _dl_signal_exception (err, &exception, NULL);

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

struct call_dl_lookup_args
{
  /* Arguments to do_dlsym.  */
  struct link_map *map;
  const char *name;
  struct r_found_version *vers;
  int flags;

  /* Return values of do_dlsym.  */
  lookup_t loadbase;
  const ElfW(Sym) **refp;
};

static void
call_dl_lookup (void *ptr)
{
  struct call_dl_lookup_args *args = (struct call_dl_lookup_args *) ptr;
  args->map = GLRO(dl_lookup_symbol_x) (args->name, args->map, args->refp,
                    args->map->l_scope, args->vers, 0,
                    args->flags, NULL);
}

А вот как выглядит "бросание" исключений внутри dl_lookup_symbol_x:

      if ((*ref == NULL || ELFW(ST_BIND) ((*ref)->st_info) != STB_WEAK)
      && !(GLRO(dl_debug_mask) & DL_DEBUG_UNUSED))
    {
      /* We could find no value for a strong reference.  */
      const char *reference_name = undef_map ? undef_map->l_name : "";
      const char *versionstr = version ? ", version " : "";
      const char *versionname = (version && version->name
                     ? version->name : "");
      struct dl_exception exception;
      /* XXX We cannot translate the message.  */
      _dl_exception_create_format
        (&exception, DSO_FILENAME (reference_name),
         "undefined symbol: %s%s%s",
         undef_name, versionstr, versionname);
      _dl_signal_cexception (0, &exception, N_("symbol lookup error"));
      _dl_exception_free (&exception);
    }

Что вы там рассказывали про секс в гамаке? Да тут настоящее шибари.

Здравствуйте, so5team, Вы писали:

S>Я был наслышан (а что-то и пробовал начиная с 1992-го) про компиляторы от Borland, Zortech/Symantec, Watcom, Microsoft, IBM. Что-то работало под MS-DOS, что-то под MS-DOS и Windows, что-то под MS-DOS и OS/2, что-то только под OS/2 (тот же IBM я пробовал только под OS/2). Где-то во второй половине 1990-х довелось и с GCC под Linux встретится.

Я тоже о них был наслышан и пробовал, но после 95 года, по поводу состояния плюсов в 1992 году, тем не менее, знаю очень мало.


S>Но вот про Cfront для MS-DOS/Windows/OS-2/Linux никогда не слышал.

В середине 90ых он был уже неактуалелен, Бьярн забил на него. Тем не менее:

Comeau Computing's CEO, Greg Comeau, provided one of the early ports of cfront to the PC.

Ну и потом был Comeau C/C++, например. К сожалению, не скажу, когда точно это было, в вики мало инфы, а искать глубоко как-то недосуг. Но, думаю, для писишки таки были варианты и для 32ух бит.


S>Насколько я помню, первый C++ный компилятор, в котором появилась поддержка шаблонов, был не Cfront, а компилятор толи от HP, толи от Sun.

Ну, как такое могло бы быть? Реализация плюсиков в CFront'е была на тот момент единственным стандартом, если Бьярн выкладывал беты, то другие компиляторы максимум могли идти с ним в ногу.
Ещё были такие Edison Design Group, они делали фронтэнды, которые использовали много кто. Так что, думаю, что-то под писишку таки было.

Вот тут история CFront'а (чутка покоцал):

1985 October
Cfront Release 1.0 (first commercial release)
The C++ Programming Language
1986
First commercial Cfront PC port (Cfront 1.1, Glockenspiel)
1987 December
First GNU C++ release (1.13)
1988
First Oregon Software C++ release [announcement]; first Zortech C++ release
1989 June
Cfront Release 2.0
1991
First ISO WG21 meeting (Lund, Sweden); Cfront Release 3.0 (including templates); The C++ Programming Language (2nd edition)
1992
First IBM, DEC, and Microsoft C++ releases

А тут можно поковырять старые гнутые плюсики


S>Для больших машин, не для персоналок. На нем-то вроде бы Степанов своим STL и занимался.

Сам Степанов говорит следующее:

В 1988 г. я перешел в HP Labs, где я был нанят для работы над обобщёнными библиотеками. В течение нескольких лет, я работал вместо этого над жесткими дисками, и это было захватывающе, но совершенно ортогонально к этой области исследований. Я вернулся к разработке обобщенной библиотеки в 1992, когда Билл Ворли, бывший заведующим моей лаборатории, запустил проект по алгоритмам со мной в качестве руководителя. C++ к тому моменту имел шаблоны. Я обнаружил, что Бьярн проделал превосходную работу по проектированию шаблонов. Очень давно я принял участие в нескольких дискуссиях в Лабораториях Белла о проектировании шаблонов, и спорил с Бьярном достаточно жёстко о том, что он должен сделать шаблоны C++ настолько близкими к дженерикам Ada, насколько это возможно. Я думаю, что спорил так жёстко, что он принял противоположное решение. Я осознал важность наличия шаблонных функций в C++, а не только шаблонных классов, как многие считают. Я думал, однако, что шаблонные функции должны работать как дженерики Ada, т.е. что они должны были быть явно инстанцируемы. Бьярн не послушал меня и спроектировал механизм шаблонных функций, в котором шаблоны инстанцируются явно, используя механизм перегрузки. Эта специфическая техника стала решающей для моей работы, т.к. я обнаружил, что она позволила мне делать многое из того, что было невозможно в Ada. Я вижу этот особый дизайн, разработанный Бьярном, как превосходный результат, и я счастлив, что он не последовал тогда моему совету.

https://habr.com/ru/articles/166849/
И продолжение


S>А первый компилятор для персоналок с поддержкой шаблона появился у Borland-а в 1994-ом.

У Borland-а в 91ом:

Turbo C++ 3.0 was released on November 20, 1991, amidst expectations of the coming release of Turbo C++ for Microsoft Windows. Initially released as an MS-DOS compiler, 3.0 supported C++ templates, Borland's inline assembler and generation of MS-DOS mode executables for both 8086 real mode and 286 protected mode (as well as 80186). 3.0 implemented AT&T C++ 2.1, the most recent at the time.

https://en.wikipedia.org/wiki/Turbo_C%2B%2B

Но уверен, что были и другие реализации


S>Но все это по памяти, так что надежным источником быть не могу. Однако про то, чтобы кто-то использовал Cfront на персоналках не помню в упор.

В середине 90ых Cfront был уже не актуален. Да, думаю, уже и в начале тоже, потому как были уже другие компиляторы получше


S>Линус мог разве что GCC использовать,

g++-1.42.0.tar.bz2 1992-07-13 22:13 637K
Можно собрать и потыкать, если не лень. Я что-то не нашел нигде текстом, какие фичи в нем реализованы, но не думаю, что сильно отставало от того же Turbo C++


S>но сомневаюсь, что C++ там был хоть сколько-то похож на C++98.

В BC 3.1 шаблоны были вполне похожи, и даже в Turbo C++ 3.0 (начал припоминать, что я на нём писал первое время) были вполне себе, и Степанов STL начинал писать именно на них. Да, потом STL сильно изменилась, но шаблоны уже тогда были вполне круты.

Там в ранних шаблонах были какие-то баги/непродуманности/недоделки (это наверное надо смотреть в дизайне и эволюции), но в целом обобщённо программировать уже вполне можно было

Здравствуйте, Shmj, Вы писали:

S>Но вот глянуть на стандартную библиотеку — там же нет даже списков (динамических массивов) и словарей. Или я не увидел? А ведь без этого практически ни один проект не обходится.

S>И вопрос — будете ли вы это писать с нуля каждый раз?

Так и происходит — каждый раз с нуля.

Была интересная хохма с GC дотнета. Выложили в интернет его код, ровно один файл 1мб+ весом, и там полный фарш — базовые сишные структуры данных, с нуля, алгоритмы типа сортировок итд На этом фоне сам GC где то потерялся

В продолжение темы

Автор: vsb
Дата: 12.09 09:43

.

Вот, vsb говорит что C простой язык — 45 слов всего нужно выучить. И ни тебе классов ни тебе виртуальных методов ни тебе шаблонов.

Но вот глянуть на стандартную библиотеку — там же нет даже списков (динамических массивов) и словарей. Или я не увидел? А ведь без этого практически ни один проект не обходится.

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

DP>>Шымж, вот я например пишу видео-енкодер: тот кусок, где голая математика, числодробилка. Надо макси-переносимо на более чем 3 платформы. Плюс свести все с SIMD-ами. Мне вот твои хипстотошно-модные паттерн в пень не уперлись. Мне процедурно нужно все запрограммить. Нафейхоа, еще раз спрашиваю, мне там ООП и прочее???

S>Я думал у нас тут таких нету, обычно подобные вещи пишут в высшей цивилизации а простым смертным достается работа попроще.

Это было для примера. Я сам енкодер не пишу. Но я из этой темы и много что приходилось делать.

И нет, я не считаю, что это какая-то "высшая каста". Я говорил лишь о том, что где-то выгоднее и все еще используют Си и там не нужны ООП и прочие современные мейнстримовые модные посылы.

Здравствуйте, DiPaolo, Вы писали:

DP>Шымж, вот я например пишу видео-енкодер: тот кусок, где голая математика, числодробилка. Надо макси-переносимо на более чем 3 платформы. Плюс свести все с SIMD-ами.

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

Дали же вам, инженеграм, Аду, ещё в 83 году — так ведь нет — на сишечке корябать продолжаете.

Здравствуйте, sergii.p, Вы писали:

SP>ну плюс же! Никаких проблем с виртуальным деструктором, нет проблем с шаблонами.

SP>

SP>В первую очередь, Линус говорит, что использование C++ неизменно приводит программиста к плохим решениям вроде использования библиотек STL или Boost, которые считаются прекрасными.

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

Так что мимо.


SP>

SP>Однако на деле, по мнению Линуса, они постоянно ломаются, отладка кода становится испытанием, а сам код нестабильный и не портируемый.

У меня ничего не ломается, отладка тривиальна, код стабильный, и работает на любых системах, будь то линукс, винда, или микроконтроллер. Видимо, я что-то делаю не так.


SP>

SP>Также Торвальдс заявил, что код на C++ построен на абстракциях, которые не работают как следует. Программист может легко обнаружить, что использованная им абстракция неэффективна, и захочет заменить ее, но для этого ему потребуется переписать все приложение.

Чушь. Во-первых, всё работает как следует. Во-вторых, если неправильно выбрать тип контейнера под задачу, то переписывать придётся и на плюсах, и на сишечке, только на сишечке это превратиться в боль и унижение.


SP>

SP>Если же программист захочет написать хорошее, эффективное и портируемое приложение на C++, он будет ограничен рамками, которые уже хорошо реализованы на языке Си.

Полная чушь.


SP>

SP>Кроме того, использование Си страхует программистов от ошибок, и они не смогут «облажаться» на проекте, а сам язык учит кодеров разбираться в низкоуровневых проблемах. По версии Торвальдса, сплошные плюсы.

Си страхует от ошибок? Лол-што?


SP>

SP>Линус признался, что в 1992 году они уже пытались использовать C++ для написания Linux. С тех пор, по его мнению, мало что изменилось.

Ну так бы и сказал, что не осилил. Ну, или в 92ом году они использовали глючный и сырой компилятор с кривой реализацией STL, такое вполне могло быть в те времена. Ему бы дурню понять, что с тех пор мир изменился.


SP>Нельзя не согласиться.

Нельзя согласится. Главпингвин просто не осилил плюсики даже в минимальном объёме студента-первокура.


SP>Для такого монстра как Linux уже написаны базовые вещи типа списка и переписывание в С++ парадигме ломает совместимость и кучу кода.

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


SP>Также бесспорно, что для нового проекта использовать С не имеет смысла. Хотя я бы попробовал: интересно. Язык с челенжем. Как раз после универа была возможность, но я её упустил, потому как мозг был засран ООП.

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

Здравствуйте, пффф, Вы писали:

П>Ну, или в 92ом году они использовали глючный и сырой компилятор с кривой реализацией STL, такое вполне могло быть в те времена.

В 92-ом STL был только в маленькой лаборатории Алекса Степанова и это был не совсем тот STL, который мы затем увидели в C++98.
Так что вряд ли Линус в 92-ом вообще слышал про STL от Степанова. Не говоря уже про то, чтобы попробовать. Тогда, емнип, на x86 вообще не было C++ных компиляторов с поддержкой шаблонов, первый такой от Borland-а, появился году в 1994-ом.

Здравствуйте, DiPaolo, Вы писали:

DP>зачем?
DP>зачем?
DP>зачем?
DP>зачем?
DP>зачем?

Слишком много банального нужно объяснять, и так все знают зачем — вводите в гугле и получаете.

S>>А ведь без этого практически ни один проект не обходится.
DP>какой проект? не стоит писать на Си перекладывание из базы в ДЖСОН и обратно, вот не стоит. просто поиграться для себя, поизвращаться, устроить себе боль, страдания и мучения, БДСМ и вот это вот все... да пожалста! писать такое в проде – нафейхоа бы оно надо было?!?!?

Так и юзер-интефейс пишут, а юзер-интерфейс это всегда дерево объектов, фактически. Пишут все.

Здравствуйте, DiPaolo, Вы писали:

S>>А ведь без этого практически ни один проект не обходится.
DP>какой проект? не стоит писать на Си перекладывание из базы в ДЖСОН и обратно, вот не стоит. просто поиграться для себя, поизвращаться, устроить себе боль, страдания и мучения, БДСМ и вот это вот все... да пожалста! писать такое в проде – нафейхоа бы оно надо было?!?!?

Ну вот есть redis , например. Не то, чтобы мне было понятно почему они избрали именно C, но есть и такое. Там и списки и словари, и, по-моему, джсоны тоже.

S>Слишком много банального нужно объяснять, и так все знают зачем — вводите в гугле и получаете.

Шымж, вот я например пишу видео-енкодер: тот кусок, где голая математика, числодробилка. Надо макси-переносимо на более чем 3 платформы. Плюс свести все с SIMD-ами. Мне вот твои хипстотошно-модные паттерн в пень не уперлись. Мне процедурно нужно все запрограммить. Нафейхоа, еще раз спрашиваю, мне там ООП и прочее???

Ты попробуй пошире помыслить, еще раз те повторяю! не все пишут перекладывания из ДЖСОНа в базку и обратно!

S>>>А ведь без этого практически ни один проект не обходится.
DP>>какой проект? не стоит писать на Си перекладывание из базы в ДЖСОН и обратно, вот не стоит. просто поиграться для себя, поизвращаться, устроить себе боль, страдания и мучения, БДСМ и вот это вот все... да пожалста! писать такое в проде – нафейхоа бы оно надо было?!?!?

S>Так и юзер-интефейс пишут, а юзер-интерфейс это всегда дерево объектов, фактически. Пишут все.
Я тебе про Фому, ты мне про Ерему. Еще раз: сходи и попробуй поперекладывать из БД в ДЖСОН и обратно, где объекты по 30-50 филдов содержат и надо в 3-5-7 табличек сходить. Контроллеры то бишь пописать. Десктоп тут не при чем. Там иначе.

D>Ну вот есть redis , например. Не то, чтобы мне было понятно почему они избрали именно C, но есть и такое. Там и списки и словари, и, по-моему, джсоны тоже.

Все верно! Редиска должна быть мега-быстрой. И там нет никакой бизнес-логики в ДЖСОНах.

Ну и кстати сейчас глянул: так модуль для работы с ДЖСОНом на касте вообще написан – https://github.com/redisjson/redisjson

Я говорил о том, что у тебя есть сущности системы, которые лежат в базе. Тебе нужно сделать АПИшку, к ней доку сгенерить, и это все отделается наружу на фронт и мобилки, допустим. Нужно написать тонны бойлерплейта на Си, чтобы это все взлетело!

На всех же современных языках, для этого предназначенных, уже все есть! Описал структуру – и она сама умеет через ОРМку или фреймворк ходить в базу и перекладывать с языка базы (любой! почти) в язык моделей. Другая функция – и у тебя есть маршаллинг/демаршаллинг/сериализация/как угодно в ДЖСОН/XML/ini/csv/что угодно еще...

На Си это писать мучение! На плюсах полегче, но и там – трата времени, высокая вероятность ошибки. В общем, дорого.

Вот для примера АПИшка к одной-единственной сущности User. 105 строк с учетом кода сервера. Сколько сотен и тысяч строк кода надо будет на Си и сколько писать+отлаживать?

	https://gist.github.com/mashingan/4212d447f857cfdfbbba4f5436b779ac
	package main import ( "fmt" "net/http" "strconv" "github.com/jinzhu/gorm" _ "github.com/jinzhu/gorm/dialects/sqlite" "github.com/labstack/echo" ) type User struct { gorm.Model `json:"model"` Name string `json:"name"` Email string `json:"email"` } func handlerFunc(msg string) func(echo.Context) error { return func(c echo.Context) error { return c.String(http.StatusOK, msg) } } func allUsers(db *gorm.DB) func(echo.Context) error { return func(c echo.Context) error { var users []User db.Find(&users) fmt.Println("{}", users) return c.JSON(http.StatusOK, users) } } func newUser(db *gorm.DB) func(echo.Context) error { return func(c echo.Context) error { name := c.Param("name") email := c.Param("email") db.Create(&User{Name: name, Email: email}) return c.String(http.StatusOK, name+" user successfully created") } } func deleteUser(db *gorm.DB) func(echo.Context) error { return func(c echo.Context) error { name := c.Param("name") var user User db.Where("name = ?", name).Find(&user) db.Delete(&user) return c.String(http.StatusOK, name+" user successfully deleted") } } func updateUser(db *gorm.DB) func(echo.Context) error { return func(c echo.Context) error { name := c.Param("name") email := c.Param("email") var user User db.Where("name=?", name).Find(&user) user.Email = email db.Save(&user) return c.String(http.StatusOK, name+" user successfully updated") } } func usersByPage(db *gorm.DB) func(echo.Context) error { return func(c echo.Context) error { limit, _ := strconv.Atoi(c.QueryParam("limit")) page, _ := strconv.Atoi(c.QueryParam("page")) var result []User db.Limit(limit).Offset(limit * (page - 1)).Find(&result) return c.JSON(http.StatusOK, result) } } func handleRequest(db *gorm.DB) { e := echo.New() e.GET("/users", allUsers(db)) e.GET("/user", usersByPage(db)) e.POST("/user/:name/:email", newUser(db)) e.DELETE("/user/:name", deleteUser(db)) e.PUT("/user/:name/:email", updateUser(db)) e.Logger.Fatal(e.Start(":3000")) } func initialMigration(db *gorm.DB) { db.AutoMigrate(&User{}) } func main() { fmt.Println("Go ORM tutorial") db, err := gorm.Open("sqlite3", "sqlite3gorm.db") if err != nil { fmt.Println(err.Error()) panic("failed to connect database") } defer db.Close() initialMigration(db) handleRequest(db) }

Здравствуйте, DiPaolo, Вы писали:

DP>Шымж, вот я например пишу видео-енкодер: тот кусок, где голая математика, числодробилка. Надо макси-переносимо на более чем 3 платформы. Плюс свести все с SIMD-ами. Мне вот твои хипстотошно-модные паттерн в пень не уперлись. Мне процедурно нужно все запрограммить. Нафейхоа, еще раз спрашиваю, мне там ООП и прочее???

Я думал у нас тут таких нету, обычно подобные вещи пишут в высшей цивилизации а простым смертным достается работа попроще.

Здравствуйте, DiPaolo, Вы писали:

S>>ни тебе классов
DP>зачем?

Инкапсуляция


S>>ни тебе виртуальных методов
DP>зачем?

Полиморфизм. Иногда нужно (в каждом втором проекте на сишечке изобретают виртуальные методы)


S>>ни тебе шаблонов
DP>зачем?

Чтобы не писать десять раз одно и тоже, и не городить шаблоны на макросах


S>>списков (динамических массивов)
DP>зачем?

Всё равно придётся писать, а когда есть готовое и отлаженное — это удобно


S>>словарей
DP>зачем?

Всё равно придётся писать, а когда есть готовое и отлаженное — это удобно


S>>А ведь без этого практически ни один проект не обходится.
DP>какой проект? не стоит писать на Си перекладывание из базы в ДЖСОН и обратно, вот не стоит. просто поиграться для себя, поизвращаться, устроить себе боль, страдания и мучения, БДСМ и вот это вот все... да пожалста! писать такое в проде – нафейхоа бы оно надо было?!?!?

ООП нужен только для перекладывания из базы в ДЖСОН и обратно?


DP>короче, отвечай для себя на вопросы выше и думай...

И ты думай


DP>не ООП единым и иже с ними депенденсями ижекшнами и прочими паттернами живет мир разработки... ну так, к сведению

К сведению, ООП так или иначе везде применяется, просто если в языке нет его нативной поддержки, то изобретают свой ООП через костыли, боль и страдание

Здравствуйте, DiPaolo, Вы писали:

DP>Шымж, вот я например пишу видео-енкодер: тот кусок, где голая математика, числодробилка. Надо макси-переносимо на более чем 3 платформы. Плюс свести все с SIMD-ами. Мне вот твои хипстотошно-модные паттерн в пень не уперлись. Мне процедурно нужно все запрограммить. Нафейхоа, еще раз спрашиваю, мне там ООП и прочее???

Тут шаблоны явно напрашиваются.


DP>Ты попробуй пошире помыслить, еще раз те повторяю! не все пишут перекладывания из ДЖСОНа в базку и обратно!

Это ты попробуй пошире мыслить, и понять, что бывают не только числодробилки с голой математикой и перекладывание из ДЖСОНа в базку и обратно

Здравствуйте, Слава, Вы писали:

С>Дали же вам, инженеграм, Аду, ещё в 83 году

И 640Kb на все про все. Так ведь нет же, все вам, инженеграм, мало.

Здравствуйте, DiPaolo, Вы писали:

DP>Вот для примера АПИшка к одной-единственной сущности User. 105 строк с учетом кода сервера. Сколько сотен и тысяч строк кода надо будет на Си и сколько писать+отлаживать?

DP> https://gist.github.com/mashingan/4212d447f857cfdfbbba4f5436b779ac

Не справедливости ради, а холивара для, солько сотен и тысяч строк кода в следующих пакетах?:

"github.com/jinzhu/gorm"
"github.com/jinzhu/gorm/dialects/sqlite"

Плюс в пакетах, которые туда импортируются.

Значит вопрос лишь в наличии/отсутствии библиотек.

Здравствуйте, so5team, Вы писали:

С>>Дали же вам, инженеграм, Аду, ещё в 83 году

S>И 640Kb на все про все. Так ведь нет же, все вам, инженеграм, мало.

Вы вроде должны быть в курсе технических подробностей Ады и её версий. Ну и причём тут 640килобайт? На Аде просто ковбойствовать не столь круто, как на Си segfault ловить. Как, знаете, в российском БДСМ-сообществе от бедности любят вместо покупки чего-то нормального изобретать свою кривую ерунду, из деревянных табуреток и бельевых прищепок. Зато творчество. Программисты любят творчество. И покупать ничего не надо, свобода же, если у вас есть тьюринг-полное говно, то значит можно на нём писать, а кто этим брезгует — тот, стало быть, плохой программист. Именно поэтому мы наблюдаем такой прогресс в разработке софта, от Вин95 на 16мб оперативки, до современного сайтостроительства.

Здравствуйте, Слава, Вы писали:

С>>>Дали же вам, инженеграм, Аду, ещё в 83 году

S>>И 640Kb на все про все. Так ведь нет же, все вам, инженеграм, мало.

С>Вы вроде должны быть в курсе технических подробностей Ады и её версий. Ну и причём тут 640килобайт?

При том, что как 640Kb не хватило, так и возможностей Ada для широкого круга проектов не хватало еще в 1980-х.
Тот же ООП туда, емнип, только в Ada 95 запихнули. А в 1995-ом C++ за счет нужного тогда ООП был уже настоящим мейнстримом и даже Java уже была на подходе.

D>Не справедливости ради, а холивара для, солько сотен и тысяч строк кода в следующих пакетах?:
D>

D>"github.com/jinzhu/gorm"
D>"github.com/jinzhu/gorm/dialects/sqlite"
D>

D>Плюс в пакетах, которые туда импортируются.

D>Значит вопрос лишь в наличии/отсутствии библиотек.

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

Здравствуйте, DiPaolo, Вы писали:

S>>ни тебе классов
DP>зачем?

S>>ни тебе виртуальных методов
DP>зачем?

S>>ни тебе шаблонов
DP>зачем?

S>>списков (динамических массивов)
DP>зачем?

S>>словарей
DP>зачем?

Это все инструменты для управления сложностью. В Си у вас ничего подобного нет, а потому каждый старается во что горазд. Если приходится писать что нибудь прикладное, код быстро превращается в непойми что.
Т.е. для управления сложность в Си есть функции, массивы, указатели. И всё. В принципе, почти всё то же, что и в ассемблере, только кроссплатформенность получше.

Здравствуйте, so5team, Вы писали:

П>>Ну, или в 92ом году они использовали глючный и сырой компилятор с кривой реализацией STL, такое вполне могло быть в те времена.

S>В 92-ом STL был только в маленькой лаборатории Алекса Степанова и это был не совсем тот STL, который мы затем увидели в C++98.

Да, согласен, STL тогда не было, значит, высказывание Линуса относится к более позднему C++, и видимо, он не глядя переносит свои ощущения из 92го года на современные плюсы.


S>Так что вряд ли Линус в 92-ом вообще слышал про STL от Степанова. Не говоря уже про то, чтобы попробовать. Тогда, емнип, на x86 вообще не было C++ных компиляторов с поддержкой шаблонов, первый такой от Borland-а, появился году в 1994-ом.

CFront был как раз под PC, и шаблоны в нём появились в 91ом, как раз тогда, когда Линус только начал Линупс.

Templates were introduced in Release 3.0 of the language, in October 1991.

https://belaycpp.com/2021/10/01/history-of-c-templates-from-c-style-macros-to-concepts/

Там по ссылке приведён пример, как извращались без макросов. Что характерно, линупсоиды и сейчас страдают этой хренью.

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

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

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

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

Turbo Vision был выпущен в 90м году, хотя хз, может тот вариант был на паскале.
Но в 92ом под C++ уже точно был:

3.1 (1992): Introduction of Windows-based IDE and application frameworks (OWL 1.0, Turbovision 1.0)

https://en.wikipedia.org/wiki/Borland_C%2B%2B

Да, я вроде на BC++ 3.0 начинал, и он уже вроде с шаблонами был, это 91ый год (Страуструп наверняка же выкатывал беты CFront'а, и шаблоны были интересной фичей, думаю, борманцы задолго до офф релиза начали их делать).

SP>Линус признался, что в 1992 году они уже пытались использовать C++ для написания Linux. С тех пор, по его мнению, мало что изменилось.
блин, даже интересно стало, что у них могло пойти не так с С++ в 92м году?

Здравствуйте, пффф, Вы писали:

П>CFront был как раз под PC, и шаблоны в нём появились в 91ом, как раз тогда, когда Линус только начал Линупс.
П>

П>Templates were introduced in Release 3.0 of the language, in October 1991.

Никогда не слышал о полноценном CFront под x86. Да еще и вопрос где в 1992-ом году на x86 можно было 32 бита использовать.

П>Turbo Vision был выпущен в 90м году, хотя хз, может тот вариант был на паскале.
П>Но в 92ом под C++ уже точно был:
П>

П>3.1 (1992): Introduction of Windows-based IDE and application frameworks (OWL 1.0, Turbovision 1.0)

П>https://en.wikipedia.org/wiki/Borland_C%2B%2B

В TurboVision не использовались шаблоны в 1992-ом и OWL была классической ООП-шной библиотекой без шаблонов.

Здравствуйте, so5team, Вы писали:

S>Никогда не слышал о полноценном CFront под x86.

Ну хз, хотя тут пишут:

Бьёрн предупредил нас, что с проверкой может оказаться не всё так просто:

Please remember this is *very* old software designed to run on a 1MB 1MHz machine and also used on original PCs (640KB). It was also done by one person (me) as only part of my full time job.

S>Да еще и вопрос где в 1992-ом году на x86 можно было 32 бита использовать.

Это вопрос, да. Но GCC с 87го года в C++ умел

1.42.0 (g++) September 20, 1992
1.41.0 (g++) July 13, 1992
1.40.3 (g++) October 19, 1991
1.39.1 (g++) May 4, 1991
1.37.1 (g++) March 1, 1990
1.37.0 (g++) February 28, 1990
1.36.4 (g++) January 30, 1990
1.36.3 (g++) January 16, 1990
1.15.3 (g++) December 18, 1987

https://gcc.gnu.org/releases.html

Я так понимаю, пометки g++ это обновления плюсового компилятора

К 92му 9 версий выпущено было, наверное, не такой уж и сырой был. Но тут хз.


П>>Turbo Vision был выпущен в 90м году, хотя хз, может тот вариант был на паскале.
П>>Но в 92ом под C++ уже точно был:
П>>

П>>3.1 (1992): Introduction of Windows-based IDE and application frameworks (OWL 1.0, Turbovision 1.0)

П>>https://en.wikipedia.org/wiki/Borland_C%2B%2B

S>В TurboVision не использовались шаблоны в 1992-ом и OWL была классической ООП-шной библиотекой без шаблонов.

Да это не про шаблоны и было, а про то, что на плюсах можно было писать нормально в то время. А если представить TV на сишечке в любимом стиле Линуса? Это ж ад и израиль был бы (как ядро линупса)

Здравствуйте, пффф, Вы писали:

П>Ну хз, хотя тут пишут:

Я был наслышан (а что-то и пробовал начиная с 1992-го) про компиляторы от Borland, Zortech/Symantec, Watcom, Microsoft, IBM. Что-то работало под MS-DOS, что-то под MS-DOS и Windows, что-то под MS-DOS и OS/2, что-то только под OS/2 (тот же IBM я пробовал только под OS/2). Где-то во второй половине 1990-х довелось и с GCC под Linux встретится.

Но вот про Cfront для MS-DOS/Windows/OS-2/Linux никогда не слышал.

П>Я так понимаю, пометки g++ это обновления плюсового компилятора

Насколько я помню, первый C++ный компилятор, в котором появилась поддержка шаблонов, был не Cfront, а компилятор толи от HP, толи от Sun. Для больших машин, не для персоналок. На нем-то вроде бы Степанов своим STL и занимался.

А первый компилятор для персоналок с поддержкой шаблона появился у Borland-а в 1994-ом.

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

Линус мог разве что GCC использовать, но сомневаюсь, что C++ там был хоть сколько-то похож на C++98.

Здравствуйте, Shmj, Вы писали:

S>Но вот глянуть на стандартную библиотеку — там же нет даже списков (динамических массивов) и словарей. Или я не увидел? А ведь без этого практически ни один проект не обходится.
Да с этим то проблем нет. Один раз написал и пользуйся. Более того, все давно уже написано — гугли и что найдешь.
Интересней другое. Как блин немногословно обрабатывать ошибки без исключений. Хреначить через коды возврата, а результат передавать по ссылке, или наоборот в каждую функцию писать ссылку на ошибку? И как то исхитриться макросами чтоб не было многословно? Или через глобальные переменные ошибки, и макросом проверять, каждую строку которая может требовать ошибку оборачивать в макрос? Делать как в
https://club.shelek.ru/viewart.php?id=343?
С шаблонами тоже через макросы работать? Или тупо копипастить алгоритм с учетом всех возможных типов?

Здравствуйте, пффф, Вы писали:

S>>А первый компилятор для персоналок с поддержкой шаблона появился у Borland-а в 1994-ом.

П>У Borland-а в 91ом:
П>

П>Turbo C++ 3.0 was released on November 20, 1991, amidst expectations of the coming release of Turbo C++ for Microsoft Windows. Initially released as an MS-DOS compiler, 3.0 supported C++ templates, Borland's inline assembler and generation of MS-DOS mode executables for both 8086 real mode and 286 protected mode (as well as 80186). 3.0 implemented AT&T C++ 2.1, the most recent at the time.

П>https://en.wikipedia.org/wiki/Turbo_C%2B%2B

Спасибо, заставили меня поднять информацию.

У меня была другая траектория -- начинал с Turbo C++ 1.0, затем почти сразу перешел на Borland C++ 2.0 (не Turbo C++). И там я шаблонов не помню от слова совсем. А потом пересел с Borland C++ 2.0 на Borland C++ 4.0 и вот там уже с шаблонами познакомился. Но, оказывается, шаблоны появились в Borland C++ 3.0 в 1992-ом году (здесь вот есть Programmer's Guide для BC++ 3.0, там уже реально шаблоны описаны).

Так что был не прав, каюсь.

Здравствуйте, so5team, Вы писали:

S>Спасибо, заставили меня поднять информацию.

S>У меня была другая траектория -- начинал с Turbo C++ 1.0, затем почти сразу перешел на Borland C++ 2.0 (не Turbo C++). И там я шаблонов не помню от слова совсем. А потом пересел с Borland C++ 2.0 на Borland C++ 4.0 и вот там уже с шаблонами познакомился. Но, оказывается, шаблоны появились в Borland C++ 3.0 в 1992-ом году (здесь вот есть Programmer's Guide для BC++ 3.0, там уже реально шаблоны описаны).

S>Так что был не прав, каюсь.

Borland С++ 2.0 вообще хз что за зверь, Turbo C++ 2.0 вообще не было, а по идее, это просто с разными бандлами по разной цене для разной аудитории, а под капотом одно и то же.


Скачал BC2 и BC3 отсюда — http://old-dos.ru/files/file_938.html
Думал глянуть в хидерах мож что есть. Божечки, там пара десятков файлов, простых, как мой валенок. Сорцов у продукта, думаю, примерно столько же. И каждый год версию выпускали. Я сейчас за квартал пишу гораздо больше гораздо более сложного кода, а продукты пилятся всё медленнее и медленнее. Какое время было.

А, так вот, в хидерах про шаблоны нет ни там ни там ничего, нашел в generic.h
BC2

/* generic.h -- for faking generic class declarations

    Copyright (c) 1990,1991 by Borland International    
    All rights reserved

    When type templates are implemented in C++, this will probably go away.
*/

BC3

/*  generic.h -- for faking generic class declarations

    Copyright (c) 1990, 1992 by Borland International
    All rights reserved

    When type templates are implemented in C++, this will probably go away.
*/

Ставить DOS-бокс, запускать и проверять, что там поддерживается — лень

Могу предположит, что в BC2 таки что-то было про шаблоны — вроде бы шаблоны классов в плюсики завезли позже шаблонов функций, возможно в BC2 были только вторые, а в BC3 — первые, потому и не отложилось.

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

Здравствуйте, Pauel, Вы писали:

P>Была интересная хохма с GC дотнета. Выложили в интернет его код, ровно один файл ...

А не знаешь какая это версия дотнета была? Где его найти?

Здравствуйте, Философ, Вы писали:

P>>Была интересная хохма с GC дотнета. Выложили в интернет его код, ровно один файл ...

Ф>А не знаешь какая это версия дотнета была? Где его найти?

Там и сейчас похоже один файл, только уже 2мб

https://github.com/dotnet/runtime/blob/main/src/coreclr/gc/gc.cpp

Где найти тот, от старого дотнета, и не представляю