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

CC>>Вообще порой думается что и к С и к С++ без ассемблерного и системного бэкграунда нельзя подпускать.
BZ>а люди с ассемблерным бэкграундом плюются от него.
У всех разный вкус, я начинал с ассемблера и не плююсь.

BZ>как например заставить компилятор сгенерить cmov вместо перехода?
Эм, взять нормальный компилятор?

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

BZ>а люди с ассемблерным бэкграундом плюются от него. как например заставить компилятор сгенерить cmov вместо перехода?

а в С как?

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

BZ>>как например заставить компилятор сгенерить cmov вместо перехода?
CC>Эм, взять нормальный компилятор?

назови компилятор, который правильно откомпилирует этот код:

    for (int w1=257; w1<512; ++w1)
    {
        cnt[w1] = INT_MAX;
        left[w1]  = (cnt[r0]<=cnt[r1]? r0++ : r1++);
        right[w1] = (cnt[r0]<=cnt[r1]? r0++ : r1++);
        cnt[w1] = cnt[left[w1]] + cnt[right[w1]];
    }

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

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

A>а в С как?

точно так же. вообще по моему опыту c++ для оптимизации предпочтительней, поскольку поддерживает темплейты, лямбды и классы

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

BDA>Конечно же, надо вставить сиплюсплюсный супербезопасный dynamic_cast<> и проверку на 0. Чего несчастный урод не потрудился выяснить, это что мы собираем проект под платформу, которая не поддерживает RTTI. Как я узнал об этом замечательном рефакторинге? А в посленовогодние праздники написали мне в скайп из европы: йебалайтунг руссиш швайнен программен краш-краш!! Они там с 1 января пытались заюзать новую версию.

у вас ревью чтоли нету? сразу в мастер коммитите и в продакшен раскатываете?

BDA>Затем, в моем личном хит-параде идут любителя заменять небезопасные указатели на ссылки.
BDA>Это ничего, что объект создается на куче чуть выше по колстеку.
да, это ничего, какая разница что и как создается
BDA>Это ничего, что по своей сути родительская и дочерняя функции имеют трехзначную логику.
и это тоже ничего, но много кода в одном юните это конечно говнокод
BDA>Это ничего, что теперь для вызова функции на стеке надо создавать немалый суррогатный объект, а в его конструктор добавлять детектор суррогатности (зачем выполнять дорогостоящие операции, если объект все равно — пустышка?). Ничего, что в сигнатуру дочерней функции надо добавлять булевский параметр isValid, а поскольку булевские параметры — моветон, заводить enum, выносить его в околокорневой неймспейс. Главное, что теперь все это будет — БЕЗОПАСНО!
что? какой еще суррогатный объект? и главное при чем тут ссылки?
я на всякий случай напомню, что ссылка — это тот же указатель, только иммутабельный и не-нуллабельный. и естественно что все указатели, значения которых не меняются, и которые не равны nullptr можно и нужно заменить на ссылки.

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

CC>Это не настоящий С++сник, это просто каску нашёл теоретик.

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

>Надо гнать сцаными тряпками.

Он сам себя выгнал. В смысле, после того нового года никто его не видел. Может, под трамвай, про который любят менеджеры говорить, попал. А может его похитило правительство — Чебурашку писать. Как бы то ни было, запомнился он мне надолго. Такой архетипичный фоннат, что прямо в рамку и на стенку.

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

BZ>назови компилятор, который правильно откомпилирует этот код:

Хм. Посмотрел на код.
Совеременные компиляторы похоже забросили использовать эту инструкцию, и вот почему:

Do not do this for predictable branches. Do not use these instructions to eliminate all unpredictable conditional branches, because using these instructions will incur execution overhead due to executing both paths of a conditional branch.
In addition, converting conditional branches to cmovs or setcc trades control-flow dependence for data dependence and restricts the capability of the out-of-order engine.
When tuning, note that all 32-bit Intel® processors have very high branch-prediction rates.
Consistently mispredicted branches are rare.
Use these instructions only if the increase in computation time is less than the expected cost of a mispredicted branch.

По тестам получается что если predictor сработал то CMOV в 2.2 раза медленее. Если не сработал — в 1.2 раза быстрее.
Чем собственно и объясняется нежелание компиляторов его использовать.

BZ>только пож-та проверенный на деле.
Боюсь проверенный будет уж очень старым.

BZ> генерация cmov сейчас — моя головная боль, поскольку ни интринсика, ни сишных идиом для него нет.
Самое забавное что есть несколько способов сказать что вот этот бранч более вероятный, но сказать обратного нельзя никак.

BZ>может моё си-фу просто слишком солабо по сравнению с твоим?
Mine C-fu failed me as well.

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

E>Простые статики уже лежат проиниченые, а в_atexit функции надо сначала понапихать.

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

Здравствуйте, мыщъх, Вы писали:

М>вы совершенно правы. я был приятно удивлен, обнаружив, что в штатах можно знать си и совсем не париться по поводу плюсов. ладно бы я один не парился, так ведь и люди вокруг меня программируют на си и плюсы им совсем ни к чему. от рядовых разработчиков до архитекторов. си, линух. плюс питон | руби | что-то еще. и незначние плюсов (по крайней мере там, где я работал) это скорее плюс, чем минус, т.к. сишный код понятен большему числу людей и его читают все остальные сотрудники, даже те, кто больше по джава.

адреса, явки дадите, если не трудно? буду весьма благодарен и не только на словах

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

Kvd>Здравствуйте, мыщъх, Вы писали:

Kvd>адреса, явки дадите, если не трудно? буду весьма благодарен и не только на словах
например, Intel, Sourcefire и многие другие... security.do так же использует си без плюсов. в сша это очень широко распространенное явление. си и линух. линух и си.

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

R>А можно ли быть программистом-системщиком, но знать только С, без С++?

Теоретически, наверное, можно. Но практически -- скорей нельзя. Можно не иметь опыта программирования на C++, например. Но вообще вот так чтобы не знать вообще ничего -- сомневаюсь. Инопланетянином нужно быть что ли.

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

R>А можно ли быть программистом-системщиком, но знать только С, без С++? Вообще, насколько важно знать С++ или достаточно только С? Не только в России, но за бугром тоже. В Америке, я знаю, именно С больше в почете.

можно.

например https://sites.google.com/site/cinterfacesimplementations/ как аналог stl

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

Очень сложно выписали, но мне понравилось Тут чувствуется влияние стандарта:

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

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

CC>Ну и по факту, на С пишут такие обормоты, что просто за голову хватаешься.

Такие:



Квалификацию Криса под сомнение не ставлю.

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

> А причина в том, что на С трудно писать хороший код

Это как сделать вывод о том, что cлух у таракана в ногах, на основании того, что, таракан на убегает при стуке
если ему ноги оторвать.

На C можно писать красивейший и лаконичый код, загляните, например, в исходники opensolaris
Собственно, для разработки ядер и системных либ язык и создавался, и идеально подходит для этого до сих пор, инфа 100%.
И на C++ безпроблемно можно вахлять только в песочницах хотелки менеджеров, он для этого и создавался.

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

S>На C можно писать красивейший и лаконичый код
S>загляните, например, в исходники opensolaris
Я там вижу много рукопашки, типичной для С.
Это всё можно написать ещё красивее и лаконичнее. Но не на С.

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

CC>Я там вижу много рукопашки, типичной для С.

Там и должна быть именно рукопашка, "мы в ядре".

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

CC>>Я там вижу много рукопашки, типичной для С.
S>Там и должна быть именно рукопашка, "мы в ядре".
Это с чего бы? В ядре точно так же работают деструкторы и умные указатели. И даже исключения можно сделать, при желании.

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

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

CC>>Я там вижу много рукопашки, типичной для С.

S>Там и должна быть именно рукопашка, "мы в ядре".

Не должна, а приходится, потому что C. Я не совсем понимаю какой кайф в необходимости делать всё руками? Допустим, добавил еще один kmutex в znode_t и забыл проинициализировать его в zfs_znode_cache_constructor или разрушить в zfs_znode_cache_destructor. Или передал в zfs_znode_cache_constructor указатель не на znode_t, а на какой-то другой тип, и твое ядро очень классно заупсилось после memory corruption.

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

C>Это с чего бы? В ядре точно так же работают деструкторы и умные указатели. И даже исключения можно сделать, при желании.

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