си C99

Да всем насрать! emulek, ты точно клоун.

а ты говнокодер.

Ты не только клоун, но и дегенерат. Размер void* p (в первом случае) и std::unique_ptr<void> p (во втором случае) одинаков.

однако void* p удаляется быстрее. Посмотри в коде, у тебя p — адрес на стеке, который указывает на адрес в куче. И тебе необходимо удалить сначала память в куче, а потом уже на стеке.

Что-бы не говорить чушь, посмотри пожалуйста, как твой std::unique_ptr изнутри устроен.

Ты эту жесть видел вообще? Ну и как ее переносить, скажем, на ARM? Писать другой велосипед? Аппаратно-зависимые части — это плохо

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

http://benchmarksgame.alioth.debian.org/u32/program.php?test=mandelbrot&l...

Такое не соберешь tcc, например. Это вообще не код на С, но авторам нужно было выжать максимум. Правда вот беда, рядом у rust действительно переносимый код оказался эффективней, а у Java действительно переносимый код незначительно меньше эффективный. Так что нефиг выделываться, просто возьми и используй препроцессор еще раз.

на самом деле делает: плодит лишнюю сущность «auto p» на стеке для эмуляции управления памятью.

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

однако void* p удаляется быстрее.

Пруф?

Посмотри в коде, у тебя p — адрес на стеке, который указывает на адрес в куче.

Тоже самое у тебя в случае void *p. Это переменная на стеке, которая указывает на адрес в куче.

И тебе необходимо удалить сначала память в куче, а потом уже на стеке.

Никакой разницы с void *p тут нет. Возможно, будет еще храниться функциональный объект для удаления.

Что-бы не говорить чушь, посмотри пожалуйста, как твой std::unique_ptr изнутри устроен.

Упрощенно так:

template<class T,
         class Deleter = std::default_delete<T>>
class unique_ptr {
// ...

private:
    T *p;
    Deleter d;
};

Чушь здесь говоришь исключительно ты. В обоих случаях в куче и на стеке выделяется одинаковое количество памяти. Более того, я тебя обрадую: освобождение памяти на стеке занимает ровно одну инструкцию, сколько бы там её ни было.

P. S. я писал свою реализацию unique_ptr, сравнивал сгенерированный машинный код и могу со всей уверенностью сказать, что правильно написанный unique_ptr идентичен ручному управлению памятью с точностью до порядка инструкций.

А как ты будешь буферы выделять? Считать в байтах от начала до конца нужного куска? Вообще маразм, когда длина в буквах не равна длине в байтах...

А реальная переносимость с сохранением быстродействия это, например, Java или rust

Ложь. Там просто за тебя сделали платформеннозависимую часть. И это обернулось в итоге жуткими тормозами. Уж что может быть тормознее жабки?

А может надо было просто забабахать детектор платформы?
Типа

if (i386); {
(i386-специфичное);
} else {
(армоспецифичное); }

А как ты будешь буферы выделять? Считать в байтах от начала до конца нужного куска? Вообще маразм, когда длина в буквах не равна длине в байтах...

Маразм рассуждать о том, что не понимаешь. А ты явно не умеешь писать на С. Никакие буферы выделять не надо, запрос парсится на месте, просто расставляются \0 и сохраняются указатели на начало строк. Ну и плюс делается URL-декодирование, но оно только уменьшает строку, так что опять же никаких дополнительных буферов не нужно, только один исходный.

Ложь. Там просто за тебя сделали платформеннозависимую часть.

А в С типа не сделали. Ты регистры в С видишь? Нет? А действительно ручную работу по запросу участка памяти? Тоже нет? От тебя спрятали все реально платформозависимое и оставили байто%бство? Ну так ты тоже в песочнице сидишь, только без игрушек и с голой жопой.

И это обернулось в итоге жуткими тормозами. Уж что может быть тормознее жабки?

http://benchmarksgame.alioth.debian.org/u32/program.php?test=knucleotide&...

Напиши более быстрый вариант, не стесняйся. А то у других почему-то не вышло.

Ломает. Но обычно так и делают, да.

Напиши более быстрый вариант, не стесняйся

Ты бы хоть написал, что оно делает. Потому как жабокод для меня — как китайская грамота.

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

ты возьми и посмотри. В C++ нет «простого управления памятью», только стековые переменные, для которых вызывается деструктор в момент выхода из области видимости. Вот этот деструктор уже вызывает free(3)/std::delete для памяти в куче. Т.е. получается лишняя (хотя и очень дешёвая) сущность.

Тоже самое у тебя в случае void *p. Это переменная на стеке, которая указывает на адрес в куче.

не, детка, компилятор не будет вызывать деструктор для типа void*.

class unique_ptr

а вот для этого класса — будет. И этот деструктор вызовет ::delete unique_ptr::p. Вот только unique_ptr::p это совсем другой указатель, нежели unique_ptr ::p.

Потому как жабокод для меня — как китайская грамота.

Аглицкий тоже?

http://benchmarksgame.alioth.debian.org/u32/performance.php?test=knucleotide#...

П.С. кстати на первом месте Ada, но у них кода в 4 раза больше чем на С++, который на втором, видно кто-то сильно хотел сделать самый быстрый вариант. Хотя на 4-х ядрах С++ все с тем же кодом уже первый:

http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=knucleotide

А С слил и Go, и Ada, и Rust, и Java. Вобщем хочешь доказать, что С не тормозное говно - у тебя есть такая возможность.

Аглицкий тоже?

Жесть-то какая! Я в биологии вообще нуль. Так что, отстань. А то я тебе сейчас какую-нибудь модель звездных атмосфер предложу...

Жесть-то какая! Я вообще нуль.

Fixed. Вот тебе реализация на perl:

my ($sequence);
$/ = ">";
/^THREE/ and $sequence = uc(join "", grep !/^THREE/, split /\n+/) while <STDIN>;

my ($l,%h,$sum) = (length $sequence);
foreach my $frame (1,2) {
  %h = ();
  update_hash_for_frame($frame);
  $sum = $l - $frame + 1;
  printf "$_ %.3f\n", $h{$_}*100/$sum for sort { $h{$b} <=> $h{$a} || $a cmp $b } keys %h;
  print "\n";
}

foreach my $s (qw(GGT GGTA GGTATT GGTATTTTAATT GGTATTTTAATTTATAGT)) {
  update_hash_for_frame(length($s));
  printf "%d\t$s\n", $h{$s};
}

sub update_hash_for_frame {
  my $frame = $_[0];
  $h{substr($sequence,$_,$frame)}++ foreach (0..($l - $frame));
}

Или все еще слишком сложно и непонятно? Ну извини, тут тебе не школа, никто вдалбливать очевидности не будет.

А ты конкретизируй - где именно их нет.

спросил у коллеги. он вспомнил только wii u. там какой-то дикий компилятор, который умеет только в c++98.

на десктопе (т.е. в редакторе) разрешено использовать C++11, но т.к. никто его не знает - все кодят по привычке на c++98.

upd: нашел табличку в корпоративном wiki, там примерно 3/4 платформ перечислены в списке «не умеют в c++11», в т.ч. current gen консоли. более того, на некоторых платформах даже обычные C++ templates не работают :) последнее обновление списка - конец 2014, так что все вполне актуально.

«не умеют в c++11», в т.ч. current gen консоли

Да ну нах, вот, например:

http://i.piccy.info/i9/1a058a93d4fbda90cb57f335432ff1ce/1426501875/181297/840...

Скорее не платформы не умеют, а писавший табличку, или у него свои критерии.

XDK для xbone не умеет c++11, как и для x360

Ты еще на пыхпыхе напиши =D

xbone

Если имеется ввиду xbox one - там SDK от VS2012 и выше, а там есть поддержка С++11.

x360

Далеко не current gen.

Ты еще на пыхпыхе напиши =D

Так ты ж все-равно не поймешь. Хоть на PHP, хоть на Basic.

Я это к тому, что на кой черт мне эта китайская грамота? Неужто нет блок-схемы алгоритма?

Я это к тому, что на кой черт мне эта китайская грамота?

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

Неужто нет блок-схемы алгоритма?

Задача пошагово расписана по ссылке.

а там есть поддержка С++11.

нет

Далеко не current gen.

угу, но там тоже нет поддержки C++11 (vs2010).

ты возьми и посмотри. В C++ нет «простого управления памятью», только стековые переменные, для которых вызывается деструктор в момент выхода из области видимости. Вот этот деструктор уже вызывает free(3)/std::delete для памяти в куче. Т.е. получается лишняя (хотя и очень дешёвая) сущность.

Не получается никакой лишней сущности. Был тип void * у которого деструктора нет, стал тип std::unique_ptr у которого деструктор есть. Этот деструктор будет встроен, делитер будет встроен и ты получишь тот же самый код. Только ты физически не сможешь случайно пропустить что-то и не удалить память.

не, детка, компилятор не будет вызывать деструктор для типа void*.

Ну и что? Переменная никуда не делась. Просто у void * нет деструктора.

Вот только unique_ptr::p это совсем другой указатель, нежели unique_ptr ::p.

Что?

Задача пошагово расписана по ссылке

Угу, расписана. На китайском языке:

• построчно прочитать перенаправленный со стандартного входа файл формата FASTA (WTF?)
• извлечь последовательность №3 (WTF?) ДНК
• для каждого считанного блока данных определить процедуру/функцию для обновления хеш-таблицы ключей К-нуклеотидов и значений счетчика, даже если придется скомбинировать счетчики К-нуклеотидов для всех считанных блоков (расширяя хеш-таблицу от небольшого начального размера по умолчанию)
• труляля-траляля-непонятно-нихрена

нет

Есть, частичная (таки стандарт тогда по сути только приняли), но вполне достаточная для многих задач. Ну и можно использовать даже Visual Studio 2015 Preview, а там практически все ключевые улучшения С++11 реализованы, и даже частично С++14.

угу, но там тоже нет поддержки C++11 (vs2010).

С 2010 уже можно, например, использовать лямбды, вывод типов, enum class, override, final, nullptr, умные указатели. Собс-но с его выходом мы и начали постепенно переползать на новый стандарт, т.к. нам нужно было собираться и в visual, а он отставал. Хотя как отставал... до принятия стандарта был еще год.

труляля-траляля-непонятно-нихрена

Хорошо, не надо ничего писать, я тебе верю на слово, Java тормозит, а С рулит.

ты уж определись, она есть, или ее нет. частичная — это значит ее нет. к тому же, я тебе писал выше, что на других платформах все еще хуже. намного хуже. там c++98 с трудом парсится (привет нинтенда 3дс!).

ты уж определись, она есть, или ее нет. частичная — это значит ее нет

А, ну тогда и С99 нигде не поддерживается. gcc, например, так и не осилил #pragma STD, а glibc не реализовало все библиотечные плюшки. Про всякие visual и говорить не стоит. Но при этом люди ж используют c99, и даже не просто c99, а еще и с гнутыми расширениями.

я тебе писал выше, что на других платформах все еще хуже. намного хуже. там c++98 с трудом парсится (привет нинтенда 3дс!).

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

gcc, например, так и не осилил #pragma STD

Кстати о прагмах, атрибутах и пр., в С++ наконец-то внесли в стандарт нормальный и единый синтаксис атрибутов:

~$ cat ./test.cpp
#include <cstdio>

[[deprecated("Need to use fucking snprintf")]]
int sprintf( char* str, const char* format, ... );

int main() {
    char buf[10];
    sprintf( buf, "" );
    
    [[gnu::unused]]
    int n;
}
~$ clang++ -Wall -std=c++14 ./test.cpp
./test.cpp:8:5: warning: 'sprintf' is deprecated: Need to use fucking snprintf
      [-Wdeprecated-declarations]
    sprintf( buf, "" );
    ^
./test.cpp:4:5: note: 'sprintf' has been explicitly marked deprecated here
int sprintf( char* str, const char* format, ... );
    ^
1 warning generated.

Мелочь, а приятно.

А, ну тогда и С99 нигде не поддерживается.

угу, в вижуалах его вообще нет. я кстати порылся в интернетиках сегодня, и, похоже, в vs2015 мы его тоже не увидим.

gcc, например, так и не осилил #pragma STD

можно ссылку на описание этого STD? впервые слышу

glibc не реализовало все библиотечные плюшки

угу, и не только glibc. но библиотеки нетрудно допилить, если компилятор рабочий (например, под андроидом bionic аццки урезан, но большинство кода на c99 собирается вообще без проблем, а то чего не хватает можно дописать/притащить из других библиотек). в C++ же проблема в том, что компилятор еще пилить и пилить (MSVC), и код вообще не соберется.

Но при этом люди ж используют c99

из-за отсутствия его поддержки в вижуалах, для игровой индустрии он вообще не годен. или исключать windows/xb360/xbone. для почти любого другого софта можно использовать без проблем.

а еще и с гнутыми расширениями.

они бывают полезны. и их легко завернуть в #ifdefs.

но это же не повод везде и всегда оставаться на старых стандартах.

можно не оставаться. но тогда код не собрать.

грубо говоря, если говорить об играх — то c++98 еще какое-то время будет с нами, а c99, видимо, появится не раньше чем лет через 5 (если вообще появится). в M$, подобно многим лоровским школьникам, считают что C++ это новая версия C, и реализовывать новый стандарт «старой версии C++» не собираются.

а теперь иди и проверь свой нерабочий говнокод. (он заработает тогда, и только тогда, когда компилятор догадается, что 0x80 это unsigned int).

В коде все правильно, сработает integer promotion.

Мелочь, и ненужно.

FTFY

vs2015 мы его тоже не увидим.

Ну вот, а говоришь «хорошая IDE»...

Хех, а при чем тут IDE?

можно ссылку на описание этого STD? впервые слышу

драфт стандарта, там все есть, ищется поиском, вроде 7.-что-то там.

но большинство кода на c99 собирается вообще без проблем, а то чего не хватает можно дописать/притащить из других библиотек). в C++ же проблема в том, что компилятор еще пилить и пилить (MSVC), и код вообще не соберется.

Аналогично - большинство кода на С++11 собирается вообще без проблем, в том числе использующий новые библиотечные функции/классы, например треды. На текущий момент MSVC (2015) умеет уже практически весь стандарт, где-то как раз на уровне С99 в gcc.

Мелочь, и ненужно.

Кто пустил сюда школьника? Быстро отправьте его читать хедеры glibc.

Ну вот, а говоришь «хорошая IDE»...

дык ничего лучше все равно нет.

драфт стандарта, там все есть, ищется поиском, вроде 7.-что-то там.

гугл-поиском не ищется.. ни драфт, ни pragma std.

гугл-поиском не ищется.. ни драфт, ни pragma std.

У тебя китайский гугль, сдай его по гарантии, мой первым же результатом выдал:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

pragma std

Таки pragma stdc, запамятовал, впрочем и так должно было найтись.

На JavaScript реализация быстрее сишной.

Где?

Sample: lorem_1mb.txt (1000205 bytes raw / ~257018 bytes compressed)
 > deflate-dankogai x 7.40 ops/sec ±0.25% (22 runs sampled)
 > deflate-gildas x 7.72 ops/sec ±2.23% (23 runs sampled)
 > deflate-imaya x 6.31 ops/sec ±1.74% (20 runs sampled)
 > deflate-pako x 18.03 ops/sec ±1.16% (49 runs sampled)
 > deflate-pako-string x 14.85 ops/sec ±1.02% (41 runs sampled)
 > deflate-pako-untyped x 8.77 ops/sec ±0.93% (25 runs sampled)
 > deflate-zlib x 24.58 ops/sec ±0.40% (62 runs sampled)
 > inflate-dankogai x 66.88 ops/sec ±0.67% (70 runs sampled)
 > inflate-imaya x 159 ops/sec ±1.28% (85 runs sampled)
 > inflate-pako x 124 ops/sec ±0.62% (80 runs sampled)
 > inflate-pako-string x 60.66 ops/sec ±0.74% (63 runs sampled)
 > inflate-pako-untyped x 77.54 ops/sec ±2.60% (72 runs sampled)
 > inflate-zlib x 199 ops/sec ±1.21% (82 runs sampled)

Чёт нихрена оно не быстрее.

И да, его тест на нфлейт брешит, ибо:

$ time for i in {0..199}; do gzip -d lorem_1mb.txt.gz -c > /dev/null; done

real    0m0.787s
user    0m0.028s
sys     0m0.012s

Сишный же compress2/uncompress у меня выдаёт: 26.477028ops 450.168306ops

И это логично, как минимум потому-что JIT для конкретной железки сможет сгенерировать более эффективный блоб

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

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

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

Опциональные возможности, которые использует v8:

// CPU feature flags.
enum CpuFeature {
// x86
SSE4_1,
SSE3,
SAHF,
AVX,
FMA3,
ATOM,
// ARM
VFP3,
ARMv7,
ARMv8,
SUDIV,
MLS,
UNALIGNED_ACCESSES,
MOVW_MOVT_IMMEDIATE_LOADS,
VFP32DREGS,
NEON,
// MIPS, MIPS64
FPU,
FP64FPU,
MIPSr1,
MIPSr2,
MIPSr6,
// ARM64
ALWAYS_ALIGN_CSP,
COHERENT_CACHE,
// PPC
FPR_GPR_MOV,
LWSYNC,
ISELECT,
NUMBER_OF_CPU_FEATURES
};

Если у тебя есть еще фантазии - не стесняйся.

Так уж и быть - как мне будет не лень я напишу тебе реальный сишный код

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

Куллстори, только вот не гинерирует.

А если ты имел ввиду именно конечную скорость, вот тебе тоже задачка:

http://benchmarksgame.alioth.debian.org/u32/performance.php?test=regexdna

Если не балабол, обгони v8. Покажи скил.