Двач.hk не отвечает.
Вы видите копию треда, сохраненную 8 июля 2016 года.

Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
78 Кб, 792x1023
C Programming Language #7 # OP #749121 В конец треда | Веб
Тред, посвященный прародителю всех С-подобных языков и по совместительству единственному идеальному и всесторонне годныму средству программирования как на системном, так и на прикладном уровне.

Что читать:

- Классика от Отцов: http://www.ime.usp.br/~pf/Kernighan-Ritchie/C-Programming-Ebook.pdf
- Годное пособие для гуманитариев: http://c.learncodethehardway.org/book/
- Немного примеров хорошего стиля: http://www.oualline.com/books.free/style/index.html
- ООП, например: http://www.cs.rit.edu/~ats/books/ooc.pdf
- Стандарт ISO/IEC 9899:1999 (он же C99): http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf (драфт) не драфт ищем на торрентах
- Стандарт ISO/IEC 9899:2011 (он же C11): http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf (драфт)
- man/Dash/zealdocs

Чем конпелировать:

- Очевидный GCC.
- clang: оче годно, батя рекомендует. Дрочим на --analyze.
- Intel C++ Compiler: оптимизации, тысячи их.
- Visual Studio 2015 Community Edition: внезапно этим стало можно пользоваться, особенно с тулсетом clang/C2. Поддержка C11 на уровне "есть все, что тебе понадобится в реальном проекте плюс кривая библиотека". Анализатор кода в комплекте.
- Pelles C (шиндоуз онли): поучиться, вкатиться в C11 (стандарт полностью реализован, имеются в том числе threads.h и прочие stdatomic.h), но количество багов в оптимизаторе и редкие апдейты напрочь отбивают желание собирать этим что-то сколько-нибудь серьезное.
- TCC: очень маленький компилятор с багами и неполной поддержкой C99. С ключом -run умеет компилировать код в память и запускать его, что позволяет писать скрипты прямо на сишечке.

Что еще почитать:

http://c-faq.com/
FAQ из comp.lang.c. Древний, но все еще актуален.

Stephen Prata "C Primer Plus, 6th Edition" (2014)
Свежая знает про C89, C99, C11, описывает различия, объемная около тысячи страниц, годная хотя есть некоторые шероховатости, с вопросами, упражнениями и ответами. Читать после K&R или до.

Samuel P. Harbison, Guy L. Steele Jr. "C: A Reference Manual, 5th Edition" (2002)
Ебаный пересказ стандартов C89 и C99 (включая стандартную библиотеку). Для не осиливающих стандарт в оригинале. Читать в качестве подготовки к собеседованиям (есть задачник с ответами) и для ознакомления с масштабами пиздеца перед написанием своего парсера/компилера.

Peter Van Der Linden "Expert C Programming. Deep C Secrets" (1994)
"Си: грязные истории". Смехуечки, немного объяснений, чем обусловлены особенности языка, всем известные подводные камни кто там ругал косяки в JS? у нас в сишечке их гораздо больше, просто они лучше спрятаны, немного байтоебли и непонятно откуда взявшаяся глава про старинные плюсы. Читать в качестве сказки на ночь (на пару вечеров хватит).

Ben Klemens "21st Century C: C Tips from the New School" (2012)

Stephen G. Kochan "Programming in C (3rd Edition или 4th Edition, если найдется)" (2014)

MISRA Ltd. "Guidelines for the Use of the C Language in Critical Systems" (2013)
Набор рекомендаций по написанию надежного кода на C (промышленный стандарт). Читать - однозначно, следовать - вдумчиво и без фанатизма. Также можно посмотреть https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard

Еще более длинный список: http://www.iso-9899.info/wiki/Books#Learning_C

Прошлые треды:

- https://arhivach.org/thread/106153/
- https://arhivach.org/thread/131949/
- https://arhivach.org/thread/140570/
- https://arhivach.org/thread/153698/
- https://arhivach.org/thread/155908/
- https://arhivach.org/thread/173837/

Шапка: http://piratepad.net/bJ1SdmkZyu
>>749562>>761448>>767837
#2 #749562
>>749121 (OP)
А в природе встречаются переводы стандартов? А то, май инглиш соу бэд.
>>749578
#3 #749578
>>749562
Для их чтения ингриш знать-то и не надо. Точнее их вообще читать не стоит
>>749744
#4 #749744
>>749578
Вот уж нихуя, ещё как стоит.
>>749750
#5 #749750
>>749744
Зачем? Си простой как палка.
Можешь стандарт крестов там почитать если совсем делать нехуй.
>>750044>>750064
#6 #750044
>>749750
Да и у крестов стандарт лексически не сильно сложнее. Там реально достаточно знать порядка ста баззвордов и словосочетаний, типа if X, program is ill-formed. На 0.99 стандарт состоит из этих фраз, а вся сложность в нихуевом объеме и неестественно-буквоедском порядке утверждений.
>>750064>>750069
#7 #750064
Почитал бы полезные выжимки из MISRA.
>>750044
>>749750
Долбоебы знание языка - это 10-30%.
Остально - сопутствующие технологии, будь то контроллеры, система или прикладные либы типа stl или boost, раз уж вы крестах.
>>750069
#8 #750069
>>750044
там вся сложность в том, что это на 1,5+к страниц размазано.

>>750064
Долбоёб только ты, от меня это был сарказм.
#9 #751839
Есть профи по OPC и COM?
>>754757
#10 #752368
Смотрите какой охуенный сайт:
http://cdecl.org/
>>752515
#11 #752375
А есть ли какая-нибудь синтаксическая оберка для работы с указателями? Я пока все время путаюсь, где у меня поинтер, где разыменование поинтера, где ссылка и т.д. Нет ли того же самого, только в функциональной обертке? Чтобы функции имели бы человекочитаемые имена?
>>752389
#12 #752389
>>752375
Что там непонятного, наркоман?
&yoba - адрес переменной yoba
ptr - содержимое по указателю (адресу) ptr
mamka_c_blyadi->anus - альтернативный синтаксис для (mamka_c_blyadi).anus
>>752390
#13 #752390
>>752389

> ×ptr - содержимое по указателю (адресу) ptr


> mamka_c_blyadi->anus - альтернативный синтаксис для (xmamka_c_blyadi).anus


Опять разметка проебалась, раньше звездочки постились.
#14 #752515
>>752368
Он кривой - не хавает половину валидных объявлений (может уже и пофиксили, хуй знает).
#15 #754083
Подскажи Анон. Можно ли в си определить литерал функции и передать его в качестве аргумента другой функции?
>>754087>>754166
#16 #754087
>>754083
Можно.
>>754089
#17 #754089
>>754087
как?
>>754090
#18 #754090
>>754089
Напиши пример.
#19 #754092
Попробуй загуглить для начала.
https://www.google.ru/search?q=c+function+as+argument&ie=UTF-8&oe=UTF-8&hl=ru-ru&client=safari
>>754098
#20 #754098
>>754092
Мой вопрос внимательно прочитал?
>>754166
#21 #754166
>>754083
>>754098

> Мой вопрос внимательно прочитал?



Я не он, но что не так-то? Функции в Си только в виде константных литералов и существуют, без кодогенератора ты функцию в рантайме не создашь, существующую изменять не имеешь права, а анонимных функций пока нет, поэтому передавай указатель на функцию и не выделывайся. Или задай правильный вопрос: опиши, чего ты хочешь добиться, а не то, как ты хочешь этого добиться.
>>754170
#22 #754170
>>754166
Видимо не корректно задал вопрос.
Выкрутился так
printf ( "%12.12s ", ({ long tmp=current_record.ut_time; ctime(&tmp);
↪ }) );
>>754210>>755785
#23 #754202
http://hastebin.com/bupideteje.coffee
Почему-то пару раз работает потребитель и все останавливается.
не лаба, для себя

Кто-то может помочь или подтолкнуть на правильную мысль?
>>754366>>754823
#24 #754210
>>754170
Я бы не постеснялся подготовить данные перед printf и объявить переменную. А ты можешь сделать чуть более читаемо, если у тебя современный стандарт и есть compound literals:
printf("%12.12s ", ctime(&(time_t) { c }));
#25 #754237
Что вы пишете на Си в 2016 году?
Я бы тоже хотел перекатиться в сишечку с ерланга и жс, но ума не приложу чтобы такого написать.
Крудошлепство и жс засели глубоко в мозгах
>>754290>>769730>>769732
#26 #754290
>>754237
Всё, что будет тормозить на эрланге выносить в сишные модули – стандартная практика например.
>>754347
#27 #754299
как передать аргументом в функцию массив не из char-ов как константу ?

то есть все то же самое что

function(char massive[]);

function("\x10\x20\x30");

а я хочу

function(int massive[]);

function({0x10,0x20,0x30});

но такого синтаксиса в си нет, а как надо ?
>>754300>>754304>>754305
#28 #754300
>>754299

fix как литерал
#29 #754304
>>754299

бля

function(int massive[]);

function([0x10,0x20,0x30]);

ну вот так короче я хочу
>>754314
#30 #754305
>>754299
Чем указатель плох?
>>754312
#31 #754312
>>754305

мне не нравится что с массивами char такая хуйня прокатывает а с массивами int нет. я пока сделал через приведение типов но это выглядит погано и работает не лучше. я не хочу каждый раз инициализировать массив отдельно для передачи нескольких байтов в функцию.
#32 #754314
>>754304
void f(vector<int> v) {}

vector<int> v = {0x10,0x20,0x30};
f(v);
>>754321>>754327>>754333>>754821
#33 #754321
>>754314
Или чисто для С:

void f(int * arr) {}

f((int []){1,2,3,4});
>>754338>>754821
#34 #754327
>>754314
1) для статических завезли std::array;
2) Не. Копируй. Сука.
>>754333
#35 #754333
>>754314
я на микроконтроллере пишу крестов туда не завозили
>>754327
а я не пишу, я передаю указатель на константу(мразь)
>>754354
#36 #754338
>>754321

клева, спасибо
#37 #754347
>>754290
а у меня нечему тормозить. Я пишу распределенные отказоустойчивые круды.
Хочется чего нить близкого к железу. чтобы прям low layer
>>754349>>754354
#38 #754349
>>754347
Ну так бери ардуину и пиши себе лампы настроения на Си.
#39 #754354
>>754347
Имидж процессинг напиши на эрланге, который на сотне нод тормозить не будет.

>>754333
Ты вообще кто?
#40 #754366
>>754202

>


Бамп
>>754819
#41 #754757
>>751839
что надо то?
#42 #754819
>>754366
По твоей ссылке нихуя нет. Браузеры рапортуют об ошибке в регэкспе где-то в недрах хайлайтера из-за неверной кодировки.
#43 #754821
>>754314
>>754321
ебанутые
#44 #754823
>>754202
Перепиши заново
#45 #755749
Посикаем в этом треде Кернигану и Ритчи в ротешник:
http://russian.joelonsoftware.com/Articles/BacktoBasics.html
>>755772>>755795>>769741>>769744
sage #46 #755772
>>755749
Не совсем понял, что не нравится лично тебе. ASCIIZ универсальны, они работают для любой длины, хоть в пару терабайтов. Для тех времен, когда создавался язык, они стали отличным решением - байтики приходилось экономить, и делать паскалевые строки сразу 32-битным (да и 16-битным тоже) счетчиком было расточительно, а городить зоопарк из строк с разными размерами префиксов (как в каком-нибудь паскале) - глупо.
Тебе никто не мешает, начитавшись Джоэла, запилить строки, которые тебе нравятся. Можешь сделать паскалевые, можешь гибридные с ASCIIZ и счетчиком одновременно, можешь добавить в заголовок еще и плюсовые capacity и allocator, можешь хранить все это добро по отрицательному индексу, чтобы строки казались обычными ASCIIZ для всего остального мира, можешь хранить целиком, можешь кусками в связанном списке - все зависит от твоих требований. И, конечно же, ты можешь запилить свою собственную либу для работы со строками: безопасную, быструю, понимающую UTF-8 выбери одно из трех.
#47 #755785
>>754170

>printf ( "%12.12s ", ({ long tmp=current_record.ut_time; ctime(&tmp);}) );


Что это за конструкция? Впервые вижу подобное. Мы типа делаем скоуп на месте аргумента? Это вообще по стандарту? Что загуглить, чтобы про это почитать?
>>755793
#48 #755793
>>755785
Не по стандарту. Это расширение гцц: https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html
#49 #755795
>>755749

>Почему строки в языке C так работают? А потому что микропроцессор PDP-7, на котором разрабатывались UNIX и C, имел такой строковый тип ASCIZ. ASCIZ означало "ASCII с нулём (zero) на конце."


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


>наихудший способ хранить строки


>наихудший



[CODE]
2.1. The size of an array is part of its type

If one declares

var arr10 : array [1..10] of integer;
arr20 : array [1..20] of integer;

then arr10 and arr20 are arrays of 10 and 20 integers respectively. Suppose we want to write a procedure 'sort' to sort an integer array. Because arr10 and arr20 have different types, it is not possible to write a single procedure that will sort them both.

The particular data type most often affected is 'array of char', for in Pascal a string is an array of characters. Consider writing a function 'index(s,c)' that will return the position in the string s where the character c first occurs, or zero if it does not. The problem is how to handle the string argument of 'index'. The calls 'index('hello',c)' and 'index('goodbye',c)' cannot both be legal, since the strings have different lengths. (I pass over the question of how the end of a constant string like 'hello' can be detected, because it can't.) The next try is

var temp : array [1..10] of char;
temp := 'hello';

n := index(temp,c);

but the assignment to 'temp' is illegal because 'hello' and 'temp' are of different lengths.

The only escape from this infinite regress is to define a family of routines with a member for each possible string size, or to make all strings (including constant strings like 'define' ) of the same length.
[/CODE]

https://www.lysator.liu.se/c/bwk-on-pascal.html
#49 #755795
>>755749

>Почему строки в языке C так работают? А потому что микропроцессор PDP-7, на котором разрабатывались UNIX и C, имел такой строковый тип ASCIZ. ASCIZ означало "ASCII с нулём (zero) на конце."


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


>наихудший способ хранить строки


>наихудший



[CODE]
2.1. The size of an array is part of its type

If one declares

var arr10 : array [1..10] of integer;
arr20 : array [1..20] of integer;

then arr10 and arr20 are arrays of 10 and 20 integers respectively. Suppose we want to write a procedure 'sort' to sort an integer array. Because arr10 and arr20 have different types, it is not possible to write a single procedure that will sort them both.

The particular data type most often affected is 'array of char', for in Pascal a string is an array of characters. Consider writing a function 'index(s,c)' that will return the position in the string s where the character c first occurs, or zero if it does not. The problem is how to handle the string argument of 'index'. The calls 'index('hello',c)' and 'index('goodbye',c)' cannot both be legal, since the strings have different lengths. (I pass over the question of how the end of a constant string like 'hello' can be detected, because it can't.) The next try is

var temp : array [1..10] of char;
temp := 'hello';

n := index(temp,c);

but the assignment to 'temp' is illegal because 'hello' and 'temp' are of different lengths.

The only escape from this infinite regress is to define a family of routines with a member for each possible string size, or to make all strings (including constant strings like 'define' ) of the same length.
[/CODE]

https://www.lysator.liu.se/c/bwk-on-pascal.html
#50 #755902
Есть два почти одинаковых кода, разница в функции undef отмечена восклицательными знаками:

https://ideone.com/5NvTMI Почему-то крашится на идеоне, хотя нормально запускается в консоли линукса и в дебаггере студии.

https://ideone.com/CZ7nTT Тут все ровно наоборот. Сначала освобождаю память, выделенную под ноду списка, а потом освобождаю поля этой ноды. Но почему этот код работает? Ведь когда нода освобождена, к ней нельзя обращаться. И еще странный эффект: если код оставить таким же, но освободить только ноду, а не каждое ее поле, то вот эта строчка все равно выведет корректные данные:

if (lookup("H") != NULL)
printf ("%s\n", lookup("H")->defn);

Почему так? Ведь данной ноды в этот момент уже не должно существовать.
>>755909>>755967>>756051
#51 #755909
>>755902
Блять, какого хуя этот код работает в студии, но крашится, если компилировать gcc?
>>755967
#52 #755967
>>755902
>>755909

> какого хуя


Во-первых, в строке 45 в install() ты закольцовываешь связный список, хотя по идее должен в next записать NULL. Во-вторых, если ты удаляешь первый элемент в цепочке, то после free() в undef() у тебя остается "висячий" указатель на него из hashtab, и при первом же lookup() ты по нему идешь с очевидными последствиями. Я бы сделал last указателем на указатель на nlist (на элемент в бакете сначала, а потом на next предыдущего элемента), тогда это красиво решается без дополнительных условий.

Алсо в install касты перед malloc() и в free() не нужны. А вот при сфэйлившемся strdup() теоретически неплохо было бы сделать free(), иначе будет утечка памяти. И в ветке else есть теоретическая вероятность оставить defn равным NULL. Алсо для указателей в printf у нас есть %p. Но это придирки.

> если ... освободить только ноду ... то вот эта


> строчка все равно выведет корректные данные


Ты просто не должен ходить по указателю после free(), иначе будет UB. А undefined behavior в данном случае то, что в зависимости от компилятора и условий менеджер кучи не повреждает данные по указателю (а может и затирать служебными данными, а может затирать частично, а может вообще не трогать очень долго, до очередного malloc с запросом точно такого же объема памяти).
>>755980>>761456>>761533
#53 #755980
>>755967

>Во-первых, в строке 45 в install() ты закольцовываешь связный список, хотя по идее должен в next записать NULL


Это вставка нового элемента в голову списка, а не закольцовывание.
>>755983
#54 #755983
>>755980

> Это вставка нового элемента в голову списка, а не закольцовывание.


Да, ты прав, прошу прощения.
#55 #756051
>>755902
Как будто поправил. Сегфолт возникал в функции поиска по таблице, когда элемента там не было из-за того, что некорректно удалялся элемент списка. Это происходило в том случае, когда в списке только один элемент. Для обработки этого случая написал костыль: https://ideone.com/pdUGr0
Вроде, в книгах по структурам данных так и делается удаление.
>>756074
#56 #756069
Прога отказывается работать. Задача : скопировать текст из одного файла в другой, рекурсивно заменяя include<filename.txt> на содержимое этого файла.
Код http://pastebin.com/2xMWD0jy
Три файла внутри( копировал в спешке, извиняюсь)
Файл с функцией, тест1 и функция.h
Выдача gcc:
test1.c: В функции «main»:
test1.c:7:1: ошибка: passing argument 1 of «reshift» discards «const» qualifier from pointer target type
if(0==reshift("input.txt", "output.txt", 1))
^
In file included from test1.c:4:0:
realezat.h:3:5: замечание: expected «char » but argument is of type «const char »
int reshift(char in[], char out[], int n);
^
test1.c:7:1: ошибка: passing argument 2 of «reshift» discards «const» qualifier from pointer target type
if(0==reshift("input.txt", "output.txt", 1))
^
In file included from test1.c:4:0:
realezat.h:3:5: замечание: expected «char » but argument is of type «const char »
int reshift(char in[], char out[], int n);
>>756132>>756137>>756374
#57 #756074
>>756051

> return


Так ты памятью течешь и похериваешь список заодно. Кто curr-то освобождать будет? Что будет, если в hashtab[hashval] цепочка из более чем одного элемента? Я тебе вот такой костыль предлагал: https://ideone.com/lRjUri
>>756085
#58 #756085
>>756074

>Что будет, если в hashtab[hashval] цепочка из более чем одного элемента?


Блять, действительно. Я имел в виду, что список должен быть из единственного элемента, а мое условие выполняется, когда нужное значение хранится в первом элементе. И про free тоже забыл.
#59 #756132
>>756069
Ну бамп вопросу.
#60 #756137
>>756069

> прога отказывается работать



(Код не осилил). Предупреждениями GCC тебе какбэ напоминает, что строковые литералы у нас константные. Дальше, если тебе нужно рекурсивно заменять, то назачем ты затираешь выходной файл при каждом вызове reshift()? Открой его один раз в main. Почему у тебя buf2 так интересно инициализируется, я тоже не понял.

Можешь сделать просто: считал весь файл в память, нашел с помощью strstr() вхождение "include<", записал в выходной файл все, что до вхождения (или до конца, если "include<" больше нет). Нашел strchr() '>', поимел имя файла, пошел в рекурсию, после возврата пошел снова strstr() после '>' искать "include<". Все. Один цикл.

Можно читать кусками или читать fgetc(), но там уже придется обрабатывать всякие интересные ситуации. Если у тебя include<> в начале строки (как в самой сишечке), то все еще проще.
>>756217>>756235>>756385
#61 #756217
>>756137
Спасибо, твой метод реально легче, strstr-то что нужно, так и реализую, но не понял фразу насчет константных литералов.
>>756361
sage #62 #756235
>>756137

> насчет константных литералов


Строка в кавычках, как "input.txt" - это строковый литерал, его нельзя изменять. Поэтому когда ты его передаешь в reshift(), соответствующий указатель должен быть const char ∗, а не char ∗.
Алсо, можно так: https://ideone.com/L2VPc3 В принципе, тот же цикл, только strstr самодельная и выполняется во время посимвольного чтения файла.
>>756385>>761903
#63 #756361
>>756217
Это лаба? Если нет, можно нагуглить препроцессор на C, fcpp к примеру, и воспользоваться им. Просто парсинг C-файла не тривиальная задача. Однострочные и многострочные комментарии, include на одной строке, сам файл на другой.
>>756376
#64 #756374
>>756069

Давай попробуем.

#include <stdio.h>
#include <string.h>

#define STRING_LEN 4096

int main(void) {
FILE a, b;
char cw, cr, include[9] = "include<", fnameb[1024];
int i, n, cp;

a = fopen("1.txt", "w+");

while(!feof(fp))
{
cw = fgetc(a);
i = 0;
//А не считывается ли у нас "инклюде<"?
while(!feopf(fp) && cw == include)
{
cw = fgetc(a);
i++;

if(i == 8)//Нашоль инулюде!
{
n = 0;
//Копирую имя файла
while(!feopf(fp) && cw != '>' && i < 1024)
{
cw = fgetc(b);
fnameb[n] = cw;
n++;
}
fname[n + 1] = '\0';
cp = ftell(a) - (n + 8);//Становлюсь на начало слова инклюд в файле
fseek(a, cp, SEEK_SET);
}
}
//На этом поиск инвазивного файла завершён, открываю его и вставляю
b = fopen(fnameb, "r+");
i = 0;
while(!feof(a) && !feof(b))
{
cr = fgetc(b);//Беру символ инвазивного файла
cw = fgetc(a);//И символ инвазируемого
//И меняю их местами
fputc(cr, a);
fputc(cw, b);
i++;
}
//А теперь восстанавливаю инклюд
fseek(a, cp, SEEK_SET);
fseek(b, 0, SEEK_SET);
while(i > 0)
{
fgetc(a);
fputc(b);
i++;
}
}

return 0;
}
#64 #756374
>>756069

Давай попробуем.

#include <stdio.h>
#include <string.h>

#define STRING_LEN 4096

int main(void) {
FILE a, b;
char cw, cr, include[9] = "include<", fnameb[1024];
int i, n, cp;

a = fopen("1.txt", "w+");

while(!feof(fp))
{
cw = fgetc(a);
i = 0;
//А не считывается ли у нас "инклюде<"?
while(!feopf(fp) && cw == include)
{
cw = fgetc(a);
i++;

if(i == 8)//Нашоль инулюде!
{
n = 0;
//Копирую имя файла
while(!feopf(fp) && cw != '>' && i < 1024)
{
cw = fgetc(b);
fnameb[n] = cw;
n++;
}
fname[n + 1] = '\0';
cp = ftell(a) - (n + 8);//Становлюсь на начало слова инклюд в файле
fseek(a, cp, SEEK_SET);
}
}
//На этом поиск инвазивного файла завершён, открываю его и вставляю
b = fopen(fnameb, "r+");
i = 0;
while(!feof(a) && !feof(b))
{
cr = fgetc(b);//Беру символ инвазивного файла
cw = fgetc(a);//И символ инвазируемого
//И меняю их местами
fputc(cr, a);
fputc(cw, b);
i++;
}
//А теперь восстанавливаю инклюд
fseek(a, cp, SEEK_SET);
fseek(b, 0, SEEK_SET);
while(i > 0)
{
fgetc(a);
fputc(b);
i++;
}
}

return 0;
}
>>756385
#65 #756376
>>756361
ХЗ, что такое лаба, мне на ЭВМ такую задачу на зачет дали.
>>756389
#66 #756385
>>756137
>>756235
>>756374
Вы вернули мою веру в человечество, все понял, в теме разобрался спасибо.
#67 #756389
>>756376

>ХЗ, что такое лаба


Лабораторная работа.
>>756395
#68 #756395
>>756389
Ситуация не прояснилась, я такое только на уроках физики делал.
>>756433
#69 #756433
>>756395
на физике лабы делают с помощью проводов ключей и лампочек, в прогаммаче, клавиатуры и блокнота.
#70 #756607
Ребята, кто-нибудь ещё пишет в 2016 на C89? Если да, то поясните свой выбор. Всякий легаси код не считается.
>>756629>>756631
#71 #756629
>>756607
Эмбед.
#72 #756631
>>756607
На C89 пишут зрелые программисты, скептически относящиеся ко всему новому и еще когда нужна максимальная кроссплатформенность, хотя в последние годы этот довод подрастерял силу. Например, в коде fossil или sqlite до сих пор фанатично искореняются любые намеки на C89.
>>756632
sage #73 #756632
>>756631

> намеки на C89


*на C99, конечно же
88 Кб, 630x408
#74 #756639
Что такое "шестой класс памяти" на пикрилейтед? Гугл не помогает.
>>756652>>756674
#75 #756652
>>756639
Классы памяти: локальная, статическая, глобальная, регистровая , константа?, да?
Хуй знает почему пойнтер - ШЕСТОЙ. Откуда это?
>>756659
23 Кб, 730x171
#76 #756659
>>756652
Спасибо тебе.

> Откуда это?


С муука мейл.ру.
#77 #756674
>>756639
А пятый-то какой?
>>756675>>756687
#78 #756675
>>756674
Статическая тоже делится на локальную и глобальную
>>756676
#79 #756676
>>756675
Нет. Есть внешняя (extern), есть автоматическая, какбы есть регистровая, а вся остальная статическая. Это не про видимость.
>>756677
#80 #756677
>>756676

https://ru.wikipedia.org/wiki/Класс_памяти

> Класс памяти переменной (англ. Storage class) — понятие в некоторых языках программирования. Он определяет область видимости переменной, а также как долго переменная находится в памяти.

>>756687
#81 #756687
>>756677
Да, класс памяти определяет область видимости. А в дополнение к нему область видимости определяется расположением самой переменной. Алсо, стандарт не согласен с нами обоими, предпочитая разделять "storage duration", "scope" и "linkage", заодно намекая, что я >>756674 забыл про динамически выделенную память.
#82 #756867
Правильно ли я понимаю, что структуры, классы, методы внутри классов не порождают никакого ассемблерного кода до тех пор пока не начинают явно использоваться в программе?
>>756873>>756973
#83 #756873
>>756867
если ты про исполняемые команды то да, они их не порождают, но их описание(объявление) занимает память.
>>756894
#84 #756894
>>756873
Спасиб. Действительно, если метод класса ни разу не вызвать, то для него и код не сгенериться.

Нашел в студии строку Address в Disassembly Window. Раньше ее не видел. Можно переходить по адресу FooStruct::BarMethod, FooStruct::operator= и т.д.
#85 #756973
>>756867
Зависит от параметров компилятора,если -O0, то занимает любое, даже не используемое объявление, можешь проверить в дебагере.
#86 #757449
Решил написать компилятор С на С. Подсильно ньюфагу?
>>757451>>757499>>757555
#87 #757451
>>757449
по-моему только так и стоит вкатываться в си
#88 #757461
На что влияет длина ключа в RC4?
Это же просто xor с псевдослучайной последовательностью, которая один хуй через 128 байт повторяется.
>>757488
#89 #757488
>>757461
По ключу генерируется s-box.
#90 #757499
>>757449
Калькулятор разбирающий и считающий цепочки выражений хотя бы напиши для начала.
>>757547
#91 #757547
>>757499
Польскую нотацию мы в 5-м классе проходили.
>>757574
#92 #757555
>>757449
Правильный компилятор, который знает обо всех тонкостях стандарта и одинаково хорошо со всеми ими справляется? Нет, не осилишь чтобы осознать это, попробуй просто прочитать весь стандарт. Упрощенный компилятор чего-то, что внешне похоже на C - задача не совсем для ньюфага, но если упорства хватит, вполне выполнимая.
>>757559
#93 #757559
>>757555
Чел с хабра за 40 дней написал полностью по стандартам.
>>757563
#94 #757563
>>757559

> Чел с хабра


> Rui Ueyama


Он был ньюфаг? Ты читал его девлог? Спойлер: не за 40 дней. И вообще, ознакомься, занимательно. И непофикшенные баги там до сих в ассортименте. И если дело дойдет до тонкостей, вылезет еще дофига всего.
>>757565>>757637
#95 #757565
>>757563
Да, чет я обосрался.
#96 #757574
>>757547
Дык суть в том, чтобы научится составлять AST и парсить выражения на примере полегче, а не в смене порядка цифр и знаков.
sage #97 #757637
>>757563
Алсо, поясню за уровень тонкостей, про которые я говорил. Минимальный пример (да, он ебанутый, зато минимальный!): http://ideone.com/Z5v4Gh скомпилируется любым обычным компилятором, и сфэйлится в 8cc, потому что там _Pragma по каким-то причинам стала макросом, а не оператором. На этой фазе трансляции макросы уже заменяются, а ключевых слов, в том числе и именованных операторов (за исключением defined) еще не существует.
#98 #757818
Подскажите ламповых стилей для Nano.
#99 #758095
Помогите разобраться с fopen
http://all-ht.ru/inf/prog/c/func/fopen.html
А именно с a+
Абсолютно не понятно как работает. Программа выглядит так
Открыть с а+ выходной файл, открыть первый инпут файл, печатать в выходной до середины, открыть с а+выходной файл и окрыть для чтения второй инпут, печать весь в выходной, допечатать первый(рекурсивный вызов).
В результате получаю в выходном:
весь текст второго\n
весь текст из первого.
Что не так и как исправить?
>>758099>>758190
#100 #758099
>>758095
условно выглядит вот так
[code]
int fuckgoogle(const char in)
{
char c;
FILE input=fopen(in, "r");
FILE *output=fopen("output.txt", "a+");
while((c=getc(in))!='i')//печатаем до знака "i" к примеру
{
fprintf(output, "%c", c);
}
fuckgoogle(filename);//filename получен во время печатанья первого файла(да, я тот анон с парсингом)
while((c=getc(in))!=EOF)
{
fprintf(output, "%c", c);
}
}
[/code]
>>758100>>758116>>758121>>759567
#101 #758100
>>758099
Сорри за разметку.
Если первый файл имеет вид
(-----i____)
а второй ()
то на выходе я получаю (
-----____)
а должен (------_____)
i так и должна пропадать
>>758101
#102 #758101
>>758100
Мда,
Если первый файл имеет вид
(-----i____)
а второй ()
то на выходе я получаю (/////////*
-----____)
а должен (------_____)
>>758103
#103 #758103
>>758101
Вместо // подставтье звездочки
Порядок следования правильный, то звездочки черточки идут в правильном порядке. То есть это не обратная печать.
#104 #758116
>>758099
Вы посмотрите, куда этот пошёл спрашивать свои ответы: https://otvet.mail.ru/question/190885445
>>758120
#105 #758120
>>758116
Бля, ну ты меня затролил, давайте всем двачем набижим и посмеемся, как хорошо, что есть такие детективы как ты, защищающие двач от рака. Хотя погодите ка...
#107 #758122
>>758121
Пиздец, он еще и пруфы принес, там же видно что я первокурсник с мехмата. Ах, да, я не особо то это и скрывал.
#108 #758140
Парни, отбой, я вам покушать принес супер эзотерического кода(там реально оченьстранная реакция).
http://pastebin.com/xY38erAD это файл reshift.c
http://pastebin.com/aHWSSwee это файл test.c
http://pastebin.com/4iagN99N это realezat.h
Задача, рекурсивно заменить в текстовике инклюд<имя файла> на текст из имя файла
Структура слудующая, в тесте содержится майн, создается два массива, один для хранения символов, второй из одного эл-та для хранения числа эл-ов в первом массиве(не бейте). Все это рекурсивно передается в reshift.c где массив преобразовывается. Затем в майне массив перепечатывается.
Внимание магия. Если во входных данных содержитсябуква i, то все будет нормально, кроме этой самой буквый ай, которая превратится во что угодно(от буквы o, до иероглифа вопроса). пример входных файлов и выдачи: http://pastebin.com/3U403Ryy
>>758189>>758190>>758323
#109 #758189
>>758140
Сам нашел, если мы не добрали инклуд, то запись производилась из пустого массива, а не из префикса.
sage #110 #758190
>>758095
FILE умеет в буферизацию ввода/вывода и по умолчанию ее делает. И буфер там от 256 символов. Все буферизируется, а пишется тот, который первым сказал fclose(). И даже если бы ты расставил fflush() правильно, открытие файла на запись одновременно несколько раз - это пиздец в любом случае, никогда так не делай.

>>758140
Боже. А надо было всего-то putchar на fputc заменить.
#111 #758196
Встретил в одном коде подобное объявление (в качестве примера):
extern void TROLOLO_DLL sampleFunction();

Всегда считал что пишется так:
(спецификатор)(тип)(имя функции())

Но что значит вот это вот TROLOLO_DLL не понятно? Причём что характерно везде где есть спецификатор extern пишется дополнительное слово.
>>758203
sage #112 #758203
>>758196
Очередность следования - это вопрос стиля, стандарт порядок следования не определяет. Всякие static const int foo = 1 и int const static foo = 1 воспринимаются компилятором одинаково (конечно, не в случае всяких указателей и массивов).
А насчет TROLOLO_DLL - это макрос. Он где-то определен как __declspec(export) расширение Microsoft, которое позволяет сразу, без .def-файла поместить имя в таблицу экспорта, когда собирается DLL. Или он просто задел на будущее, чтобы потом не ходить и не менять объявления всех экспортируемых функций, если захочется что-то подобное сделать.
>>758211
#113 #758211
>>758203
Спасибо дружище! Точно так и есть.
#114 #758323
>>758140
Новые приколы, реалоки теперь херят все, помогла замена на малоки. В общем жесть
>>758374
#115 #758374
>>758323
Там половины пасты нет, но ты так и не объяснил, зачем тебе вообще выделять память. Я сходу могу придумать только один повод что-то буферизировать вручную - если тебе нужно, чтобы работало нечто вроде:
input.txt: incinclude<input2.txt><input3.txt>
input2.txt: lude
input3.txt: hello, world!
>>758470>>761456
#116 #758470
>>758374
Рекурсивная замена, именно это мне и нужно.
58 Кб, 400x367
#117 #758687
Поздравляю местных синьоров с сезонным схебом школьников из треда
#118 #758692
С машинным языком, любая комбинация байтов производимая обезьянами будет принята и запущена. Но в высокоуровневых языках, высоко ценится то, что компилятор способен обнаружить лексические и грамматические ошибки. Многие программы будут просто отвергнуты, а обезьяны останутся без бананов, зато остальные будут иметь больше шансов быть осмысленными. Проверка типов обеспечивает еще один барьер против бессмысленных программ. Кроме того, в то время как в динамически типизированных языках несоответствия типов будут обнаружены только во время выполнения, в строго типизированных статически проверяемых языках несоответствия типов обнаруживаются во время компиляции, что отсеивает множество некорректных программ, прежде чем у них есть шанс быть запущенными.

Итак, вопрос в том, хотим ли мы, чтобы обезьяны были счастливы, или создавать корректные программы?
>>758701>>758762>>758768
#119 #758701
>>758692

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


У тебя крайне странные представления о коде.
#120 #758754
местные ваннаби синьоры, как через linq грамотно проверить строку почтой на наличие определенного домена?
#121 #758762
>>758692

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


http://wiki.osdev.org/Exceptions#Invalid_Opcode
#122 #758768
>>758692

>в строго типизированных статически проверяемых языках несоответствия типов обнаруживаются во время компиляции, что отсеивает множество некорректных программ



А ты в курсе, что строго типизированные статически проверяемые языки не эквивалентны машине Тьюринга, а беднее её?
#123 #759254
Как такое на си въебать?
https://ideone.com/dgrbax
>>759319
sage #124 #759319
>>759254

> Ну зделойте за меня лабу, ну плез!


Напиши сам хоть что-нибудь, а с ошибками поможем.
sage #125 #759355
Как такой вариант?
https://ideone.com/pUZ1lJ
>>759370
sage #126 #759370
>>759355
Норм, но первый scanf можно выкинуть, а max инициализировать каким-нибудь INT_MIN.
#128 #759572

>Haskell Curry Мастер (1018) 1 день назад


>Мастер


> >[code]
> >я тот анон

>Пиздос! Ты понимаешь, как ты зашкварил себя и /pr/ своим появлением здеся?

>>759578>>759589
sage #129 #759578
>>759572
Хуястер
#131 #759594
>>759589
Простите, уже мелькало в треде, не увидел.
#132 #759596
Посоветуйте годный внешний препроцессор. Как доказательство годноты покажите изящное решение хуйни, как тут.
http://stackoverflow.com/questions/788903/valid-use-of-goto-for-error-management-in-c
>>759597>>759601>>759666>>759668>>759777>>759778>>760211
sage #133 #759597
>>759596
Надо же, Эли Еврейски спрашивает ответы на SO.
>>759598
#134 #759598
>>759597
Кто такой, чем знаменит?
>>759600
#136 #759601
>>759596
что за говнокод, нахуй так жить...
>>759602
#137 #759602
>>759601
А как ты без исключений предлагаешь? В чистой сишке здесь у тебя два стула: гото и макросы.
>>759603>>759604>>759607
#138 #759603
>>759602
пишешь void error_handeler(int error); и кайфуешь.
>>759605
sage #139 #759604
>>759602
setjmp/longjmp
>>759774
#140 #759605
>>759603
Ну и засрешь неймспейс кучей таких обработчиков, да и код в итоге только более раздутым станет.
>>759608
#141 #759607
>>759602
Ну или иначе взгляни на метки - после метки 1 идёт код, затем сразу метка 2, если функции не предполагают завершение программы, то 1 ошибка вызовет 2 функции, даже если должна вызвать одну.
#142 #759608
>>759605
Нахуя?
#143 #759609
Мне за препроцессоры пояснят в итоге?
>>759611
#144 #759610
Что такое препроцессоры?
sage #145 #759611
>>759609
Что ты хочешь? Чтобы препроцессор тебе сам метки и goto расставил где надо?
>>759613
#146 #759613
>>759611
Он хочет чтобы препроцессор за него код писал увидев фразу "Хочу чтоб было заебись".
>>759616
#147 #759616
>>759613
Хочу, чтоб, к примеру, можно было реализовать что-то типа лиспового unwind-protect.
>>759618>>759619
#148 #759618
>>759616
Заебись объяснил. Чтоб тебе всю жизнь так объясняли.
>>759625
#149 #759619
>>759616
Или defer как в go.
>>759620>>759624
#150 #759620
>>759619
Ещё лучше.
>>759625
#151 #759624
>>759619
Тут уже нужно расширять компилятор.
>>759629
#152 #759625
>>759618
>>759620
Ну, чтоб тот код из СО можно было написать как-то так.
int foo(int bar)
{
int return_value = 0;
BLOCK(govno)
if (!do_something( bar )) {
RETURN_FROM(govno);
}
defer(cleanup_1());
if (!init_stuff( bar )) {
RETURN_FROM(govno);
}
defer(cleanup_2());
if (!prepare_stuff( bar )) {
RETURN_FROM(govno);
}
defer(cleanup_3());
BLOCK_END(govno)
return_value = do_the_thing( bar );
}
>>759626>>759628>>759640>>759662>>759664
#153 #759626
>>759625
DEFER тоже макрос, типа.
#154 #759628
>>759625
Тоесть ты хочешь юзать функции не предусмотренные стандартом? Лучше сам напиши их.
>>759630
#155 #759629
>>759624
Ну, я имел в виду, хотя бы ненастолько мощный дефер, а хотя бы простенький, как в моем примере.
#156 #759630
>>759628
Не функции, макросы. Чтоб препроцессором все развернулось примерно как в вопросе на СО.
>>759631>>759632
#157 #759631
>>759630
Я про это и говорю. Лучше сам напиши препроцессор под свои особенные нужды.
>>759634
sage #158 #759632
>>759630
Короче, можно зделать, но используя не совсем стандартные фичи.
>>759640
#159 #759634
>>759631
Нахуя? Просто посоветуй, каким можно более-менее легко реализовать то, что я написал. Их же дохуя готовых есть.
>>759637
#160 #759637
>>759634
Ручками
>>759638
#161 #759638
>>759637
Вся суть зк.
sage #162 #759640
>>759625
>>759632
Как тебе такое решение:
BlOCK(X) начинает блок (ставит открывающую фигурную скобку) и объявляет переменную-ноду связного списка:
#define BlOCK(X) { struct function_list __list_head_for_X = EMPTY_LIST;

Тааак. Теперь defer будет принимать функцию(указатель на функцию) типа void(void) (можно зделать и void(void) или несколько макросов defer_N, где N — число аргументов не суть важно), выделять структуру типа function_list_node: т.к. мы не хотим теребить кучу, выделять будет с помощью alloca(); совать туда указатель на функцию и добавлять function_list_node в список.

BLOCK_END(X) будет закрывать блок и проходиться по списку __list_head_for_X, вызывая все функции оттуда.
>>759641>>759644>>759662>>759664
sage #163 #759641
>>759640
А, да. BLOCK_END(X) должна ставить метку "__label_huyabel_X:", а RETURN_FROM(X) делать "goto __label_huyabel_X;"
>>759642
#164 #759642
>>759641
Тебе понадобится отдельный макрос на каждый блок.
>>759643
sage #165 #759643
>>759642
zachem?
>>759645
#166 #759644
>>759640
А если внутри блока я вдруг решу использовать имя function_list __list_head_for_X?
Я выше исправился, что DEFER - макрос, он никаких указателей принимать не будет, а прост типа код внутри себя скопипастит в конец блока и сгенерирует нужные переходы.
>>759647>>759650
#167 #759645
>>759643
Chtobi ne videlivalsya
sage #168 #759647
>>759644

> А если внутри блока я вдруг решу использовать имя function_list __list_head_for_X?


То ты ССЗБ. Имена с multiple underscores это зарезервированные для деталей реализации библиотек имена.
>>759655
#169 #759650
>>759644
Что мешает написать вызов функии без слова defetr?
>>759651
#170 #759651
>>759650
Забей на меня, я что то туплю.
#171 #759655
>>759647
А если блок внутри блока? Гигиену в любом случае соблюдать над.
>>759658
sage #172 #759658
>>759655

> А если блок внутри блока?


именуй их по-разному.

Ах, да. defer у нас без указания блока...
Бида-пичать, тогда BEGIN_BLOCK(X), кроме __list_head_for_X, пусть создаёт указатель на этот __list_head_for_X под одинаковым именем во всех блоках:
struct function_list *__current_list_head = &__list_head_for_X;
а defer() будет добавлять ноды к __current_list_head.

> Гигиену в любом случае соблюдать над.


Если тебе нужна схема — пиши на схеме.
>>759660
#173 #759660
>>759658
Да блжад. Мне нужен удобный препроцессор, вот и все. Нахуя ты мне предлагаешь решения на стандартном, если он говно?
sage #174 #759662
>>759625
>>759640
Да, для тех, кто боится, что если кто-то зделает RETURN_FROM(X) для X, который является не текущим блоком, а обрамляющим текущий, то это тоже решаемо: вместо пихания кода прохождения по списку в BLOCK_END(X), запихнуть его в функцию, а эту функцию указать в __attribute__((cleanup)) у __list_head_for_X.

cleanup работает с нелокальным выходом!!! http://ideone.com/0m6gO8
sage #175 #759664
>>759625
>>759640
Короче, arbitrary code можно запихать в DEFER, если позволить ему создавать вложенные функции и пиать код в них.

А указатели на эти вложенные функции так же, как и раньше, сохранять в списке.
>>759666
#176 #759666
>>759664
Я хочу макросы, которые сгенерируют код как в >>759596
С уникальными именами меток, канеш.
>>759667
sage #177 #759667
>>759666
Тебе это не нужно.
>>759668
#178 #759668
>>759667

>нинужна


Пока не будет исключений в языке, нужно. А вот исключения как раз в сишке не нужны, так что актуально будет всегда. Выше не увидел ни одного адекватного решения проблемы без использования метапрограммирования. Так что если и буду что-то такое писать без нормальных макросов (а ведь придется), то буду с гото в ассемблерном стиле как в >>759596
>>759669>>759678
sage #179 #759669
>>759668
goto на лейблы в конце функции это никак не похоже на исключения.
>>759672
#180 #759672
>>759669
Любая практически обработка нестандартной ситуации похожа на исключения.
>>759674
sage #181 #759674
>>759672
Лол, нет. Исключения можно протаскивать по стеку вызовов, а эти goto нельзя.
>>759678
sage #182 #759677
Test
>>759679
#183 #759678
>>759668
Это не ассемблерный стиль. Тут все использование гото ограничивается прыжком вперед на единственный и хорошо заметный блок кода. И вот эти error_1, error_2 нинужны, достаточно goto cleanup везде. Ошибки случаются относительно редко, и пара лишних if в cleanup - вполне адекватная цена за красивый читаемый код.

>>759674

> протаскивать по стеку вызовов


Если хочешь странного, есть setjmp.
>>759695
sage #184 #759679
>>759677
passed
>>759680
#185 #759680
>>759679

А зачем ты пишешь с сажей?
>>759681
sage #186 #759681
>>759680
"Test" написал не я
>>759682
#187 #759682
>>759681
Это написал я.
>>759683
sage #188 #759683
>>759682
Молодец.
>>759684
#189 #759684
>>759683
Нахуя сажа? А вообще мне удалось сегодня запилить кросс-компиляцию :3
Я доволен как слон.
>>759687
sage #190 #759687
>>759684

>удалось сегодня запилить кросс-компиляцию


Пока жители Виллабаджо собирают кросс-компилятор, жители Вилларибо установили proot+qemu-user, скачали rootfs для нужной архитектуры и собрали весь код под неё.
>>759689>>759690
#191 #759689
>>759687
Спасибо, почитаю
16 Кб, 250x184
#192 #759690
>>759687

> Виллабаджо


> Вилларибо


ты сейчас просто пробудил во мне вихрь воспоминаний
>>759691
#193 #759691
>>759690

>pic


Это было гораздо раньше
#194 #759695
>>759678

>Это не ассемблерный стиль.


Ну, хз, просто такая ассоциация возникла, потому что в ассемблере такие переходы часто приходится писать. По поводу одной метки — да, дельное замечание. Походу единственный адекватный ответ насчет обработки похожих ситуаций. Если б ты мне еще за препроцессоры пояснил, вообще круто было бы.
>>759842
#195 #759774
>>759604
хуета по сравнению seh/veh и что там под юниксами аналогичное
>>759776
#196 #759776
>>759774

>что там под юниксами аналогичное


Что же?
>>759780>>759781
#197 #759777
>>759596
дык обычно в функции вверху выделяют все ресурсы сразу зарас
ну и потом в ошибочных ситуациях выходят через goto на код очистки внизу
те там нет такой хуеты error_1, error_2, error_3
те и спрашивающий тот еще лошок и отвечающие - чуханы
>>759779
#198 #759778
>>759596
дык обычно в функции вверху выделяют все ресурсы сразу зарас
ну и потом в ошибочных ситуациях выходят через goto на код очистки внизу
те там нет такой хуеты error_1, error_2, error_3
те и спрашивающий тот еще лошок и отвечающие - чуханы
#199 #759779
>>759777

> выделяют все ресурсы сразу зарас


А если ошибка в выделении ресурсов произошла, когда часть уже выделена, а часть — нет?
>>759783
#200 #759780
>>759776
нативные сигналы наверное, я ебу как там у них, я вод виндой
>>759784
#201 #759781
>>759776
Синхронные сигналы.
Кстати, вот что по препроцессингу интересного нашел.
https://www.cs.nyu.edu/rgrimm/papers/ecoop12.pdf
#202 #759783
>>759779
в коде очистки проверяют на ноль, типа если не ноль - то нада чистить
вы че ни разу промышленный код не видели что ли?
там везде такая идеома
>>759786>>759792
#203 #759784
>>759780
Как тебе сигналы помогут устроить обработку произвольных исключений?
#204 #759786
>>759783
Сынок. Код должен быть быстрым. Особенно в ядре.
Любые условные переходы — это лишние тормоза.

К тому же, чтобы в переменной был до выделения ресурсов, её надо этим нулём инициализировать. Инициализация тоже занимает лишние такты.
>>759789>>759791>>759792>>759795>>759796
#205 #759789
>>759786

>К тому же, чтобы в переменной был до выделения ресурсов


был ноль
#206 #759791
>>759786

>Любые условные переходы — это лишние тормоза.


Лол. А проверки перед goto — это не условные переходы?
>>759792
#207 #759792
>>759783
Я о том, как сгенерировать данный код макросом. А если код генерится макросом, то надо выбирать более быстрый вариант, как >>759786
тебе пытается донести.
>>759791
Но там проверки будут в любом случае.
И вообще, блядь, я у вас спрашиваю, как это написать с использованием кодогенерации, чтоб не было говнокода, а вы толкуете о том, как правильно писать говнокод.
>>759793
#208 #759793
>>759792
Проблема в том, что метки в конце и переход на них никто не считает говнокодом (кроме тебя).

А вот твои BLOCK_END() это говнокод. Никому не известны, требуют напряга, чтобы понять, к чему они, требуют нестандартных препроцессоров.
>>759797
#209 #759795
>>759786
какой я те сынок, иди нах
#210 #759796
>>759786
на, жри, даунина
https://github.com/torvalds/linux/blob/master/fs/crypto/crypto.c
первый рандомно открытый файл, первая ранодмно просмотренная функция, 261 линия
#211 #759797
>>759793
Ну, про говнокод я довольно образно сказал. Я понимаю, что для pure c такие переходы — довольно распространенная практика, и не надо их особо бояться. Просто сишке реально часто не хватает мощи, и я рассматриваю кодогенерацию как шанс ее повысить. А почему мой код является говнокодом, если он способствует лучшей структуризации и устранению goto? Почему требуют напряга? Просто вот есть какой-то паттерн, я его выделил и придумал решение, основанное на метапрограммировании. Вот если бы внутри какой-то команды разработчиков было принято писать с препроцессором во имя структуризации, и была бы договоренность, где какие макросы использовать, разве это бы считалось говнокодом? Просто не используй препроцессор, где он не нужен, а если решил написать свой макрос (а такое вряд ли часто понадобится, когда есть какой-то общий набор для решения частых задач вроде этой), то тщательно его документируй, вот и все.
>>759844
#212 #759842
>>759695
Да хули ты пристал со своими препроцессорами?
#213 #759844
>>759797
Мощи нехватает твоим мозгам, сишка лишь инструмент.
>>759886
#214 #759848
согласен
#215 #759886
>>759844
Лишь инструмент, которому не хватает мощи. В чем проблема? Моим мозгам как раз хватает мощи, чтоб понять очевидную вещь.
>>759956>>759996
#216 #759956
>>759886
Современные компиляторы Сишки настолько оптимизированы, что условные операторы в них часто сводятся к одной машинной команде. О какой, нахуй, немощности ты тут говоришь?
>>760041
#217 #759996
>>759886
Взять более высокоуровенный инструмент.

Можешь даже не менять язык – возьми компилятор objc и компилируй с ARC, вот тебе и нормальное использование RAII, а не уродский дефер.
>>760041
#218 #760041
>>759956

>отождествлять мощь языка с оптимизированностью компилятора


Слушай, ты заебал, просто не пиши сюда, хорошо?
>>759996
Objc тащит за собой рантайм и не имеет zero cost абстракций.
Подсчет ссылок к метапрограммированию отношения не имеет.
Мой более высокоуровневый инструмент, который меня устроит — сишка с нормальным препроцессором. Какие вопросы?
>>760083>>760120
#219 #760083
>>760041
А от нас-то ты что хочешь? Возьми сишку или пайтон и напиши себе препроцессор, какой больше нравится (не забудь генерить #line, иначе отладка и bistect превращаются в ад). Не хотел тебе отвечать, но расскажу кулстори: был у нас один проект, где предыдущий кодер "расширил" синтаксис - там все упиралось в быстродействие в рантайме, поэтому он добавил синтаксис для предвычисления в compile-time табличек и вставки бинарных данных. И это было, в принципе, неплохо (для конкретного проекта), но как только он ушел, все это быстро выкинули, потому что нестандартно и некому поддерживать. Возможно, тебе стоит взять какой-то другой язык, если ты хочешь "мощь", а не простоту.
>>760150
#220 #760120
>>760041

>Objc тащит за собой рантайм


Так пиши на си, дебил.

>не имеет zero cost абстракций.


Си их вообще не имеет, вась. С этим в кресто/расто-треды. Там и с метапрограммированием более-менее в рамках говноедства, и аналоги скоупов (деферов) есть.
>>760150
18 Кб, 250x360
#221 #760150
>>760083

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


>>760120
Так и пишу!

>кресты, раст


Пикрелейтед.
>>760176
#222 #760171
Поделитесь ссылочками, ежели таковык имеются?
Stephen G. Kochan "Programming in C (4th Edition, если найдется)" (2014)

MISRA Ltd. "Guidelines for the Use of the C Language in Critical Systems" (2013)
>>760179>>760188>>760305
#223 #760176
>>760150

>Пикрелейтед


Взгляд со стороны:

>мааам, я хачу метапрараммарованея и бесплатных в рантайме абстракций!!!


>ну держи сына кресты с растом


>фиии, нихачу, хачу писать на си с макросаме!



Ты серьёзно дурак?
>>760193
#224 #760179
>>760171
Кочан есть в epub, но я не люблю epub, поэтому не дам ссылок.
>>760182
#225 #760182
>>760179
epub я тоже нашёл, но он мерзок и непрекрасен. PDF бы.
>>760298
#226 #760188
>>760171

>MISRA


• Reduced language subset
• Ensure that “goto” or “malloc” is not used
• Style guidelines
• Ensure that the “tab” character is not used
• Naming conventions
• Ensure that all public functions start with <filename>_

Пздц.
Софт сразу станет секурным, если я не буду использовать табы.
#227 #760193
>>760176
У раста рантайм тяжелый, кресты — монстроузный ненужный язык, которому место на помойке. На какой-нибудь Nim посмотрел бы, который полностью на сишном рантайме и на раз-два интегрируется с сишкой, но он мертворожденный. Хочу, блядь, просто сишку с макросами, все, отъебитесь. Блядь, можете просто не отвечать, я уже все для себя решил.
>>760197>>760202>>760213
#228 #760197
>>760193

>раста рантайм тяжелый


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

>Nim посмотрел бы


У раста откуда-то тяжёлый рантайм появился, а язык с GC – ок. Ну лан.
>>760199
#229 #760199
>>760197
ГЦ отключаемый у нима.
Насчет раста, я думал, там одно следствием другого является. Я особо не разбирался, если честно. Один хуй ведь маргинальный хипсторский язык без задач.
>>760203
#230 #760202
>>760193
так напиши себе препроцессор на перле и вперед
>>760207
#231 #760203
>>760199
Только без GC там такая же печаль как и в D — всё, от стандартной библиотеки до замыканий требует сборщика, и течёт как твоя мамаша от негра без него.

>я думал, там одно следствием другого является


Вся суть твоего уровня. Там банально весь мир слинкован статически.

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


Ясн.
>>760210
#232 #760206
Мб когда-нибудь займусь по приколу. Жаль, он никому нахуй не нужен будет, ибо большинству не надо, лишь бы им не мешали их байты перекладывать, а тут всякие ебланы со своими макросами сунутся. А кому надо, уже М4 каким-нибудь пользуются, который ничего про AST не знает. А вещи типа вброшенного мной Marco так и останутся сырыми исследовательскими проектами, ибо НЕНУЖНО.
>>760207>>760211
#233 #760207
>>760202
>>760206
#234 #760210
>>760203
Да я особо и не защищаю этот Nim, ибо такой же маргинальный язык, как рашт, просто не хайпнутый.

>Ясн.


А что, разве нет? Сами себе придумали проблему (я про потокобезопасность), сами с ней борются, так еще прикол состоит в том, что не решают ее!
>>760219
#235 #760211
>>759596
>>760206
Вот тебе псто от самого автора вопроса на SO
http://eli.thegreenplace.net/2012/06/08/basic-source-to-source-transformation-with-clang (устаревший. про обновления там в начале написано)

Може допоможе.
>>760229
#236 #760213
>>760193
Нахуй тебе все эти заморочки? Ты в продакшн такое будешь гнать? Как это потом поддерживать?
#237 #760219
>>760210

>я про потокобезопасность


И почему же это они придумали проблему?

>что не решают её


Держи нас в курсе.

Есть ещё куча проблем который он решает.
#238 #760229
>>760211
Спасибо, довольно занятная штука.
#239 #760244
Уважаемые. Как можно в этом коде проэксплуатировать переполнение буфера?
http://pastebin.com/7Nt4n6B3
>>760268>>760276
#240 #760268
>>760244
Если нет DEP и ASLR, то все сводится к тому чтоб в адресном пространстве найти FF D4 (call esp), затереть адрес возврата в стеке адресом этого участка, и расположить шелл-код так, чтобы на него передалось управление. Мб ты это и знал, хз, я ща попробую реализовать такое, только вспомню, как отладчик в руках держать.
>>760280>>760290
#241 #760276
>>760244
В каком смысле проэксплуатировать?
#242 #760280
>>760268
Смотри, когда идёт запрос на ввод сообщения, я туда вставляю свой payload: http://pastebin.com/3QERVFx8,
отчего и происходит переполнение буфера и ошибка сегментирования.
>>760281>>760282
13 Кб, 670x549
#243 #760281
>>760280
>>760289
#244 #760282
>>760280

>This page has been removed!

>>760283>>760285
#245 #760283
>>760282
Запятую убери.
#246 #760285
>>760282
Блядь, у тебя прыщи. А какие у тебя там байты после букв?
#247 #760286
Кстати, задача как-то получить доступ через утечку к /bin/sh.
#248 #760289
>>760281

>eip 41414141 ('AAAA')


Это же вроде inc ecx, что не так? Мб там стек неисполняемый?
>>760290>>760296
#249 #760290
>>760289
Ой, я затупил. Все верно же, у тебя адрес возврата затерся. Введи другие символы, чтоб понять, чем он затирается и куда новый адрес записать. Новый пиши, как я тут >>760268
сказал.
#250 #760296
>>760289

> стек неисполняемый


Очевидный ROP.
#251 #760298
>>760182
На самом деле epub это всего-лишь zip-архив с html. Его можно разархивировать и если ты программист, то далее легко меняешь верстку ПОЛНОСТЬЮ.
#252 #760305
>>760171
library genesis
#253 #760316
у меня есть странный вопрос
как у функции write вызвать ошибки при этом не изменяя код(ну типа никакой лажи в самом коде нет)
я так понимаю нужно сделать какие то манипуляции с файлом
>>760342>>760417
#254 #760342
>>760316
Что значит вызвать ошибки? Ты хочешь чтобы write вернула -1?
>>760348
#255 #760348
>>760342
Если да, то ответ на твой вопрос в секции Errors:
http://man7.org/linux/man-pages/man3/write.3p.html
#256 #760417
>>760316
Дай файлу атрибут "только чтение"
25 Кб, 263x317
#257 #760645
Анон, личинка быдлокодера итт.
Учил С по курсу со средой MS VS2008exp. Потом на компе сгорела видюха и пришлось перекатываться на стабильного демиена. В самом курсе крайне мало рассказывается про среды, и я в этих ваших эклипсах разобраться не смог.
Так вот вопрос: в какой простой среде мне теперь писать свои хэллоуворды, чтоб как в вижуале(искаропки), и чтоб она была в стандартных репах демьяна?
>>760649>>760651>>760686>>760788
#258 #760649
>>760645
А потом вот такие вот личинки пишут адово говно с утечками под ШИНДОШС. Блокнот и соснолька — вот и вся среда разработки, блядь! Перепробовал кучу сред — все говно. Пока настроишь — заебешься. А в соснольке достаточно напечатать «gcc *.c».
>>760652>>765363
sage #259 #760651
>>760645
gedit
>>765363
#260 #760652
>>760649
С вимом достаточно и голой консольки.
>>760653
sage #261 #760653
>>760652

> 2016


> vim

>>760656
#262 #760656
>>760653
Ну можешь и nvim взять если восьмёрку лень руками собирать, хотя на шиндовсе действительно печально с этим.

Алсо, лучше редактора нету, это как наркота.
>>760658>>760659
sage #263 #760658
>>760656
Редактор нужен чтобы редактировать, а не пердолиться в него.
>>760691
sage #264 #760659
>>760656
Да, я тебя ни в чём не переубеждаю. Пердолься сколько влезет.
>>760691
#265 #760686
>>760645
QtCreator, Code::blocks или любо текстовый редактор, у которого есть плагин для rtags. Rtags умеет семант
>>760687>>765363
#266 #760687
>>760686
Сорвалось. Так вот, rtags делает семантический разбор clang-analyzerom и умеет комплит, навигацию и подчеркивание ошибок. Из любого редактора делает сишную IDE.
#267 #760691
>>760658
>>760659
Семён-неосилятор, успокойся, нету там пердолинга.
#268 #760788
>>760645
geany тебе в помощь. Если убрать лишнее (2-3 галочки) то будет годный блокнот с подсветкой и исполнением команд компилятору(какие пропишешь) на кнопках.
#269 #761022
А что это такое? Это я снова выхожу на связь со своей прогой.
Задача скопировать input.txt в output.txt рекурсивно заменяя include<filename.txt> на символы из filename.txt
Имеется следующий код http://pastebin.com/sHdEV3vJ который я поясню ниже, поскольку в нем комментарии только человека, написавшего основную часть(он кстати из этого треда).
Там три файла, написано что куда кидать.
Все работае правильно например в следующем варианте
+++++++++
input.txt:"3jirejinclude<file1.txt>efrf"
file1.txt:"weinclude<file2.txt>ewf"
file2.txt:""или"1"
+++++++++
но если мы поменяем содержимое file2.txt на "1111", к примеру, то мы получаем ошибку сегментирования, gdb говорит, что на каком-нибудь шаге мы херим массив cru при помощи реаллока.
Собственно пояснения кода. Создается массив из cru из одного элемента, куда будет записываться то, что в результате мы выведем в оутпут, массив сту из одного элемента, в единственный элемент которого мы будем сохранять количество символов в cru(не спрашивайте почему я такой даун). Затем мы сравниваем каждый элемент входа с первым элементом массива инклюде_префикс(туда записано "include<") и если он совпал то то следующий элемент сравниваем со следующим элементом инклюд префикс. И либо на каком-то шаге мы целиком совпадем, либо нет, соотвественно, начинаем считывать имя файла, либо печатаем то что уже насовпадало соответственно.
ПС Возможно замена реаллоков на маллок поможет, но у меня не сработало.
>>761023>>761026>>761456
#270 #761023
>>761022
Поправочка, непонятно почему этот код работает, потому что я скопировал его неисправленным, вот нормальная версия
http://pastebin.com/9LwUs5dz
(cru[stu[0]] заменено везде на cru[stu[0]-1])
Проблема все та же, если в file2 3 единицы, то все работает, а вот при 4 нет.
>>761026
#271 #761026
>>761022
>>761023
Можно поинтересоваться нахуя ты вообще все это делаешь? Это лаба1?
>>761029>>761174
#272 #761029
>>761026
Пишу убийцу clang и gcc
>>761132>>761175
#273 #761056
Namespace?
#274 #761132
>>761029
судя по твоим начинаниям, тебе предстоит ОЧЕНЬ долгий путь
>>761175
#275 #761174
>>761026
задание по ЭВМ, вроде не последнее.
#276 #761175
>>761132
Это >>761029 не я
#277 #761379
А чем сейчас модно разбирать командную строку?
или как всегда руками?
>>761383>>761415
#278 #761383
>>761379
Ну как бы первым ответом на этот вопрос всегда был getopt, а вторым, да, ручной парсинг, если у тебя полторы опции.
#279 #761415
>>761379
shell?
45 Кб, 300x300
#280 #761448
>>749121 (OP)
ЛЯМБДЫ-ТО ТАМ ЕСТЬ?
>>761452
#281 #761452
>>761448
Нет.
>>761463
#282 #761456
>>761022

> test.c


У тебя счётчик лежит всегда в одном месте, он всегда один. Почему ты выделяешь память, а не используешь указатель на int. Ты ведь умеешь в указатели?
int text_length = 0;
reshift("input.txt", 1, cru, &text_length);
// Алсо, внутри reshift:
∗stu вместо stu[0]
Подходы равнозначные, но stu[0] вводит в заблуждение, намекая, что stu - это массив. С именами переменных у тебя тоже проблема. Сейчас не 80е, лимит на длину идентификаторов практически отсутствует, не ленись писать что-то более понятное. А если дело именно в лени, возьми ту же Sublime Text - там охуенное автодополнение.

> reshift.c


> filename = '\0';


> n++;


Если у тебя в input.txt, т.е., на одном уровне, будет 5 include подряд, шестой не сработает. Если n предназначен для ограничения глубины рекурсии, нужно передавать вглубь n + 1, а вот изменять при этом локальный n не нужно.

Ниже в коде вывода include_prefix realloc() можно сделать до цикла, чтобы не ебать бедный менеджер кучи на каждый новый символ. В идеале, если уж тебе так хочется буферизировать текст, тебе стоило бы сделать вместо cru и stu какую-нибудь:
struct text {
char ∗buffer;
size_t used;
size_t allocated;
};
и написать функцию типа void text_put(struct text ∗text, сhar c); чтобы она (и только она!) записывала символ в буфер и при необходимости перевыделяла буфер с запасом (например, вдвое большего размера). Можешь взять любую готовую реализацию динамических массивов из гугла.

Дальше. Умножение на sizeof(char) тебе тоже не нужно нигде. Язык гарантирует, что sizeof(char) == 1.

И, наконец, проблема твоего кода - непонимание тобой, что в Си все передается по значению. Когда ты вызываешь reshift, передавая ему указатель cru, внутри этого указателя лежит, уж прости за подробности, адрес буфера в памяти. Если внутри reshift() ты по этому указателю сходишь и изменишь данные (cru[0] = 'x'), то функция main() после возврата из reshift() увидит эти изменения. Но сам указатель передается по значению, т.е., как если бы создавалась новая переменная cru, которая живет от момента вызова функции reshift() до момента возврата из нее, и в нее писалось переданное тобой значение. Если ты изменишь указатель cru внутри reshift(), т.е., запишешь в него новый адрес, то функция main() об этом не узнает - ее собственная cru будет содержать все тот же адрес, что и был там до вызова reshift(). Именно это у тебя и происходит - внутри reshift() ты вызываешь realloc(), она рано или поздно возвращает тебе адрес, не совпадающий с тем, что был раньше, ты счастливо пишешь по новому адресу свои символы, возвращаешься в main(), она начинает читать по старому адресу и... тут может случиться все, что угодно (см. >>755967 последний абзац realloc(), вне зависимости от реализации, должна вести себя так, как если бы она делала malloc() нового блока, memmove() из старого блока в новый и free() старому блоку, поэтому если realloc(ptr, ...) вернула не NULL, по ptr ходить уже нельзя.). Можешь возвращать из reshift указатель на буфер вместо int.

Алсо, код, который ты модифицируешь, не умеет в >>758374, и если попытаться его переделать, чтобы он сумел, он станет более запутанным, поэтому для меня по-прежнему загадка, зачем ты буферизируешь данные.
#282 #761456
>>761022

> test.c


У тебя счётчик лежит всегда в одном месте, он всегда один. Почему ты выделяешь память, а не используешь указатель на int. Ты ведь умеешь в указатели?
int text_length = 0;
reshift("input.txt", 1, cru, &text_length);
// Алсо, внутри reshift:
∗stu вместо stu[0]
Подходы равнозначные, но stu[0] вводит в заблуждение, намекая, что stu - это массив. С именами переменных у тебя тоже проблема. Сейчас не 80е, лимит на длину идентификаторов практически отсутствует, не ленись писать что-то более понятное. А если дело именно в лени, возьми ту же Sublime Text - там охуенное автодополнение.

> reshift.c


> filename = '\0';


> n++;


Если у тебя в input.txt, т.е., на одном уровне, будет 5 include подряд, шестой не сработает. Если n предназначен для ограничения глубины рекурсии, нужно передавать вглубь n + 1, а вот изменять при этом локальный n не нужно.

Ниже в коде вывода include_prefix realloc() можно сделать до цикла, чтобы не ебать бедный менеджер кучи на каждый новый символ. В идеале, если уж тебе так хочется буферизировать текст, тебе стоило бы сделать вместо cru и stu какую-нибудь:
struct text {
char ∗buffer;
size_t used;
size_t allocated;
};
и написать функцию типа void text_put(struct text ∗text, сhar c); чтобы она (и только она!) записывала символ в буфер и при необходимости перевыделяла буфер с запасом (например, вдвое большего размера). Можешь взять любую готовую реализацию динамических массивов из гугла.

Дальше. Умножение на sizeof(char) тебе тоже не нужно нигде. Язык гарантирует, что sizeof(char) == 1.

И, наконец, проблема твоего кода - непонимание тобой, что в Си все передается по значению. Когда ты вызываешь reshift, передавая ему указатель cru, внутри этого указателя лежит, уж прости за подробности, адрес буфера в памяти. Если внутри reshift() ты по этому указателю сходишь и изменишь данные (cru[0] = 'x'), то функция main() после возврата из reshift() увидит эти изменения. Но сам указатель передается по значению, т.е., как если бы создавалась новая переменная cru, которая живет от момента вызова функции reshift() до момента возврата из нее, и в нее писалось переданное тобой значение. Если ты изменишь указатель cru внутри reshift(), т.е., запишешь в него новый адрес, то функция main() об этом не узнает - ее собственная cru будет содержать все тот же адрес, что и был там до вызова reshift(). Именно это у тебя и происходит - внутри reshift() ты вызываешь realloc(), она рано или поздно возвращает тебе адрес, не совпадающий с тем, что был раньше, ты счастливо пишешь по новому адресу свои символы, возвращаешься в main(), она начинает читать по старому адресу и... тут может случиться все, что угодно (см. >>755967 последний абзац realloc(), вне зависимости от реализации, должна вести себя так, как если бы она делала malloc() нового блока, memmove() из старого блока в новый и free() старому блоку, поэтому если realloc(ptr, ...) вернула не NULL, по ptr ходить уже нельзя.). Можешь возвращать из reshift указатель на буфер вместо int.

Алсо, код, который ты модифицируешь, не умеет в >>758374, и если попытаться его переделать, чтобы он сумел, он станет более запутанным, поэтому для меня по-прежнему загадка, зачем ты буферизируешь данные.
>>761533>>761867
114 Кб, 800x800
#283 #761463
>>761452
сишника ответ
Даже в Delphi есть ЛЯМБДЫ, а у опущенцев-байтоебов нету.
>>761471
#284 #761471
>>761463
Толстить запрещено!!
>>761483
#285 #761483
>>761471
Действительно, инвалидов обижать нехорошо.
>>761534
#286 #761533
>>761456
>>761456

>И, наконец, проблема твоего кода - непонимание тобой, что в Си все передается по значению. Когда ты вызываешь reshift, передавая ему указатель cru, внутри этого указателя лежит, уж прости за подробности, адрес буфера в памяти. Если внутри reshift() ты по этому указателю сходишь и изменишь данные (cru[0] = 'x'), то функция main() после возврата из reshift() увидит эти изменения. Но сам указатель передается по значению, т.е., как если бы создавалась новая переменная cru, которая живет от момента вызова функции reshift() до момента возврата из нее, и в нее писалось переданное тобой значение. Если ты изменишь указатель cru внутри reshift(), т.е., запишешь в него новый адрес, то функция main() об этом не узнает - ее собственная cru будет содержать все тот же адрес, что и был там до вызова reshift(). Именно это у тебя и происходит - внутри reshift() ты вызываешь realloc(), она рано или поздно возвращает тебе адрес, не совпадающий с тем, что был раньше, ты счастливо пишешь по новому адресу свои символы, возвращаешься в main(), она начинает читать по старому адресу и... тут может случиться все, что угодно (см. >>755967 последний абзац realloc(), вне зависимости от реализации, должна вести себя так, как если бы она делала malloc() нового блока, memmove() из старого блока в новый и free() старому блоку, поэтому если realloc(ptr, ...) вернула не NULL, по ptr ходить уже нельзя.). Можешь возвращать из reshift указатель на буфер вместо int.


Все выше тоже принял к сведению, но это самое главное. Спасибо тебе большое. Щас придумаю как исправит код. Не знаю почему я не понял, что там ошибка, Наверное теперь буду возвращать из решифта новый массив,(return cru; вот так вот? ну и понятно что функция не инт, а дабл, только теперь массив будет содержать дополнительный элемент, который раньше возвращался из функции, 0 или 1 в зависимости от того, нормально ли все или нет).
За использование массива вместо переменной сразу извинился, теперь переправлю, конечно. Насчет глубины рекурсии твой вариант действительно более верный, нам предпочтительнее заменять кучу инклюдов в исходнике, чем одну глубокую замену.
В

> struct text {


char ∗buffer;
size_t used;
size_t allocated;
};
не умею, но пойду разберусь.
Насчет гарантированности размера char не знал
Насчет буферизации не понял вопроса. Мне нужно рекурсивно заменять инклюды и я вижу только два варианта, то как делаю это я(шаманю в массиве), либо сразу печатать в файл, однако поскольку у меня рекурсия, а выходной файл один, возможно множественное открытие этого файла. А ка мне пояснили выше фпринтф умеет в буферизацию, и я себе порву что-нибудь, пытаясь придумать как бы правильно фклозе приладить.
В общем огромное спасибо, может есть еще какие советы или замечания?
#286 #761533
>>761456
>>761456

>И, наконец, проблема твоего кода - непонимание тобой, что в Си все передается по значению. Когда ты вызываешь reshift, передавая ему указатель cru, внутри этого указателя лежит, уж прости за подробности, адрес буфера в памяти. Если внутри reshift() ты по этому указателю сходишь и изменишь данные (cru[0] = 'x'), то функция main() после возврата из reshift() увидит эти изменения. Но сам указатель передается по значению, т.е., как если бы создавалась новая переменная cru, которая живет от момента вызова функции reshift() до момента возврата из нее, и в нее писалось переданное тобой значение. Если ты изменишь указатель cru внутри reshift(), т.е., запишешь в него новый адрес, то функция main() об этом не узнает - ее собственная cru будет содержать все тот же адрес, что и был там до вызова reshift(). Именно это у тебя и происходит - внутри reshift() ты вызываешь realloc(), она рано или поздно возвращает тебе адрес, не совпадающий с тем, что был раньше, ты счастливо пишешь по новому адресу свои символы, возвращаешься в main(), она начинает читать по старому адресу и... тут может случиться все, что угодно (см. >>755967 последний абзац realloc(), вне зависимости от реализации, должна вести себя так, как если бы она делала malloc() нового блока, memmove() из старого блока в новый и free() старому блоку, поэтому если realloc(ptr, ...) вернула не NULL, по ptr ходить уже нельзя.). Можешь возвращать из reshift указатель на буфер вместо int.


Все выше тоже принял к сведению, но это самое главное. Спасибо тебе большое. Щас придумаю как исправит код. Не знаю почему я не понял, что там ошибка, Наверное теперь буду возвращать из решифта новый массив,(return cru; вот так вот? ну и понятно что функция не инт, а дабл, только теперь массив будет содержать дополнительный элемент, который раньше возвращался из функции, 0 или 1 в зависимости от того, нормально ли все или нет).
За использование массива вместо переменной сразу извинился, теперь переправлю, конечно. Насчет глубины рекурсии твой вариант действительно более верный, нам предпочтительнее заменять кучу инклюдов в исходнике, чем одну глубокую замену.
В

> struct text {


char ∗buffer;
size_t used;
size_t allocated;
};
не умею, но пойду разберусь.
Насчет гарантированности размера char не знал
Насчет буферизации не понял вопроса. Мне нужно рекурсивно заменять инклюды и я вижу только два варианта, то как делаю это я(шаманю в массиве), либо сразу печатать в файл, однако поскольку у меня рекурсия, а выходной файл один, возможно множественное открытие этого файла. А ка мне пояснили выше фпринтф умеет в буферизацию, и я себе порву что-нибудь, пытаясь придумать как бы правильно фклозе приладить.
В общем огромное спасибо, может есть еще какие советы или замечания?
#287 #761534
>>761483
Прежде чем выразить человеку свое мнение, подумай о том, в состоянии ли он его принять.

© Ямамото Цунэтомо. Сокрытое в листве
>>761537
#288 #761537
>>761534
Ты листва?
>>765006
#289 #761749
Коданы, нужен молниеносный способ определения того, что число равно некому набору констант. Констант около 15, диапазон 0-150.
Т.е. нужна быстрая версия варианта:
if (V1 == v || V2 == v || V3 == v || ... V15 == v) {...}
Пока кроме варианта с битовой маской ничего не нашел.
>>761756>>761764>>761774
#290 #761756
>>761749
Я обычно в таких случаях завожу еще одну константу с именем вроде V_LAST, равную последнему значению.
>>761760
#291 #761760
>>761756
и как это должно помочь?
>>761763
#292 #761761
А если серьезно, почему до сих пор нет лямбд (анонимных функций)? Для всяких коллбеков было бы удобно.
>>761764>>761766>>761866
#293 #761763
>>761760
if (v>=V1 && v1<=V_LAST) - тебе нужно так? Проверка на вхождение в диапазон?
>>761774
#294 #761764
>>761749
switch сделай. Потом дизасмишь и видишь, что твой switch превратился в bool matches = table[v];

>>761761
В следующем стандарте, если комитет не образумится.
#295 #761766
>>761761
Потому что, например, в цепепе лямбды это объекты классов с оператором()

В более управляемых языках лямбды это какие-нибудь замыкания.

Как ты собираешься делать лямбды в чистом С?
>>761769>>761770
sage #296 #761769
>>761766
В предыдущем треде и сам лямбдосрач, и ссылка на pdf с деталями реализации.
>>761771>>761793
#297 #761770
>>761766
Без замыканий, просто анонимные функции. Кому надо, сделают замыкания сами через локальные static переменные.
#298 #761771
>>761769
Почему у байтоопущенцев так бомбит от лямбд? Они тупые как Skipy с javatalks?
>>761778
#299 #761774
>>761763

>тебе нужно так? Проверка на вхождение в диапазон?


Нет не диапзон, вхождение в набор, типа есть ли 2 среди 1,5,6,9,20 и тп.
>>761749

>switch превратился в bool matches = table[v];


массив я и сам могу сделать, а всякие конпеляторные хитрости очень нужно избежать.
>>761789
#300 #761778
>>761771
Потому что язык предполагает, что большинство из того, что делается, делается явно. Если вдруг локальные переменные начинают жить дольше, чем им отпущено, это вызывает разные чувства, от недоумения до батхертагнева.
>>761789
#301 #761789
>>761774
Чем тебе массив не нравится?

>>761778
Лямбда-выражение - это просто функция без имени. Т.к. в Си нет ни паскалевских модулей, ни namespace'в из C++, хотелось бы свести число глобальных имен к минимуму. Для всяких обработчиков событий (таймеры, оконные процедуры в WinAPI, сравнение для сортировки и т.д.) заводить именованную функцию нет никакого смысла. А замыкания можно реализовать через дополнительный параметр (хранящий ссылку на контекст), использовать локальные переменные для этого не нужно.
>>761794>>761796>>761799
#302 #761793
>>761769

> pdf с деталями реализации


О они придумали C++ с name mangling-ом, структурами-объектами и неявным аналогом this
>>761798
#303 #761794
>>761789

>Чем тебе массив не нравится?


можно использвать более эффективную битовую маску
#304 #761796
>>761789
К примеру:
WNDCLASSEX wc;
wc.lpfnWndProc = LRESULT WINAPI (HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam) -> {...}
Что в этом плохого?
>>761814
#305 #761798
>>761793

> и неявным аналогом this


Ну это уже лишние. Неявных элементов быть не должно, замыкания при необходимости (а нужны они очень редко) должны реализовываться программистом вручную.
#306 #761799
>>761789

> А замыкания можно реализовать через дополнительный параметр (хранящий ссылку на контекст)


Ага. А ещё этот контекст надо выделить на хипе. И подсчитывать ссылки, чтобы когда все лямбды, ссылающиеся на него, подохнут, освободить.

Спасибо, если мне нужны будут first-class functions, я возьму OCaml.
>>761804
sage #307 #761804
>>761799
Про atexit не слышал?
>>761805
#308 #761805
>>761804

>Про atexit не слышал?


Нет, аптайм — 18 лет.
#309 #761814
>>761796

> свести число глобальных имен к минимуму


С этим успешно справляется static. А если у тебя в одном модуле слишком много говна, это только повод разбить его на два.

> что в этом плохого


Без замыканий - в этом почти ничего плохого (ну кроме того, что об это сломается большинство существующих парсеров, включая давно не поддерживаемые).
>>761850
#310 #761850
>>761814
Может, еще для каждого типа данных заводить отдельный файл, как в жабе?
#311 #761866
>>761761
лямбды нужны для вещей типа "применить операцию к каждому элементу контейнера"
в крестах, в stl эта хуета нужна (но является по сути синтаксическим сарахком)
а на си ты же будешь по старинке перебирать все элементы контейнера и делать что-то с элементом (те тупо напишешь функцию)
для чего нужны "истинные" лямбды в функциональных языках, можно оставить за кадром
#312 #761867
>>761456

>указатель cru внутри reshift(), т.е., запишешь в него новый адрес, то функция main() об этом не узнает - ее собственная cru будет содержать все тот же адрес, что и был там до вызова reshift()


сразу вспомнил, как скрипят мозги новичков когда впервые видят код, напичканый указателями на указатель..
>>761892>>761903
#313 #761892
>>761867
А что в этом такого?
>>761914
#314 #761903
>>761867
Не заметил твоего ответа.

> в зависимости от того, нормально ли все или нет


Ну и возвращай NULL, если все плохо.

> возможно множественное открытие этого файла


Я тебе еще тогда советовал открыть файл один раз в main(), а в reshift его использовать:
int reshift(const char ∗in, int n, FILE ∗output)
и вместо шаманства с cru/stu писать в этот файл:
fputc(что-то, output);
Или даже так: берешь код из >>756235, идешь в main(), перед вызовом reshift пишешь if (!freopen("output.txt", "w", stdout)) { fprintf(stderr, "ниудалось"); return 1; } и код работает абсолютно идентично тому, чего ты пытаешься добиться уже пол-треда.
>>762408
#315 #761914
>>761892
они не понимают для чего это нужно
#316 #762358
Кто-нибудь знает, как заставить libevent дождаться отправки данных? Когда libevent вызывает соответствующий callback, данные, фактически, ещё не переданы и находятся во внутреннем буфере библиотеки.
#317 #762408
>>761903
Пока недалеко ушел.
По поводу ссылки на инт
в майне написано
int num;
reshift(..., &num);
в reshift написано
reshift(...int num);
reshift(...int num)
{
num++;
}
Так пишется?
>>762429>>762501
#318 #762429
>>762408
А тебе обязательно рекурсивно делать надо? Завести структуру типа
typedef struct open_file
{
FILE ∗file;
struct open_file ∗next;
struct open_file ∗prev;
} open_file;
И глобально хранить текущий указатель на файл.
>>762456>>762465
#319 #762456
>>762429
Рекурсивно обязательно, И проблема не в открытии файла, он тут не при чем. У меня на синтаксис с указателями на инт жалуется.
#320 #762465
>>762429
И кстати проблема и с массивом, если я хочу чтобы функция возвращала массив чар, то каков синтаксис?
я пишу так:
char reshift()
{
return cru;
}
но такой синтаксис кажется мне нелогичным и странным.
>>762471
24 Кб, 1027x545
#321 #762471
>>762465
Два примера, как возвращать.
>>762475>>762482>>762501
#322 #762475
>>762471
Используй умные указатели. unique_ptr там, вот это вот.
>>762494>>762501
#323 #762482
>>762471
А принимать
*cru=reshift();
?
>>762494
24 Кб, 1027x545
#324 #762494
>>762475

>умные указатели


>C


>>762482
char ∗cru = reshift();
Или выше по коду определяешь char ∗cru, потом присваиваешь cru = reshift();
>>762498>>762505
#325 #762498
>>762494
Пикча приклеилась.
#326 #762501
>>762408
++∗num или (∗num)++ или ∗num += 1.

>>762471
Ни то, ни другое. У тебя же там реаллок был?
char ∗reshift(...char ∗cru, int ∗stu) {
cru = realloc(cru, ...);
...
cru = reshift(..., cru, stu);
...
return cru;
}

int main(...) {
...
int stu = 0;
cru = reshift("input.txt", NULL, &stu);
...
}
Ну или можешь указатель на указатель передавать:
int reshift(..., char ∗∗ptr) {
char ∗my_local_cru = ∗ptr;
...
my_local_cru = realloc(my_local_cru, ...);
...
reshift(..., &my_local_cru, ...);
...
// и перед возвратом пихать обратно
∗ptr = my_local_cru;
return 0;
}
Но мне кажется, что мы тебя тут всем тредом окончательно запутали. Алсо, https://gist.github.com/anonymous/7030ec3709ea33c81f2bf21902023dd6

>>762475
Кресты в соседнем треде.
#326 #762501
>>762408
++∗num или (∗num)++ или ∗num += 1.

>>762471
Ни то, ни другое. У тебя же там реаллок был?
char ∗reshift(...char ∗cru, int ∗stu) {
cru = realloc(cru, ...);
...
cru = reshift(..., cru, stu);
...
return cru;
}

int main(...) {
...
int stu = 0;
cru = reshift("input.txt", NULL, &stu);
...
}
Ну или можешь указатель на указатель передавать:
int reshift(..., char ∗∗ptr) {
char ∗my_local_cru = ∗ptr;
...
my_local_cru = realloc(my_local_cru, ...);
...
reshift(..., &my_local_cru, ...);
...
// и перед возвратом пихать обратно
∗ptr = my_local_cru;
return 0;
}
Но мне кажется, что мы тебя тут всем тредом окончательно запутали. Алсо, https://gist.github.com/anonymous/7030ec3709ea33c81f2bf21902023dd6

>>762475
Кресты в соседнем треде.
>>762503>>762508>>762516
#327 #762503
>>762501

>Ни то, ни другое. У тебя же там реаллок был?


Не знаю, что у него было. Просто написал возможные варианты без привязки к его коду.
#328 #762505
>>762494
Ну вот и я так же пишу.
main:
int num;
crureshift(&num);
reshift(int *num)
{
num++;
}
Компилятор утверждает, что нельзя потому что num это указатель
>>762511
#329 #762508
>>762501
Так все таки через звездочку обращаться?
а какой в этом смысл если я принимаю так
reshift(int *num)
Алсо, большое спасибо.
>>762511
#330 #762511
>>762505

>Компилятор утверждает, что нельзя


Странный компилятор.
В твоём примере ты переходишь на следующий элемент, а не увеличиваешь его на единицу. Чтобы изменить переменную, указатель надо разыменовать - использовать ∗ перед ним.
>>762508

>reshift(int ∗num)


А так ты объявляешь, что передаёшь аргументы по ссылке, а не по значению.
#331 #762516
>>762501
Спасибо, код заработал
#332 #763358
Посоны накидайте планчик тем, что нужно знать с\с++ куну, чтобы
пробоваться джуниором.
>>763378
#333 #763378
>>763358
Умение отлизать бабе в HR-отделе, умение отсосать интервьюеру и умение давать в жопу тимлиду. Еще пригодится умение скрытно крысить печенье с рабочей кухни.

Если ты обладаешь всеми этими умениями, то добро пожаловать на собеседование.
>>763380
#334 #763380
>>763378
Чувак, ну отлизать там еще куда ни шло(если не жируха какакя), но заднеприводные темы это както по гейски, не?
Так че надо то, есть тут джуны?
>>763636
#335 #763381
Коданы, есть кроссплатформенный проект, но заточен под пидерскую МакОС (name.xcodeproj и все такое), есть ли способ конвертнуть его в ВижуалСтудию?
>>763397
#336 #763397
>>763381
Кинь ссылку. Это ведь наверняка попенсорс.
>>763691
#337 #763610
http://pastebin.com/izrVz4p0

Не понимаю, чому потребитель и производитель оба стопаются, как выполнят первые 10 элементов. Ну что за хуйня, 100 раз уже все проверил.
>>763708>>763938>>765098
#338 #763636
>>763380
А ты думал каждый может стать си джуном?
#339 #763691
>>763397
ня
https://github.com/lexborisov/myhtml
з.ы.
я так понял он собирается при помощи cmake, тогда можно конвертуть, вечером проверю.
з.з.ы
а яблочная ымперия разве свой особый конпелятор и сборщик не догодались спиздить?
#340 #763708
>>763610
Потому, что ты - рукожопая макака.

Называешь семафоры мьютексами, не можешь нормально реализовать решение из педивикии.

Гори в аду, мудак.
>>764190>>764196
#341 #763938
>>763610
Тому, что man sem_init, второй аргумент.
>>764193
#342 #764190
>>763708
В чем твоя проблема?
Мутекс - бинарный семафор.
#343 #764193
>>763938
Я думал, что это правильно только в случае предоставления доступа из разных потоков.
Неправильно прочел в доке.
Спасибо.
#344 #764196
>>763708
Какой педивикии, даун? Что в этом решении тебе не нравится?
Поставлена задача - сделать производитель/потребитель через shared memory и семафоры, твое какое нахуй дело? Кончай байтоебиться, а то совсем моча в голову бьет.
>>764290
#345 #764290
>>764196
Сам ты даун, блядь. Для продюсер-консюмер нужно строго два счетных семафора, а если продюссеорв или консюмеров может быть много, то тогда еще один мьютекс.

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

Тебе должно быть стыдно, кароч.
>>765072
#346 #764642
Господа, зачем нужен decltype, если есть auto?
>>764802
#347 #764802
>>764642
У нас нет ни auto, ни decltype. Тебе сюда >>764736 (OP).
#348 #765006
>>761537
Я - нет.
мимо-анон
#349 #765072
>>764290
Ну так там ведь без разделяемой памяти.
#350 #765098
>>763610

>потребитель и производитель


читани сначала что такое сопрограммы, потом как их на сишке эмулируют
сделай однопоточную реализацию
а потом уже многопоточную
иначе так и будешь биться лбом в собственный говнокод
>>765136
sage #351 #765136
>>765098
При чем тут нахуй копрограммы, когда там два отдельных процесса?
>>765198>>765223
#352 #765198
>>765136
Вово. Лишь бы обосрать
#353 #765223
>>765136
не причем
продолжай сосать
117 Кб, 850x544
#354 #765363
>>760649
>>760651
Спасибо вам. Накатил gedit
(>>760686 просто у меня lxde и не хотелось qt'шный редактор). С gcc в принципе разобрался. Нашелся даже плагин интегрирующий терминал в редактор. Пойду покорять задачники для девятиклассников.
>>767502
#355 #765558
накидайте норм туторов по libcpap. Нужно написать аналог tcpdump (с маленькими погрешностями). В офф.доке либы не особо разобрался, то есть так то все понятно, а вот как заставить это все вместе работать, я пока-что не понимаю.
>>765559
#356 #765559
>>765558
libpcap быстрофикс
>>765669
#357 #765669
>>765559
А то, что гугль показывает по запросу winpcap tutorial тебе чем не нравится? Понимание происходящего даст.
>>765875
#358 #765875
>>765669
нужен линух.Кстати, первая ссылка по winpcap tutorial это около того что мне надо. Но, на самом сайте tcpdump документация постепенно уходит не в ту степь.
#359 #766618
Полчаса сижу и не могу понять, почему:
1) бекспейс не считается за символ;
2) при написании слова (печатаю набор символов, жму пробел/таб/энтер), а потом его стирании бекспейсом, счетчик слов не изменяется.
Подскажите, пожалуйста!

#include <stdio.h>

#define IN 1
#define OUT 0

int main()
{
int c, nc, nl, nw, state;

state = OUT;
nc = nl = nw = 0;
while ((c = getchar()) != EOF) {
++nc;
if (c == '\n')
++nl;
if (c == ' ' || c == '\n' || c == '\t')
state = OUT;
else if (state == OUT) {
state = IN;
++nw;
}
}
printf("%d %d %d\n", nc, nl, nw);
}
#359 #766618
Полчаса сижу и не могу понять, почему:
1) бекспейс не считается за символ;
2) при написании слова (печатаю набор символов, жму пробел/таб/энтер), а потом его стирании бекспейсом, счетчик слов не изменяется.
Подскажите, пожалуйста!

#include <stdio.h>

#define IN 1
#define OUT 0

int main()
{
int c, nc, nl, nw, state;

state = OUT;
nc = nl = nw = 0;
while ((c = getchar()) != EOF) {
++nc;
if (c == '\n')
++nl;
if (c == ' ' || c == '\n' || c == '\t')
state = OUT;
else if (state == OUT) {
state = IN;
++nw;
}
}
printf("%d %d %d\n", nc, nl, nw);
}
>>766622>>766639
#360 #766622
>>766618
На ideone: https://ideone.com/n8L8qJ
1 Кб, 323x56
#361 #766639
>>766618

>1) бекспейс не считается за символ;


считается
>>766657
#362 #766657
>>766639
Вот, через пайп действительно работает так, как я рассчитывал:
$ echo -ne '1 \b2\n' | ./a.out
5 1 2

Но если запустить программу и ввести то же самое, получится:
$ ./a.out
12
3 1 1

Но почему во втором варианте программа считает уже по факту?
>>766663
#364 #766669
>>766663
Понял, спасибо!
732 Кб, 288x422
#365 #767502
>>765363
Почему все гайды по работе с gcc, упираются в с++? У меня, блять, джва дня ушло, чтобы дойти в одном из них до, подключения объявленых библиотек(типа math.h), зато узнал кучу пока не нужной дрисни по ООП.(да, в man gcc я был, но там сам чёрт сломит ногу от обилия всего)
>>767702
#366 #767702
>>767502

>да, в man gcc я был


зайди ещё в info gcc
>>767849
#367 #767837
>>749121 (OP)
Как юзать c++ библиотеки из C?
>>767839
#368 #767839
>>767837
Просто берешь и без задней мысли используешь.
А вообще пишешь обертку и вызываешь методы уже в виде Си-функций.
Вопрос гуглится на stackoverflow за секунду.
#369 #767849
>>767702
Команда не найдена. А вот gcc --h выдаёт основные ключи, но -l там нет.
>>767852
#370 #767852
>>767849
похоже что надо слазить с тырнет-говнокурсов и браться за кернигана&ритчи
>>767912
#371 #767912
>>767852
Что за тырнет-говнокурсы?
>>768144
#372 #768144
>>767912
http://www.youngcoder.net/
Ну может я чуть погорячился. Придумывать курсы для нулевых в информатике людей наверное та ещё жопа. Просто автор их по сути забросил, ответов на задания после 7(?) урока нет, в комментах домохозяйки, опускаться страшно.
Но они есть и на том ему спасибо.
#373 #768970
Господа, пользоваться CLion как основной IDE считается ли зашкваром?
>>768978>>769002
27 Кб, 256x192
#374 #768978
>>768970
Как и любой IDE.
Ты можешь выбрать только Emacs или vim.
#375 #769002
>>768970
Не считается. В крупном незнакомом проекте ты без IDE взвоешь. Особенно, если начнешь знакомство с рефакторинга, как это обычно бывает.
>>769018>>769029
#376 #769018
>>769002
grep откорой для себя.
>>769019
#377 #769019
>>769018
И ctags
#378 #769029
>>769002

>Особенно, если начнешь знакомство с рефакторинга


Опасность? IDE же может так нарефакторить, что обратно незарефакторишь.
>>769037
#379 #769037
>>769029
Так он же не говорил что с IDE лучше для результата.
Он говорил что с IDE - лучше для него.
Мозги можно не включать, охуенчик же.
#380 #769041
Есть два стула с циклами, в одном простое сравнение, в другом битоебство со сдвигом и маской, как узнать какой быстрей? В количествах инструкций битоебстов проигрывает, как посчитать количество процессорных циклов без смс и регистрации?
>>769043>>769046
#381 #769043
>>769041
з.ы.
типа такой шняги тока для итела
http://pulsar.webshaker.net/ccc/index.php?lng=us
#382 #769046
>>769041
Померять.
По количеству инструкций можно было что-то сказать о производительности уже очень, очень давно.
>>769052
#383 #769052
>>769046

>По количеству инструкций


это не правильная мера, ясчитаю, нужно в циклах , я считаю.
>>769065
#384 #769065
>>769052
Ну так фишка как раз в том что количество циклов от количества инструкций зависит самым ебанутым способом.
Префетчи, кэши, бренч предикшн, что сможет векторизовать компилятор и все это говно.
>>769070
#385 #769070
>>769065
ну для каждого проца известно сколько циклов требуется на инструкцию с опр. операндами, вот этого было бы достаточно для меры.
>>769087
#386 #769087
>>769070
Нет, неизвестно.
Современные процессоры давно уже non-deterministic, о чем я тебе пытаюсь объяснить уже битый час.
>>769098
#387 #769098
>>769087

>Нет, неизвестно


известно, http://zsmith.co/intel.html
то, что там интел или амд пердолится внутри процессора с выборками и прочими кешами к циклам не относится
>>769103>>769104
#388 #769103
>>769098
Нет, неизвестно.
Время выполнения той же самой инструкции с теми же самыми операндами может быть разным в зависимости от того как ляжет фишка - в какой блок памяти попадут данные, как инструкции лягут в instruction cache, и подобной хуиты. В несколько раз может отличаться только из-за этого.
Почитай хотя бы Линуса 2009 года http://yarchive.net/comp/linux/benchmarks.html
С тех пор прошло много времени и все стало в разы ебанутей
>>769105>>769118
#389 #769104
>>769098

> http://zsmith.co/intel.html


Охуенно, 486 у тебя современный процессор, ты под него запускать собрался? для 4004 ничего на нашел?
>>769118
187 Кб, 770x642
#390 #769105
>>769103
И не забывай что инструкции в современном процессоре не существуют отдельно от того что идет перед ними и после них. Поэтому даже вопрос "сколько циклов занимает эта инструкция" ставить некорректно.
>>769107
#391 #769107
>>769105
А это уже Skylake.

> There is a warm-up period of approximately 14 µs before it can execute 256-bit vector instructions at full speed. Apparently, the upper 128-bit half of the execution units and data buses is turned off in order to save power when it is not used. As soon as the processor sees a 256-bit instruction it starts to power up the upper half. It can still execute 256-bit instructions during the warm-up period, but it does so by using the lower 128-bit units twice for every 256-bit vector. The result is that the throughput for 256-bit vectors is 4-5 times slower during this warm-up period. If you know in advance that you will need to use 256-bit instructions soon, then you can start the warm-up process by placing a dummy 256-bit instruction at a strategic place in the code. My measurements showed that the upper half of the units is shut down again after 675 µs of inactivity.



Сколько же циклов занимает инструкция?
#392 #769118
>>769104
да
>>769103

>Почитай хотя бы Линуса


линусу я ссу в ротешник, он никто и звать его никак.

>Время выполнения той же самой инструкции с теми же самыми операндами может быть разным в зависимости от того как ляжет фишка


а вот это и плохо, есть некоторая последовательность кода, скорость которой нужно измерить в некоторых постоянных единицах, без всяких "как ляжет фишка", поэтому можно взять лист бумаги с ассемблерным кодом, на полях посчитать циклы, все.
>>769103

>"сколько циклов занимает эта инструкция" ставить некорректно


как корректно измерить код, в попугаях?
>>769121>>769125>>769127
#393 #769121
>>769118

> линусу я ссу в ротешник, он никто и звать его никак.


Залогиньтесь, мистер Таненбаум.
#394 #769125
>>769118

>можно взять лист бумаги с ассемблерным кодом, на полях посчитать циклы, все


Нельзя. Для этого ты должен знать стоимость каждой микрооперации, разложить их по execution-юнитам, и учесть все их inter-dependencies, как по данным, так и по внутренним пайплайнам. Для этого тебе нужно иметь полный код той машины состояний, которая рулит юнитами внутри процессора. Начни с покупки электронного микроскопа и возьми отпуск лет на тысячу, и займись.
>>769143
#395 #769127
>>769118

>как корректно измерить код, в попугаях


Использовать встроенный в CPU perf-counter. http://www.brendangregg.com/perf.html#Examples
Оценка будет приблизительной, ее можно использовать только для сравнения и только на той модели CPU, на которой производился замер.
>>769131>>769143
#396 #769131
>>769127
Желательно сделать несколько замеров, между ними перезагрузки машины. Так можно снизить роль флуктуаций той фишки, что неизвестно как ляжет - то что я говорил про instruction cache, например.

И не забудь освободить то ядро (или ядра), на котором ты собираешься мерять, от прерываний операционной системы. Не забудь крепко привязать свою тестовую программу к конкретному ядру.
Как это делается - нагуглишь.
>>769143
#397 #769143
>>769125
>>769127
>>769131
короче, вундеркинды, прогнал с замерами простым clock(), версия до семи параметров в условии дает пасасать битовой версии, при 20 параметрах медленней в джва раза, а вот при -O2 оптимизации, битовая версия сосет с проглотом во всех случаях. так что, битовый массив хуйня.
>>769152>>769154>>769164
163 Кб, 777x528
#398 #769152
>>769143

>короче, вундеркинды


Не мы такие, Интел такой.

Не забудь что твой микробенчмарк тоже хуйня, потому что в твоей большой прграмме всё будет не так.
65 Кб, 814x399
#399 #769154
>>769143
Что битовый массив - хуйня это я тебе мог и сразу сказать.
Но ты же умный дохуя, пиздел про битоебство со сдвигом и маской.
Сдвигать и маски накладывать надо на аккуратно выравненные слова. И иметь в виду оптимизации разных компиляторов.
>>769164
#400 #769164
>>769154

>надо на аккуратно выравненные слова


чем тебе bitset[4] не аккуратно выравненный?

>пиздел про битоебство со сдвигом и маской


без оптимизашки, как я уже говорил массив дает пасасать на более чем семи условиях, но проблема в диапазоне, думаю, до 32/64 бит за битовым массивом будет преимущество за счет того, что нет необходимости в вычислении индекса (как в моем четырехсловном массиве).

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

>>769143

>потому что в твоей большой прграмме всё будет не так


о, да.

>Не мы такие, Интел такой.


на интел тоже ссу, хочу обмазаться ARM
>>769186
#401 #769165
Хочу POSIX обмазаться. Скажите, как оно вообще, востребовано ирл или вообще никак?
#402 #769186
>>769164

> массив дает пасасать на более чем семи условиях


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

У ARM ты вообще головой перегреешься, когда его условные инструкции увидишь

> В то время как для других архитектур таким свойством, как правило, обладают только команды условных переходов, в архитектуру ARM была заложена возможность условного исполнения практически любой команды. Это было достигнуто добавлением в коды их инструкций особого 4-битового поля (предиката). Одно из его значений зарезервировано на то, что инструкция должна быть выполнена безусловно, а остальные кодируют то или иное сочетание условий (флагов).



Cortex M0 бери, он простой как пробка, только без кеша.
>>769193>>769196
#403 #769193
>>769186

> У ARM ты вообще головой перегреешься


а я теку по RISC архитектуре с его пиздатой организацией, а не это у x86-уебанство.

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


вообщем я уже поебал, все что надо прояснил, но может ты, чего добавишь, короче упрощенная версия:

1. есть константы в диапазоне 1-150
2. на вход идет байтовый массив произвольной длины с произвольными данными
3. нужно прекратить обработку данных если встречается байт из заданной последовательности
4. заданных последовательностей несколько в разных участках кода

int sub1(....)
{
while (
data != E_1 &&
data != E_2 &&
data != E_3 &&
data != E_5 &&
data != E_6 &&
data != E_7 &&
data != E_8 &&
data != E_9 &&
data != E_15 &&
data != E_16 &&
data != E_17 &&
data != E_18
) {

...
}
}

int sub2(....)
{
while (
data != E_8 &&
data != E_9 &&
data != E_10 &&
data != E_11 &&
data != E_12 &&
data != E_13 &&
data != E_14 &&
data != E_15 &&
data != E_16 &&
data != E_17 &&
data != E_18
) {
...
}
}

и т.п.
#403 #769193
>>769186

> У ARM ты вообще головой перегреешься


а я теку по RISC архитектуре с его пиздатой организацией, а не это у x86-уебанство.

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


вообщем я уже поебал, все что надо прояснил, но может ты, чего добавишь, короче упрощенная версия:

1. есть константы в диапазоне 1-150
2. на вход идет байтовый массив произвольной длины с произвольными данными
3. нужно прекратить обработку данных если встречается байт из заданной последовательности
4. заданных последовательностей несколько в разных участках кода

int sub1(....)
{
while (
data != E_1 &&
data != E_2 &&
data != E_3 &&
data != E_5 &&
data != E_6 &&
data != E_7 &&
data != E_8 &&
data != E_9 &&
data != E_15 &&
data != E_16 &&
data != E_17 &&
data != E_18
) {

...
}
}

int sub2(....)
{
while (
data != E_8 &&
data != E_9 &&
data != E_10 &&
data != E_11 &&
data != E_12 &&
data != E_13 &&
data != E_14 &&
data != E_15 &&
data != E_16 &&
data != E_17 &&
data != E_18
) {
...
}
}

и т.п.
>>769196>>769199
#404 #769196
>>769186
>>769193
но sub1, sub2, sumN я бы мог заменить

int sub(..)
{
while (!(bitset[data / 32] & 1 << data % 32)) {
...
}
}

но с обосрамсом по скорости...
#405 #769199
>>769193
>>769193

макака индексы проебал как всегда... эх
>>769202
#406 #769202
>>769199
pastebin для кого делали?
Чтоб не гадать какие именно индексы и где проебались.
>>769205>>769222
#407 #769205
>>769202
Хотя уже из текстового описания ясно что тебе для скорости лучше всего сделать вот что. Образцы, с которыми ты сравниваешь входной поток, разложить в вектора и сравнивать сразу по N штук SIMD-командами.
>>769215>>769222
#408 #769215
>>769205
Если разбираться с SIMD тебе некогда, хотя бы убери образцы из дохуя переменных и положи их в массив, и проходи по нему ровно - тогда есть шанс что хороший компилятор сам тебе векторизует. Но шанс невеликий, особенно если компилятор не интеловский.
И байтовый поток тоже желательно брать не по байту, а хотя бы по 4, и сравнивать так - первый байт с первым образцом, второй со вторым, третий с третьим, четвертый с четвертым - процессор сам распараллелит и со второго по четвертое сравнение тебе достанутся бесплатно, а шанс что на 1-3 байта впереди встретится совпадение - есть.
#409 #769222
>>769202
считай data массивом в 4 слова
>>769205
на самом деле входной поток представляет собой связанный список, где есть ID, по которому и определяется дальнейшее действие с узлом, я про массив просто упростил, в любом случае, порциями читать я не могу, да и нужен переносимый код без всяких SIMD
>>769274
#410 #769274
>>769222

> связанный список


Твоей производительности уже пиздец. Переделывай на массив.

Переносимость достигается использованием интринсинков
>>769303
#411 #769303
>>769274

>Твоей производительности уже пиздец


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

>интринсинков


в душе не ебу что это такое, но полагаю что это специфическая хуета которая нинужна
>>769413
#412 #769413
>>769303
Ну ты охуеть вообще. Занимаешься оптимизациями, не зная про интринсики. Это такие псевдо-функции, которые компилятор предоставляет для доступа ко всяким архитектурно-зависимым хреням. Они часто разворачиваются в одну инструкцию, что позволяет, например, использовать в программе на Си какое-нибудь SSE абсолютно без оверхеда и без ассемблера.

Алсо, ты можешь четко ответить: какого хуя ты считаешь себя умнее компилятора и не используешь switch? Ты тестировал производительность? Ты сравнивал с lookup table, когда у тебя много условий?
>>769465
#413 #769465
>>769413

>Занимаешься оптимизациями, не зная про интринсики.


успокойся и выпей смузи, я против всякой новомодной хуйни, темболее SSE, которое на том же ARM нихуя не канает

>используешь switch


>lookup table


ну это же сорта одного говна, только вместо битового массива будет создаваться просто массив, из за трех условий нужно создавать lookup table/массив размером 120 x int 32/64? нахуй. хотя доступ по массиву будет быстрей, нет нужды в вычислении индекса... подозреваю, что конпелятор с -О2 так и поступает
>>769519
sage #414 #769519
>>769465

> новомодной хуйни


Компиляторы делают это с тех пор, как появились.

> конпелятор с -О2 так и поступает


Он по-разному поступает, в зависимости от значений констант в switch. А вот аналогичный if несколькими сравнениями не все компиляторы и не всегда могут оптимально развернуть.
>>769692
#415 #769692
>>769519

>Он по-разному поступает, в зависимости от значений констант в switch


т.е. есть некие общие для всех конпеляторов алгоритмы оптимизации? Одни где то описаны? Хочу почитать и стать конпелятором.
>>769696
#417 #769699
>>769696
пасиб

хотя я вот пробежался, там оптимизация уровня прибирания за рукожопыми обезьянами, типа: i/2 => i>>2
>>769704>>769705
49 Кб, 821x616
#418 #769704
>>769699
Про https://en.wikipedia.org/wiki/Static_single_assignment_form еще почитай.

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

Такова сишечка и таковы современные процессоры.

> By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine



Как мы дожили до такого маразма - http://pastebin.com/UAQaWuWG

В нормальных, высокоуровневых языках существует множество других техник оптимизации, навороченных по самое-самое. Как пример можешь на Haskell посмотреть. В Хаскеле вообще не используется классический стек вызовов "push/call/return/pop", т.к. его невозможно использовать при call by need. Соответственно, и оверхед при бета-преобразовании совсем другой, чем был бы, если бы просто добавился "push/call/return/pop". Особенность ленивых языков в том, что их невозможно реализовать эффективно на стековых машинах. Соответственно, в процессе наивного исполнения программы выполняется чудовищное количество аллокаций в куче и косвенных вызовов, делающее невозможным использование таких языков на практике. Для того, чтобы сколь-нибудь приемлемо выполнять программы, рантайм-библиотеки ленивых языков содержат хитрые программные исполнители (SECD-machine, G-machine, PABC-machine) вместо стековых машин, реализованных аппаратно посредством поддержки инструкций call/push/pop/ret процессором. Хаскелевская G-machine вообще не использует инструкций call/ret. И затем поверх этих исполнителей накручивается гигантский оптимизатор на порядок эффективнее сишного. Вот благодаря противодействию ускоряющего сверхмощного оптимизатора и замедляющего уебищного исполнителя Хаскель и получает почти паритет с сишечкой по скорости.

Проблема Хаскеля в том, что оптимизатор ускоряет программы на порядки (в сотни раз), и несрабатывание его в каком-то месте так же замедляет программу на порядки. Однако, как мы видим в этом ITT-треде, современные процессоры постарались и сделали написание и оптимизацию сишного кода, к которому прелъявляются требования к производительности, уже настолько неинтуитивным, что почти однохуйственно и профайлер, профайлер и еще раз профайлер.
49 Кб, 821x616
#418 #769704
>>769699
Про https://en.wikipedia.org/wiki/Static_single_assignment_form еще почитай.

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

Такова сишечка и таковы современные процессоры.

> By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine



Как мы дожили до такого маразма - http://pastebin.com/UAQaWuWG

В нормальных, высокоуровневых языках существует множество других техник оптимизации, навороченных по самое-самое. Как пример можешь на Haskell посмотреть. В Хаскеле вообще не используется классический стек вызовов "push/call/return/pop", т.к. его невозможно использовать при call by need. Соответственно, и оверхед при бета-преобразовании совсем другой, чем был бы, если бы просто добавился "push/call/return/pop". Особенность ленивых языков в том, что их невозможно реализовать эффективно на стековых машинах. Соответственно, в процессе наивного исполнения программы выполняется чудовищное количество аллокаций в куче и косвенных вызовов, делающее невозможным использование таких языков на практике. Для того, чтобы сколь-нибудь приемлемо выполнять программы, рантайм-библиотеки ленивых языков содержат хитрые программные исполнители (SECD-machine, G-machine, PABC-machine) вместо стековых машин, реализованных аппаратно посредством поддержки инструкций call/push/pop/ret процессором. Хаскелевская G-machine вообще не использует инструкций call/ret. И затем поверх этих исполнителей накручивается гигантский оптимизатор на порядок эффективнее сишного. Вот благодаря противодействию ускоряющего сверхмощного оптимизатора и замедляющего уебищного исполнителя Хаскель и получает почти паритет с сишечкой по скорости.

Проблема Хаскеля в том, что оптимизатор ускоряет программы на порядки (в сотни раз), и несрабатывание его в каком-то месте так же замедляет программу на порядки. Однако, как мы видим в этом ITT-треде, современные процессоры постарались и сделали написание и оптимизацию сишного кода, к которому прелъявляются требования к производительности, уже настолько неинтуитивным, что почти однохуйственно и профайлер, профайлер и еще раз профайлер.
>>769708
49 Кб, 821x616
#419 #769705
>>769699
Про https://en.wikipedia.org/wiki/Static_single_assignment_form еще почитай.

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

Такова сишечка и таковы современные процессоры.

> By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine



Как мы дожили до такого маразма - http://pastebin.com/UAQaWuWG

В нормальных, высокоуровневых языках существует множество других техник оптимизации, навороченных по самое-самое. Как пример можешь на Haskell посмотреть. В Хаскеле вообще не используется классический стек вызовов "push/call/return/pop", т.к. его невозможно использовать при call by need. Соответственно, и оверхед при бета-преобразовании совсем другой, чем был бы, если бы просто добавился "push/call/return/pop". Особенность ленивых языков в том, что их невозможно реализовать эффективно на стековых машинах. Соответственно, в процессе наивного исполнения программы выполняется чудовищное количество аллокаций в куче и косвенных вызовов, делающее невозможным использование таких языков на практике. Для того, чтобы сколь-нибудь приемлемо выполнять программы, рантайм-библиотеки ленивых языков содержат хитрые программные исполнители (SECD-machine, G-machine, PABC-machine) вместо стековых машин, реализованных аппаратно посредством поддержки инструкций call/push/pop/ret процессором. Хаскелевская G-machine вообще не использует инструкций call/ret. И затем поверх этих исполнителей накручивается гигантский оптимизатор на порядок эффективнее сишного. Вот благодаря противодействию ускоряющего сверхмощного оптимизатора и замедляющего уебищного исполнителя Хаскель и получает почти паритет с сишечкой по скорости.

Проблема Хаскеля в том, что оптимизатор ускоряет программы на порядки (в сотни раз), и несрабатывание его в каком-то месте так же замедляет программу на порядки. Однако, как мы видим в этом ITT-треде, современные процессоры постарались и сделали написание и оптимизацию сишного кода, к которому прелъявляются требования к производительности, уже настолько неинтуитивным, что почти однохуйственно и профайлер, профайлер и еще раз профайлер.
49 Кб, 821x616
#419 #769705
>>769699
Про https://en.wikipedia.org/wiki/Static_single_assignment_form еще почитай.

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

Такова сишечка и таковы современные процессоры.

> By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine



Как мы дожили до такого маразма - http://pastebin.com/UAQaWuWG

В нормальных, высокоуровневых языках существует множество других техник оптимизации, навороченных по самое-самое. Как пример можешь на Haskell посмотреть. В Хаскеле вообще не используется классический стек вызовов "push/call/return/pop", т.к. его невозможно использовать при call by need. Соответственно, и оверхед при бета-преобразовании совсем другой, чем был бы, если бы просто добавился "push/call/return/pop". Особенность ленивых языков в том, что их невозможно реализовать эффективно на стековых машинах. Соответственно, в процессе наивного исполнения программы выполняется чудовищное количество аллокаций в куче и косвенных вызовов, делающее невозможным использование таких языков на практике. Для того, чтобы сколь-нибудь приемлемо выполнять программы, рантайм-библиотеки ленивых языков содержат хитрые программные исполнители (SECD-machine, G-machine, PABC-machine) вместо стековых машин, реализованных аппаратно посредством поддержки инструкций call/push/pop/ret процессором. Хаскелевская G-machine вообще не использует инструкций call/ret. И затем поверх этих исполнителей накручивается гигантский оптимизатор на порядок эффективнее сишного. Вот благодаря противодействию ускоряющего сверхмощного оптимизатора и замедляющего уебищного исполнителя Хаскель и получает почти паритет с сишечкой по скорости.

Проблема Хаскеля в том, что оптимизатор ускоряет программы на порядки (в сотни раз), и несрабатывание его в каком-то месте так же замедляет программу на порядки. Однако, как мы видим в этом ITT-треде, современные процессоры постарались и сделали написание и оптимизацию сишного кода, к которому прелъявляются требования к производительности, уже настолько неинтуитивным, что почти однохуйственно и профайлер, профайлер и еще раз профайлер.
#420 #769708
>>769704

>Во-вторых, оптимизация для современных процессоров это


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

мне больше импонирует простой кроссплатформенный конпелятор в 10000 строк кода, чем еба GCC с миллионами строк непонятного говна которое хуй пойми как работает и что делает с моим няшным кодом
>>769716
#421 #769716
>>769708
Watcom был с одной стороны компилятором очень хорошим, с другой - со значительным количеством своих багов (не так много) и заебов (больше). Люди его писали очень умелые, но собственно компиляторных хитростей в нем никаких сверхъестественных (почти) не было, просто люди умели хорошо (очень хорошо) писать код.
Они это потом еще лучше продемонстрировали своим Watcom SQL, который купил у них Sybase - мобильный edition sql-сервера, работающий с транзакциями и полной поддержкой SQL на огрызках памяти ранних PocketPC, и делающий это быстро это было очень впечатляюще.

Сейчас ваткомовский компилятор, конечно, по современным меркам ни на что не годится.
>>769718>>769719
#422 #769718
>>769716

>по современным меркам ни на что не годится.


по каким меркам? он собирает невалидный код? я вот раньше хотел обмазаться вaткомом, выпилить от туда плюсы и фортран, сделать няшу, свой йоба болден конпелятор. но пока выкатился из с. и да, мне в ваткоме все нравилось, включая исходники и мне пиздец как пичет, что такой мегаохуенный проект заброшен, но ниче, я до него доберусь.
>>769725>>769726
#423 #769719
>>769716

>компиляторных хитростей в нем никаких сверхъестественных (почти) не было


да, и вот этим тоже он мне нравится
>>769726
#424 #769725
>>769718

> по каким меркам? он собирает невалидный код?


Перестал развиваться же. А валидный код и C++ Builder собирает. Сейчас самый оптимизирующий - Intel C/C++.

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


Он сейчас опенсурсный, пожалуйста: www.openwatcom.org
Только никому это не нужно, все на GCC сидят.
>>769728
#425 #769726
>>769718
Валидный, но тормозной по сегодняшним меркам.

>>769719
Ну бери и используй если нравится.
>>769728
#426 #769728
>>769725

>Он сейчас опенсурсный


кэп?
>>769725

>самый оптимизирующий - Intel C/C++


ну и нахуй он кроме интела где нужен?
>>769725

>GCC


это очень плохо, гцц это же ебаный франкенштейн, типа ядра линуха
>>769726

> но тормозной по сегодняшним меркам.


в цифрах можешь сказать на сколько он тормознутый?
>>769731>>769733
#427 #769730
>>754237
Мелкие утилиты или игори на нем пишут. Напиши платформер про Ватника в стиле Super Mario Bros.
>>769734
#428 #769731
>>769728

> ну и нахуй он кроме интела где нужен


У тебя вокруг одни альфы с итаниумами штоле?

> в цифрах


Возьми, померяй - приходи, расскажи.
>>769735
#429 #769732
>>754237
Посмотри например сколько модулей для nginx на одно только гитхабе понаписали.
#430 #769733
>>769728

>это очень плохо, гцц это же ебаный франкенштейн, типа ядра линуха


Что плохого-то? Что поддерживает любой стандарт? Что в оптимизациях с переменным успехом даёт пососать интеловскому компилятору?
>>769736>>769739
#431 #769734
>>769730
Это пуревасику оставь.
#432 #769735
>>769731

>У тебя вокруг одни альфы с итаниумами штоле?


есть ARM на который я начинаю теребонькать, есть ОС отличные от виндовз
>>769731

>Возьми, померяй


обозвал конпелятор тормозом, а теперь мерять отправляет, хитрюша
>>769737>>769740
#433 #769736
>>769733
Он имел в виду что gcc сложный внутри. Это действительно так, хотя сейчас немного и почистили, и документировали.
Зачем он собрался лезть внутрь сишного компилятора в 2016 году - оставим эту задачу его психоаналитику
>>769738
#434 #769737
>>769735
Арм настолько редкий, что ни один форк GCC или бэкэнд шланга его не поддерживает?

Посмотри когда закончилось его развитие, на этом всё.
#435 #769738
>>769736
Любой большой проект очень сложный внутри, особенно такой, в котором куча легаси и помойка из разных языков.
>>769742
#436 #769739
>>769733

>Что плохого-то


то, что в нем уже напрочь отсутствует какая либо четкая архитектура, излишне усложнен, много избыточного кода. наврядли есть хоть один человек, полностью понимающий его работу.
#437 #769740
>>769735
ОС отличные от виндовз gcc, intel и clang умеют. Если тебе нужны очень отличные от виндовз типа zOS или OpenVMS - то одинхер ватком тебя не спасет.

Для ARM кроме кейла никто нормально не конпелирует.
>>769823
#438 #769741
>>755749
Хе-хе я еще будучи школотой и пописывая на турбо паскале, тралил сиблядей медленными строками. Они кричали что я дурак и сопляк и говорили, что ЗАТО У НАС СТРОКИ ЛЮБОЙ ДЛИНЫ.
>>769743
#439 #769742
>>769738
и в один прекрасный момент все это может ебнуться под своим весом. но это не главная причина того, что это плохо
>>769745
#440 #769743
>>769741
Тоже мне.
Ты бы их временем линковки тралил - вот это было б дело. Рассказал бы им про TPU и как ты на победном Turbo Vision имеешь интерактивность разработки практически как у какого-нибудь Лиспа.
>>769746
#441 #769744
>>755749

> Да, надо было посчитать байты вручную и забить полученное число в первый байт строки. Ленивые программисты иногда писали так (и получали медленные программы):


>


> char str = "Hello!";


> str[0] = strlen(str) - 1;


>


> Обратите внимание, что в данном случае вы получаете строку, которая имеет замыкающий нулевой байт на конце (его добавляет компилятор), и при этом является паскалевской. Я использовал для таких строк термин fucked strings, потому что называть их паскалевские строки с нулевым байтом в конце очень длинно (мне можно, это канал для взрослых, вам придётся использовать более длинное название).



Жид не врубился в тему, ебаные строки нужны, когда тебе в твоей проге (с нормальными паскалевскими строками) нужно вызвать функцию из сишной библиотеки, например из WinAPI.
#442 #769745
>>769742
Я же тебе говорю что у gcc тенденция обратная - он вычищается и становится прямее, а не копит кривизну.
>>769747
#443 #769746
>>769743
Turbo Vision не осилил. Сначала писал свою библиотеку для GUI (на VESA), потом перешел на винду и Delphi.
>>769748>>769749
#444 #769747
>>769745
кем он вычищается, если никто не знает как он работает?
>>769749>>769752
#445 #769748
>>769746

>Delphi


фуфуфу
>>769749>>769751
#446 #769749
>>769747
Разработчиками он вычищается.

>>769746
Ну Delphi логичное развитие Turbo Vision, легко было перезжать.

>>769748
Попизди мне тут. Более удобного RAD под винду формочки шлепать не было, нет и не будет. Если бы микроскопичееский софт не перекупил бы из Борланда 37 человек во главе с Хейлсбергом - всю команду практически - потому что нихуя не мог тягаться по-честному, сейчас все по-другому бы было.
>>769754>>769755>>769756
#447 #769751
>>769748
Для написания виндовых программ самый лучший инструмент, всяко лучше визуального бейсика.
#448 #769752
>>769747

>никто не знает как он работает


лол, обычная ситуация для больших проектов. Почитай фактор автобуса.
>>769753>>769762
#449 #769753
>>769752
Да не слушай ты его. Дохрена народу, который знает досконально как что работает. Почитай их мейлинг-лист блджад штоле
>>769759
#450 #769754
>>769749

> Ну Delphi логичное развитие Turbo Vision, легко было перезжать.


Возможно. На Turbo Vision не было рисования форм мышкой. Да и не привлекал как-то GUI на псевдографике. Хотя была какая-то библиотека, тот же Turbo Vision, но графический, и вроде даже VESA 1.2 поддерживал.
>>769758>>769761
#451 #769755
>>769749

>Разработчиками он вычищается


чистили, чистили и решили запилить очередно говно типа llvm
>>769760
#452 #769756
>>769749

> Более удобного RAD под винду формочки шлепать не было, нет и не будет.


Ну Qt вроде неплох, если закрыть глаза на язык (а можно и подключить другой вместо крестов).
#453 #769758
>>769754
Да и без того было удобно. Я ж говорю - интерактивность как у Лиспа была, за счет пересборки проекта с сверхзвуковой скоростью. Ну и сам Turbo Vision летат аки самолет и не тормозил на самых медленных ПеКа - у него большая часть натурально на ассемблере внутри была написана.
>>769769
#454 #769759
>>769753
да, да, все там все знают, еще скажи, что торвальдс в своем ядерном говне что то там понимает
>>769764
#455 #769760
>>769755
Говно типа LLVM решил запилить совершенно посторонний мудень. Поддержали же его в этом корпорасты, которым GPL поперек горла.
>>769765
#456 #769761
>>769754
Была, но не объектно-ориентированная совсем, тупая как бревно. А TV был для того времени охуенно технологичная штука.
>>769773
#457 #769762
>>769752

>лол, обычная ситуация для больших проектов.


вот как можно писать проекты на миллионы строк кода? это же пиздос, это уже показатель токо что с проектом что то не то. мир сошел с ума нахуй
>>769764
#458 #769764
>>769759
>>769762
Да нормально, вы тут пизданулись с чего-то?
Чего вам в Linux ядре непонятно?
>>769766>>769786
#459 #769765
>>769760

>Говно типа LLVM решил запилить совершенно посторонний мудень.


те, кто понял, что легче создать новое, чем ковырятся в гцц
>>769768
#460 #769766
>>769764

>Чего вам в Linux ядре непонятно


как из Minixа можно было сделать такое уебанство как Linux
#461 #769768
>>769765
Мотивация была не в этом, не знаешь - не пизди, не вводи людей в заблуждение.
GCC отказывались выдавать корпорастам промежуточное представление для запиливания своих проприетарных поделок которые бы использовали gcc как бэкенд и ничего не возвращали бы миру свободного ПО.
Вот этот мудень и стал пилить LLVM чтоб корпорастам стало хорошо.
>>769781
#462 #769769
>>769758
Видимо, это ключевое:

> Да и не привлекал как-то GUI на псевдографике.


Тот порт для VESA я так и не нашел. А про скорость согласен, Турбо Паскаль никогда не тормозил, проекты собирались за секунду (как и в Delphi).
У сишников ЕМНИП тогда и precompiled headers не было.
>>769770>>769774
#463 #769770
>>769769
С precompiled сильно лучше не стало, основные тормоза в большом проекте были в линкере, и эту проблему решить нельзя
>>769775
#464 #769773
>>769761
Нет, она тоже называлась как-то-там Vision (точно не помню), и была объектно-ориентированной. Но появилась поздно, когда все перешли на винду.
#465 #769774
>>769769
GraphicsVision она называлась.

С псевдографикой номрально все было, я когда надо знакогенератора перепрограммировал, добавлял вместо неиспользуемых буковок нужные графические примитивы - чертежи рисовать было вполне охуенно
#466 #769775
>>769770
А что там? Разве паскаль и си создают объектные файлы разных форматов?
>>769776
#467 #769776
>>769775
а еще Земля вращается вокруг Солнца, удивись
>>769778
#468 #769778
>>769776
И в чем разница?
>>769779
#469 #769779
>>769778
Во всем. http://prog21.dadgum.com/47.html

> Turbo Pascal used a custom object file with a minimal design. The "linker" wasn't doing anywhere near the work of standard linkers. The result was that the link step was invisible; you didn't even notice it

>>769790>>769793
#470 #769781
>>769768
The LLVM project started in 2000 at the University of Illinois at Urbana–Champaign, under the direction of Vikram Adve and Chris Lattner. LLVM was originally developed as a research infrastructure to investigate dynamic compilation techniques for static and dynamic programming languages.

в качестве исследования, исследовать гцц они побрезговали
>>769787
sage #471 #769784
Что вы там оптимизируете, дауны? Выбор подходящих алгоритмов и структур данных даст больший прирост производительности, чем ваши ручные копрооптимизации. Поссал на байтоебов.
>>769789>>769791
#472 #769786
>>769764
возьми отпуск в 1000 лет, изучи кодовую базу ядра линукс
>>769788
#473 #769787
>>769781

>Chris Lattner


Вот он, этот мудень корпорастический.
Исследования в американских университетах это совсем не то что в твоем заборостроительном воронежском ПТУ. Их заказывают корпорации и спонсируют некислым баблом. А корпорациям GPL НЭНАДА.
#474 #769788
>>769786
Блджад, ну что там изучать? Да, как в любом проекте есть кривые и сложные места. Но в целом очень все понятно и стройно.
>>769803>>769804
#475 #769789
>>769784

>чем ваши ручные копрооптимизации


мы тут как раз об автоматических толкуем
#476 #769790
>>769779
Ты на вопрос не ответил. Сам Turbo Pascal не создает объектных файлов, он лишь подключает объектные файлы от других языков (Turbo C, Assembler и т.д.). Там и линкера по сути нет, просто компилятор, который умеет подключать к твой проге объектные файлы (OBJ) и статические библиотеки (TPU).
>>769792
#477 #769791
>>769784

>подходящих


Теперь уебывай отсюда пока не задумаешься над смыслом и значением этого слова.
#478 #769792
>>769790
Ну а я про что говорю? Пока сишник за соседней машиной линкует, ты уже пять раз пересобрал, все поправил и у мамки молодец.
>>769796
#479 #769793
>>769779

> Turbo Pascal used a custom object file with a minimal design.


Не помню такого. Там при компиляции создавался сразу EXE или COM файл, ничего лишнего.
>>769795
#480 #769795
>>769793
TPU
>>769797
#481 #769796
>>769792
Ага, все понял. Там можно обходиться без линкера, а сишнику - хуй.
>>769798
#482 #769797
>>769795
Это для unit'ов только.
>>769799
#483 #769798
>>769796
А сиплюсплюснику совсем была жопа.
На 286 заебешься проект собирать, покурить сходить успеешь
>>769800
#484 #769799
>>769797
А тебе что нужно при разработке на трубопаскакале кроме основной программы и библиотек, сконпелированных в юниты?
>>769802
#485 #769800
>>769798
Интересно, почему жаба и шарп так быстро не собирают, там ведь все библиотеки уже откомпилированы?
У них компилятор конечно быстрее крестового, но все равно приходится ждать.
>>769801
#486 #769801
>>769800
Потому что не паскаль. В нем специально все было Борландой заточено
>>769805
#487 #769802
>>769799
TPU это не объектный файл, это все-таки статическая библиотека.
>>769806
#488 #769803
>>769788
знаток линупса в треде, готов спорить, ты не вылазил за пределы кода для x86
127 Кб, 800x561
#489 #769804
>>769788
действительно
#490 #769805
>>769801
Так шарп вроде те же люди делали.
>>769809>>769810
#491 #769806
>>769802
Учтивый малый, НО ПЕДАНТ

В экосистеме турбо паскаля и дельфи они играли роль аналога объектного файла из си-экосистемы. Не обладая той же универсальностью и пригодностью для использования универсальными линкерами для сборки из стотыщ объектвных файлов написанных на стотыщах языков (которая нахуй никому в реальной жизни никогда не была нужна кроме старых фортранщиков - и настоящий объектный файл все-таки можно вроде было из паскакаля сделать - но никто не пробовал потому что нахуй никому не надо), они были заточены под скорость.
>>769814
#492 #769809
>>769805

>Так шарп вроде те же люди делали


я думал она просто спизлили Джаву
>>769814
#493 #769810
>>769805
У шарпа задача была - вот вам васик, вот вам COM, добавьте к этому такую Java чтоб была не Java и попытаемся с этой всей хуйней взлететь. Да, и еще вам в помощь индусов две сотни, которые нихуя не умеют.
>>769813
#494 #769813
>>769810
А чтоб было не грустно, вот вам за то что ушли из Борланды по миллиону долларов бонусов на рыло (хейлсбергу больше).
Да им похуй уже было на все с такими бонусами, сделали на отъебись.
#495 #769814
>>769806
В объектных файлах (.OBJ) не было описания функции (имена были, типов параметров и результата не было), поэтому их нельзя было использовать как статические библиотеки. В отличие от TPU.
Turbo Pascal не мог создавать объектные файлы, но мог подключать их от других языков.

>>769809
C# - это гибрид Java и Delphi.
>>769818
#496 #769818
>>769814
Это при том что именно язык в Delphi не был сильной стороной, но всем было пофиг. Потому что охуительнейшая IDE, охуительнейшая VCL (напоминаю - кроме ебанутой MFC и голого Win32API других вариантов в сишечке не было), охуительнейшая система компонентов, охуительнейший авыбор этих компонентов, подключаемых одной левой.
Эффективность работы с этим комбайном была потрясающая, от языка там мало что зависело - на Алгол похож и ладно
>>769821>>769825
#497 #769821
>>769818
Язык как язык. Только массивы были криво реализованы (в C массив = указатель, что позволяло легко создавать динамические массивы), ну begin-end еще бесит, а остальное норм. С массивами такая шняга, потому что по Вирту они контролировать выход за границы диапазона.
>>769826
#498 #769823
>>769740
Да ты охуел забывать IAR. Богомерзкая ide, но компилер то вполне.
>>769827
#499 #769825
>>769818
Меня больше сишный синтаксис раздражает, все эти лишние скобки, прямо недолисп какой-то. И везде этот синтаксис засовывают - Java, C#, PHP, JavaScript...
>>769828
276 Кб, 1024x768
#500 #769826
>>769821

>на Алгол похож и ладно


Я и говорю.

Плюс к тому - все это конпелировалось в один небольшой EXE, влезало на дискетку и неслось заказчику в обмен на бабло.

С микрософтными же уебными мегатехнологиями надо было еще собрать кучу DLL, попробуй забудь хоть одну, попробуй положить несовместимые с теми версиями виндовз что у заказчика, попробуй это говно упакуй инсталлятором и попробуй запихни на дискеты.
#501 #769827
>>769823
Да, кейла и иара.
>>769831
#502 #769828
>>769825
В Lua заебись зделали - begin end.
И массивы с единицы нумеруются.
И летает на LuaJIT.
#503 #769831
>>769827
Вот теперь порядок.
7 Кб, 320x200
#504 #769843

> The first major OO language for PCs was Borland Turbo Pascal 5.5, introduced in 1989. Oh, sure, there were a few C++ compilers before that, but Turbo Pascal was the language for MS-DOS in the 1980s, so it was the first exposure to OOP for many people. In Borland's magazine ads, inheritance was touted as the big feature, with an example of how different variants of a sports car could be derived from a base model. What the ads didn't mention at all was encapsulation or modularity, because Turbo Pascal programmers already knew how to do that in earlier, pre-object versions of the language.

#505 #769848
Анон, который не любит сложные оптимизирующие компиляторы, для тебя написали
"On the Madness of Optimizing Compilers"
http://prog21.dadgum.com/217.html
>>769866>>769872
#506 #769866
>>769848
там по соседству http://prog21.dadgum.com/136.html
..
Oberon's maxim of making things "as simple as possible"
..
Trying to make an optimizing compiler as simple as possible and yet as powerful as necessary requires
...

практически описали мое взгляд на конпиляторы
>>769874>>769878
#507 #769872
>>769848
з.ы.
James Hague дельные вещи пишит, хотя я бы еще и динамические библиотеки абассал
>>769875
#508 #769874
>>769866
Судя по использованию Модулы-2 с неебического качества компиляторами типа XDS, заверенного всеми печатями в оборонках, этот подход имеет право на существование.

Но зачем Вирт так издевался над синтаксисом?

> Синтаксис алгола 60, который Вирт потом последовательно ухудшал, не разрабатывался с какой-бы то ни было целью. Это был первоначальный набросок, от которого потом довольно быстро ушли. Собственно, и ML-ный синтаксис (через ISWIM и Hope) и Сишный (через алгол 68 и CPL) произошли от синтаксиса алгол 60, но изменения делались с целью сделать что-то удобно. Изменения которые делал Вирт, по всей видимости, делались с целью "показать им всем"

>>769877
#509 #769875
>>769872
Ну давайте еще и динамическое распределение памяти заклеймим.
Потом и стек тоже.
Вернемся к временам Фортрана со статическим распределением памяти и нахуй рекурсии.
>>769879
#510 #769877
>>769874

>Изменения которые делал Вирт, по всей видимости, делались с целью "показать им всем"


кек, вот и ответ

>этот подход имеет право на существование


ну тащемто это был основной взгляд на разработку ПО, когда его еще разрабатывали инженеры. вещи/программы должны быть простыми (в разумных пределах), как я уже говорил, если программа большая, то с ней явно что то не то.
>>769880
#511 #769878
>>769866

> Excepting the extreme minimalism of Forth, this is the first language I'm aware of where simplicity of the implementation was a concern



Да уж какой там первый.

Из истории сишечки

> Had to use Most Godawful Computer on Earth (EDSAC) to build the CPL compiler.


> Queued up behind others with snippets of EDSAC machine code testing pieces of it. Predictably, this didn't scale to CPL's size and complexity. Abandoned CPL compiler.


> New design goal: trim out anything hard to compile from CPL. Naturally eliminates most features for robust and maintainable programming.


> The result of these was BCPL a typeless, word-oriented language with few keywords and unrestricted use of memory. Created philosophy of "the programmer is in charge and gets no help." Compiler was easy to write on Most Godawful Computer on Earth. Ran fast on it, too.

#512 #769879
>>769875

>Ну давайте еще и динамическое распределение памяти заклеймим.


>Потом и стек тоже.


это не создает таких проблем как динамические либы
>>769881
#513 #769880
>>769877
Насчет больших программ и борьбы с ними вряд ли удастся переплюнуть APL.
Но его не инженер делал, поэтому он получился красивым
>>769889
#514 #769881
>>769879
Какие тебе проблемы создают динамические либы?
>>769885
#515 #769885
>>769881

>тебе проблемы создают динамические либы


1. их отсутствие в целевой системе
2. не та версия

поставляемая программа должна быть самодостаточной, копирнул и запустил, все, без смс и регистрации.
>>769894
55 Кб, 500x500
#516 #769889
>>769880
Охуенно, там и про APL с компанией http://prog21.dadgum.com/114.html

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

> Чувак убил годы на то, чтобы люди убивали недели и месяцы чтобы сука сослаться на тип, и понять тип значения в рантайме, ну и при желании что-то там намутить на стадии комплияции (типа узнать размер коллекции), причем для того чтобы это сделать, нужно хорошо так вынести себе мозг, и нахерачить код типа того что я привел выше. Я конечно глубоко не вникал, может этот shapeless на который надо убить тучу времени (и который видимо далеко не самая навороченная библиотека Scala мира) делает что то там еще полезное, но у меня нет слов — люди делают про это какие-то толки на конфах, воркшопы, презы на 56 страниц типа Demystifying Shapeless. И все это зачем? Чтобы выковырять тип значения во время компиляции, братан. Бебать, да я в 95 программировал на Delpi и у меня все это сразу было. Я ничего не знал про Polymorphic typed λ-calculus, да и сейчас ничего не знаю, но вот цимус в том что и без знаний любой школьник на дельфи, напишет такой HList за 10 минут, и тип в рантайме познает, и сошлется на него, и сравнит и хрен знает что еще. И даже не задумается как все это сделать. Если бы в Delph были макросы, и генерики — я уверен в том, что школьники писали бы точно такие же либы как и вся эта элита пишет на Scala, но только на порядки быстрее, чем эти дяди, и даже не задумывались, о том что им нужны structural refinement types и прочая лабуду (правда что-ли нужны?). Жизнь мне это подтвердила, о чем позже. Да, кстати работал бы этот школьный код в продакшене тоже на порядки быстрее — старая школа в Borland умела делать вещи.

>>769928
#517 #769894
>>769885
Потом в OpenSSL, которую ты используешь, находят баг.
Все программы, которые с ней динамически линковались, продолжают работать после обновления OpenSSL с устранением бага.
Твоя программа продолжает использовать дырявую.
>>769900
#518 #769900
>>769894

>Потом в OpenSSL, которую ты используешь, находят баг


>Все программы, которые с ней динамически линковались, работают с багом


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

>>769903
#519 #769903
>>769900

>Изъян там был с 1982 года

>>769905
#520 #769905
>>769903

>Изъян там был с 1982 года


ну ход мысли ты понял, в случае с OpenSSL конечно пиздос
>>769906
#521 #769906
>>769905
Ну вот и хуй знает что лучше.
У каждого варианта свои недостатки, от задачи и условий надо плясать.
>>769908
#522 #769908
>>769906

>У каждого варианта свои недостатки,


саму концепцию динамических библиотек абассывали с момента их появления. но имеем, что имеем.
>>769909
#523 #769909
>>769908
В Go смогли соединить недостатки всех подходов к проблеме и избегнуть всех же преимуществ
>>769913>>770114
#524 #769913
>>769909

>В Go смогли соединить недостатки всех подходов к проблеме и избегнуть всех же преимуществ


Вот не понял как Роб Пайк и Кен Томпсон могли до этого опустится, ведь сам Пайк на них писякал:
http://harmful.cat-v.org/software/dynamic-linking/

Они ебанулись наверное уже когда Инферно пилили.
>>769917
#525 #769917
>>769913
Всегда такими были. В Bell Labs один был приличный человек - McIlroy, придумал им пайпы, вдохновляясь APL и языком POCAL, который ему большие дяди показали на MULTICS.
>>769919
#526 #769919
>>769917

>Всегда такими были


ну нинаю, Plan9 охуенен, нет, он БОЖЕСТВЕНЕН. как эти болбесы могли так деградировать.
>>769922
#527 #769922
>>769919
Если ничего слаще морковки^H^H^H^H^H^H^H^H юниксов и виндовзов не видеть - да.
Если посмотреть хотя бы на AS/400 и VMS - уже нет.
Есть внимательно изучить перечисленное в https://news.ycombinator.com/item?id=10957020 - то совсем нет.
>>769924>>770039>>770264
#528 #769924
>>769922
Ну сама концепция "все есть файл", пространство имен и взаимодействие по протоколу 9P это гениально.
>>769926
#529 #769926
>>769924
Сколько пришлось десятилетий наворачивать на юниксовую модель безопасности десять слоев не самых прямых костылей из-за этой концепции "все есть файл" (а если переформулировать точнее - "что не файл, с тем мы хуйзнает чего делать")?
>>769929
#530 #769928
>>769889

Похоже

> Цели создателей языков тоже на удивление разнообразны. Вот c какой целью Odersky создавал Scala? Может быть это были сугубо академические (исследовательские) цели, и ему, как исследователю, было интересно сделать что-то новое вокруг идеи связки функционального и объектно-ориентированного программирования. Из презентации: в создании Scala он был мотивирован двумя гипотезами. Причем большинство других языков не мотивированы одной или обоими из этих гипотез. А если гипотезы не верны, то где будет Скала? А если верны то где будут другие языки? А может эти гипотезы вообще фуфло для “красоты”. Может быть он просто выполнял некий университетский “план” и типа вот вам как просите: гипотезы и брюки для птиц. А может быть Sun его чем то обидел, пока он c ними работал:



> Sun hired Martin Odersky to design Generics for Java, and the GenericJava compiler actually became the standard javac compiler shipped with the SDK as early as Java 1.2 (with the bits about generics disabled). Later on, a modified design of generics (with wildcards being the main new addition) was released with Java 1.5. Odersky, of course, went on to first design Funnel, then Scala, but his compiler still ships with Java 8.



> Почему нет? Вот представьте Мартин такой толкает Сану идеи, вот так говорит надо, а они его заворачивают. В результате вообще его работа в свет не выходит ни в 1.2 ни в 1.3. А в 1.5 выходит нечто не совсем то, что он считал правильным (у меня нет никакой информации просто вот прямо сейчас родившаяся теория заговора). Ну и он такой обозлился и типа “щас я вам, [синонимы] штопаные, покажу язык, перед которым вы будете тем что вы есть — [синоним]” и понеслось. И язык создавался совсем не для того, для чего вы думаете, а чтобы уделать кого-то, и показать кто тут главный по языкам.

#531 #769929
>>769926

>Сколько пришлось десятилетий наворачивать на юниксовую модель...


Ты про Линух? Так там жалкая пародия, Торвальдс даун и нихуя и воровал, что было.

Просто когда например в Plan9 можно смонтировать сетевуху из машины в другой подсети к себе в дерево, то просто отпадает например необходимость в целом пласте сетевого ПО таким как прокси сервера. А если смонтировать удаленную видеокарту, представляешь? Это крышеснос.
>>769932>>769935
#532 #769932
>>769929

> Ты про Линух



Без разницы. BSD, AIX, Linux, Solaris, HPUX - костыли только везде разные.
>>769934>>769937
#533 #769934
>>769932
Это не имеет ничего общего с файловым подходом в Plan9
>>769938
#534 #769935
>>769929
Обдумай вопрос как на эти вставляния правами управлять.
Вот с Юниксами так же и получилось - "смотрите как охуенно, пользователи и группы, и битовую маску можно пиздецом эффективно накладывать"
>>769939
#535 #769937
>>769932
А есть еще PlanB, там больше похоже на "все есть объект"
#536 #769938
>>769934

Я тебе говорю что у них один раз уже получилось с Юниксом, и следующие разы ничем не отличаются - главная идея только разная. Но сам подход имени известного аниматора Макото Синкая - "похуй сюжет, рисуем облака" - один и тот же. Люди такие.
>>769943
#537 #769939
>>769935

>Обдумай вопрос как на эти вставляния правами управлят


В Plan9 есть тащемто сервер авторизации, так что или макнись в Plan9 или не обобщай с люнохами
#538 #769943
>>769938

>Я тебе говорю что у них один раз уже получилось с Юниксом


Так они прекрасно переработали весь опыт UNIXа, что подробно описывается в доках
>>769952
#539 #769952
>>769943
Ну говорю же - нихуя они не то что не переработали, они до сих пор не поняли что Юникс это жуткое говно, и почему оно говно.

Смотрим в Plan9

> If a note interrupts a system call



Смотрим в https://www.jwz.org/doc/worse-is-better.html

> Let me start out by retelling a story that shows that the MIT/New-Jersey distinction is valid and that proponents of each philosophy actually believe their philosophy is better.



> Two famous people, one from MIT and another from Berkeley (but working on Unix) once met to discuss operating system issues. The person from MIT was knowledgeable about ITS (the MIT AI Lab operating system) and had been reading the Unix sources. He was interested in how Unix solved the PC loser-ing problem. The PC loser-ing problem occurs when a user program invokes a system routine to perform a lengthy operation that might have significant state, such as IO buffers. If an interrupt occurs during the operation, the state of the user program must be saved. Because the invocation of the system routine is usually a single instruction, the PC of the user program does not adequately capture the state of the process. The system routine must either back out or press forward. The right thing is to back out and restore the user program PC to the instruction that invoked the system routine so that resumption of the user program after the interrupt, for example, re-enters the system routine. It is called ``PC loser-ing'' because the PC is being coerced into ``loser mode,'' where ``loser'' is the affectionate name for ``user'' at MIT.



> The MIT guy did not see any code that handled this case and asked the New Jersey guy how the problem was handled. The New Jersey guy said that the Unix folks were aware of the problem, but the solution was for the system routine to always finish, but sometimes an error code would be returned that signaled that the system routine had failed to complete its action. A correct user program, then, had to check the error code to determine whether to simply try the system routine again. The MIT guy did not like this solution because it was not the right thing.



> The New Jersey guy said that the Unix solution was right because the design philosophy of Unix was simplicity and that the right thing was too complex. Besides, programmers could easily insert this extra test and loop. The MIT guy pointed out that the implementation was simple but the interface to the functionality was complex. The New Jersey guy said that the right tradeoff has been selected in Unix-namely, implementation simplicity was more important than interface simplicity.



> The MIT guy then muttered that sometimes it takes a tough man to make a tender chicken, but the New Jersey guy didn't understand



Те же грабли, теперь пройдем по ним в профиль. Ничего не поняли, ни о чем не задумались, в 2030 году будут опять новый Юникс пилить, с перламутровыми пуговицами, новой Великой Идеей, забиванием на все остальное, и так же на коленке
#539 #769952
>>769943
Ну говорю же - нихуя они не то что не переработали, они до сих пор не поняли что Юникс это жуткое говно, и почему оно говно.

Смотрим в Plan9

> If a note interrupts a system call



Смотрим в https://www.jwz.org/doc/worse-is-better.html

> Let me start out by retelling a story that shows that the MIT/New-Jersey distinction is valid and that proponents of each philosophy actually believe their philosophy is better.



> Two famous people, one from MIT and another from Berkeley (but working on Unix) once met to discuss operating system issues. The person from MIT was knowledgeable about ITS (the MIT AI Lab operating system) and had been reading the Unix sources. He was interested in how Unix solved the PC loser-ing problem. The PC loser-ing problem occurs when a user program invokes a system routine to perform a lengthy operation that might have significant state, such as IO buffers. If an interrupt occurs during the operation, the state of the user program must be saved. Because the invocation of the system routine is usually a single instruction, the PC of the user program does not adequately capture the state of the process. The system routine must either back out or press forward. The right thing is to back out and restore the user program PC to the instruction that invoked the system routine so that resumption of the user program after the interrupt, for example, re-enters the system routine. It is called ``PC loser-ing'' because the PC is being coerced into ``loser mode,'' where ``loser'' is the affectionate name for ``user'' at MIT.



> The MIT guy did not see any code that handled this case and asked the New Jersey guy how the problem was handled. The New Jersey guy said that the Unix folks were aware of the problem, but the solution was for the system routine to always finish, but sometimes an error code would be returned that signaled that the system routine had failed to complete its action. A correct user program, then, had to check the error code to determine whether to simply try the system routine again. The MIT guy did not like this solution because it was not the right thing.



> The New Jersey guy said that the Unix solution was right because the design philosophy of Unix was simplicity and that the right thing was too complex. Besides, programmers could easily insert this extra test and loop. The MIT guy pointed out that the implementation was simple but the interface to the functionality was complex. The New Jersey guy said that the right tradeoff has been selected in Unix-namely, implementation simplicity was more important than interface simplicity.



> The MIT guy then muttered that sometimes it takes a tough man to make a tender chicken, but the New Jersey guy didn't understand



Те же грабли, теперь пройдем по ним в профиль. Ничего не поняли, ни о чем не задумались, в 2030 году будут опять новый Юникс пилить, с перламутровыми пуговицами, новой Великой Идеей, забиванием на все остальное, и так же на коленке
>>769973
#540 #769973
>>769952

>Unix and C are the ultimate computer viruses.


ясно понятно
>>769980
#541 #769980
>>769973
Это верно. Они отбросили разработку языков программирования и операционных систем на много лет назад, и даже сегодня - если с языками программирования прогресс очевиден, то с операционными системами полная херь, Юниксы и виндовзы это отвратительно
>>770015
#542 #770015
>>769980

>если с языками программирования прогресс очевиден,


и какой там прогресс? наработки 50 летней давности
>>769980

>Юниксы и виндовзы это отвратительно


а что не отвратительно, поделись?
>>770039
Аноним #543 #770024
Здарова коданы, использую скриптоту по работе но сейчас дикое желание обмазаться си, хочу написать для практики небольшой проект на пару тысяч строк, но какая-то творческая импотенция, что можно под дебиан запилить нормальное или допилить?
>>770030
#544 #770030
>>770024
В убунте прописываются подключения к vpn и прокси через GUI. Бывает их достаточно много. Запили библиотеку либо программу, которые можно будет использовать из других программ, допустим из Гидры, для переключения подключения к сети.
#545 #770039
>>770015
Haskell, Agda, ATS, Joy, Scala - это все не наработки 5-летней давности.

>>Юниксы и виндовзы это отвратительно


>а что не отвратительно, поделись?


>>769922
#546 #770114
>>769909
Там же просто статическая линковка, нет?
#547 #770264
>>769922
Это очень удобно утверждать, что нечто, о чём большинство не имеет понятия, в 100 раз круче того, о чём все знают и чем пользуются. Приведи хоть пару тезисов, чем этот VMS баще.
ПЕРЕКАТ # OP #548 #770284
>>770283 (OP)
>>770283 (OP)
>>770283 (OP)
Обновить тред
Двач.hk не отвечает.
Вы видите копию треда, сохраненную 8 июля 2016 года.

Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
« /pr/В начало тредаВеб-версияНастройки
/a//b//mu//s//vg/Все доски