Призовой фонд ЮПОКИ(Юбилейный Пятый Общетабунский Конкурс Игростроения)

+74
в блоге ОКИ
https://tabun.everypony.ru/blog/OKI/186528.html
Думал я, думал, и решил для этого дела отдельный пост сварганить. Всё-таки планы на этот конкурс у меня колоссальные, а потому и размах должен быть больше)))

Пока что призовой фонд составляет:
9 000 рублей.

Для поддержки конкурса и воплощения полного его потенциала, вот номер киви: киви+380505520672

Планируемая сумма: 50 000 рублей.

P.S. Если никто не наберётся в конкурсе, то просто отдам все деньги обратно)))

168 комментариев

GIVE ME ALL YOUR MONEY!!!
Да, конечно, один момент, кошелек только достану.
Так, где же он… А, вот же
Сударь, почему бы вам не проследовать строго нахуй? Ваше мнение здесь никому не всралось =)
Простите, как я мог забыть, для вас у меня тоже кое-что есть.
Так, где же оно… А, вот же
На 4 участника 3 судьи. Может сначала набрать участников, а потом формировать призовой фонд.
не слишком ли большой?
Если никто не наберётся, то просто отдам все деньги обратно… Кстати, да, об этом нужно в посте сообщить)))
Планируемая сумма: 50 000 рублей.



А вам (тебе) не кажется, что это чутка перебор?
Лох не мамонт, лох не вымрет.
Возможно и перебор… Я эту цифру так, от балды написал, чтобы был хоть какой-то ориентир))) А там как получится)))
А вам (тебе) не кажется, что это чутка перебор?

Кстати да. Не особо видно, чтоб тут народ рокфеллерством страдал.

… впрочем, кто знает… ^^
чтоб тут народ рокфеллерством страдал.

Так, либо я старый уже стал, либо не общаюсь с молодёжью… Что значит это выражение?
Немного ликбеза по ссылке: ТЫЦЬ

либо не общаюсь с молодёжью

Спасибо за комплимент. :)
Эта аватарка вас так молодит!
:D
Понятно, спасибо)))
Планируемая сумма: 50 000 рублей.

Эм, тут надо смотреть внимательно — если реально будет призовой фонд даже 15000-20000 рублей, то оно сравнимо с заказами свободных разработчиков, и кто-то может отнестись к этому как к заказу — то есть, выделить время пару недель, планово поработать и порвать всех, как Твайлайт Трикси.

Не про себя, если что, но и без меня профессионалов хватает.
Я б не стал на такое закладываться. Логика «жюри из народа» порой весьма причудлива, и качественно сделанная игра может запросто слить какой-нибуть ереси.
Жюри в долю взять
Так вот зачем набирают жюри. А я то думал.
Таки бронирую себе второе место в жюри, кстати, разрешите познакомить со своими родственниками, они все весьма авторитетные эксксперты со стажем!
И сколько у тебя родственников из Ярославля? Просто выиграть надо.
Только не говори что твои родственники из Хабаровска, иначе мне дешевле к другим жюри пойти.
качественно сделанная игра может запросто слить какой-нибуть ереси.

Сделать качественную ересь?
По поводу «мнений из народа»: тут ещё не стоит забывать, что обязательно «понабигают» те, которые всегда ждут МегаСуперПуперКонфетку, и если оно не заслуживает 100500 «межгалактичеких оскаров», то это «полный аццтой!».
И получится лучше Anthem'а
Anthem

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

Круче ходячего замка? Ну может быть.
Anthem — AAA проект. От твоей игры ждут хотя бы чтоб запускалась.
AAA

(полез читать) я думаю, что даже АААА-проекты пишут не агенты матрицы, а обычные люди, время от времени путающих a++ и ++a

отя бы чтоб запускалась

По данным последнего исследования, проект успешно запускается на 94% машин. Это неплохой показатель для древнего движка с нативным кодом и заплатками в виде прямой записи в память текстур (полагаю, что именно прямая запись в текстуры и гадит на оставшихся 6%). Теперь-то я умный и знаю про шейдеры.
a++ и ++a

А есть разница? Офк, кроме затыков в stl на c++?
А есть разница?

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

int a = 10;
int b = 10;
printf("%d %d",a++,++b);
i += i++ + ++i;
cчастливой отладки ;)
Хорошо что в Питоне такой херни нет)
В Паскале тоже сделали унарные операции процедурами, и это хорошо.
Только Керниган & Ричи сотворили по накурке такой синтаксис, который приходится трижды проверять самому у себя.
Керниган & Ричи просто взяли старую хорошую идею. Операция вида *р++ была на минуточку еще в калькуляторах типа мк-61. Команда К.ПХ.9 если не ошибаюсь за давностью. Ибо естественна по сути своей — взять значение по некоему адресу, и перейти к следующему.
Понятный (хоть и очень консервативный) синтаксис паскаля наверно один из его жирнейших плюсов супротив чрезмерной многословности. В C++ конечно никто не мешает придерживаться правил и не срать в коде типа «лаконичностью», делая его таким же понятным и легкочитаемым, но надеяться на долбоебов не приходится.
Я думал тут будут что-то интересное, а не банальное показывание как они работают.
Опять же, у тебя ошибка в последний строке. По Страуструп, у них одинаковый приоритет и потому ни ясно какой из двух выполнится первым.
А не важно, какой будет первый, важно что на любом устройстве, от AVR-платы до суперкомпьютера, напечатает 10 11
В данном случае не важно, но могу поспорить что можно найти случай где это ещё стрельнет в ногу. Стандарт c++ и компиляторы немного не одно и тоже.
Вообще, если мне память не изменяет то в упрощённом виде это выглядит как.
i++
int temp=i+1;
return temp;

++i
i=i+1;

При работе с шаблонами и итераторами не всегда создание временного объекта хорошая идея, потому там повально используют префексуную форму. С другой стороны, компиляторы уже научины не создавать лишних и ненужных объектов, как бы прогер не старался. Вот та самая различие стандарта от компилятора.
Например:
A geta()
{
 A a;
return a;
}

Большинство компиляторов не будут создавать временного объекта.
int temp=i+1;
return temp;
Скорей не так, а так:
int temp=i;
i=i+1;
return temp;
компиляторы уже научины не создавать лишних и ненужных объектов, как бы прогер не старался.
Это да. Постфиксная нотация без использования результата всегда на фазе оптимизаций «unused return value elimination» превращается в то же самое, что и префиксная.
Ну да. Пока на телефоне искал все символы, всю мысль потерял.
Разница в том что a++ и ++a используют на отдельной строке нормальные люди, а тупорылые ебланы не сеченые розгами пихают внутри выражений.
скорее всего так делают те кто просто хотят выпендриться. Ненавижу таких людей

Два альтернативно развитых, нихуя в теме не понимающих, но Охуенно Важное Мнение имеющих.
нихуя в теме не понимающих

Я считаю себя понимающим в теме, но тоже очень, ОЧЕНЬ не одобряю использование унарных операций совместно с прочими. Это сильно усложняет чтение даже своего кода.
Как по мне, так усложняют километровые портянки вместо лаконичности.

while(*dst++=*src++);

дай краткий аналог без унарных?
краткий аналог без унарных

doSomeMagic(dst,src);

а реализацию вынести в .h и .cpp, при необходимости загнать в .lib

Так мы достигаем двух великих целей.
1) Предельно лаконичная запись doSomeMagic, к тому же, самодокументируемая (делаем какую-то магию)
2) Если понадобится её отладить — мы идем в отдельный .cpp и там видим многострочную понятную запись.

Потому что я сейчас минут 10 смотрел и всё равно не уверен, что правильно понял действие этого кода.
Пока значение по указателю dst не равно нулю, записывать в него значение из указателя src и двигать указатели вперед?
Пока в src не нуль копировать в dst, как только скопировали нуль то хватит.

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

Код-то пишется людьми для людей.
А можно вопрос, как вы учили С/С++? Ибо приведенный пример — боянище бородатейшее, используется и разбирается практически в любой книжке в главе про указатели.
Получал заказ, делал его, получал оплату, пропивал деньги, искал следующий заказ :-)
И всегда старался писать максимально развернуто.
PS: Я не учился на программиста, я физик-теоретик по образованию. Просто так получилось, что за скрипты, базы и сервера платят, а за физику нет.
Подход конечно имеющий право на жизнь, но почему тогда не паскаль/дельфи? Или из современного — питон/го?
но почему тогда не паскаль/дельфи

А я и пишу в основном на Delphi (в последние 5 лет еще C#), но есть ряд случаев, когда приходится использовать С (например, системное ПО для Linux или нативное приложение для Windows, которое не сожрет злой антивирус (а дельфийские бинарники он жрет, из-за чего меня не раз пытались казнить))
Тогда понятно. Есть конечно в С/С++ вещи, глядя на которые вспоминается старая копипаста про «это вам не чикатило и не архивы КГБ, не суйтесь сюда», но я уверяю, что для регулярно пишущих на С/С++, унарки с указателями читаются так же легко, как inc(x) в делфях. Образно говоря это не высший матан, но арифметика.
Если эта строка с пятью операциями в одной — типичный паттерн для С, как для Паскаля запись вида
FOR I:=1 to N
тогда да, соглашусь.

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

Вот это уже позапутанней
#define offsetof(st, m) ((size_t)&(((st *)0)->m))

А чтобы впечатлить девушек, пишут так))
www.opennet.ru/opennews/art.shtml?num=35129&post=-23513226_1779
Сие немного плохо, просто потому, что я понимаю смысл КАЖДОГО фрагмента команды, но не могу понять, что оно делает. А это, согласитесь, не должно быть — человек, знакомый с синтаксисом языка, должен быть способен как минимум, ПРОЧИТАТЬ и ПОНЯТЬ код (но не написать, конечно).
Это с практикой и опытом приходит. Как ин.язык учить… Там тоже поначалу кажется «все слова понятны, а смысла фразы нет», а потом ничего, нормально)
Как ин.язык учить…

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

Аллегорически говоря, когда мы пишем программу, мы должны писать её не для Шекспира или репера, а для иностранца.

Потому что скорее всего, иностранец её и будет читать. Да, чаще всего бизнес просто выкидывает запутанный код и с трехэтажным матом пинает старого разработчика, так что тот улетает на 9600 бод впереди своего визга. Однако известны и другие случаи — когда разработчика приковывают цепями и говорят «пока вот этот индус не поймет твой код до конца — с работы не уйдешь». И тут уже разработчик вспоминает, что помимо круто выглядящих конструкций, были еще какие-то правила, вроде не класть более одной изменяющей данные операции в строку, не менять переменные внутри процедуры, не превышать размер процедуры на экранную страницу, не использовать бессмысленные имена переменных (за исключением i,j,k,n,p и мат.формул) да еще куча всего, что было гордо игнорировано.
не класть более одной изменяющей данные операции в строку
Да, это, пожалуй, одно из самых основных правил написания понятного кода на С.
А чтобы впечатлить девушек, пишут так))
Где-то я видел прогу, печатающую числа Фибоначчи, в которой длина каждой N-той строки равна N-му числу Фибоначчи, начиная с 1 =)
Было, да. Еще был расчет числа пи в виде ascii-арта большой буквы пи)
Если каждую такую тривиальную мелочь (а этот пример действительно тривиален для хоть немного осиливших С) выносить в свой.срр
Такую тривиальную мелочь нужно выносить в libc.so, а не в *.cpp. Потмоу что она используется не в одной программе, а очень много где.
Потому что я сейчас минут 10 смотрел и всё равно не уверен, что правильно понял действие этого кода.
Я понял, потому что знаю, что это implementation-defined определение strcpy(). Но с непривычки да, сложно.
Лол, конструкция красивая, но не прочитав книжку какого-нибудь Кнута, в неё въехать так же тяжело, как в эти всякие лестницы из eval() и apply() у новомодных адептов функциональных языков в промышленном программировании (хотя они подходят исключительно для теоретического).

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

Та же конструкция (да, банальный strcpy) может быть описана менее лаконично:
vector Src(begin = src, length = find(t_byte, src, 0));
vector Dst(begin = dst, length = Src.length);
vector::copy(Src, Dst);

Но при этом правильный компилятор её сумеет оптимизировать гораздо лучше, понаставив префетчи и воспользовавшись SSE-командами и прямой работой с кэшем, где надо — всего лишь потому, что vector::copy() написана не в одну строчку, а гораздо объёмнее, но при этом гораздо оптимизированнее. Например, как-то так (я накидал реализацию для SSE, кэши и прочее писать лень):
#define __builtin_xmm_load (reg_num) asm "movss xmm##reg_num, [rbx + rsi]"
#define __builtin_xmm_store(reg_num) asm "movss [rbp + rdi], xmm##reg_num"

inline __attribute__((always_inline)) void __builtin_xmm_copy(xmmint_t *dst, xmmint_t *src, int count)
{
    asm "mov rbx, src; xor rsi, rsi";

    #pragma always_unwind
    for(int i = 0; i < count; ++i)
    {
        __builtin_xmm_load(reg_num = i);
        asm "add rsi, XMMREG_LENGTH";
    }

    asm "mov rbp, dst; xor rdi, rdi";

    #pragma always_unwind
    for(int i = 0; i < count; ++i)
    {
        __builtin_xmm_store(reg_num = i);
        asm "add rdi, XMMREG_LENGTH";
    }
}

inline __attribute__((always_inline)) void __builtin_int_divide_pow2(int dividend, int divisor, int& quotient, int remainder)
{
    #pragma always_unwind
    for(int pow = 0, i = 1; i < INT_MAX; i <<= 1, ++pow)
        if (i == divisor)
        {
            quotient  = dividend >> pow;
            remainder = dividend & --divisor;
            return;
        }

}

inline __attribute__((always_inline)) void __builtin_byte_copy(register __attribute__(register("rbx")) char *dst, register __attribute__(register("rbp")) char *src, register __attribute__(register("rsi")) int offset, register __attribute__(register("rcx")) int count)
{
    #pragma always_predict
    switch(count)
    {
        case 0: return;
        case 1: asm "mov rdi, rsi; mov byte ptr [rbp + rdi], [rbx + rsi]"; return;
        case 2: asm "mov rdi, rsi; mov word ptr [rbp + rdi], [rbx + rsi]"; return;
        case 4: asm "mov rdi, rsi; mov dword ptr [rbp + rdi], [rbx + rsi]"; return;
        case 8: asm "mov rdi, rsi; mov qword ptr [rbp + rdi], [rbx + rsi]"; return;
        default: asm "mov rdi, rbp; add rbp, rsi; add rsi, rbx; rep movsb"; return;
    }
}

inline void vector::copy(vector src, vector dst)
{
    if (src.length < XMMREG_LENGTH * XMMREG_COUNT)
    {
        register int regs_used, leftover;
        __builtin_int_divide_pow2(dividend = src.length, divisor = XMMREG_LENGTH, regs_used, leftover);
        __builtin_xmm_copy(dst = dst.begin, src = src.begin, count = regs_used)
        __builtin_byte_copy(dst_base = dst.begin, src_base = src.begin, offset_byte = src.length - leftover, count = leftover))
        return;
    }
    if (src.length < L1_CACHE_LINE_LENGTH)
    {
        ... // L1 cache implemetation
        return;
    }
    if (src.length < L2_CACHE_LINE_LENGTH)
    {
        ... // L2 cache + prefetch2() implemetation
        return;
    }
    ... // other implementations
}
(Написал С/С++-подобным псевдокодом с учётом архитектуры x86_64; на «Эльбрусе», например, немного другое — там вместо SSE используются регистровые окна и многоканальное копирование. Само собой, все билтины реализуются компилятором, а не библиотекой. Лол, хотел показать десяток строчек, но в итоге увлёкся, потому что объяснить псевдокодом оказалось проще, чем словами. =)
И это я ещё не учитывал того, что можно выделять память не побайтно, а блоками по 128 бит, и тогда всё упростится вплоть до полной ненужности __builtin_byte_copy().
Та же конструкция (да, банальный strcpy) может быть описана менее лаконично:

vector Src(begin = src, length = find(t_byte, src, 0));
vector Dst(begin = dst, length = Src.length);
vector::copy(Src, Dst);


ИМХО так не делают тоже. Тот же strcpy внутри стандартных h/cpp файлов у gcc например просто напрямую превращается в десяток вариантов, которые выбираются через #ifdef в зависимости от выбранной архитектуры, опций оптимизации, и много еще чего. В том числе я там и через SSE видел варианты, да, и через классику с while.

К тому же в варианте с vector мы имеем два прохода по строке — сначала чтобы найти завершающий нуль, а потом собственно копирование.
while же работает в один проход. Для длинных строк затраты времени на двойной проход могут перекрыть выгоду от SSE.
Тот же strcpy внутри стандартных h/cpp файлов у gcc например просто напрямую превращается в десяток вариантов, которые выбираются через #ifdef
Не только через #ifdef, но и по некоторым другим критериям, один из которых — длина строки (хотя как в современном gcc точно не знаю; видел это в uclibc, если не ошибаюсь, хотя там эта реализация подцепляется только если в компиляторе нет интринсика __builtin_strcpy()).
Для длинных строк затраты времени на двойной проход могут перекрыть выгоду от SSE.
Возможно, там используется find, который, если не смог найти ноль в пределах длины одной строки L1-кэша, возвращает что-то типа «строка слишком длинная» для того, чтобы использовался обычный fallback-вариант с поиском нуля в процессе копирования. Это, возможно, даст выгоду на очень длинных строках (килобайты-мегабайты), но на большинстве строк поиск нуля ещё и загонит строку в кэш (если она там не лежит), а это здорово ускорит последующее копирование. Можно было бы строку закэшировать и без поиска нуля, дав префетчеру прямое указание «сейчас мы будем много и долго читать вот с этого адреса», но если заодно с ним сделать ещё и вычисление размера, то это будет удобнее (при определённых не так уж и редко встречающихся размерах копирование может быть очень быстрым; к примеру, скопировать 512 байт (выровненные тоже на 512 байт, разумеется), в принципе, можно за 8 тактов (префетч и реассоциация строки кэша, если кэш может в copy-on-write, а 511 — за что-то около нескольких сотен). Хотя мы за такое быстрое копирование поплатимся значительной latency при первой записи в новую строку; но учитывая то, что большинство копирований — это создания read-only копий объектов на стеке, которые не элиминировались при оптимизациях, записи в них может вообще не происходить.
Но с кэшем тоже аккуратненько надо, а то при неудачной комбинации адресов исходника, приемника и размера кэщ-линейки, можно словить кэш-трешинг, и вместо профита получить дикую просадку скорости, если например много строк в цикле копируем.
Да, поэтому в некоторых реализациях malloc выдаёт адреса, выровненные по границе строки кэша (из-за этого выделение десятка разных char-ов сожрёт килобайты). Благо проверка на выровненность и длину достаточно проста — «and addr, 0x1FF; jnz classic_implementation; and size, 0x1FF; jnz classic_implementation», а вероятность того, что строку надо будет копировать целиком, а не с какого-то смещения — небольшая.
Можно даже не закладываться на то что там malloc делает. Есть же надстройка над ней mm_malloc, которая позволяет принудительно выравнивание задать.
mm_malloc (и её не-Intel-овские аналоги), как я понимаю, имеют смысл там, где нужно задавать выравнивание для чего-то более крупно выровненного (например, при DMA-обменах, которые должны быть выровнены по границе 4К-страницы). Ну а я именно про такую реализацию malloc(), которая всегда выдаёт такие указатели, которые выровнены на одну, специфическую для L1 гранулярность. Заодно можно косвенно проверять, правильный ли указатель передан во free().
Наверное, тут имелось в виду не унарные операции, а операции, изменяющие аргументы.
В подобных унарных операциях, думаю, нет ничего плохого:
if (!a) c = -b;
Зато вот тут даже бинарные операции заставляют задуматься:
k = (l += n) + (m += n); // Да-да, этой строкой мы меняем и k, и l, и m.
Да-да, этой строкой мы меняем и k, и l, и m.

А не надо так делать. Менять нужно только то, что слева от знака =
Тогда любой ёж, севший читать мой код (и даже я спустя десять лет), точно будет знать, что изменяется только одна переменная.
Если уж так хочется, то эту строчку нужно оформить процедурой.

int getSumAndIncLM(int *l,int *m, int n) {
*l+=n;
*m+=n;
return *l+*m;
}

я сразу вижу, что у меня изменяются две переменные и возвращается их сумма после изменения.
В исходном же примере я без подглядывания в приоритеты операций не скажу, что идет раньше — увеличение l,m или сложение l+m
я без подглядывания в приоритеты операций не скажу

Скобки же стоят, однозначно расставляющие приоритеты.
То есть, я верно переписал код?
Верно)
А не надо так делать. Менять нужно только то, что слева от знака =
Именно. Это одно из главных правил хорошего тона в C, если мы не говорим о каких-то широко известных паттернах.
В общем, как я и говорю: вопрос не в унарности операций, а в том, что они могут изменять свои аргументы.
k = (l += n) + (m += n); // Да-да, этой строкой мы меняем и k, и l, и m.


Удобный лаконичный код же. А gcc расширения вообще позволяют писать хоть пол-программы в выражении.

k = n + ({ int s = 0; for( int i = n; --i >= 0; ) s += i; s; });
пол-программы в выражении.

Разве анонимных методов нет в C?

PS: Вот зачем так

for( int i = n; --i >= 0; )

если можно так?

for( int i = n; i >= 0; i--)

в чем смысл загнать сравнение и изменение данных в одну операцию?
Разве анонимных методов нет в C?

Лямбды только в с++11 появились.

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

Дело вкуса, как мы уже выяснили же) Кому то важнее лаконичность, кому то полная «прозрачность» кода.
Кому то важнее лаконичность

Эм, в примере из моего поста выше длина второй записи больше на 1 байт, но понятность и вероятность убрать граничную ошибку в плюс.
Лямбды только в с++11 появились

Ясно, изучу. Мне после C# как приходится на сишный код смотреть/править, так всякий раз рыдаю и пью неразбавленный спирт.
Эм, в примере из моего поста

Ну я уже в целом. Если привык к тем же унаркам, то автоматом везде ставишь.

Ясно, изучу

Изучи. На самом деле с++ в редакциях 14 и 17 года попрятал довольно много «крипоты» «под капот», обзавелся удобными ништяками (те же лямбды например, или range-for), расширил STL, и вообще уже не такой пугающий как с++89 )
range-for

Спайк хоооочет! То есть, мне можно теперь писать примерно так:

int arr = new int[N];
int sum = 0;
for (auto a in arr)
sum+=a;

Может, там еще и подобие LINQ сделали, чтобы код выше был как-то так
int s = arr.Sum();
Много чего можно)
en.cppreference.com/w/cpp/language/range-for
тут примеры)
тут примеры)


Sum s = std::for_each(nums.begin(), nums.end(), Sum());

уже много лучше, но всё равно как-то мучительно выглядит.

Всё-таки для большой и сложной логики тот же C# или Java куда больше подходят, пусть они и жрут память как кони
Это основа же. Можно спрятать в простенький макрос, будет удобнее. В это и фишка с/с++, он дает не рыбку, а удочку)
C++ двигается к отказу от сишных массивов к stl шаблонам. Вроде с c+20 хотят new и указатель вынести в устаревшие фичи.
new и указатель вынести в устаревшие фичи.

Это сомнительно. Все же прямая работа с памятью — одна из основ с/с++, и есть еще критические места где надо выжимать по скорости максимум именно прямой работой, а STL пока еще не всегда моГет) Помню на хабре вроде сравнивали скорость std::fill vs memset и std::copy vs memcpy. Слив в 2-3 раза по скорости у stl на -О3 даже. И это на самой тривиальщине — заполнить/копировать.
Прямая работа с никуда не уйдет, просто изменит свою форму. Умные указатели по итогу работают также как и сырой указатель — компилятор сам все приберет. С массивами вроде таже хрень.
На компилятор надейся, а сам не плошай. Есть случаи, когда банально нужно подсказать компилятору, что массив в памяти тут требуется не простой, а выровненный — и это катастрофически повысит производительность.
Комитету, который пилит стандарт, видней. Кто я такой чтобы спорить с ними.
Умные указатели оно конечно хорошо… но огромнейшая масса легаси/библиотечного кода хочет именно сырых.

Простейший пример — чтение из файла

std::unique_ptr p;
fread( p, 1, 10, f ); // так не могу
fread( p.get(), 1, 10, f ); // извращайся так.

или

std::vector v;
fread( v, 1, f ); // так не могу
fread( v.data(), 1, v.size(), f ); // извращайся так.

Можно конечно запиливать обвертки, макросы под все это — но это такое себе…
Их не удаляют, а переводят в ранг устаревшего стандарта и плохой практики.
С std::copy немного странная хрень. По факту это шаблон который выдаст самый оптимальный способ копирования: если вогнать в него массив то он развернется в сишный memcpy, только тебе не придется самому с ним возиться. Откуда падение производительности — хз.
хз, но однозначно помню что читал такое. Может в последних реализациях STL уже исправили на прямую подстановку memcpy.
Вроде std::copy всегда так работал, т.к. он является шаблонной обёрткой под memcpy и другие способы копирования. Так что хз как они намеряли.
Возможно это связано с string'ами. Их только к с14 привели в порядок, до этого некоторые писали собственные строки из медлительности стандартных.
рыдаю и пью неразбавленный спирт.
И тут я такой вспоминаю про песню «Дьявол» «Белой гвардии». =)
Разве анонимных методов нет в C

Я больше скажу, в Си вообще нет методов :) Он чисто процедурный. По крайней мере в ANSI C.
Создать указатель на функцию внутри структуры данных — вот тебе и метод в С.
Это неправильный метод. Мы ожидаем от методов полиморфизма.
Ну можно и аналог vtable скостылить… но это уже бдсм с Молестией) С++ то и начали пилить отчасти потому что захотели костыльный ООП сделать нативным и без геморроя.
Кстати, насчёт
--i >= 0
а точнее, такого случая, как
--i > 0
ЕМНИП, здесь, что забавно, один из тех редких случаев, когда на некоторых архитектурах компилятор преобразовывает не вычитание единицы в декремент, а наоборот, несмотря на то, что декремент регистра медленнее вычитания. Всё лишь потому, что декремент выполняется на регистре в счётном режиме и на таких архитектурах не устанавливает флаг нуля (на x86 и x86_64 устанавливает, а вот то ли на на ARM, то ли на MIPS — нет), и потому вместо «dec r0; and r0, r0; jnz continue» лучше будет «sub r0, 1; jnz continue» (псевдокод, близкий к ассемблеру x86). А вот на x86 такого не нужно — там есть специальная инструкция loop (если счётчик цикла удалось поместить в rcx), ну или иначе — «dec reg; jnz continue».

Да, кстати, поэтому же цикл с условием i > 0 эффективнее цикла с условием i >= 0.
На современных х86 кстати loop намного медленней чем пара dec reg; jnz continue, ибо является сложной CISC инструкцией, которая разбирается на кучу микрокода, прежде чем уйти в RISC ядро.

Кстати вспоминается древний 8-битный проц z80, из знаменитого «спектрума». Там декремент 8-битного регистра флаги менял, а 16-битного нет. Поэтому вместо dec de; jnz continue приходилось делать что то типа dec de; ld a,d; or e; jnz continue;
На современных х86 кстати loop намного медленней чем пара dec reg; jnz continue
Лол, а это уже забавно: loop изначально и была на 8086 сделана для того, чтобы ускорить циклы по регистру cx (там больше времени занимало декодирование команды, чем её исполнение), а теперь получается ради обеспечения совместимости такого наворотили, что она стала медленнее, чем «обычный» путь. Лол.
Там декремент 8-битного регистра флаги менял, а 16-битного нет.
Емнип (могу ошибаться, например, путать с 8080), 16-битные регистры (кроме адресных) в Z80 были эдакой «виртуальной» склейкой 8-битных, а АЛУ и всё остальное было 8-битным, потому операции с 16-битными регистрами были очень ограничены по возможностям.
16-битные регистры (кроме адресных) в Z80 были эдакой «виртуальной» склейкой 8-битных, а АЛУ и всё остальное было 8-битным, потому операции с 16-битными регистрами были очень ограничены по возможностям.


Именно так, и в Z80 и в 8080

(кроме адресных)

И адресные тоже из половинок были. Пары IX,IY недокументированым юзанием префиксов #DD и #FD прекрасно пилились на 8-битные половинки. Единственно SP нельзя было попилить, и то только потому что наружу не вытащили его префикс.
Именно так, и в Z80 и в 8080
А, значит в обоих. Я помнил только про один, значит, в другом было так же.
Пары IX,IY недокументированым юзанием префиксов #DD и #FD прекрасно пилились на 8-битные половинки.
Лол, забавно. Можно даже по этой инфе предположить, как реализован дешифратор команд внутри процессора и как он взаимодействует с мультиплексором регистрового файла.
Про Z80 предполагать уже не надо. Распотрошили его прямым микрофотографированием кристалла вдоль и поперек.

АЛУ там вообще 4-битное оказалось.
www.righto.com/2013/09/the-z-80-has-4-bit-alu-heres-how-it.html
Воу, занятная инфа. Вот так оптимизировали схемы в прошлом, а сейчас чё, бахнуть ещё миллион транзисторов на кристалл — и ничего. =)
Кстати, n-МОП логика достаточно забавно выглядит на таких микрофотографиях в отличие от КМОП.
Удобный лаконичный код же.
Он удобный и лаконичный, но его понятность оставляет желать лучшего. А учитывая то, что в современных реалиях большинство программистов не очень профессиональны, то поддерживаемость такого кода оставляет желать лучшего.
в современных реалиях большинство программистов не очень профессиональны

Для них Го придумали)
Ой да что вы говорите, а 97 баллов по егэ, где так-же есть код по с++, я по-вашему просто так получил?)))
чувааааак… хелло ворлд и пара лабораторок по расчету факториала и пузырьковой сортировке — это не код
у меня в школе не было информатики вообще. Я полностью самоучка.
Информатики не было, а егэ по ней был? «Помоему одна из черепашек пиздит» ©
Ты идиот? Заявление на егэ подаётся самостоятельно вне зависимости от того, какие были предметы. Походу ты давно в школе не учился. Сейчас система образования совсем другая
Лучше бы ты заявление на егэ по культуре общения подал. Было бы на одного культурного человека больше и на одного говнокодера меньше.
Вот с NTFS например я могу подискутировать по вопросам программирования, потому что он
1. Писал «боевой» код, за который отвечаешь деньгами и репутацией.
2. Общается корректно, без «ненавижу» и «ебланы».

А агрессивные школотроны могут отправляться туда где не светит солнце, обмывать свои 97 баллов ягой, или чем там щас упарываться модно.
Если ты пишешь код просто ради того, чтобы писать код, не думая о том, для чего в принципе ты это делаешь и ради кого — то мне в принципе нечего добавить.
Дебилушко, ты под бутиратом чтоль? Чего ты несешь, болезный? Я тебе как раз говорю, что я и тот же НТФС пишем код в продакшен, и отвечаем за него. А твои диванные измышления, имеющие под собой чуть менее чем нихера, отправляются под хвост Молестии.
С чего ты взял, что они диванные? Я точно так же занимаюсь программированием, как и он. А от таких неадекватов как ты, у меня просто тошнит.
Дебилушко, уж кому бы про неадекватность говорить… Общаться научись сначала, а не влетать в дискуссию с воплями «НЕНАВИЖУ!!!», «ТОШНИТ!!!».
скорее всего так делают те кто просто хотят выпендриться. Ненавижу таких людей
.
На сайте с модерацией ты б в бан улетел тупо за такое.

И если ты разупорешься, то заметишь, что НТФС тоже высказал свое мнение по унарным операциям, отличающееся от моего, однако с ним была абсолютно нормальная дискуссия, так же как и с makise_homura например.

А диванными твои высеры останутся до тех пор, пока ты не напишешь хотя бы одну программу, за которую несешь какую-либо ответственность. А для диванного самоудовлетворения можешь хоть дырки на перфокартах шилом пробивать — никого это не волнует. НТФС отвечает за свои программы, и я могу принять его мнение что ему для этого удобно кодить без унарок. А твой диванный вскукарек «ололо, ненавижу!» — имеет ценность чуть менее чем нихуя.
Да и отдельные строки (++) чаще всего не нужны — разве что в классическом цикле for для вычисления факториала.
После того, как добрые люди создали контейнеры, можно забыть массивы с индексами как страшный сон Лунной Пони.
При заявленной системе оценивания, всё равно не мотивирует =/
Сперва человек активно просит денег якобы на лечение, потом начинает активно собирать призовой фонд на конкурс со сроками в полгода… что-то мне это внушает подозрения.

А куда на самом деле пойдут деньги?
В карман. Он не отчитывается о реальном приходе денег и игнорирует прямые вопросы.
Какие прямые вопросы я игнорировал?
Вот тут например ты на хую вертел что-либо отвечать. Ну и опять же, нулевая отчетность. И разумеется в посте речь о каких-то мистических «задержках».
Действительно, почему 10 000 рублей, разделённое на 5 человек, даёт 9 000 рублей. Это прям мистика какая-то)))
Ну вот, на прямо поставленный вопрос никакого ответа.
Ты серьёзно?
Да. Я смотрю тебя беспокоит необходимость отчитываться в растрате чужих денег.
А какой ответ я могу дать? Меньше получилось, потому что комиссия. А задержки, я даже и не помню, с чем это было связано(((
Но это же и так очевидно))) Кроме задержек… Либо не мог вывести деньги, либо было лень в тот период из-за проблем… Кто его знает)))
Уважаемые доенные коровы, вот ваш организатор. «Не помню», «Это очевидно», «Было лень», «Кто его знает». Продолжайте в том же духе, от вас, доенных коров, ждут уже не мелочиться, а выкладываться на несколько десятков тысяч рублей. Долой стеснение
Нехорошо людей оскорблять, вообще-то!!! И следи за языком, будь любезен!!! Я, кажется, в твой адрес ещё ничего не высказывал!!! Так что грубить незачем!!!
Ну вообще-то обращение было не к тебе, а к участникам. Тебя я назвал организатором, что не является оскорблением или грубостью. Но видно у кого-то колечко все таки сжалось от неудобных вопросов.
Как скажешь)))
Есть простой способ разрешить эту проблему. Касса должна быть у третьего лица — известного и равно уважаемого как участниками, так и организаторами, но не относящегося ни к первым, ни ко вторым. Можно предложить ovnd или Prodius , например. Или другого кого, тут много достойных людей.
Верно)))
Можно предложить ovnd или Prodius

Гулять так гулять: предлагаю кассу отдать принцу марсу. Это будет очень забавно =D
Я уверен, что я упускаю какую-то шутку, связанную с этим человеком… Можете объяснить?))
Известен в фандоме как гипер ответсвенный и повёрнутый на скрупулёзном выполнении обещаний и сроков. О его трепетном отношении к чужим деньгам едва ли не легенды ходят. Многие с него хренеют. Меметичная личность.
Недалеко я от него ушёл))) Запомните имя Шадовика, хахаха)))
Ну, тебя точно на табуне многие помнят. Ты много всякого сотворил. И ОКИ, и шахматный турнир.
Можете объяснить?))

Нежные понилюбы вынырнули из розового мира единорогов и чаепитий, и обнаружили, что время от времени частные лица и/или организации не могут/не хотят исполнять договорные обязательства. Вместо того, чтобы плюнуть и забыть, или же решить вопрос в рамках гражданского-правовых отношений через мировой суд, они страшно обиделись и вспоминают эту страшную историю.
Много буков для простого определения «весёлые срачики в комментах время от времени»
Но я усматриваю какую-то целенаправленную ненависть, словно он ваших любимых котиков ест на завтрак :-)
Никакой ненависти у 99% участвующих в марсосрачах. Just for lulZ, не более… а получить с Марса какой-то профит уже никто не ждет. Его даже «в рамках гражданского-правовых отношений» не особо прижмешь, выясняли уже… ибо сумма кидалова не дотягивает до уголовки по 159-й статье
в рамках гражданского-правовых отношений

до уголовки

это как бы разное дело. Уголовка это только когда был исходный умысел, доказанный, что негодяй специально собрал деньги, чтобы присвоить.
А если по договорным отношениям обязательства не исполнены — суд, приставы, исполнительный лист и дальше медленно и печально получать. Ценности там, техника, машины, акции. Нет, носки и трусы нельзя.
Ну, лет через шесть выигрыш может и отдаст. Процентов 30 от него.
Чего он делать разумеется не будет.
К тому же, он до сих пор может отчитаться за полученные на прошлые конкурсы средства и за выданные победителям. Он брал деньги не с рук, а собирал электронные переводы, история о которых никуда не делась. Но делать этого он тоже не будет. К моему вопросу о 10 000 он написал
А какой ответ я могу дать? Меньше получилось, потому что комиссия.

В каком размере была эта комиссия, со скольки переводов, ибо не с каждого комиссия взимается. Если комиссия была, зачем писать призовой фонд который в действительности урезан комиссией? Ответа нет.
Ну и разумеется, он хлопает глазами и искренне недоумевает, как такие вопросы вообще могут возникнуть
Ты серьёзно?
Чего он делать разумеется не будет.
Ну да… Всё верно)))
Лечение реально было и это меня подкосило… Насчёт сроков, сразу скажу, что это не моя инициатива устраивать на полгода, но идея неплохая и почему бы так не сделать)))
А куда на самом деле пойдут деньги?

Смотря сколько будет))) Если в пределах прошлых конкурсов, то как и обычно раздача… А если больше, то есть у меня идеи)))
То есть, ты устраиваешь конкурсы не ради того чтобы купить яхту длиннея чем абрамовича? Так даже не интересно.
Интересно, почему Навальный ещё не выпустил фильм «он вам не шадовик»?
Во-первых, это первая мысль, которая приходить в голову любого, кто видит подобные сообщения/посты. Что хотят заграбастать себе побольше денег))) Это логично)))
Во-вторых, даже если бы и хотел купить яхту, тут бы я на неё не насобирал бы)))
В-третьих, на конкурсах я в основном деньги раздаю, так что как я могу делать конкурсы для заработка — это вопрос… Хотя я хотел бы знать, как)))
В-четвёртых, я не в курсах про Навального, так что я не понял(((
опять я не смог в шутку.
Если бы я знал про Навального, то может шутка и зашла бы… Извини)))
Что-то вроде местного Шария. Ругает власть в интернетах, но, в отличии от Шария, и сам не прочь припасть к кормушке.
Ладно, а кто такой Шарий?
Окей, я глянул, и я про него ничего не знаю)))
Ну вот простой вопрос — мои деньги последние на что пошли? Не то чтобы это была та сумма, с которой я не готов расстаться ради веры в людей, но просто интересно?
То, что я до конкурса попросил, это я отдам в следующем месяце тебе. То я занял у тебя на проживание)))
Я же ничего не говорил про конкурс)))
Ну так это и работает. Скидываются копейками про которые легче забыть чем спрашивать. С миру по нитке.
Ура, ОКИ снова в деле!
Скорее всего, мы (я, BlazerDom и olga131186 ) присоединимся.

Призовой фонд внушает уважение, постараемся подкинуть в меру сил и возможностей :3
Бл*YaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaY*ть.. а я опоздал на регистрацию, поздравьте меня :c
Ну кто тебе виноват? В жюри записывайся тогда)))
Всё ещё можно поддержать наш конкурс))) Первый отчёт об играх участников будет 1 мая, так что ждите)))
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.