Это копия, сохраненная 21 января 2019 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Пожалуйста, пользуйтесь https://ideone.com/ или http://pastebin.com/ для вставки кода, если он длиной больше нескольких строк или содержит [i] или ∗.
Что читать:
- Brian Kernighan, Dennis Ritchie "The C Programming Language": http://www.cypress.com/file/56651/download
- Stephen Prata "C Primer Plus, 6th Edition" (2014): относительно свежая, знает про C89/C99/C11, описывает различия, объемная (около тысячи страниц), годная, с вопросами, упражнениями и ответами. Читать после K&R или до.
- Zed A. Shaw "Learn C the Hard Way" (2015): годное пособие для гуманитариев для гуманитариев!
- Немного примеров хорошего стиля: 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: оче годно, батя рекомендует.
- Intel C++ Compiler: оптимизации, тысячи их.
- Visual Studio 2017 Community Edition: внезапно этим стало можно пользоваться, особенно с тулсетом clang/C2. Поддержка C11 на уровне "есть все, что тебе понадобится в реальном проекте плюс кривая библиотека". Анализатор кода в комплекте.
- Pelles C (шиндоуз онли): поучиться, вкатиться в C11 (стандарт полностью реализован, имеются в том числе threads.h и прочие stdatomic.h), но количество багов в оптимизаторе и редкие апдейты напрочь отбивают желание собирать этим что-то сколько-нибудь серьезное.
- TCC: очень маленький компилятор с багами и поддержкой C99. С ключом -run умеет компилировать код в память и запускать его, что позволяет писать скрипты прямо на сишечке.
Что еще почитать:
http://c-faq.com/
FAQ из comp.lang.c. Древний, но все еще актуален.
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? у нас в сишечке их гораздо больше, просто они лучше спрятаны, немного байтоебли и непонятно откуда взявшаяся глава про старинные плюсы. Читать в качестве сказки на ночь (на пару вечеров хватит).
Richard M. Reese "Understanding and Using C Pointers. Core Techniques for Memory Management" (2013) - почитать, вкатиться в указатели.
Ben Klemens "21st Century C: C Tips from the New School" (2012)
Paul Deitel, Harvey Deitel "C for Programmers with an Introduction to C11" (2013)
Stephen G. Koch@n "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://godbolt.org/ - Compiler Explorer позволяет посмотреть выхлоп компиляторов для введенного куска кода (больше полусотни разных версий компиляторов).
- http://cdecl.org/ - С Gibberish ↔ English помогает читать сложные сишные декларации.
Прошлые треды:
- №33: https://arhivach.tk/thread/383767/
- №34: https://arhivach.tk/thread/398890/
- №35: https://arhivach.tk/thread/398891/
Чуток подучил С, разобрался с байтоебством, могу написать программку которая считывает инпуты и записывает их в файлы, разные алгоритмы сортировки и поиска тоже могу написать.
А теперь вопрос, где применить эти знания? Как написать настоящую программу? Просто не понимаю области применения С.
>Просто не понимаю области применения С
Да всё что угодно, где нужен прямой доступ к памяти/железу или важна производительность и нетребовательность к ресурсам или же интероперабельность с другими ЯП.
> Просто не понимаю области применения С.
В данный момент только embedded -- ебаться с железками и байтоебством. Никакой другой области для сишки, где платят деньги сейчас нет. Да и за это платят не сказать что бы много.
И где ты собрался работать? У кашперского? Один работодатель на все рашку -- работа мечты просто. Я тащемта не обоссать написал все, а типа мудрого совета.
> просто нужно уметь найти ее
Да-да, ПРОСТО взял и нашел. Сам-то уже нашел? Чтобы хотя бы 200к+ было?
Ну вот конкретно ты, который говорит, что
> Работы куча, просто нужно уметь найти ее.
Уже нашел? Сколько получаешь? Или только мечтаешь?
> Сишнкиком? Пока нет, даже не искал
Но вот и не пизди тогда.
> но нашел бы если нужно было
Да-да, иди нахуй. Оригинальное заявление было в том, что работа на сишки есть только в embedded и за нее не особо платят. Какие-то там другие отдельные вакансии для звезд.
>>05235
Я подробнее объясню:
Сам я макака-формошлеп, зарабатываю неплохо, но угарел по С и начал изучать его, мне просто нравится да и полезно в работе будет (надеюсь). И если в работе формошлепом, выучив js, я могу выучить какой-нибудь фреймворк и написать браузерное приложение или же зная C# и .net я могу написать .exe программу под винду например и использовать. Так вот что пишут на С? Какие то программы которые запускают из консоли и они начинают работать "с железом", то есть с компьютером? Есть ли где-то туториалы или что-то подобное? Просто вообще не понимаю как подойти и с чего начать чтобы сделать что-то серьезное.
охуеть
Драйвера для новых устройств, прошивки для всякой встроенной залупы вроде видеорегистраторов, охранных систем и т.д. В линупсе много программ на сишке, но никто тебе за них платить не будет. Ищи на hh.ru вакансии по слову embedded и узнаешь что хочет работодатель от сишника
https://hh.ru/search/vacancy?text=embedded&area=1
Про то, что на сишке пишут все, где важна производительность не слушай, отдельные такие проекты разрабатывают суперзвезды или оупенсоурс, и джуны там в хуй не вперлись.
Я не ищу работу, я уже работаю. Но в целом понял тебя.
Так кто тебе мешает внедрить плюсы в свои навыки? Или ассемблер какой нибудь ебануть?
>Просто не понимаю области применения С.
Очевидный эмбед и всё железно-низкоуровневое. Если в ангельский можешь, записывайся на edx на Embedded Systems - Shape the World, а закончишь, можешь об hardware hacking поколотиться.
фу, мог бы не шквариться гуглозондами, а поднять свой сервак
>Мой план на ближайшие 9 месяцев:
>(В примерно хронологическом порядке)
>C Primer Plus -- Stephen Prata
>Data Structures Using C -- Langsam, Augenstein, Tenenbaum
>Algorithms in C -- Robert Sedgewick
>Structured Computer Organization -- Andrew Tanenbaum
>Modern Operating Systems -- Andrew Tanenbaum
>Computer Networks -- Andrew Tanenbaum
V1.1
C Primer Plus -- Stephen Prata
Data Structures Using C -- Langsam, Augenstein, Tenenbaum
Algorithms in C -- Robert Sedgewick
* Computer Systems, A Programmer’s Perspective -- Bryant, O’Hallaron
Computer Networks -- Andrew Tanenbaum
>На edx проходил курс cs50
CS50 неплохой, но только в качестве базового. Там, например, указатели довольно тухло объяснены.
Не пожалей времени, запишись на и пройди 7 курсов C Programming от Dartmouth College и IMT! Это будет ОХУИТЕЛЬНЕЙШИМ продолжением CS50 и прекрасной базой для Embedded Systems - Shape the World. Для последнего уже нужно владеть C на более-менее пристойном уровне - особенно это касается структур (structs).
Я вот работаю джуном, пишу на си, драйвер для Linux.
Пришёл вообще без опыта работы, получаю сейчас 35к.
норм ящитаю, я не в ДС живу, да ещё и без опыта уже такая зп
Спасибо за наводку, обязательно пройду.
Я сейчас на третьем курсе, образование ойти.
Собственно на втором курсе начал усиленно дрочить плюсы, т.к. изучал глубинные вещи, то это имело отношение и к си тоже.
Собственно из того, что спрашивали на интервью я не знал только, что такое union, т.к. никогда до этого ими не пользовался.
Алсо собеседование было и по си и по плюсам.
просто у нас пишут не только на си, но я попал в Линуксовую команду, а тут как бы выбора и нет
>Что то не могу найти, ссылкой не поделишься?
www.edx.org/school/dartmouthx
Все курсы, которые с "C Programming:" начинаются, и можешь ещё из этой же серии Linux Basics взять, если для тебя актуально. По ошибке только специализацию не схвати (Professional Certificate Program которая; это то же самое, но с сертификатом и за деньги).
Каким хуем вызов функции меняет локальную переменную (переданную как аргумент функции если важно) provname?
Не вижу, где ты передаешь provname куда-либо. Где-то ты сам пидорасишь стек, ищи. По скриншотам нихуя не понятно.
Все довольно линейно, не представляю как что-то может похериться.
Есть мейн, provname берется из аргументов командной строки (argv[6]), переводится в массив wchar_t (возможно с этим связано, без этого преобразования не работает так что я не вдумываясь зачем как и почему спиздил его со стековерфлоу), передается в encrypt (wc2), хуйня происходит всегда на CertOpenStore, 100% воспроизводимость, во всяком случае со значением "Microsoft Strong Cryptographic Provider".
Я тащемта обошел это тем, что просто provname использовал до откытия хранилища, но все равно интересно что за дерьмо там происходит.
Самое классное еще что у аргумента const стоит, но он все равно изменяется.
Так я не совсем с нуля. Двенадцать лет назад писал лабы на няшной и немного на asm для К580 на первоми единственном курсе. Знаю, что такое указатели, двоичная арифметика и всё такое, но после отчисления дел с погромированием не имел. Чекнул вакансии по регионубульба и если, например, по java тоннами берут джунов, есть горы всевозможных стажировок и тренингов, то по няшной/крестам почти везде нужны инжинеры с опытом и профильной вышкой и самих вакансий меньше раз эдак в 50. Сейчас у меня примерно год, чтобы сделать вкат на зарплату во что-нибудь и я боюсь, что если начну няшную, в лучшем случае смогу попасть на какой-нибудь завод, прошивать контроллеры за еду. Такие дела.
Все найдешь, люди на базе 9 классов работают получше чем те, что с образованием, и корка о высшем это уже стереотип далеко неприятный многим. Мой совет это различного рода конференции по тематикам которые тебе нравятся, дают визитки всем и со всех стран.
Для примера, мне как хую который ничего не знает предложили должность джуна в Китае, Эмиратах, Канаде и т.д
Английский конечно важен и наличие хотя бы 30К чтобы поехать на конференцию, но все зависит от местоположения.
Можно так же устроиться в какую нибудь команию типа Samsung, опять же, резюме и навыки, но примут и так и так, но без базы и хороших знаний лучше не лезть, хотя бы на базовые вопросы нужно уметь отвечать. Can you C?
А так если есть желание можно в тот же инстаграм устроиться, главное это упорство как мне кажется. Но уметь налаживать контакты с людьми с которыми вы познакомились очень важно, важны связи опять же, которые делаете ВЫ.
Ну дк Си это инструмент, а не специализация же, это очень мощная галочка если ты пойдешь в какую либо сферу, например дрова писать, не?
Сейчас кресты очень сильно ся потеснили с последними стандартами языка за счет своей халявной магии шаблонов и смартпоинтеров с placement new. В итоге нонешние кресты позволяют теперь обходиться без тяжелого наследования и жирного рантайма, в отличии от раньше. Многие системные хуитки (например mesa3D и её юзермодные драйверы) уже вовсю на крестах.
Благодарочка.
Сам Альберт Хуй пригласил на собес.
Сишечка сейчас это системный софт *NIX, а также embedded soft (микроконтроллеры).
Web сервера, NGINX - это кресты.
Гамесы - это кресты.
>поисковые Google сервера
это звучит только пафосно, там логики меньше чем в Постгресс, которая внезапно на ..
Сишечка хороша для вкатывания в программирование и как база для дальнейшего обучения.
Все, кто в этом треде и подобных тредах утверждает, что сишечка самодостаточна и способна вынести большой, современный проект - суть лицемеры.
Да, есть лялих оставим неземное качество продухта, но удел современного сишечника, не сподобившегося научиться современным технологиям - "программирование" станков и оборудования за еду.
К величайшему сожалению.
Надо понимать, что для многих упертых сишечников, си - это пора юности и счастья. Как для некоторых, например, QBasic. Но доказывать окружающим а на самом деле - себе что на си время застыло - это вызывает только жалость.
Си - это только начало пути. Как Паскаль 40 лет назад. Как Бейсик 30 лет назад.
Добро пожаловать в 20 лет назад, анон.
>большой, современный проект
Это что например?
>научиться современным технологиям
Это чему например?
>Это что например?
Посмотри вокруг, например.
>Это чему например?
Все что пришло после си. Посмотри вокруг.
Это все так. Но есть очень простой контраргумент: сишечку можно выучить и досконально понимать целиком. Современные кресты выучить нельзя, степень реализации везде отличается, полного понимания языка нет ни у кого. Поэтому вменяемые люди оставляют крестам высокий уровень, а либы пишут на Си.
>Сишечка хороша для вкатывания в программирование и как база для дальнейшего обучения.
Для этого сишка очень плоха.
Сишка хороша для программирования под железо и как база для изучения с++.
Ну и еще сишный FFI поддерживают все языки.
>Сишечка хороша для вкатывания в программирование
Хуйни не городи! Сейчас для этих целей идеально подходит Python: минимум писанины, возможность быстро получить наглядный а не текстовую дрись результат, нет жёсткой привязки к железу.
>и как база для дальнейшего обучения
Любой язык - это тупо инструмент, который можно рассматривать как базу для для дальнейшего обучения. Вопрос только, чему учиться. Cи сегодня - это возня с железом, но не на уровне цифровой схемотехники, а чуть повыше.
>Все, кто в этом треде и подобных тредах утверждает, что сишечка самодостаточна и способна вынести большой, современный проект - суть лицемеры
Что в твоём понимании "большой проект"? На борту у микроконтроллера может быть несколько десятков Кб памяти, но при этом сам микроконтроллер управляет хуергой размером с дом. Это как, большой проект или небольшой? Алсо, id Software про невозможность создания больших проектов расскажи. У них всё, что создано до 2000, писалось на чистом Cи.
>Надо понимать, что для многих упертых сишечников, си - это пора юности и счастья
Для многих это тупо инструмент. Берёшь и хуяришь. Любить или не любит язык - это приблизительно то же, что и любить или не любить шариковую ручку или молоток.
>Python
>нет жёсткой привязки к железу.
>отбиваешь табами отступы как пидор
Нет, спасибо, ональное ООП в куче с уебищной реализацией и косплейем Перла с тормозами
Ну а что еще, руби помер, у жс куча других недостатков. Статические языки вообще мрак
>отбиваешь табами отступы как пидор
Ты в нотепаде что-ли код пишешь? Или у тебя автоотступалка поломалась?
>Нет, спасибо, ональное ООП
Взять скриптовую пепяку, изначально созданную для несложной автоматизации, и удивляться несерьёзности. Это как местные идиоты пытаются с помощью ардуины автоматизировать производство, а потом клянут саму ардуину и удивляются "чому не взлетает?!"
>Взять скриптовую пепяку, изначально созданную для несложной автоматизации, и удивляться несерьёзности.
Ты долбоеб? Какие пипяки, какие несерьезности, давай конкретику.
>в нотепаде
Да, писал в ВИМЕ, но сейчас на ноутпаде++ под спермосью. Язык навязывающий стилистику однозначно пидерский.
>Ты в нотепаде что-ли код пишешь? Или у тебя автоотступалка поломалась?
Из-за отсутствия end'ов питон не знает, что конкретно ты имеешь в виду, чтобы автоматически делать отступы. Поэтому приходится и вручную блоки двигать (естественно, выделяя блок целиком, а не табами, но все равно это гемор), и проебывать индентацию при копипасте. Блядство редкостное такой синтаксис.
>косплейем Перла
ебло стяни. Где эти лаконичные сокращения в питоне как в перле?
Да и на питоне необязательно в ООП-писать. То, что там всё - объекты не значит, что ты не можешь там создать свои пускай и костыльные типы данных и писать в ООП-парадигме. Наоборот динамическая типизация избавляет от лишних проверок. Хз, что ты агришься на питон. Дебил, навернок.
>костыльные типы данных
Все ясно, ты малолетний долбоеб. За сим прощаюсь и иду шпилить твою мамку в очело.
Рассказал тебе мужским членом за щеку. Теперь глотай и уебуй делать домашку.
>Ты долбоеб? Какие пипяки, какие несерьезности, давай конкретику.
Какую тебе конкретику? Прохладную о том, как Гвидо создал язык как автоматизации какой-то там своей повседневной хуерги, а потом этот язык зажил своей жизнью? Почитай интервью Гвидо, он сто раз про рождение питона рассказывал.
>Язык навязывающий стилистику однозначно пидерский.
Ох, а фигурные скобки тебе ничего блять не навязывают! Мань, ну хорош! Просто ты закусился на предмет "питон - говно", и теперь тебе всякое лыко в строку: отступы не отступы, синтаксис не синтаксис и ООП не ООП... А в сухом остатке, нормальный язык для начинающих а также сисадминов, бэк-эндщиков и мамкиных машинно-обучаторов - можно быстро игрулю типа тетриса написать, наглядно разобраться с основами погромизма, а за всем остальным идти на C/C++/C#/Java или к чему там душа больше лежит.
>Но есть очень простой контраргумент: сишечку можно выучить и досконально понимать целиком
Как и QBasic. Как и Pascal.
Это не контраргумент, а совершенно обратное, обрати внимание.
Повторюсь - к большому моему сожалению.
>как база для изучения с++.
Об этом собственно и речь. С++ - серьезный уровень, за серьезные деньги. С++ должен быть целью, хотя бы промежуточной. А начать надо с Си.
Не буду холиварить, вот реально не хочу. Выбор языков - та еще тема.
Но:
>id Software про невозможность создания больших проектов расскажи. У них всё, что создано до 2000, писалось на чистом Cи.
Ты неправ. Писалось на плюсах.
>что и любить или не любить шариковую ручку
Когда в детстве писал пером и чернилами.
Это аллегория, и я с тобой согласен насчет инструмента. Речь об эмоциональной связи с предметом, которая подменяет функциональность.
>>05807
>Сейчас для этих целей идеально подходит Python
Только добавлю один момент.
Из моего окружения довольно много вкатывальщиков, всех практически возрастов.
Так вот, если человек - взрослый технарь с вышкой, то переучиться на программиста кайфовее начиная с сишечки.
Если подросток или еще в универе - питон самое то.
Не знаю почему так. Просто наблюдение.
Думаю, что старшим технарям нужно знать досконально что конкретно происходит в каждой инструкции, плюс привычка работать по стандартам.
ООП - всего лишь развитие парадигмы, которая была реализована на си в том числе, была признана перспективной, и в конце концов реализована через отдельный зоопарк.
Что за ненависть-то?
Да, бесполезно с этой дурой разговаривать. Залётыш-крестоблядь, которая рещила собрать внимания.
Не рвись!
>>05859
>Не буду холиварить, вот реально не хочу. Выбор языков - та еще тема.
Так я тоже. Я к тому, что каждый язык для какой-то конкретной задачи разрабатывался и сравнивать их на уровне "лучше - хуже" - это детский сад. Анон утверждал, что закатываться в программирование лучше через Си, а по мне, лучше через Питон, ибо он проще для нубов в т.ч. и из-за отсутствия миллиона скобок и прочей писанины. Что, впрочем, не делает Питон языком богов и наоборот. Разные языки, разные области/ниши/задачи.
>id Software
>всё, что создано до 2000, писалось на чистом Cи
>Ты неправ. Писалось на плюсах.
Кармак говорит, писал на чистом Си, ты говоришь, на плюсах. Кому из вас верить?
Во, тебя двачую!
>Из моего окружения довольно много вкатывальщиков, всех практически возрастов
>если человек - взрослый технарь с вышкой, то переучиться на программиста кайфовее начиная с сишечки
Я преподавая золотую середину, кстати, нашёл, которая для всех абсолютно нубов подходит:
1). Берём питон (pygame), и пишем простенькую игрулю уровня флаппи бёрд.
2). Написали, берём ардуину, барахло натурально, задача не взять готовые кнопки и т.д., а наковырять из какой-нибудь старой железяки говна, и делаем к этому флаппи бёрду контроллер.
В сухом остатке, весело, наглядно и удаётся 12-52-левелам быстро и погромизм, и основы эмбеда/электронства в головы запихать. А начинали бы с С/С++, на втором-третьем занятии уже никого бы не было.
>Кармак говорит, писал на чистом Си, ты говоришь, на плюсах. Кому из вас верить?
Лол, я почему-то твердо помню, что он говорил про С++. Извини.
Лол, мне 38.
Начинал с вкатывание с С++, Java, Haskelllol, C#.
Ничего не зашло.
Читаю сишечку Прату, отлично заходит.
На курсы не могу записаться, читаю/решаю задачки реально урывками, работа все время съедает.
>говорил
И это программисты блядь. Кармак последовательно опенсорсит свой старый код, все лежит на гитхабе.
С++ у него начался с quake 3.
Вот тебе квейк первый на чистом си например:
https://github.com/id-Software/Quake/tree/master/QW/client
Потому что она не установлена? Добавь её в проект и укажи путь, где она лежит.
Потому как ты отстал лет на 20-25? Этой библиотеки давно уже нет в поставках Студии, накатывай какой-нибудь Turbo C в досбоксе.
>Потому как ты отстал лет на 20-25? Этой библиотеки давно уже нет в поставках Студии, накатывай какой-нибудь Turbo C в досбоксе.
А как рисовать кружочки/квадратики?
>Но есть очень простой контраргумент: сишечку можно выучить и досконально понимать целиком. Современные кресты выучить нельзя, степень реализации везде отличается, полного понимания языка нет ни у кого.
Не-а. Чтобы писать большие проекты на сишке, надо знать С++ и уметь реализовывать все крестоконцепции на более низком уровне. Потому что собственно С++ появился как автоматизация сишных костылей.
Например, что там у нас есть...
В С++:
struct Yoba {
private:
int yoba;
public:
int getYoba(){return yoba;}.
};
В сишке как инкапсуляцию структуры сделать? О, это целое дело. В хедере нужно написать форвард декларейшен структуры
typedef struct Yoba_tag Yoba;
В .c файле сделать конструктор и пропертю:
void create_yoba(Yoba@@);
int getYoba(Yoba@ yoba);
Шаблоны? Приготовся пердолиться с препроцессором и .inc файлами. Типа
#define YOBA_VECTOR_TYPE double
#include "yoba_vector.inc"
#undef YOBA_VECTOR_TYPE
yoba_vector_double yoba;
И так далее. Писать нормальный код на сишке сложнее, чем на С++, а знать примерно одинаково по сложности.
>Но есть очень простой контраргумент: сишечку можно выучить и досконально понимать целиком. Современные кресты выучить нельзя, степень реализации везде отличается, полного понимания языка нет ни у кого.
Не-а. Чтобы писать большие проекты на сишке, надо знать С++ и уметь реализовывать все крестоконцепции на более низком уровне. Потому что собственно С++ появился как автоматизация сишных костылей.
Например, что там у нас есть...
В С++:
struct Yoba {
private:
int yoba;
public:
int getYoba(){return yoba;}.
};
В сишке как инкапсуляцию структуры сделать? О, это целое дело. В хедере нужно написать форвард декларейшен структуры
typedef struct Yoba_tag Yoba;
В .c файле сделать конструктор и пропертю:
void create_yoba(Yoba@@);
int getYoba(Yoba@ yoba);
Шаблоны? Приготовся пердолиться с препроцессором и .inc файлами. Типа
#define YOBA_VECTOR_TYPE double
#include "yoba_vector.inc"
#undef YOBA_VECTOR_TYPE
yoba_vector_double yoba;
И так далее. Писать нормальный код на сишке сложнее, чем на С++, а знать примерно одинаково по сложности.
Если прямо надо через graphics (требует препод, например) - качай WinBGI, это порт либы. Если не надо - то у тебя огромный выбор, от WinAPI и DirectX до SDL2 и OpenGL. Сам рекомендую SDL2, он достаточно прост в освоении.
Вот это кстати показатель. Если раньше для рисования кружка в сишке ничего не надо было, то сейчас новичку нечего особо предложить, только пердолинг с гуем
Дело не в этом, а в том, что когда компьютеры были простыми, начинать с сишки было легко и приятно. В конце концов, принципиально она отличается от того же турбопаскаля разве что наличием в паскале человеческих коротких строк.
Сейчас же уровень не просто низкий, это уровень шахты с шахтерами.
Начинал с паскаля, быстро перекатился на Си. Теперь даже какой-нибудь Питон и даже кресты освоить не могу, мозги основательно заклинило на Си.
Сишечка слишком упрощает, я не могу строки воспринимать иначе как последовательность байт теперь. Постоянно на байтоебство тянет.
>Пиздец. То, что ты не можешь в scope - это не проблема сей. Смекаешь?
Разъясни плизики. Причем здесь скоп?
Инкапсуляция это несколько выше возможностей сишечки.
Ведь это:
>Потому что собственно С++ появился как автоматизация сишных костылей
Правда, зачем отрицать очевидное?
Мимонуб-миддл
О БОЖЕ МОЙ, просто используй строку без задней мысли и все.
Если раньше для выезда в другой город надо было всего лишь сесть на лошадь, то теперь пердолинг с рулём и АКП.
Но ведь сразу видно, что решить ее может опытный кодер на Си, ибо я таких тонкостей языка не знаю, я уже перечитываю главу много раз и не вижу там даже намека на решение и в общем голова болит.
У Праты с таким нет проблем, все задачки решаемы и он все объясняет, но я хочу продолжить с K&R параллельно с Пратой и еще подключаю Learn C The Hard Way, но там вообще кошмар.
Сижу на Шляпе и там параллельно на административку системы учусь, скрипты пишу, с железом разбираюсь и т.д
Я в правильном направлений?
Нахуй, аналогии для долбоебов
>Но ведь сразу видно, что решить ее может опытный кодер на Си, ибо я таких тонкостей языка не знаю
При чем тут тонкости языка, задача для школьника с использованием двух функций, которые тебе уже объяснили - getchar и putchar и одной переменной состояния.
Ты просто туповат. Не в смысле пиздец как тупой и сишка тебе не светит, а так, среднемакака.
>Ты просто туповат.
Не отрицаю, но чет сложна. Книга была написана аж в 80х, там люди поумнее конечно и наверняка знали не только Си.
Бля, кир не для новичков, эта книжка писалась для программистов на других языках. То, что долбоебы советуют ее новичкам -- ну так на то они и долбоебы. Не мучай себя, прочитай прату, потому КиР.
>Бля, кир не для новичков, эта книжка писалась для программистов на других языках. То, что долбоебы советуют ее новичкам -- ну так на то они и долбоебы. Не мучай себя, прочитай прату, потому КиР.
Да мне никто не советовал, сам нашел заинтересовался. Я тоже об этом подумал кстати, там люди программировали в баше и в общем то наверняка дальше просто по книге пошли и когда поняли язык решили эту задачку на каком то этапе.
>Какой номер упражнения btw?
1-9.
Сейчас порылся в своих старых записях, вот так я его делал:
https://ideone.com/DgD8SY
> задачка типа где нужно вместо двух бланков один сделать непонятна и решить ее не могу, решить хочу сам поэтому прошу не помогать.
Но ведь сразу видно, что решить ее может опытный кодер на С
Там нихуя сложного не было, соглашусь с аноном выше, что ты просто туповат. Там чуть дальше есть задача, где надо вычислить максимальные размеры разных типов данных и для этого надо толи битоебство, то ли еще что-то я так и не понял. Вот тут косяк конечно, я не понял как ее решать.
Тебе нужно сделать, чтобы пробел был только один.
1. Считываем символ;
2. Если это пробел, то проверяем счетчик пробелов space;
3. Если счетчик равен нулю т.е. пробелов перед ним не было, то просто выводим этот символ пробел в stdout с помощью putchar;
4. Если счетчик больше нуля, значит пробелы перед ним уже были и мы просто увеличиваем счетчик на единицу и ничего не выводим в stdout;
5. Если это вообще не пробел, то обнуляем счетчик пробелов space и просто выводим символ в stdout.
Ну это мое решение НАЧИНАЮЩЕГО, так что не судите строго лол. Но вроде должно работать правильно.
Зачем там что-то считать (не читал задание)?
int prev = EOF, c;
while ((c = getchar() != EOF) {
if (c != ' ' || c != prev) { putchar(c); }
prev = c;
}
Что значит максимальные размеры?
Диапазон значений или размер в плане сколько они в памяти занимают?
алсо и то и то очень легко
> Диапазон значений
Да.
> алсо и то и то очень легко
Решения, которые я находил заключались в сдвиге битов или какой-то другой подобной залупе.
Увеличивай на 1, пока у тебя значение переменной меньше, чем значение переменной + 1.
Так ты найдешь верхнюю границу.
Аналогично с нижней.
Ну это конечно может и правильное решение, но как-то.. хуй знает. Я понял что ты имеешь ввиду, но я ожидал немного другого лол. Хотя может так оно и задумывалось.
>>06217
Наверное так эти решения и работали, я просто пока не вкуриваю двоичную арифметику и все эти сдвиги и поэтому не понял что там имели ввиду.
Двоичная арифметика тоже самое что и обычная, нет никакой магии.
Алсо вот, что я имел в видуя хз, что тебя смутило, очень простое решение
https://ideone.com/qy4f9N
Да я понял что ты имел ввиду. Просто некоторые решения кажутся настолько тупыми, что думаешь НЕ, НУ ЭТО НЕ МОЖЕТ БЫТЬ ТАК ПРОСТО/ТУПО, ОЧЕВИДНО ТАМ ЧТО-ТО ХИТРОЕ ПОДРАЗУМЕВАЛИ. А на самом деле ничего такого не подразумевали :)
В этой книге нет сложных заданий, которые бы ты не смог решить на том уровне, на котором ты до них добрался.так в принципе везде
хотя так говорить я наверное не имею права, т.к. я никогда не читал эти книжки и не выполнял по ним задания, лол
>Кармак последовательно опенсорсит свой старый код, все лежит на гитхабе.
А где лежит арихитектура проекта? Не UML но хотя бы блок схема простая, из каких компонентов состоит проект, наглядно.
Ведь не может быть что такую большую разработку без элементарного чертежа.
>Ведь не может быть что такую большую разработку без элементарного чертежа.
Любой чертеж требует постоянного согласования между собственно чертежом и исходным кодом, поэтому после начальных набросков, если они есть, работают уже непосредственно с кодом, а все эти UML'и не взлетели.
Ты можешь найти статью по архитектуре кваки http://fabiensanglard.net/quake3/ , но это уже описание того, что получилось
Я понимаю, но мой вопрос в том как например они разделяют обязанности между командой.
Я не знаю как это делается, но например двое работают над движком, один над графикой.
Как стыковать отдельные участки кода без чертежа? Где задокументированы т.н. интерфейсы отдельных кусков проекта?
>Game Engine Black Book: Wolfenstein 3D
Уухх бля, чую на неделю по пизде пошел мой план обучения.
Ныряю в детство!
Там разве два человека работало над движком?
>Как стыковать отдельные участки кода без чертежа
Если ты так любишь инженерные аналогии, то программа и есть чертеж. Изделие это билд.
Блин, знакомая проблема. Я начинаю дико буксовать при попытке написать хоть сколько-то большую программу. Пытаюсь придумать архитектуру, фейлюсь и забиваю. Плохо быть тупым.
Ну вот например сейчас я хочу сделать небольшую типа стратегию пошаговую. Прикинул - надо отдельным модулем графику низкоуровневую (обертку над SDL) реализовывать, отдельным - сцены и объекты на них, скриптовый движок прикручивать, саму общую логику, обработку ввода. И все это еще и вместе собрать. Не знаю, за что браться.
Цель какая? Если сделать игру на продажу, то браться надо за мануал к игровому движку по своему вкусу.
Если цель просто поразвлекаться, я бы остановился на ascii графике, которую впоследствии можно сделать тайловой.
Нестрогая типизация как есть
Для себя. Там графики-то и не надо, по сути, все будет в тоннах меню происходить.
Бампану, пожалуй.
Итак, как из сорцов получить архитектуру? Надо самому вычеркивать на бумажке в 21м веке? Или все-таки есть решения?
>Каждая группа разработчиков получает набор требований к своей части системы, включая точное описание её функциональности и предельные требования к процессорному времени, занимаемой памяти, месту на диске и т. д.
Где вот это вот всё? А?!
Вот хотелось знать как профессионал читает исходники. Открывает функцию мейн и все, что в ней найдет?
Тоже интересно. Эксперты, вы здесь?
WinMain
в отрасли есть интуитивное мнение, что полностью исходный код унаследованного проекта читают только единицы программистов
и это и есть лучшие кадры
как читают? да как книгу, пусть и дурно написанную
В неповоротливых корпорациях, живущих по заветам доинтернетовских времен.
Краткий экскурс в историю. Сначала была инженерия. Какой-нибудь автомобиль разрабатывают лет пять, не меньше. У инженера циклы итерации длятся месяцами, а ошибка стоит дорого.
Потом появилось ПО, на которое перенесли методы инженерии, ну просто потому что ничего другого не умели. Но релизы сократились примерно до года. Раз в год какой-нибудь майкрософт выпускал CD-ROM с носителем, в котором был вылизанный продукт. То есть примерно так: полгода пилятся фичи разными отделами, потом полгода пытаются совместить эти фичи до приемлемого состояния. Ошибка стоит уже не так дорого, как в случае с автомобилем, ведь можно накатить сервис-пак, но все равно это неприятно.
А потом появился интернет. Все ускорилось. Релизы раз в год - очень долго, конкуренты обойдут. "Автомобильная" ситуация, когда сначала год пишут требования, а потом их реализуют - тем более. Требования пишутся в процессе разработки. Пришла эра аджайла, когда продукт должен быть готов всегда, а требования не устаканиваются никогда. Релизы раз в две недели, между релизами улучшения идут по фичам.
Ну я хуй знает как это читать без хотя бы какой-то приблизительной документации какие компоненты за что отвечают и как все устроено. Разобраться конечно можно, но это должно занять кучу времени.
> Открывает функцию мейн и все, что в ней найдет?
В мейне он найдет примерно то же, что написано по слову "--help".
Сначала надо прочитать файлы, которые название которых лежит в корне проекта и написано капсом. Это файлы для людей - README, BUILD, и т. п. Дальше надо собрать проект, потому что иначе это будет ближе к реверс-инижинирингу.
Дальше нужно изучить файловую структуру. Найти конфиг, который программист запилил для себя - там скорее всего будут все возможности проги, даже незадокументированные. Затем можно поизучать интерфейсы основных классов и модулей, возможно там будут комменты. После этого, если проект сбилжен, брать в руки printf и хуряить лог. Мы в сишном треде, так что можно подробнее. Хуяришь вот такую йобу
#define TRACE fprintf(stderr, "trace: %s:%s:%d", __FILE__, __FUNCTION__, __LINE__);fflush(stderr);
и запускаешь. Смотришь лог - кто за чем запускается, как часто и т. п. Убираешь лишний мусор, модифицируешь этот лог, возможно добавляешь печатание дополнительной инфы. Так поймешь где в коде инициализация, "горячие" места в коде и прочие интересные места. Читаешь их.
Еще бы хорошо вспомнить, нахуя ты это делаешь. А то бывает нужно пофиксить баг в легаси-проекте, бывает спиздить алгоритм или поучиться архитектуре.
>Пришла эра аджайла, когда продукт должен быть готов всегда, а требования не устаканиваются никогда.
Создается ощущение что это просто ЕБУЧИЙ ПОРТАЛ для потоков несопровождаемого быдлокода. Я прав или просто не понял технологию?
>Создается ощущение что это просто ЕБУЧИЙ ПОРТАЛ для потоков несопровождаемого быдлокода.
Все ровно наоборот. Подумай сам, когда студент лучше учится, когда раз в две недели у него контрольная, или когда раз в год ему нужно сдавать ебический экзамен, а все остальное время он сам по себе. В аджайле технический долг весит над тобой постоянно, наговнокодил сегодня - завтра не успел с фичей и остался на ночь.
А при релизах раз в год фактически происходит следующее: полгода программисты пилят фичи, а потом пытаются из полученного франкенштена слепить что-то безбажное. А сроки поджимают и в итоге за две недели до релиза на физическом носителе начинается ебашивало с подпорками из костылей и прочего говна, лишь бы работало, а менеджер подгоняет, потому что если вы не успеете к рождеству, фирма обанкротится.
Спасибо за подробный ответ.
На уровне языка классов нет (поэтому я написал классов и модулей, модуль, которого на уровне языка тоже нет, - это пара из .h и.c файлов с одним именем, ну ты понял), но в целом, если перед тобой есть нечто, что
1. Имеет конструктор
2. Имеет деструктор
3. И имеет кучу функций, работающих только с элементом этой сущности.
4. И, опционально, допуступно только в виде указателя
То можешь считать это классом. Фактически для полноценного ООП тут нет наследования и полимрфизма, но, вообще говоря, не факт, что его там внутри нет, да и класс может быть и без этих вещей.
Пример - FILE из стандартной библиотеки.
1. fopen - конструктор
2. fclose - деструктор
3. fwrite, fseek, fprintf - методы
4. Сама структура FILE не документирована, тебе дан только указатель
Так часто бывает, то, что в языке более высокого уровня - сущность языка, в языке более низкого уровня это паттерн. Вот в сишке класс это паттерн. Умение выхватывать глазами такие паттерны важно при анализе чужого кода.
Спасибо, добра!
У меня для тебя есть вопрос интересный. Долго выписывать, попозже выложу.
Вкратце - есть одна механическая головоломка с хитрым алгоритмом решения.
Хотелось бы направление как решить описать ее програмными сущностями. Я ее понимаю как инженер, но возможно надо посмотреть под другим углом.
Механическая-механическая типа вытащить кольцо из ебучей 3д поверхности, или типа кубика Рубика? Потому что первое совсем непросто, а второе совсем просто.
Что можешь рассказать про реализацию полиморфизма в си? На мой нубский взгляд, это практически брат инкапсуляции - единственные фичи в ООП, которые не нарушают ООП, лол.
Есть некостыльные паттерны в си для этих принципов?
Там говорилось о разборе чужого кода, как читать исходник. Большинство нормальных программ нормально же и читаются, понимания происходящего в целом достаточно ознакомиться с содержимым .h и документацией (если она есть). Чтобы разобраться в реализации, чаще всего достаточно IDE или даже редактора, который умеет в goto definition/find uses. Совсем уж непонятные места гораздо проще отлаживать интерактивно и пошагово, т.е., опять-таки в IDE. А принтфы остаются для сбора информации уровня "составить более-менее полный список файлов, которые открывает программа", а эти задачи напрямую к чтению исходников не относятся.
Нет-нет, никакой топологии.
Головоломка называется waiter's tray puzzle (поднос официанта):
https://www.youtube.com/watch?v=Q5aDhxrtrP0
Если можно не выкладывай свои мысли пока, я бы хотел узнать мыслю ли я в правильном направлении.
Потому что при анализе получается что там чистейший ООП, хотя иду по ТРИЗ.
От душа анон. Какой охуенно полезный макрос. Просто тонну чая тебе. Сам почему-то до сих пор до него не додумался.
Твоя головоломка напоминает взлом отмычками цилиндровых замков.
Можно пожалуйста пример полностью с хеллоувордом каким нибудь?
Крестоблядь, съеби уже. Хватит притягивать понятие "костыль" ко всему, что увидишь. Если следовать такой логике, то кресты это один большой костыль.
Хочу поиграться с GTK+, сначала из сишки которую плохо знаю, потом из питона.
Но я виндузятник и слабо понимаю как подключаются библиотеки линуксового окружения, да и вообще слабо представляю что называют "окружением".
Обычно использую git-bash, но в его MinGW нет пекедж менеджера.
Насколько я понимаю мне нужно поставить MinGW или msys и в их пекедж-менеджере накатить GTK+.
Дальше мне нужно будет пользоваться башем что идёт с MinGW/msys или можно продолжить с привычным мне git-bash?
Ну вот откуда ты, например, узнал об этом макросе? Какие есть книги, которые рассказывают о таких вещах?
Запердоль линукс в виртуалке, в том же VMware. Под виндой юзать линуксовые тулкиты такое себе. Ну и да, с вида гтк кода ты можешь с непривычки охуеть
>Под виндой юзать линуксовые тулкиты такое себе.
Но GTK же КРОССПЛАТФОРМЕННЫЙ.
Блять, ни одного нормального GUI-фреймверка. Нет, я не хочу Qt.
>реализацию полиморфизма в си?
статический и ad hoc делается макросами
динамический через рукописный vtable
> делается макросами
Вот блять из-за этой залупы половину си-кода читать невозможно. Макрос на макросе макросом погоняет.
Как будто qt хорошая кроссплатформа. У меня на линуксах вообще культей нет. Т.к это говно на крестопараше к которому хуй прикрутишь норм ЯП. Мне вот wxWidgets нравиться, но это тоже не идеал как по мне
>инкапсуляции
на уровне динамических и статический библиотек - функции (и глобальные переменные) следует явно помечать как импортируемые/экпортируемые
на уровне объектных файлов можно ограничить видимость функций и переменных через ключевое слово static
переменные в функциях и блоках имеют локальность
композиция осуществляется за счет возможности введения производных типов, в частности структур
я другой анон, но обзывать человека дегенератом за то что он вполне справедливо заметил о том что отлаживаться принтами - глупость, это конечно, наглость
Тоже встряну. Ведь этот TRACE можно по-иному назвать ERROR_LOG, или просто LOG. Как бы ты лично реализовал логгер в одну строку?
я бы воспользовался утилитами трассирования и профилирования, да что там, достаточно было бы отладчика, так как у них есть базовый функционал для этого, ту же саму трассировку простую можно легко делать в gdb
трассировку такими отладочными макросами имеет смысл делать когда работаешь с замороченным сетевым, многопоточным кодом, потому что, хоть сейчас и есть инструментарий что может работать и с таким кодом, зачастую он требует некой предварительной настройки и, вообще, времени на его освоение
Отлаживаться принтфами вполне нормальная практика, когда на 99% понимаешь, что за код пишешь и как он будет работать, и сомнения лишь есть в самых редких случаях работы программы в сложно-спроектированных программ, но это проблема уже не разработки таких программ, а в слабом проектирование, так как добросовестно спроектированным приложениям отладка совсем не требуется.
Деббагеры нужны только в случае же анализа работы сторонних программ по бинарным файлам - реинженеринг, ну или когда код программы был написан очередным мамкиным программистом на уровне отъебись, т.е. сложность кода стремится к бесконечности, тогда и только тогда стоит использовать специальный отладочный софт. Ну а если программисту известно с чем он столкнулся и для его глаза видно, что программа неоправдано сложно реализована, тогда у него может возникнуть желание написать версию исходника намного простую (но не проще) и практичную (если ему это надо), однако это обратно пропорционально объёму исходного текста программы (желание есть, а исходник овер 9000 строк, поэтому придётся свой прекрасный код мешать с говнокодом).
----
Мораль такова, что не стоит эксплуатировать деббагеры слишком часто в неопраданных целях, потому что это приводит к такой очень плохой практике как "написание программ методом горячей отладки". В "холодной отладке" и "лог отладке" нет ничего хорошего или плохого, однако, прибегая к таким практикам, это в очередной раз лишь показывает непрофессионализм программиста.
Стремитесь к высококвалифицированности в мелочах для самых различных ситуаций программирования, проектирования и исследования стороннего кода по принципу "Лучше быть очередным Пабло Пикассо, чем инертным копипастером".
можно компилировать с опцией оставляющей результат препроцессирования, удобно смотреть во что разворачиваются макросы
потом никто не мешает использовать шаблоны с++, те писать в сишном стиле, но делать шаблоны там где их можно использовать вместо макросов
эй, давай по простому:
нахуя срать макросами трассировки по коду, компилить все это, потом оставлять всю эту отладочную срань в релизе или вычищать ручками, добавляя себе работенку
когда можно тупо прогнать ту же трассировку в отладчике, или, более того, воспользоваться специализированными тулзами для этого
Об этом мной и было написано, к тому же из того следует, что макросы трассировки желательно достигать в объме 1% исходного текста, а также программист, который выпускает исходник в массы с макросами трассировки - показывает лишь то, что этот программист совершенно не самолюбив и ментальная невежда, потому что демонстрирует свою неопытность широким массам и мазолит глаза опытным программистам.
Практика же "журналирования" предполагает постоянный вывод информации об предупреждениях или ошибках при тех или иных обстоятельствах.
Практика же "лог отладки" предполагает лишь создание временной платформы избыточного кода для того, чтобы разрешить неопределенность понимания работы спроектированного кода или произвести локальную проверку на "подводные камни" (т.е. профсамотестирование) и при получение исчерпывающей информации необходимо разобрать данную платформу (если имеется полная увереность в исчерпаности локального исследования работы разработанного кода).
Опишу ситуацию в общем. Много лет писал на паскале, использовал делфи для коммерческих задач и fpc для всякой системщины. На fpc писал используя функциональный стиль программирования. В какой то момент понял, что меня от паскаля уже воротит, и решил перекатиться в си. До этого на си писал под контроллеры только и не особо большие проекты, строк на 200-300 кода. Последний месяц пишу на це. Под линукс использую gcc+clion, под винду студию. Перекатиться с паскаля проблем не составило, к синтаксису привык за неделю. Под линукс уже написано пара проектов сетевых демонов, под винду сейчас пилится один большой проект.
Так вот, оглядываясь на свой код, я понимаю, что поддерживать его в будущем будет затруднительно, так как изначально архитектура приложения была построена криво. Когда проект не большой, помогает рефакторинг, но когда проект разрастается, тут уже борешься за голову и охуеваешь, от того, как криво все спроектировано внутри приложения.
На гитхабе изучены тонны исходников разных проектов, от маленьких до больших опенсорсных. И я замечаю, что большинство из них написаны абы как, лишь бы работало.
Так вот вопрос в чем, может есть где годные книги или статьи, как научиться правильно проектировать приложения, но именно касательно функциональных ЯП? Чтобы в будущем при поддержке проекта не возникли ситуации, что при добавлении новой фичи, приходилось бы переписывать половину кода.
Либо киньте ссылку на гитхаб проекта, который вы считаете эталоном хорошей архитектуры приложения.
Хорошо спроектировать код - это задача творческого характера.
Найти универсальное плацебо для всевозможных програм очень сложно, почти невозможно.
Обычно при проектирование кода желательно придерживаться основных принципов, таких как машстабирование, переносимость, прозрачность и максимальная независимость элементов кода. Также всегда можно обратится к практике "самопрождающих шаблонов проектирования" и полезно ознакомится с видами "антипаттернов", однако иногда при данном использование может понадобиться несколько "паттернов", что может вызвать некоторые избыточности при наложении друг на друга данных методик.
Сколько бы книжек или идеальных проектов не исследовано - проектирование всегда индивидуальный процесс для каждого проекта и регулируется в рамках поставленной цели (хорошо, конечно, если весь проект вписывается в один "паттерн", но это настолько редко, что можно назвать исключением).
Однако, ознакомится с чужим опытом, несомненно, всегда полезно, но следует всегда быть бдительным и аккуратным.
Поэтому производи усилие мысли и ментально-превозмогай, а также пытайся заглянуть наперед в жизненном цикле исходника.
>может есть где годные книги или статьи, как научиться правильно проектировать приложения, но именно касательно функциональных ЯП?
Удваиваю вопрос.
Я бы разнес все максисально по модулям и директориям, по отдельным небольшим файлам. Погугли еще TDD, должно здорово помочь с этим
Последний вообще надо выводить последовательно в цикле
Может есть способы по элегантнее?
//text.h
#define USERNAME "anonymous"
#define TEXT_HELP_APPLICATION \
"Useful documentation of the application for you.\n\
Call program without a pain and regrets, also prepare to kick self ass!\n\
After we are talking with you \
"USERNAME" \
and helpful again.\n"
//main.c
#include <stdio.h>
#include "text.h"
int main ()
{
char* something;
something = TEXT_HELP_APPLICATION;
printf("%s", something);
return 0;
}
Мне такое больше по душе, но это всегда было, как по мне, делом вкуса для каждого программиста.
>хорошей архитектуры приложения
svn, использующий apr
в отличие от git, кстати
это если речь о внутренних потрохах
Насчет "как относились" мне неизвестно, а сам язык с 1972 претерпел значительные конструктивные изменения лишь в 1989-1990 гг.
Далее небольшие дополнения в 1995 году и уже с 1999 годов Си вырос в Плюсы (Костыли) по настоящее время (2011, 2014, 2017 гг.).
Поэтому многие приверженцы языка программирования Си. Нужно больше информации по истории развития языка - читай/учи/разбирайся в спецификациях, включая мёртвые.
Историю развития языка "в лицах" самому было бы забавно почитать, но думаю такое маловероятно найдётся или не будет посвящено полностью только Си языку, а вот с историей развития ЭВМ от гигантов до декстопов весьма полезно будет ознакомится.
Почитать данную историю можешь в интернетах с помощью гугла.
По-моему из этого ответа на SO
https://stackoverflow.com/questions/1644868/c-define-macro-for-debug-printing
>>06805
Дегенерат он потому, что я не писал об отладке ни слова. Просто очередной IDE-ребенок триггернулся "ой, как же, это принтфы, а у меня же туулинг, маам, скажи этому дяде, что сейчас не 1970 год".
И если отлаживаться притфами или дебаггером - вопрос спорный и мне лень об этом спорить (ответ тут простой - нужно уметь и то и то, IDE-дети без отладчика работать не умеют), то здесь никакого вопроса нет, потому что альтернативы подобному логгированию при чтении чужого кода нет. У меня в тексте даже не написано "не пользуйтесь отладчиком", потому что мне похуй. Подобные трейсы при работе с отладчиком тоже помогают.
>трассировку такими отладочными макросами имеет смысл делать когда работаешь с замороченным сетевым, многопоточным кодом, потому что, хоть сейчас и есть инструментарий что может работать и с таким кодом, зачастую он требует некой предварительной настройки и, вообще, времени на его освоение
А еще с кодом с большим количеством рекурсивных вложений, с кодом, использующим плохо выводимые в отладчике структуры данных (типа математики видеокодеков). Ну то есть с любым современным кодом.
А вы мне тут про ваши лабы кукарекаете, в которых можно часами кликать step-in и step-out. То есть в целом аргументация простая - нахуя нам учить что-то новое, если для чтения лаб и так сойдет. Ну деградируйте, хули.
>>06814
>нахуя срать макросами трассировки по коду, компилить все это, потом оставлять всю эту отладочную срань в релизе или вычищать ручками, добавляя себе работенку
Открой для себя git stash, ребенок.
Эй, мудрецы, как там конпеляторы относятся к дефайнам с русскими утф8 символами?
>Насчет "как относились" мне неизвестно
В те годы столько программистов перешло на Си с других языков. Наверняка должны остаться письменные воспоминания с впечатлениями.
Советские программисты, наверное, позже всех перешли.
>Практика же "журналирования" предполагает постоянный вывод информации об предупреждениях или ошибках при тех или иных обстоятельствах.
Не обязательно постоянный. У журналирования может быть несколько уровней, включая несколько уровней отладочной информации.
>Практика же "лог отладки" предполагает лишь создание временной платформы избыточного кода для того, чтобы разрешить неопределенность понимания работы спроектированного кода или произвести локальную проверку на "подводные камни" (т.е. профсамотестирование) и при получение исчерпывающей информации необходимо разобрать данную платформу (если имеется полная увереность в исчерпаности локального исследования работы разработанного кода).
Эта практика предполагает наличие постоянной платформы в виде набора pretty_print функций, которые легко позволяют тебе выводить состояние твоей программы в любом месте. Вывод состояния после отладки ты удаляешь, но вот сами эти функции остаются в коде. В сишке это в особенности важно, потому что даже массивы не умеют себя выводить по умолчанию, не говоря уже о сложных рекурсивных структурах. Десятое правило Гринспена короче.
Впервые о языке C, о системе Unix я прочитал еще в семидесятые… Пользуясь семейным блатом в ГРНТБ (республиканской научно-технической библиотеке), я имел доступ к журналам, которые переводились на русский или реферировались, т.е. считались благонадежными и были всего лишь «для служебного пользования». Каковое пользование заключалось в том, что они в пятницу вечером уносились в сумке из библиотеки, а в понедельник утром благополучно туда возвращались. Так я лет пятнадцать читал Electronics Weekly и Acta Informatica… Но то были рассказы о чем-то далеком и недоступном. Как вдруг, году эдак в 81-м, сразу во многих местах появились магнитные ленты с дистрибутивами Unix v6 и v7. Откуда? Переписали у знакомых, те — у своих знакомых… далее — везде… Система преспокойно запускалась на СМ-4 (игнорируя, естественно, русский язык), а дистрибутивы содержали исходные тексты ядра, компиляторов, утилит, а также полную документацию. Конечно, требовалась русификация драйверов дисплеев и принтеров и «обучение русскому языку» многочисленных программ обработки текстов. Но это все были вполне посильные задачи, главное же — система изначально была вполне работоспособной…
Удивительного в самом факте появления лент мало: в Союз попадала математика от IBM, DEC и HP, теперь вот попали разработки Bell Labs — большое дело! Удивительна была дальнейшая судьба этих лент в Союзе. Не передача (под большим секретом) в пару-тройку институтов, чтобы там на их основе с понтом якобы разрабатывать якобы советскую математику, но бесконтрольное и явно несанкционированное распространение по разным ВЦ в разных городах страны. Похоже, что ленты привезены были в Союз не доблестными героями из «конторы глубинного бурения», а аспирантами-докторантами, выезжавшими по обмену на стажировку в западные университеты (где дистрибутивы Unix распространялись свободно и бесплатно). Конечно, людям вроде меня, бывшим долгие годы невыездными, в это верится с трудом. Когда мне разрешили, наконец, навестить родственников в Польше, я всерьез трясся, что на границе не пропустят купленные там книжки Лема. К счастью, пропустили. Однако помню, как в том же вагоне погранцы повязали старика-поляка. Они когда шли по вагону, то громкой скороговоркой возглашали: «оружие-наркотики-религиозные атрибуты». Это что запрещено, дескать, ко ввозу. Именно так, через тире: оружие — иконки — наркотики… И вот старика обшмонали и обнаружили дешевенькую литографическую бумажную иконку. Старик — явно сельский житель из галицийской глубинки — путая от волнения украинские и польские слова, сбивчиво пытался объяснить, что его старуха больная, он ей везет освященный образок Матки Боски Ченстоховой, только ей, больше никому даже показывать не будет. А когда иконку забрали — заплакал, попытался бухнуться на колени, лопотал, что у старухи рак, она умирает, он только за этим образком в Польшу и ездил… Погранцы увели его и никто в битком набитом вагоне за старика не заступился. И я молчал — такой же трусливый раб, как все, только что с фигой в кармане… Так вот, тогда у меня и в мыслях не могло возникнуть тащить через границу магнитную ленту. Но… это пуганый воробей стреляную ворону боится. А вот знакомый поляк, учившийся в заочной аспирантуре в Киеве, постоянно мотался туда-сюда и именно с лентами. Вряд ли на границе проверяли, где материалы его личной диссертации, а где что-то другое. Да и люди, выезжавшие на Запад на стажировку — хоть и мало таких, но были (даже среди авторов «Заметок» есть) — с хорошими анкетами, непуганые… Так что, по здравому размышлению, версия о привозе в Союз этих лент в порядке частной инициативы выглядит вполне реалистичной.
Другая версия — еще (сюр)реалистичней: через знаменитый рыболовецкий колхоз имени В. И. Ленина, что на острове Сааремаа (вот написал и засомневался: Ленина ли или какого другого краснопузого ублюдка калибром помельче?.. но, не суть важно). Сведущие люди не удивятся и не спросят, а какое это отношение имели эстонские рыбаки к операционным системам и вообще — к компьютерам. Те же, кто не в курсе, могут погуглить “Datasaab affair” — это будет предыстория. Что до самой истории, то позднее мне довелось познакомиться с этими славными колхозниками, о чем расскажу в свое время. На прямой вопрос об их причастности к “Unix affair” я получил довольно уклончивый ответ. Что, как говориться, наводит на…
Ну ладно, так или иначе ленты в страну попали, а дальше… А дальше сработала та Unix-магия, которая очаровывала всякого, кто начинал знакомиться с системой. И которая за считанные годы принесла сугубо исследовательскому, любопытства ради затеянному, некоммерческому проекту феноменальную популярность по всему свету… Хм… тут, чувствую, необходимо сделать некое предуведомление. До сих пор я рассказывал о делах давно минувших, о компьютерах, сохранившихся разве что в музеях, о программах и языках, если и доживших до наших дней, то доживающих где-то в укромных уголках, вдали от столбовых дорог. Unix же сегодня — это даже не одна конкретная система, а целый континент, целая техническая цивилизация со своей сорокалетней историей, что и по меркам человеческой жизни много, а в масштабе спрессованного времени IT-мира соответствует столетиям, эпохам. Это определенная философия, стиль, комплеск идей, определивших облик современной IT-индустрии. Наконец, это весомый сегмент рынка, многомиллиардные активы. Что же до языка C, то он и его потомки (C++, Objective-C, Java, C#) составляют мэйнстрим, доминанту современного программирования… и трудно сыскать язык, созданный в последнюю четверть века и не испытавший его влияния. А для большинства активно работающих программистов (тридцати- и сорокалетних) нынешний мир — единственный, другой они не застали. Я же пытаюсь рассказать о том другом, исчезнувшем мире. О далеких предках могущественных фамилий Unix и C, передавших потомкам свои имена и родовые черты, но отличавшихся от них, нынешних, поведением и мотивацией, привычками и идеалами — очень, очень многим… Тогда в начале восьмидесятых в Союзе мы имели технику семидесятых годов (неизбывное технологическое отставание) и версии Unix нам были доступны из предыдущего десятилетия (не потому даже, что более современные не удалось спереть на Западе, а попросту не было машин, где б они могли работать). Итак, если вдруг кто-то из молодых коллег будет читать этот текст, пусть примет во внимание временнóй фактор: речь идет о первом десятилетии сорокалетней истории. Это все равно как первое столетие четырехвековой истории Нью-Йорка — безлюдные лесные чащобы Манхэттэна, крошечное поселение на побережье и… все еще впереди…
Впервые о языке C, о системе Unix я прочитал еще в семидесятые… Пользуясь семейным блатом в ГРНТБ (республиканской научно-технической библиотеке), я имел доступ к журналам, которые переводились на русский или реферировались, т.е. считались благонадежными и были всего лишь «для служебного пользования». Каковое пользование заключалось в том, что они в пятницу вечером уносились в сумке из библиотеки, а в понедельник утром благополучно туда возвращались. Так я лет пятнадцать читал Electronics Weekly и Acta Informatica… Но то были рассказы о чем-то далеком и недоступном. Как вдруг, году эдак в 81-м, сразу во многих местах появились магнитные ленты с дистрибутивами Unix v6 и v7. Откуда? Переписали у знакомых, те — у своих знакомых… далее — везде… Система преспокойно запускалась на СМ-4 (игнорируя, естественно, русский язык), а дистрибутивы содержали исходные тексты ядра, компиляторов, утилит, а также полную документацию. Конечно, требовалась русификация драйверов дисплеев и принтеров и «обучение русскому языку» многочисленных программ обработки текстов. Но это все были вполне посильные задачи, главное же — система изначально была вполне работоспособной…
Удивительного в самом факте появления лент мало: в Союз попадала математика от IBM, DEC и HP, теперь вот попали разработки Bell Labs — большое дело! Удивительна была дальнейшая судьба этих лент в Союзе. Не передача (под большим секретом) в пару-тройку институтов, чтобы там на их основе с понтом якобы разрабатывать якобы советскую математику, но бесконтрольное и явно несанкционированное распространение по разным ВЦ в разных городах страны. Похоже, что ленты привезены были в Союз не доблестными героями из «конторы глубинного бурения», а аспирантами-докторантами, выезжавшими по обмену на стажировку в западные университеты (где дистрибутивы Unix распространялись свободно и бесплатно). Конечно, людям вроде меня, бывшим долгие годы невыездными, в это верится с трудом. Когда мне разрешили, наконец, навестить родственников в Польше, я всерьез трясся, что на границе не пропустят купленные там книжки Лема. К счастью, пропустили. Однако помню, как в том же вагоне погранцы повязали старика-поляка. Они когда шли по вагону, то громкой скороговоркой возглашали: «оружие-наркотики-религиозные атрибуты». Это что запрещено, дескать, ко ввозу. Именно так, через тире: оружие — иконки — наркотики… И вот старика обшмонали и обнаружили дешевенькую литографическую бумажную иконку. Старик — явно сельский житель из галицийской глубинки — путая от волнения украинские и польские слова, сбивчиво пытался объяснить, что его старуха больная, он ей везет освященный образок Матки Боски Ченстоховой, только ей, больше никому даже показывать не будет. А когда иконку забрали — заплакал, попытался бухнуться на колени, лопотал, что у старухи рак, она умирает, он только за этим образком в Польшу и ездил… Погранцы увели его и никто в битком набитом вагоне за старика не заступился. И я молчал — такой же трусливый раб, как все, только что с фигой в кармане… Так вот, тогда у меня и в мыслях не могло возникнуть тащить через границу магнитную ленту. Но… это пуганый воробей стреляную ворону боится. А вот знакомый поляк, учившийся в заочной аспирантуре в Киеве, постоянно мотался туда-сюда и именно с лентами. Вряд ли на границе проверяли, где материалы его личной диссертации, а где что-то другое. Да и люди, выезжавшие на Запад на стажировку — хоть и мало таких, но были (даже среди авторов «Заметок» есть) — с хорошими анкетами, непуганые… Так что, по здравому размышлению, версия о привозе в Союз этих лент в порядке частной инициативы выглядит вполне реалистичной.
Другая версия — еще (сюр)реалистичней: через знаменитый рыболовецкий колхоз имени В. И. Ленина, что на острове Сааремаа (вот написал и засомневался: Ленина ли или какого другого краснопузого ублюдка калибром помельче?.. но, не суть важно). Сведущие люди не удивятся и не спросят, а какое это отношение имели эстонские рыбаки к операционным системам и вообще — к компьютерам. Те же, кто не в курсе, могут погуглить “Datasaab affair” — это будет предыстория. Что до самой истории, то позднее мне довелось познакомиться с этими славными колхозниками, о чем расскажу в свое время. На прямой вопрос об их причастности к “Unix affair” я получил довольно уклончивый ответ. Что, как говориться, наводит на…
Ну ладно, так или иначе ленты в страну попали, а дальше… А дальше сработала та Unix-магия, которая очаровывала всякого, кто начинал знакомиться с системой. И которая за считанные годы принесла сугубо исследовательскому, любопытства ради затеянному, некоммерческому проекту феноменальную популярность по всему свету… Хм… тут, чувствую, необходимо сделать некое предуведомление. До сих пор я рассказывал о делах давно минувших, о компьютерах, сохранившихся разве что в музеях, о программах и языках, если и доживших до наших дней, то доживающих где-то в укромных уголках, вдали от столбовых дорог. Unix же сегодня — это даже не одна конкретная система, а целый континент, целая техническая цивилизация со своей сорокалетней историей, что и по меркам человеческой жизни много, а в масштабе спрессованного времени IT-мира соответствует столетиям, эпохам. Это определенная философия, стиль, комплеск идей, определивших облик современной IT-индустрии. Наконец, это весомый сегмент рынка, многомиллиардные активы. Что же до языка C, то он и его потомки (C++, Objective-C, Java, C#) составляют мэйнстрим, доминанту современного программирования… и трудно сыскать язык, созданный в последнюю четверть века и не испытавший его влияния. А для большинства активно работающих программистов (тридцати- и сорокалетних) нынешний мир — единственный, другой они не застали. Я же пытаюсь рассказать о том другом, исчезнувшем мире. О далеких предках могущественных фамилий Unix и C, передавших потомкам свои имена и родовые черты, но отличавшихся от них, нынешних, поведением и мотивацией, привычками и идеалами — очень, очень многим… Тогда в начале восьмидесятых в Союзе мы имели технику семидесятых годов (неизбывное технологическое отставание) и версии Unix нам были доступны из предыдущего десятилетия (не потому даже, что более современные не удалось спереть на Западе, а попросту не было машин, где б они могли работать). Итак, если вдруг кто-то из молодых коллег будет читать этот текст, пусть примет во внимание временнóй фактор: речь идет о первом десятилетии сорокалетней истории. Это все равно как первое столетие четырехвековой истории Нью-Йорка — безлюдные лесные чащобы Манхэттэна, крошечное поселение на побережье и… все еще впереди…
Сама же система Unix привлекала своей компактностью, обозримостью, концептуальной стройностью, легкостью. Она изначально задумывалась и создавалась как антитеза тяжеловесным, многофункциональным, переусложненным, труднопостижимым, внушающим почтительный ужас разработкам огромных коллективов, что было характерно для эпохи мэйнфреймов. Квинтэссенция, яркий зримый образ этих чудищ нарисован в замечательной книге руководителя разработки системы OS/360 Фредерика Брукса «Мифический человеко-месяц» (“The Mythical Man-Month” by Frederick Brooks) — асфальтовая топь, зыбучая смоляная трясина, неумолимо затягивающая попавших в нее динозавров. В книге убедительно показано, каких чудовищных усилий и денег стоит разработка больших систем, достижение должного уровня качества и надежности. Создатели Unix участвовали в разработке операционной системы Multics, само название которой (Multiplexed Information and Computing Service) недвусмысленно указывало на сложность, множественность исполняемых функций. Устав барахтаться в смоляной яме «отцы-основатели» Кен Томпсон и Деннис Ритчи принялись делать простую и понятную систему, которую они с явным вызовом поначалу назвали Unics, т.е. “uniplexed” по контрасту с “multiplexed”. (Забавно, что пресловутый монстр Multics выглядит предельно компактным и простым до примитивности на фоне современных операционных систем, потомков Unix).
В своей книге Брукс вспоминает излюбленные журналистами сказания о том, как дескать пара энтузиастов склепала на коленке в гараже замечательную программу, оказавшуюся лучше корпоративных разработок с многомиллионными бюджетами. Многоопытный менеджер проекта с понятным сарказмом вопрошает, почему же дуэты одержимых парней из гаражей не заменили собой софтверные компании? А ведь правда — не заменили. Но и пресловутые гаражные дуэты — не выдумка: Билл Хьюлетт и Дэйв Паккард, Билл Гейтс и Пол Аллен, Стив Джобс и Стив Возняк, из совсем недавних — Ларри Пейдж и Сергей Брин. Они — больше, чем правда: «двое в гараже» — архетип современного мифа. А разгадка кажущегося противоречия в том, что в гаражах начинают, но успешное начинание успешно продолжаться может только в офисе… Unix, созданный хоть и не в гараже, но небольшой группой исследователей, тоже стал мифом, а точнее — жертвой на алтаре собственного культа.
К концу семидесятых Unix являл собой идеальную систему для университетов и исследовательских лабораторий, т.е. для групп энтузиастов. Он был ясен и прозрачен, поскольку реализовывал только «самые вкусные», концептуально важные идеи. По сути, это был замечательный набор инструментов и заготовок для творческого применения при самостоятельном построении операционной среды. Дополнительным плюсом было то, что помимо великолепно написанных программ имелась не менее великолепно написанная документация. Впрочем, тексты эти грех называть казенным словом «документация». Чего стоила только «Книга Джона Лайонса» (“Lions’ Commentary on Unix” by John Lions), которая объясняла функционирование ядра системы «в лицах», комментируя работу его модулей и служб — совершенно уникальное, бесценное пособие… Так, а чего же в системе не было? Не было ничего даже отдаленно напоминающего интуитивно-понятный «дружественный» интерфейс. Система предназначалась искушенным профи, а никак не лопуховатым ламерам, и принципиально не «обихаживала» пользователя. Что еще? Вот я упомянул раньше, что не было поддержки русского языка. Так никакого языка, ничегошеньки, кроме базовой (английской) латиницы и неявной локализации для Соединенных Штатов. Предполагалось, что если понадобится французу, японцу или русскому поддержать родной язык, то он изучит исходный код, да и наточит систему соответствующим образом. А если у кого-то на машине стоит устройство, которого не стояло у разработчиков в Bell Labs (и посему нет в поставке), то пускай возьмет и сам напишет драйвер устройства. Ну, а если захочется перенести систему на другую машинную архитектуру, то… все открыто, изучай, пиши C-компилятор (даже не весь, а только кодогенератор — модуль, где сконцентрирована машинная специфика), потом меняй машинно-зависимые модули ядра системы и… вперед. Непростая, но страшно интересная задача.
Итак, Unix был по сути типичным удачным исследовательским проектом. Только — очень удачным. Настолько удачным, что распространение его напоминало пандемию (чему изрядно поспоспешествовали дешевизна и либерализм лицензий). Естественно, не могло не возникнуть желание подзаработать на столь популярной штуковине и… дальше, в восьмидесятые годы, начинается уже другая история: выпуск множества коммерческих версий, череда покупок и перекупок лицензионных прав, бесконечные судебные тяжбы, появление альтернативных ядер (Minix, Linux), в девяностые — дурацкая быдловатая «юниксомания», круто замешанная на завистливой «гейтсофобии»… Все это общеизвестно и совсем неинтересно. На авансцену вышли торговцы, юристы и пиарщики, а симпатичные бородачи — создатели системы — тихонько отошли в тень и, поскольку слово “Unix” стало товаром, продолжили свои исследования под другой вывеской — Plan 9…
Ход событий в Союзе соответствует общему тренду: сначала хаотичное увлеченное «освоение» новой игрушки; потом постепенно выкристализовываются центры, где адаптацией и локализацией начинают заниматься всерьез — ИНЭУМ, Курчатовский институт, ИПК Минавтопрома — и выпускают, наконец, три конкурирующие локализованные версии для советских клонов PDP-11 — ИНМОС, ДЕМОС, МНОС, соответственно (расшифровка аббревиатур: «инструментальная мобильная», «диалоговая единая мобильная», «машинно-независимая» операционная система). Особняком, слегка на отшибе держались те, кто реализовывал Unix на машинах не самых массовых и популярных. Я упоминал уже команду из МГУ, сделавшую реализацию на ЕС-1010 и 1012, причем, написавшую с чистого листа C-компилятор и ядро ОС (насколько я знаю, на французские прототипы этих машин, Mitra-15 и 225, Unix так и не был портирован). В другой команде, ухитрившейся засунуть Unix в «советский Wang», легендарную «ядерно-бухгалтерскую» машину Искра-226 (о, это было не просто!), довелось участвовать автору этих строк. Но это отдельная история…
Сама же система Unix привлекала своей компактностью, обозримостью, концептуальной стройностью, легкостью. Она изначально задумывалась и создавалась как антитеза тяжеловесным, многофункциональным, переусложненным, труднопостижимым, внушающим почтительный ужас разработкам огромных коллективов, что было характерно для эпохи мэйнфреймов. Квинтэссенция, яркий зримый образ этих чудищ нарисован в замечательной книге руководителя разработки системы OS/360 Фредерика Брукса «Мифический человеко-месяц» (“The Mythical Man-Month” by Frederick Brooks) — асфальтовая топь, зыбучая смоляная трясина, неумолимо затягивающая попавших в нее динозавров. В книге убедительно показано, каких чудовищных усилий и денег стоит разработка больших систем, достижение должного уровня качества и надежности. Создатели Unix участвовали в разработке операционной системы Multics, само название которой (Multiplexed Information and Computing Service) недвусмысленно указывало на сложность, множественность исполняемых функций. Устав барахтаться в смоляной яме «отцы-основатели» Кен Томпсон и Деннис Ритчи принялись делать простую и понятную систему, которую они с явным вызовом поначалу назвали Unics, т.е. “uniplexed” по контрасту с “multiplexed”. (Забавно, что пресловутый монстр Multics выглядит предельно компактным и простым до примитивности на фоне современных операционных систем, потомков Unix).
В своей книге Брукс вспоминает излюбленные журналистами сказания о том, как дескать пара энтузиастов склепала на коленке в гараже замечательную программу, оказавшуюся лучше корпоративных разработок с многомиллионными бюджетами. Многоопытный менеджер проекта с понятным сарказмом вопрошает, почему же дуэты одержимых парней из гаражей не заменили собой софтверные компании? А ведь правда — не заменили. Но и пресловутые гаражные дуэты — не выдумка: Билл Хьюлетт и Дэйв Паккард, Билл Гейтс и Пол Аллен, Стив Джобс и Стив Возняк, из совсем недавних — Ларри Пейдж и Сергей Брин. Они — больше, чем правда: «двое в гараже» — архетип современного мифа. А разгадка кажущегося противоречия в том, что в гаражах начинают, но успешное начинание успешно продолжаться может только в офисе… Unix, созданный хоть и не в гараже, но небольшой группой исследователей, тоже стал мифом, а точнее — жертвой на алтаре собственного культа.
К концу семидесятых Unix являл собой идеальную систему для университетов и исследовательских лабораторий, т.е. для групп энтузиастов. Он был ясен и прозрачен, поскольку реализовывал только «самые вкусные», концептуально важные идеи. По сути, это был замечательный набор инструментов и заготовок для творческого применения при самостоятельном построении операционной среды. Дополнительным плюсом было то, что помимо великолепно написанных программ имелась не менее великолепно написанная документация. Впрочем, тексты эти грех называть казенным словом «документация». Чего стоила только «Книга Джона Лайонса» (“Lions’ Commentary on Unix” by John Lions), которая объясняла функционирование ядра системы «в лицах», комментируя работу его модулей и служб — совершенно уникальное, бесценное пособие… Так, а чего же в системе не было? Не было ничего даже отдаленно напоминающего интуитивно-понятный «дружественный» интерфейс. Система предназначалась искушенным профи, а никак не лопуховатым ламерам, и принципиально не «обихаживала» пользователя. Что еще? Вот я упомянул раньше, что не было поддержки русского языка. Так никакого языка, ничегошеньки, кроме базовой (английской) латиницы и неявной локализации для Соединенных Штатов. Предполагалось, что если понадобится французу, японцу или русскому поддержать родной язык, то он изучит исходный код, да и наточит систему соответствующим образом. А если у кого-то на машине стоит устройство, которого не стояло у разработчиков в Bell Labs (и посему нет в поставке), то пускай возьмет и сам напишет драйвер устройства. Ну, а если захочется перенести систему на другую машинную архитектуру, то… все открыто, изучай, пиши C-компилятор (даже не весь, а только кодогенератор — модуль, где сконцентрирована машинная специфика), потом меняй машинно-зависимые модули ядра системы и… вперед. Непростая, но страшно интересная задача.
Итак, Unix был по сути типичным удачным исследовательским проектом. Только — очень удачным. Настолько удачным, что распространение его напоминало пандемию (чему изрядно поспоспешествовали дешевизна и либерализм лицензий). Естественно, не могло не возникнуть желание подзаработать на столь популярной штуковине и… дальше, в восьмидесятые годы, начинается уже другая история: выпуск множества коммерческих версий, череда покупок и перекупок лицензионных прав, бесконечные судебные тяжбы, появление альтернативных ядер (Minix, Linux), в девяностые — дурацкая быдловатая «юниксомания», круто замешанная на завистливой «гейтсофобии»… Все это общеизвестно и совсем неинтересно. На авансцену вышли торговцы, юристы и пиарщики, а симпатичные бородачи — создатели системы — тихонько отошли в тень и, поскольку слово “Unix” стало товаром, продолжили свои исследования под другой вывеской — Plan 9…
Ход событий в Союзе соответствует общему тренду: сначала хаотичное увлеченное «освоение» новой игрушки; потом постепенно выкристализовываются центры, где адаптацией и локализацией начинают заниматься всерьез — ИНЭУМ, Курчатовский институт, ИПК Минавтопрома — и выпускают, наконец, три конкурирующие локализованные версии для советских клонов PDP-11 — ИНМОС, ДЕМОС, МНОС, соответственно (расшифровка аббревиатур: «инструментальная мобильная», «диалоговая единая мобильная», «машинно-независимая» операционная система). Особняком, слегка на отшибе держались те, кто реализовывал Unix на машинах не самых массовых и популярных. Я упоминал уже команду из МГУ, сделавшую реализацию на ЕС-1010 и 1012, причем, написавшую с чистого листа C-компилятор и ядро ОС (насколько я знаю, на французские прототипы этих машин, Mitra-15 и 225, Unix так и не был портирован). В другой команде, ухитрившейся засунуть Unix в «советский Wang», легендарную «ядерно-бухгалтерскую» машину Искра-226 (о, это было не просто!), довелось участвовать автору этих строк. Но это отдельная история…
https://medium.com/@kpem/воспоминания-советского-еврея-программиста-e57bd8666ae4
>Вывод состояния после отладки ты удаляешь, но вот сами эти функции остаются в коде.
угу, мусорный, пустой код
>В сишке это в особенности важно, потому что даже массивы не умеют себя выводить по умолчанию, не говоря уже о сложных рекурсивных структурах.
про pretty print в отладчиках слышал что нибудь?
еще раз: нахуя замусоривать код служебными вещами, когда можно обойтись готовым инструментарием?
>нахуя срать макросами трассировки по коду, компилить все это, потом оставлять всю эту отладочную срань в релизе или вычищать ручками, добавляя себе работенку
>Открой для себя git stash, ребенок.
при чем здесь git stash вообще бля?
Ебал я пытаться разобраться в многопоточном игровом движке отладчиком. Пускай он и на крестах
Мимо
>А еще с кодом с большим количеством рекурсивных вложений, с кодом, использующим плохо выводимые в отладчике структуры данных (типа математики видеокодеков). Ну то есть с любым современным кодом.
современные отладчики все это отлично переваривают, там даже скрипты подрубить можно, в gdb питон
повторюсь, мне похуй как ты там отлаживаешься
но бесит, когда вы срете в код своими макросами отладочными, оставляя всю эту мусорную срань в релизе
дело твое, вставляй printf обернутые макросами, как седые деды на pdp11 делали
ингнорируй весь тулинг, что за 50 лет существования языка был сделан
похуй
>Вывод состояния после отладки ты удаляешь, но вот сами эти функции остаются в коде.
Да, остаются в отдельном файле и благодаря макросам в сборку под релиз программы не попадают.
Си написан программистами для программистов, в отличие от корпоративных монстров с жуткими спецификациями. Та же хуйня с TCP/IP, у Танненбаума в Компьютерных сетях про это есть.
>при чем здесь git stash вообще бля?
При том, что IDE-дети не знают текстовых консольных утилит и не умеют с ними работать. Ты, например, не умеешь, и уверен, что нужно что-то там "вычищать ручками", хотя это не так. Совсем мусор stash'ится, важные вещи коммитятся и впоследствии ребейзятся.
Поэтому твои аргументы про "замусоривание" кода инвалидные. Так же как и про "тулинг за 50 лет". Это ты с git'ом работать не умеешь, а не я с отладчиком.
>современные отладчики все это отлично переваривают, там даже скрипты подрубить можно, в gdb питон
Это все пустые слова с дивана. Давай конкретику. Вот ты скачал с репы какой-то код, успешно сбилдил, дальше я проставляю трейсы в коде (это 5 букв TRACE в конце любой строчки), а ты, получается, пишешь какой-то скрипт для gdb. Какой?
>Уважаемые, я не совсем понимаю, пример чего вы здесь привели? Что крутой программер, адепт си, уже 18 лет как перешел на с++? Что это доказывает?
Читай внимательнее ветку! Анон утверждал, что на чистом Си тяжелые проекты не потянуть, а вот кресты - это свет в оконце. Я ему в пример привёл Кармака, который до 2000 всю игроклассику на чистом Си лопатил; вполне себе пример тяжёлых проектов.
Ну какбэ и времена были другие. Гтк на чистом си, ядро линупз, еще тысячи программ. Что это доказывает? На с++ то все равно удобнее разработка, иначе бы его просто не существовало. Причем то, что кресты удобнее стало очевидно еще страусу в 1985 году.
> дальше я проставляю трейсы в коде (это 5 букв
TRACE в конце любой строчки), а ты, получается, пишешь какой-то скрипт для gdb. Какой?
ты можешь сделать трассировку в gdb, либо воспользоваться еще более специализироваными тулами для этого
бля, да отладчики именно для этого и предназначены
скрипты для gdb нужно для сложных сценариев отладки
в данном же случае я говорил что для отладки сложных структур данных можно воспользоваться pretty print заготовками для того же gdb, для многих библиотек они уже есть готовые и несложно сделать их для своих часто используемых структур
нахуй нужна дополнительная работа, когда можно воспользоваться говым тулингом
ты сначала тратишь время на освоение его, но потом выигрываешь в том что меньше пишешь ручками
хотя если хочешь по старинке лепить руками трассировку - делай это, без проблем
> несложно сделать их для своих часто используемых структур
> нахуй нужна дополнительная работа
Си-сектанты даже и не знают, что в разработке с++ учавствовал сам Р-чи.
Это про евреев, они не показатель.
>ты можешь сделать трассировку в gdb, либо воспользоваться еще более специализироваными тулами для этого
Давай конкретику.
Вот написал макрос, написал, как им пользоваться. Ты утверждаешь, что с отладчиком это быстрее. Ну так напиши, как это быстрее. Или это с дивана быстрее, а на самом деле нет?
>в данном же случае я говорил что для отладки сложных структур данных можно воспользоваться pretty print заготовками для того же gdb, для многих библиотек они уже есть готовые и несложно сделать их для своих часто используемых структур
Ну то есть у тебя есть два стула
1. Написать pretty print библиотеку на языке приложения, которая будет работать всегда и везде и в любой ситуации (включая консоль gdb)
2. Написать скрипты для отладчика, для своей среды, которые будут работать только в конкретном отладчике
И первое - мусорный код. А второе - хороший годный код.
>нахуй нужна дополнительная работа, когда можно воспользоваться говым тулингом
Напоминаю, что дополнительная работа - это написать TRACE в нужных тебе местах. При чем TRACE это красиво выглядит. Макрос можно и QQQ обозвать. А когда ты выяснил, что тебе нужно, сделать git stash. Я даже не говорю про более продвинутую текстовую фильтрацию.
>хотя если хочешь по старинке лепить руками трассировку - делай это, без проблем
По какой старинке? Мне не 50 лет, я начинал с IDE с встроенным отладчиком, мне как раз усилия требовались, чтобы уйти от отладчика и не пользоваться им там, где он не нужен.
Где там-то, я набрал ascii games в гугле
Ну, я знал конечно классику типа NetHack или других рогаликов, но как-то в голову не приходило, что кто-то мог не слышать об этом. Видимо я старый слишком
>симпатичные бородачи
Тут же представил Кернигана. Пиздец. Как де я балдею от его внешности. Типикал учёный, которых я представлял в детстве.
>что меньше пишешь ручками
Вообще у чётких пацанов код сам себя пишет и сам же себя и отлаживает.
Пиздец, IDE-животные обленились. Не могут даже строчку какую-то вшивую написать. Охуеть. При этом аргументируя это тем, что сценарий для отладки выйдет намного меньше чем одна строчка в коде.
>IDE-животные
ПАЦАНЫ, Я СЕГОДНЯ ШЁЛ КОРОЧЕ ПО ОФИСУ И УВИДЕЛ ПИЗДЮКА В МАЙКЕ "VS-CODE", НУ Я ПОДСКОЧИЛ И РЕЗКО РЕБУТНУЛ ЕГО ТАЧКУ С ВЕРТУШКИ И ПОЯСНИЛ ЕГО КРИКОМ "НЕ ЛЮБЛЮ ПРОПРИЕТАРНЫЕ ПРОДУКТЫ", ПОТОМУ ЧТО Я УГОРЕЛ ПО VIM, ПАЦАНЫ ДУХ СТАРОЙ ШКОЛЫ ЖИВЁТ ТОЛЬКО В UNIX, ГДЕ ЕБАШАТСЯ ПО ХАРДКОРУ, ГДЕ ПРОГЕРЫ ЖИВУТ ТЕРМИНАЛОМ, МОЛОДОСТЬЮ И ЕБУТ СИСТЕМУ В РОТ! ТОЛЬКО GNU, ТОЛЬКО ХАРДКОР!!! ОПЕНСОРС УЛЬТРАХАРДКОР БАШ!!! пацаны ебашьте на си, собирайте проекты в make, угорайте на конференциях, любите своих Линуса, пацанов и Демо-Сцену! ГОВОРИТЕ ОТКРЫТО И СМЕЛО ПРЯМО В ЛИЦО! VIM!
зелено
>что дополнительная работа - это написать TRACE в нужных тебе местах
блядь, зачем это делать, когда можно просто собрать проект с отладочными символами и подхватить отладчик? блядь, да предназначение отладчика как раз в том и заключается чтобы делать трассировку, это его основная функция
пиздец
>git stash
бля, вот это костыль ты придумал, лол
только сейчас дошло зачем ты его используешь в этом случае
те ты у себя в рабочей директории срешь по коду макросами TRACE, а чтобы не срать ими в репу, прячешь этот код в stash
бля, пиздец, вот ты ебнутый
УРЕТЕ! Это тянощка-писейчка выпускница программы Outreachy, благодаря которой она стала програмистской, вопреки хейту хуеблядей.
Тоже самое только больше копатни.
Тянощка вынуждена называть себя в сети мужским родом, чтобы избежать дискриминации. Неужели не очевидно?
>блядь, зачем это делать, когда можно просто собрать проект с отладочными символами и подхватить отладчик
Ты так и не сказал, что конкретно ты будешь делать.
>Уже нашел? Сколько получаешь? Или только мечтаешь?
реверсом можно зарабатывать норм. Сам я макака которая только может в основы С и реверса, но коллеги которые асем в ИдеПРО читают как боги и пишут шеллы на С получают по 4-5к фунтов/евро в месяц. ХЗ есть ли подобная работа в рашке, но в бриташке, гермашке и швятой сша ее валом, гуглить Security consulting + native code + job
там я писал про зп после налогов в месяц, но 70-80к в год - это хорошая, годная зарплата для Юкей в случае понаеха
Это чё, надо загрузчик PE и ELF файлов писать?
Хто я?
#include <stdio.h>
int main()
{
int n, k, a=0, b=0, x=0;
scanf_s("%i %i", &n, &k);
while (x<1 || b<n)
{
a++;
b = k * a;
if (b == n) x = 1;
}
if (x == 1) printf("YES");
else printf("NO");
return 0;
}
Проблема в том, что цикл не останавливается при отрицательном ответе, что бы я ни делал.
Так добавь условие в цикл.
У тебя x меняется только при условии, что б равно н.
попробуй в условии поставить и, вместо или
При "и" разве цикл не продолжит делать итерации, пока оба условия не станут истинны? Почему это работает здесь как "или"? Почему "или" не работает?
Или работает пока одно из условий истинно, и работает, только когда оба условия истинно, в твоём случае если поставишь и, то цикл вылетит когда b >= n.
Кажется, я понял. Например; (x<1?=0) и (b<n?=1)На одной из итераций уже нет. 0^1=0, цикл прерывается. А если 0v1, то это равно 1 и цикл продолжается. Я правильно понял?
>Программа должна выводить YES, если k имеет целую степень, которая даёт n
Но у тебя же там не степень, а произведение. Ответ да, если существует целое a, такое что k*a=n. Иными словами n % k == 0.
Собственно поэтому тебе в твоей лабе дали степень, чтобы ты модуль не использовал, а логарифмы вы не проходили.
>Проблема в том, что цикл не останавливается при отрицательном ответе, что бы я ни делал.
А зачем ты допускаешь отрицательный ответ? В твоей задаче можно написать k=abs(k), n=abs(n) и больше об этом не париться.
В случае степеней все еще проще
Думаю, на плюсах все же проще выстрелить себе в ногу.
Нельзя использовать ничего кроме stdio.h, это препод такой, который как раз намеренно заставляет париться.
Я это пониманию. Но, тем не менее, код у тебя неправильный, он отвечает вопрос не про степень, а про делимость
> Сам я макака которая только может в основы С
> ХЗ есть ли подобная работа в рашке
> но в бриташке, гермашке и швятой сша
Классика. Какая разница что там НА ЗАПАДЕ, если чтобы туда свалить тебе нужен охуеннейший опыт, который трудно получить в рашке?
пишешь библиотеку, разбирающую любой бинарный формат
Пиши полиморфный криптор с LoadPE.
>gcc new.c -o new.exe
Что тут не так, что пpовеpить?
А что собственно выводит данная команда? Может у тебя прав на запись нет в этой директории.
эта запись ничего не выводит. Пpоходит некотоpое вpемя и потом следующей стpокой идёт та же папка, словно ничего не пpоизошло. Ну и файла нет.
Может ты конпелируешь в одной директории, а смотришь в другой? Не может быть, чтобы она ничего не выводила.
Вместо gcc new.c -o new.exe сделай gcc -Wall new.c -o new. Во-первых, посмотри, что за ворнинги вываливать будут (-Wall), во-вторых, расширение не указывай.
Что "так же"? В переменных среды путь правильно прописал? Если правильно, то в cmd независимо от текущего местоположения по команде gcc --help помощь для gcc должна на экран выкидываться.
Фаервол/антивирус ничего не рубит?
Параметр -Wall выдачу предупреждений/уведомлений врубает, по-прежнему ничего не пишет во время компиляции?
Попробуй ещё gcc -std=c11 -Wall -Wextra new.c -o new
ну в паpаметpах всё обычно: C:\MinGW\bin;C:\MinGW\MSYS\1.0\bin;C:\MinGW\MSYS\1.0\local\bin
>помощь для gcc должна на экран выкидываться
так и пpоисходит. Всякие команды. Веpсию тоже показывает.
Антивиpуса у меня... Нет.
Да, -Wall ничего не пишет.
>Попробуй ещё gcc -std=c11 -Wall -Wextra new.c -o new
так же ничего не пишет, словно всё ноpмально.
Кстати, если пpопустить точку с запятой или пpочее, gcc находит ошибки. Но до файла .exe дело не доходит
>что пишет?
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/6.3.0/lto-wrapper.exe
Target: mingw32
Configured with: ../src/gcc-6.3.0/configure --build=x86_64-pc-linux-gnu --host=mingw32 --target=mingw32 --with-gmp=/mingw --with-mpfr --with-mpc=/mingw --with-isl=/mingw --prefix=/mingw --disable-win32-registry --with-arch=i586 --with-tune=generic --enable-languages=c,c++,objc,obj-c++,fortran,ada --with-pkgversion='MinGW.org GCC-6.3.0-1' --enable-static --enable-shared --enable-threads --with-dwarf2 --disable-sjlj-exceptions --enable-version-specific-runtime-libs --with-libiconv-prefix=/mingw --with-libintl-prefix=/mingw --enable-libstdcxx-debug --enable-libgomp --disable-libvtv --enable-nls
Thread model: win32
gcc version 6.3.0 (MinGW.org GCC-6.3.0-1)
COLLECT_GCC_OPTIONS='-v' '-o' 'new.exe' '-mtune=generic' '-march=i586'
c:/mingw/bin/../libexec/gcc/mingw32/6.3.0/cc1.exe -quiet -v -iprefix c:\mingw\bin\../lib/gcc/mingw32/6.3.0/ new.c -quiet -dumpbase new.c -mtune=generic -march=i586 -auxbase new -version -o C:\Users\273C~1\AppData\Local\Temp\ccdYSzDE.s
GNU C11 (MinGW.org GCC-6.3.0-1) version 6.3.0 (mingw32)
compiled by GNU C version 6.3.0, GMP version 6.1.2, MPFR version 3.1.5, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "c:\mingw\bin\../lib/gcc/mingw32/6.3.0/../../../../mingw32/include"
ignoring duplicate directory "c:/mingw/lib/gcc/../../lib/gcc/mingw32/6.3.0/include"
ignoring duplicate directory "/mingw/lib/gcc/mingw32/6.3.0/../../../../include"
ignoring duplicate directory "c:/mingw/lib/gcc/../../include"
ignoring duplicate directory "c:/mingw/lib/gcc/../../lib/gcc/mingw32/6.3.0/include-fixed"
ignoring nonexistent directory "c:/mingw/lib/gcc/../../lib/gcc/mingw32/6.3.0/../../../../mingw32/include"
ignoring duplicate directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
c:\mingw\bin\../lib/gcc/mingw32/6.3.0/include
c:\mingw\bin\../lib/gcc/mingw32/6.3.0/../../../../include
c:\mingw\bin\../lib/gcc/mingw32/6.3.0/include-fixed
End of search list.
GNU C11 (MinGW.org GCC-6.3.0-1) version 6.3.0 (mingw32)
compiled by GNU C version 6.3.0, GMP version 6.1.2, MPFR version 3.1.5, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 384cad586f05ed581a9c068b2f18b408
>что пишет?
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/6.3.0/lto-wrapper.exe
Target: mingw32
Configured with: ../src/gcc-6.3.0/configure --build=x86_64-pc-linux-gnu --host=mingw32 --target=mingw32 --with-gmp=/mingw --with-mpfr --with-mpc=/mingw --with-isl=/mingw --prefix=/mingw --disable-win32-registry --with-arch=i586 --with-tune=generic --enable-languages=c,c++,objc,obj-c++,fortran,ada --with-pkgversion='MinGW.org GCC-6.3.0-1' --enable-static --enable-shared --enable-threads --with-dwarf2 --disable-sjlj-exceptions --enable-version-specific-runtime-libs --with-libiconv-prefix=/mingw --with-libintl-prefix=/mingw --enable-libstdcxx-debug --enable-libgomp --disable-libvtv --enable-nls
Thread model: win32
gcc version 6.3.0 (MinGW.org GCC-6.3.0-1)
COLLECT_GCC_OPTIONS='-v' '-o' 'new.exe' '-mtune=generic' '-march=i586'
c:/mingw/bin/../libexec/gcc/mingw32/6.3.0/cc1.exe -quiet -v -iprefix c:\mingw\bin\../lib/gcc/mingw32/6.3.0/ new.c -quiet -dumpbase new.c -mtune=generic -march=i586 -auxbase new -version -o C:\Users\273C~1\AppData\Local\Temp\ccdYSzDE.s
GNU C11 (MinGW.org GCC-6.3.0-1) version 6.3.0 (mingw32)
compiled by GNU C version 6.3.0, GMP version 6.1.2, MPFR version 3.1.5, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "c:\mingw\bin\../lib/gcc/mingw32/6.3.0/../../../../mingw32/include"
ignoring duplicate directory "c:/mingw/lib/gcc/../../lib/gcc/mingw32/6.3.0/include"
ignoring duplicate directory "/mingw/lib/gcc/mingw32/6.3.0/../../../../include"
ignoring duplicate directory "c:/mingw/lib/gcc/../../include"
ignoring duplicate directory "c:/mingw/lib/gcc/../../lib/gcc/mingw32/6.3.0/include-fixed"
ignoring nonexistent directory "c:/mingw/lib/gcc/../../lib/gcc/mingw32/6.3.0/../../../../mingw32/include"
ignoring duplicate directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
c:\mingw\bin\../lib/gcc/mingw32/6.3.0/include
c:\mingw\bin\../lib/gcc/mingw32/6.3.0/../../../../include
c:\mingw\bin\../lib/gcc/mingw32/6.3.0/include-fixed
End of search list.
GNU C11 (MinGW.org GCC-6.3.0-1) version 6.3.0 (mingw32)
compiled by GNU C version 6.3.0, GMP version 6.1.2, MPFR version 3.1.5, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 384cad586f05ed581a9c068b2f18b408
Да хз, по мне, так антивирус/фаервол/встроенная защита что-то рубит. Опять же, права/учётная запись какие? Админские?
Попробуй:
а). Создать какой-нибудь простейший хелло-ворлд и его компильнуть. Может, у тебя в твоей программуле какой-нибудь аномальный крокодил неперевариваемый?
б). Попробуй хелло-ворлд из предыдущего пункта make-ом компильнуть. Создаёшь Makefile, вот прям с таким ровно названием и без расширения. Пусть, к примеру, файл с текстом программы будет называться hello.c Тогда содержимое Makefile:
hello: hello.c
gcc -std=c11 -Wall -Wextra hello.c -o hello
Дальше, находясь в директории с hello.c и Makefile делаешь из командной строки mingw32-make и смотришь, что там дальше. Хотя, ещё раз, у тебя кажись на уровне правильной установки mingw и админства лажа какая-то.
hello: hello.c
[здесь Tab нажмёшь или 4 отступа сделаешь]gcc -std=c11 -Wall -Wextra hello.c -o hello
Бле, чем с глюченой вендой пердолится, лучше бы развернул линух на виртуалке давно.
Кароч, вычисти всё, а потом Code::Blocks со встроенным MinGW поставь и не еби мозга! Чёт у тебя там какие-то дупликейт директори... Ты несколько раз там случаем MinGW на машину не воткнул?
> C:\Users\273C~1\AppData\Local\Temp\ccdYSzDE.s
SET TEMP=C:\test
SET TMP=C:\test
Создай C:\test и права дай. И gcc -save-temps foo.c -o foo.exe, и сходи в эту директорию посмотреть на наличие файлов .s. Подозреваю, что оно давится либо именем new, либо (гораздо вероятнее) давится твоим русским путем.
да, от администpатоpа.
>а
Этот вайл, что я пытаюсь скомпилиpовать, и есть пpосто хелловоpлд.
>б
Makefile:2: * missing separator. Stop.
mingw32-make: Interrupt/Exception caught (code = 0xc0000005, addr = 0x77682108)
>>08727
он тоже не компилиpует. Хотя pаньше компилиpовал.
Я где-то пpочитал, что это может быть связано с тем, что вин 64-pазpядная. Ну у всех же pаботает обычно. Мне это всё уже поднадоело. Может пеpеустановка вин помочь? ...
Уже сказали - вычисти к хуям все компиляторы из системы (у меня fpc помню перехватывал вызов make, лол). Потом установи тот же C:B или там Студию2010 и попробуй.
>Я где-то пpочитал, что это может быть связано с тем, что вин 64-pазpядная
У меня 7-ка 64-разрядная. Нормально, тьфу-тьфу-тьфу, компиляет. Но я тупо Code::Blocks со включённым MinGW установил если его будешь ставить, смотри, правильную версию - с MinGW в комплекте, - качай, а не голый C::B, и оно прямо из коробки заработало. Такое ощущение, что у тебя или куча всего и конфликт версий, или хз. Не похоже это на проблемы с gcc... Админство какое-то.
Пацаны, реально реализовать классы и какой-никакой каличный но ООП на стандартном Си?..
Да
это закрытая информация, в интернете ты ничего об этом не найдешь, только из первых рук.. и то от знающих людей.. и лучше вообще тебе не соваться туда, и не выяснять в чем дело..
Оправдываться за что? За то что я могу ломануть с помощью Сишки все и вся?
Почему когда я задаю тупые вопросы в других тредах, мне отвечают, а тут все злые какие-то :(
Потому что все погромизды по своей сути и характеру говно, хуй че выпытаешь у этих зануд
> Все, что понял, что это виртуальная машина?
Нет. Хотя выполнять IR-инструкции в теории можно, но задача LLVM - дать компиляторам какое-то стандартизированное и удобное для дальнейших оптимизаций промежуточное представление, которое LLVM уже будет оптимизировать и транслировать в машинный код для целевой машины. Таким образом, если ты захочешь запилить свой компилятор, тебе не придется писать по кодогенератору под каждую поддерживаемую машину.
А чем оно отличается от CLR в .net? ну и аналогичной хуйне в яве И там и там, ты должен написать компилятор в код виртуальной машины, а она уже все переведет в машинный.
И что означает, что llvm поддерживает тот же сисярп? Или это значит, что сначала шарп транслируется в clr код, он в свою очередь, в llvm, и только потом оно транслируется в машинный? Ебать тут уровней абстракций конечно. Почему бы тогда сразу не транслировать код в llvm, который и так все за тебя переводит в машинный?
мда, что-то я вообще не про си говорю
>Привет, байт код и код на языке ассемблера это одно и то же
Нет. Байткод это любой язык, представленный не в виде текста, а в более сжатом и удобном для разбора машиной потока байт. Поэтому байткодом может быть что угодно, от байткода питона, который однозначно переводится в исходники на питоне один в один, до байткода llvm, который, в свою очередь, является бинарным представлением языка llvm ir, который является ассемблером для llvm.
А ты путаешь байткод и машинный код. Вот машинный код в текстовом виде это язык ассемблера (не совсем, так как при ассемблировании теряется информация о вещах типа имен меток, но тем не менее).
>А также в чем разница между компилируемым и интерпретируемым яп.
Ни в чем. Любой язык можно компилировать или интерпретировать. Тупые люди (включая преподов по информатике) путают это со статической и динамической типизацией. Статические языки обычно компилируют, динамические обычно интерпретируют. Но это не обязательно.
>А чем оно отличается от CLR в .net?
Толщиной и навязыванием своих услуг. CLR делает за тебя все, и любой CLR-язык это почти C#. Аналогично любой JVM-язык это почти Java. Ты должен использовать не то, что сборщик мусора, но с системой типов будут определенного рода проблемы, если ты сильно отступишь от парадигрмы основного языка. Особенно это актуально для JVM.
А llvm штука легкая и очень модульная. Система типов там есть, но она очень базовая - числа, указатели, как в сишке короче.
>Почему бы тогда сразу не транслировать код в llvm, который и так все за тебя переводит в машинный?
llvm стал более-менее юзабельным к 2010 году. Сейчас большого смысла пилить язык под jvm или clr нет.
Разница в толщине. Llvm штука тонкая, хотя при желании расширяется. А в CLR у тебя есть, допустим, сборщик мусора CLR, и все.
>llvm стал более-менее юзабельным к 2010 году. Сейчас большого смысла пилить язык под jvm или clr нет.
Но появились котлин и нет кор. Наверное, майкам было просто лень переводить CIL под регистровую WM, да и писать сборщик мусора под него.
А насчет
>Или это значит, что сначала шарп транслируется в cil код, он в свою очередь, в llvm, и только потом оно транслируется в машинный?
Я прав?
Спасибо за обьяснения, анон!
>Если не так то для чего этот самый байт код нужен в конпелере clang
Анон выше обьяснил:
>задача LLVM - дать компиляторам какое-то стандартизированное и удобное для дальнейших оптимизаций промежуточное представление, которое LLVM уже будет оптимизировать и транслировать в машинный код для целевой машины. Таким образом, если ты захочешь запилить свой компилятор, тебе не придется писать по кодогенератору под каждую поддерживаемую машину.
> А чем оно отличается от CLR в .net?
CLR заточена под ООП, LLVM IR ни к чему не привязан. В CLR основной способ выполнения JIT (т.е., трансляция в машинный код во время выполнения, но не обязательно), LLVM чаще (но не обязательно) транслирует заранее. В общем, это специально отвязанная от конкретной технологии машина.
НЕ
>что такое LLVM
Это компилятор, который охватывает сразу несколько языков программирования. Как GCC. Он предоставляет программный интерфейс для создания надстроек, которые компилируют код конкретных языков программирования. Сейчас LLVM поддерживает гораздо меньше архитектур, чем GCC, но корпорации в него вкладываются, так как лицензия позволяет легко закрывать код производных программных продуктов.
В твоем мире может быть и нет. В моем - есть и MIPS в каждом доме, и 32-битные x86 с ARM, и овердохуя микроконтроллеров со своими наборами инструкций с древним форком GCC вместо компилятора.
Двачую этого.
> и овердохуя микроконтроллеров со своими наборами инструкций с древним форком GCC вместо компилятора.
Хуево работать в российской военке.
Что за vc?
ну неважно, да будет. Это же просто иде, а не разные кудахтеры с разной архитектурой и ос
Visual studio
Просто там к примеру заставляет писать не scanf а scanf_s и думаю не мало других отличий
Ты разницу между ide и компилятором понимаешь? Ты можешь писать в кодблоках и компилировать в vc.
Так тебе же компилятор написал "мб ты, долбоящер, имел ввиду -h?".
С одной чертой полноценный команды пишутся только у рашидов из мс. Остальной мир использует конвенцию гну (или шо там).
>С одной чертой полноценный команды пишутся только у рашидов из мс. Остальной мир использует конвенцию
Сук, сколько с вами линуксёрами общаюсь, каждый раз убеждаюсь, что вы натурально отбитые ))) На ровном месте учить все эти -h, -t, -w, -b, -z... - это реально клиническая психиатрия. А почему -h должно означать именно help, а не, скажем, high, "how are you?" или huiLao?
>А почему -h должно означать именно help
Потому что это придумано задолго до того, как твой батя забыл вытянуть из твоей мамки, когда кончал.
Но в днищесегменте IoT, например, ESP32, который не ARM. Как ты теперь будешь с этим жить?
>>10133
-D_CRT_SECURE_NO_WARNINGS
В целом, если будешь писать на стандартном Си или реализовывать нестандартные функции там, где их нет, все будет ок.
>>10154
> Почему у меня количество знаком после запятой при изменении float на double не меняется?
Потому значениям для дополнительных битов взяться неоткуда? Потому что ты форматируешь принтфом с дефолтным количеством знаков? Код тащи.
>>10268
> У линопс-опен-сорос-аутистов эти двойные чёрточки чуть ли не в ранг священной коровы возведены
Если бы. В опенсорсе традиционно кто в лес, кто по дрова:
# nasm --help
nasm: error: unrecognised option `--help'
type `nasm -h' for help
Лол, отцы основатели придумали исключительно на швитом PDP-11 всё воротить. Хуле ж ты на богомерзкой пеке-то корячишься?! Работал бы на том, что было придумано задолго до того и что стало конвенцией.
>nasm: error: unrecognised option `--help'
>type `nasm -h' for help
Бгггг, что-то я в насме как-то не обратил на это внимание )))
где ты юмор увидел в моем посте?
Всем кто на рассылку гита подписался эта хуйня пришла вместо предложенных проектов.
> Потому значениям для дополнительных битов взяться неоткуда? Потому что ты форматируешь принтфом с дефолтным количеством знаков? Код тащи.
https://ideone.com/PfhH09
Только тут все работает, а у меня больше 17 знаков не выдает, только нули
У флоата точность 7 - 8 десятичных знаков после запятой, у дабла 15, все что после идет - мусор.
Напиши не корявый тетрис
Напиши опенсурсный Tetris Grand Master
А вот хуй. Обычно, с одной черточкой идут однобуквенные параметры, с двумя их полнословные синонимы.
> после запятой
Запятая тут не при чем. https://ideone.com/ZeHtT5
>>10658
> одной черточкой идут однобуквенные параметры
Разработчикам GCC рассказать забыли.
Собирал так:
export LDFLAGS="-static -static-libgcc -static-libstdc++ -lintl -liconv"
../configure --with-arch=rv32imc --with-abi=ilp32 --prefix=/opt/riscv
make
Конечно можно прописать путь к нужным dll-кам в PATH или просто скопировать их, но ведь как-то собирают тулчейны со статически прилинкованными библиотеками.
Си тут при том, что буду писать для risc-v на нем.
Потому что в данном случае не нужно и просто не умею. К тому же LLVM для RISC-V вроде как еще толком не работает.
>Конечно можно прописать путь к нужным dll-кам в PATH или просто скопировать их
А у тебя статически версии библиотек есть или ты надеешься что dll-ка каким-то магическим образом вкомпилируется?
Само собой есть. Если подменить их переименованием файлов, то все статично собирается.
You need link flags -Wl,-Bstatic and -Wl,-Bdynamic because sometimes you want to force static linking, for example, when the dynamic library with the same name is also present in a search path:
gcc object1.o object2.o -lMyLib2 -Wl,-Bstatic -lMyLib1 -Wl,-Bdynamic -o output
давно не виделись.
не. Кириллицы не было и нет. За это время откатил ноутбук до заводских настроек. MinDW так и не компилит также
попробовал как ты сказал :
создались файлы test.i и test.s
ещё заметил надпись в C:B:
Process terminated with status 1 (0 minutes, 3 seconds) 0 errors, 0 warnings
ничего не помогает
Тебе адрес в виртуальной памяти дают, пиши и читай как обычно. Падает -> смотри под strace и valgrind.
Да, создал test.o
>>11796
Ну ладно...
ALLUSERSPROFILE=C:\ProgramData
APPDATA=C:\Users\Name\AppData\Roaming
CommonProgramFiles=C:\Program Files\Common Files
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
CommonProgramW6432=C:\Program Files\Common Files
COMPUTERNAME=DESKTOP-PG05ENP
ComSpec=C:\WINDOWS\system32\cmd.exe
DriverData=C:\Windows\System32\Drivers\DriverData
HOMEDRIVE=C:
HOMEPATH=\Users\Name
LOCALAPPDATA=C:\Users\Name\AppData\Local
LOGONSERVER=\\DESKTOP-PG05ENP
NUMBER_OF_PROCESSORS=4
OneDrive=C:\Users\Name\OneDrive
OS=Windows_NT
Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\mingw-w64\x86_64-8.1.0-win32-seh-rt_v6-rev0\mingw64\bin;C:\Users\Name\AppData\Local\Microsoft\WindowsApps
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 42 Stepping 7, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=2a07
ProgramData=C:\ProgramData
ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)
ProgramW6432=C:\Program Files
PROMPT=$P$G
PSModulePath=C:\Program Files\WindowsPowerShell\Modules;C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules
PUBLIC=C:\Users\Public
SystemDrive=C:
SystemRoot=C:\WINDOWS
TEMP=C:\Users\Name\AppData\Local\Temp
TMP=C:\Users\Name\AppData\Local\Temp
USERDOMAIN=DESKTOP-PG05ENP
USERDOMAIN_ROAMINGPROFILE=DESKTOP-PG05ENP
USERNAME=Name
USERPROFILE=C:\Users\Name
windir=C:\WINDOWS
Кстати, я ещё VS2017 не могу установить, "неизвестная ошибка". Не удалось установить пакет "Microsoft.VisualStudio.Initializer,version=15.9.28107.0". Сведения
Команда выполнена: "C:\ProgramData\Microsoft\VisualStudio\Packages\Microsoft.VisualStudio.Initializer,version=15.9.28107.0\VSInitializer.exe" -Operation Modify -InstallationID 03572f9c -InstallationName VisualStudio/15.9.4+28307.222 -InstallationVersion 15.9.28307.222 -InstallationWorkloads Microsoft.VisualStudio.Workload.CoreEditor,Microsoft.VisualStudio.Workload.NativeDesktop -InstallationPackages Microsoft.VisualStudio.Component.CoreEditor,Microsoft.VisualStudio.Component.Roslyn.Compiler,Microsoft.Component.MSBuild,Microsoft.VisualStudio.Component.Static.Analysis.Tools,Microsoft.Net.Component.4.6.1.SDK,Microsoft.Net.Component.4.6.1.TargetingPack,Microsoft.VisualStudio.Component.TextTemplating,Microsoft.VisualStudio.Component.Debugger.JustInTime,Microsoft.VisualStudio.Component.NuGet,Microsoft.VisualStudio.ComponentGroup.WebToolsExtensions,Microsoft.VisualStudio.Component.VC.CoreIde,Microsoft.VisualStudio.Component.VC.Redist.14.Latest,Microsoft.VisualStudio.ComponentGroup.NativeDesktop.Core,Microsoft.VisualStudio.Component.VC.Tools.x86.x64,Microsoft.VisualStudio.Component.Graphics.Win81,Microsoft.VisualStudio.Component.Graphics.Tools,Microsoft.VisualStudio.Component.VC.DiagnosticTools,Microsoft.VisualStudio.Component.Windows10SDK.17763,Microsoft.VisualStudio.Component.VC.CMake.Project,Microsoft.VisualStudio.Component.VC.ATL,Microsoft.VisualStudio.Component.VC.TestAdapterForBoostTest,Microsoft.VisualStudio.Component.VC.TestAdapterForGoogleTest,Microsoft.Component.VC.Runtime.UCRTSDK,Microsoft.VisualStudio.Component.Windows81SDK,Microsoft.VisualStudio.ComponentGroup.NativeDesktop.Win81,Microsoft.VisualStudio.Component.WinXP,Microsoft.VisualStudio.ComponentGroup.NativeDesktop.WinXP,Microsoft.VisualStudio.Component.VC.ATLMFC,Microsoft.VisualStudio.Component.VC.CLI.Support,Microsoft.VisualStudio.Component.VC.Modules.x86.x64,Component.IncredibuildMenu,Component.Incredibuild,Microsoft.VisualStudio.Component.Windows10SDK.17134,Microsoft.VisualStudio.Component.Windows10SDK.16299.UWP,Microsoft.VisualStudio.Component.Windows10SDK.16299.UWP.Native,Microsoft.VisualStudio.Component.Windows10SDK.16299.Desktop,Microsoft.VisualStudio.Component.Windows10SDK.16299.Desktop.arm,Microsoft.VisualStudio.ComponentGroup.Windows10SDK.16299,Microsoft.VisualStudio.Component.Windows10SDK.15063.UWP,Microsoft.VisualStudio.Component.Windows10SDK.15063.UWP.Native,Microsoft.VisualStudio.Component.Windows10SDK.15063.Desktop,Microsoft.VisualStudio.ComponentGroup.Windows10SDK.15063,Microsoft.VisualStudio.Component.Windows10SDK.14393,Microsoft.VisualStudio.Component.Windows10SDK.10586,Microsoft.VisualStudio.Component.Windows10SDK.10240,Microsoft.VisualStudio.Component.VC.140 -InstallationPath """C:\Program Files (x86)\Microsoft Visual Studio\2017\Community""" -ComponentId Microsoft.VisualStudio.Product.Community -ChannelsPath """""" -SetupEngineFilePath """C:\Program Files (x86)\Microsoft Visual Studio\Installer\vs_installershell.exe""" -Log """C:\Users\Name\AppData\Local\Temp\dd_setup_20181216090741_001_Microsoft.VisualStudio.Initializer.log"""
Код возврата: -1073741819
Сведения о коде возврата: Неизвестная ошибка (0xc0000005)
Наверное правда проблема в компуктере
Да, создал test.o
>>11796
Ну ладно...
ALLUSERSPROFILE=C:\ProgramData
APPDATA=C:\Users\Name\AppData\Roaming
CommonProgramFiles=C:\Program Files\Common Files
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
CommonProgramW6432=C:\Program Files\Common Files
COMPUTERNAME=DESKTOP-PG05ENP
ComSpec=C:\WINDOWS\system32\cmd.exe
DriverData=C:\Windows\System32\Drivers\DriverData
HOMEDRIVE=C:
HOMEPATH=\Users\Name
LOCALAPPDATA=C:\Users\Name\AppData\Local
LOGONSERVER=\\DESKTOP-PG05ENP
NUMBER_OF_PROCESSORS=4
OneDrive=C:\Users\Name\OneDrive
OS=Windows_NT
Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\mingw-w64\x86_64-8.1.0-win32-seh-rt_v6-rev0\mingw64\bin;C:\Users\Name\AppData\Local\Microsoft\WindowsApps
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 42 Stepping 7, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=2a07
ProgramData=C:\ProgramData
ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)
ProgramW6432=C:\Program Files
PROMPT=$P$G
PSModulePath=C:\Program Files\WindowsPowerShell\Modules;C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules
PUBLIC=C:\Users\Public
SystemDrive=C:
SystemRoot=C:\WINDOWS
TEMP=C:\Users\Name\AppData\Local\Temp
TMP=C:\Users\Name\AppData\Local\Temp
USERDOMAIN=DESKTOP-PG05ENP
USERDOMAIN_ROAMINGPROFILE=DESKTOP-PG05ENP
USERNAME=Name
USERPROFILE=C:\Users\Name
windir=C:\WINDOWS
Кстати, я ещё VS2017 не могу установить, "неизвестная ошибка". Не удалось установить пакет "Microsoft.VisualStudio.Initializer,version=15.9.28107.0". Сведения
Команда выполнена: "C:\ProgramData\Microsoft\VisualStudio\Packages\Microsoft.VisualStudio.Initializer,version=15.9.28107.0\VSInitializer.exe" -Operation Modify -InstallationID 03572f9c -InstallationName VisualStudio/15.9.4+28307.222 -InstallationVersion 15.9.28307.222 -InstallationWorkloads Microsoft.VisualStudio.Workload.CoreEditor,Microsoft.VisualStudio.Workload.NativeDesktop -InstallationPackages Microsoft.VisualStudio.Component.CoreEditor,Microsoft.VisualStudio.Component.Roslyn.Compiler,Microsoft.Component.MSBuild,Microsoft.VisualStudio.Component.Static.Analysis.Tools,Microsoft.Net.Component.4.6.1.SDK,Microsoft.Net.Component.4.6.1.TargetingPack,Microsoft.VisualStudio.Component.TextTemplating,Microsoft.VisualStudio.Component.Debugger.JustInTime,Microsoft.VisualStudio.Component.NuGet,Microsoft.VisualStudio.ComponentGroup.WebToolsExtensions,Microsoft.VisualStudio.Component.VC.CoreIde,Microsoft.VisualStudio.Component.VC.Redist.14.Latest,Microsoft.VisualStudio.ComponentGroup.NativeDesktop.Core,Microsoft.VisualStudio.Component.VC.Tools.x86.x64,Microsoft.VisualStudio.Component.Graphics.Win81,Microsoft.VisualStudio.Component.Graphics.Tools,Microsoft.VisualStudio.Component.VC.DiagnosticTools,Microsoft.VisualStudio.Component.Windows10SDK.17763,Microsoft.VisualStudio.Component.VC.CMake.Project,Microsoft.VisualStudio.Component.VC.ATL,Microsoft.VisualStudio.Component.VC.TestAdapterForBoostTest,Microsoft.VisualStudio.Component.VC.TestAdapterForGoogleTest,Microsoft.Component.VC.Runtime.UCRTSDK,Microsoft.VisualStudio.Component.Windows81SDK,Microsoft.VisualStudio.ComponentGroup.NativeDesktop.Win81,Microsoft.VisualStudio.Component.WinXP,Microsoft.VisualStudio.ComponentGroup.NativeDesktop.WinXP,Microsoft.VisualStudio.Component.VC.ATLMFC,Microsoft.VisualStudio.Component.VC.CLI.Support,Microsoft.VisualStudio.Component.VC.Modules.x86.x64,Component.IncredibuildMenu,Component.Incredibuild,Microsoft.VisualStudio.Component.Windows10SDK.17134,Microsoft.VisualStudio.Component.Windows10SDK.16299.UWP,Microsoft.VisualStudio.Component.Windows10SDK.16299.UWP.Native,Microsoft.VisualStudio.Component.Windows10SDK.16299.Desktop,Microsoft.VisualStudio.Component.Windows10SDK.16299.Desktop.arm,Microsoft.VisualStudio.ComponentGroup.Windows10SDK.16299,Microsoft.VisualStudio.Component.Windows10SDK.15063.UWP,Microsoft.VisualStudio.Component.Windows10SDK.15063.UWP.Native,Microsoft.VisualStudio.Component.Windows10SDK.15063.Desktop,Microsoft.VisualStudio.ComponentGroup.Windows10SDK.15063,Microsoft.VisualStudio.Component.Windows10SDK.14393,Microsoft.VisualStudio.Component.Windows10SDK.10586,Microsoft.VisualStudio.Component.Windows10SDK.10240,Microsoft.VisualStudio.Component.VC.140 -InstallationPath """C:\Program Files (x86)\Microsoft Visual Studio\2017\Community""" -ComponentId Microsoft.VisualStudio.Product.Community -ChannelsPath """""" -SetupEngineFilePath """C:\Program Files (x86)\Microsoft Visual Studio\Installer\vs_installershell.exe""" -Log """C:\Users\Name\AppData\Local\Temp\dd_setup_20181216090741_001_Microsoft.VisualStudio.Initializer.log"""
Код возврата: -1073741819
Сведения о коде возврата: Неизвестная ошибка (0xc0000005)
Наверное правда проблема в компуктере
Пикрелейтед 2
>text input framework.dll
>невозможно найти файл.
Возможно, дело в этом. И в куче других dll, которые он не находит.
Я уже понял свою ошибку и всё исправил.
После объявления функции идут все операторы. int main тоже функция.
итак, для лабы я должен сделать прогу вывода на экран дисплея схематичного изображения велосипедиста. При запуске программы велосипедист начинает движение, вращая ногами педали велосипеда.
для выполнения этой красоты я должен подрубить библиотеку <graphics.h> однако моя 17-я вижла не дружит с этой библиотекой и подчеркивает её как ошибку ,хэлпаните плес ,отправлю цистерну чая по почте))
и если не затруднительно хотя бы тезисно распишите как этот велик ебучий анимировать,нарисовать руль колеса и вс. хуйню еще можно ,но я не представляю как заставить его крутить педали
int b = 89;
int a = 7;
if (b > 75)
printf("b > 75.\n");
if (a>0) {
a += b;
printf("a = %d, b = %d\n", a, b);
}
b = (a >= 90)? printf ("da\n") : 0;
printf("b is %d\n", b);
Очевидно потому что ты присваиваешь b то, что возвращает printf("da\n"), а оно возвращает 5. Почему 5 не знаю, должно быть 3, так как в этой строке 3 байта, d, a и новая строка \n
При чем я проверил - действительно должно
Если бы не возвращало, ты бы получил ошибку времени компиляции, ведь ты бы присваивал b пустоту. Оператор ? :: это не замена if'у, не путай их.
> Да, создал test.o
Тогда идей нет.
>>12120
> для выполнения этой красоты я должен подрубить библиотеку <graphics.h>
Тебе в борланд для DOS. Но ты можешь рисовать на Windows API, создав окно, и все, что полагается.
> хотя бы тезисно распишите как этот велик ебучий анимировать
Ну короч у тебя есть таймер, он тикает. Когда он тикает, ты рисуешь очередной кадр. Для этого ты инкрементируешь x_всего_велосипедиста, чтобы он двигался. Относительно этой x ты рисуешь велосипед. Для педалей у тебя будет угол вращения, который ты тоже инкрементируешь (или вычисляешь как x_всего_велосипедиста умноженный на какой-нибудь фактор). Если не знаешь, как преобразовать позицию педали из полярных координат (текущий угол и длина педали), ты легко это нагуглишь. Основная сложность задачи - написать это не в досовом стиле с рисованием в while (1), а создать окно и рисовать по таймеру.
>Наверное правда проблема в компуктере
Или битый архив скачал или проверь память. Протестируй оперативку и жесткий диск.
Нисколько не сомневаюсь в том, что двачер бы разрабатывал ядро на пхп, а его сосед-шизик добавил бы поддержку хачкеля и брейнфака.
Написал вот:
https://gist.github.com/spudro228/e72836de66f24b6943dea8076e957f9d
получаю коре дамп
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00005555555553c3 in main () at main.c:72
72 ((uint32_t)(fbp + location)) = pix;
Немогу получить доступ к fbp
>>> p location
$1 = 0
>>> p ((uint32_t)(fbp + location))
Cannot access memory at address 0x7ffff7fcc000
>>> p screensize
$2 = 7200
Вроде все флаги нормально поставил, че делать не монима, помогите пожалуйста
Что плохого в хаскелле?
Ядро очень обширное понятие, что именно тебя интересует, я периодически в net/net-next, патчи закидываю.
Это опенсорс, понятное дело, что за это не платят, на работе платят, и мы параллельно с разработкой закидываем код в ядро.
Мне нужна книжка про организацию памяти в ядре, отличная от гита торвальдса. Про struct page, vma, .fault и всю эту хуету. Причем про 4е ядро, а не про древнее дерьмо мамонта. Есть что-то такое?
Но если тебе интересует именно устройство памяти, то тебе нужно книжка по операционным системам.
Например тот же Таненбаум.
Видимо я не знаком с корпоративной разработкой до сих пор, ух бля.
{
int c;
char line[1000];
getline(line);
printf("%s",line);
return 0;
}
void getline(char line[]){
char c;
for(int i=0;(c=getchar())!=EOF && i<1000 && c!='\n';i++)
line = c;
}
Почему при выводе введенной строки программа выдает в конце какие то левые символы?
А, уже разобрался.
Меня интересует именно память в 4 ядре. В общих чертах как страницы в ядре туда-сюда через MMU гоняли 10 лет назад я примерно представляю.
>А где проверка fpb после mmap()? errno там всякое.
Слелал, а оказалось ошибка в ОДНОЙ БУКВЕ.
ioctl(fb_fd, FBIOGET_VSCREENINFO, &finfo);
Надо F, т.к. структура fb_fix_screeninfo.
Из-за этого структура заполнялась нулями.
Я в ахуе.
int i; // в начале функции
...
for (i = 0; ...)
или
int i;
for (i = 0; ...)
или
for (int i = 0; ...)
и почему именно так надо.
> Как правильнее писать?
правильнее писать data.map(lambda(element){....}), но у тебя ПЕРЕНОСИМЫЙ АССЕМБЛЕР -поэтому смотри поддерживаемый стандарт. Всё тобой перечисленное было актуально практически в порядке развития стандарта этого ногострела.
То есть i в первом цикле и i за первым циклом это разные переменные. Круто, значит можно и то и то использовать, но если переменная нигде кроме цикла использоваться не будет, то наверное правильнее for (int i = 0; ...). А как получить данные из первого i в первом цикле и записать в него другие данные?
Gtk -- это боль. То, что в нормальном языке дается по умолчанию, в сишной гткшечки ты будешь делать вручную.
ты объявляешь i из внешнего цикла, как static int i, хотя в таком случае он у тебя и во внутреннем цикле будет меняться. Так что зачем тебе это, пацан? Лучше, назови их нормально, чтобы ты мог разобраться потом, как из внутреннего а какой из внешнего цикла, например: extern_i, internal_i. Хотя тут i уже лишним будет.
точка с запятой ставится за всеми statement в теле блока if/do/while/for (внутри {}), в т.ч. и за последним, так что нет, дополнительных не надо, ;}; не бывает
Ну если приловчиться, то можно и на сишечке писать. Но плюс гтк в том что биндиги есть к любому языку, пиши хоть на пистоне если не нравится низкоуровщина. В этом и плюс библиотек на Си. На тех же крестах гораздо сложнее разработать такую же библиотеку. Та же поддержка пистона на культях, просто неимоверно костыльна
Это когда библиотека на си например, а ты ее хочешь использовать в каком-нибудь пистоне. Для этого нужна некоторая прослойка, библиотека которая позволит тебе это сделать.
думал упомянуть объявление структур, и если б не передумал, то заметил бы, что погорячился с ";}; не бывает". И, кстати, таки да, вы угадали) Предпочитаю писать typedef struct {...;} name_t; а не struct name {...;};
слегка несвоевременный, но более развернутый ответ. Да, struct - это и есть класс (разница struct и class в C++ заключается в единственной мелочи), а методы - суть обыкновенные функции, которые первым параметром принимают указатель на объект класса (структуры). В C++ это так и реализовано, и я сейчас даже не про историю о том, как первый компилятор Страуструпа сначала переводил код в Си, после чего компилил CC, а про вполне себе C++11. Чтоб "запустить" метод конкретного объекта в отдельным потоке, конструктору thread, который принимает указатель на функцию и аргументы, первым аргументом после classname::methodname следует передать, как раз таки, указатель на объект (ссылки, если что, кастуются ref(var)). В Си я предпочитаю именовать этот костыль this, ведь используется он совершенно аналогично этому keyword на C++. А полиморфизм -= это лишь пара фокусов с таблицами указателей на функции.
Любопытно, почему? Могу предположить, что это нарушает техническую прозрачность, согласно которой каждый вызов функции должен выглядеть как вызов функции (а не как встроенная операция, привет из C++), и если некоторая единица данных не является byte/word/dword/qword (не помещается в регистр), следовательно получается более сложный машинный код для копирования и других действий (одним mov не обойдешься), то об этом явно должно говорить составное typename типа struct name? Ну, я заметил, что ни сишная, ни юниксовая, ни посиксная библиотеки никогда не содержат typedef для структур, даже если имя явно говорит name_st, но разве это настолько нежелательно, чтоб даже в .c файле себе не позволить? (оставим .h)
ан нет, pthread_mutex_t таки структура, стало быть, это не преступление, и ничто не мешает избежать конфликта имен, используя префикс zalupa_mutex_t для своих мьютексов)
> следовательно получается более сложный машинный код
У нас опять набег людей со странностями? Тайпдеф - синоним типа на уровне компилятора. Кроме удобства и более читаемого кода разницы между кодом с тайпдефами и без него нет.
> что ни сишная, ни юниксовая, ни посиксная библиотеки никогда не содержат typedef для структур
А FILE - что по-твоему?
>>13733
> используя префикс zalupa_mutex_t для своих мьютексов
Суффикс _t зарезервирован посиксом.
более сложный машинный код нужен для действий над структурами, в сравнении с аналогичным действиями над встроенными типами, а typedef позволяет объявить переменную типа структуры без keyword struct, что делает более трудоемкой оценку сложности кода для того, кто читает исходник, я об этом.
Да, FILE туда же, что и pthread_mutex_t, я тупо не вспомнил, в голову пришли контрпримеры типа struct stat. Понимаю, что надо не примерами мыслить, а более дедуктивно, но я в конвенциях не шарю, признаюсь, дилетант. Кстати, и FILE, и pthread_mutex_t не предполагают, чтоб юзер рассчитывал на конкретное определение, используются только посредством предоставляемых функций (или макросов). Видится закономерность, что typedef в библиотеках используются только для структур, к полям которых пользователь напрямую не обращается. Есть такой принцип? Ну, мне для себя интересно.
А как же суффикс _t в size_t?
> что делает более трудоемкой оценку сложности кода для того, кто читает исходник
20189 год на пороге, и уже десять лет IDE умеют показывать хинты с определениями структур. Чтобы что-то оценить, все равно нужно видеть тип. Может, там юнион, который никаких дополнительных сложностей (кроме разрешения алиасинга) не создает, или структура, которая отлично упаковывается в 1-2 инта и копируется точно так же как uint64/128_t.
> Есть такой принцип? Ну, мне для себя интересно.
Нет. Есть div_t в stdlib.h. А struct tm и прочее осталось в наследство еще из pre-ANSI С.
> А как же суффикс _t в size_t?
Это стандарт Си, он первичен, ему можно. А вот тебе, пользователю, нельзя.
> IDE умеют показывать хинты с определениями структур
Я, все же, убежден, что код должен быть читаем, даже если его распечатать на черно-белом принтере. IDE в первую очередь упрощает жизнь, а не компенсирует усложнение от гавнокода.
> копируется точно так же как uint64/128_t
Всякие struct {GLfloat r, g, b, a;} - частный случай, все таки довольно часто структуры выходят за uint128_t, что более общий случай.
> А вот тебе, пользователю, нельзя
Ок, не буду)
а вообще, изначально в этом обсуждении я был ЗА typedef, лишь потом как предположение высказал эту байду с читаемостью сложности типа, в вопросительном контексте, мне ведь один товарищ настоятельно отсоветовал юзать тайпдефы. Я же, по скромному опыту, могу знать, что typedef обычно используются, как синоним для существующего встроенного типа, например GLboolean, чтоб точнее отражать смысл в контексте.
> один товарищ настоятельно отсоветовал юзать тайпдефы
sqlite, zlib, libpng, libjpeg, sdl, pcre всякие - везде тайпдефы. Есть и контрпримеры - тот же libcurl, ну и линукс, куда же без него.
> GLboolean
Однозначно зло, когда есть встроенный в язык тип. В каждой второй библиотеке свой Bool/BOOL/BOOLEAN/u32/word32/uint32 или еще какая-нибудь хрень. Но это тоже легаси с тех времен, когда в Си stdbool/stdint не было - менять уже поздно, а вот новый код так писать не стоит.
> чтоб точнее отражать смысл в контексте
Да, тогда имеет смысл, вот как в посихах всякие uid_t.
Да, если ты будешь пытаться их использовать без инициализации. Если на стеке: void *array[...] = {0};, если на куче, есть calloc. Еще есть memset, и хотя это не совсем по стандарту, на распространенных архитектурах никаких проблем нет.
допустим, у тебя один байт(восемь бит) на сферическое число
1000 01012это -5.
ты сдвигаешь содержимое и самый старший бит(самый левый бит в BigEndian), отвечающий за знак, исчезает. И выходит после первого сдвига 0000 1010=10=А
потом ты сдвигаешь вправо на бит, но единица, отвечающая за знак не возвращается и выходит 000 0101=5.
Хотя лично для меня немного стало открытием, что можно такое присваивание делать сразу с битовым оператором.
Спасибо
а, блин, в натуре. В другую же сторону. К -128 же нужно прибавлять 5. Серьёзный косяк, блин. Извиняюсь.
Ну, дак это unsigned.
А я ж про signed. В знаковом же типе семь цифр значащих. Или ты про что?
при операциях сложения и вычитания с битами signed и unsigned происходит абсолютно одно и то же. Вот с умножением и делением уже сложнее. Существуют инструкции imul и idiv, но не существует инструкций iadd и isub. 11111110 + 11111101 = 11111100 тут имеет место технический overflow, но не математичский, -1 + -2 = -3 все работает как надо, единицы безболезненно для процессора выталкиваются из пазов регистров, выдуваются кулером и скапливаются на дне системника в виде пыли.
>выталкиваются из пазов регистров, выдуваются кулером и скапливаются на дне системника в виде пыли
самое главное, что я подчерпнул на сегодня.
Почему, вроде только сдвиг влево UB, т.к. может получиться число любого знака, сдвиг вправо всегда даёт тебе положительное число.
И все же не понимаю.
#include <stdio.h>
main(){
int n;
scanf("%d",&n);
n<<=1;
n>>=1;
printf("%d",n);
return 0;
}
При вводе отрицательного числа на выходе получаю тоже отрицательное. При том если в числе 10 и более знаков выводится пикрил.
Где вообще про все это подробно почитать на русском? Мне просто надо написать программу, которая бы выводила как число хранится в памяти компьютера.
При сдвиге влево старший бит (знаковый в случае с signed) "срезается". Для сдвига же вправо есть две инструкции - unsigned версия тупо ставит нуль, а signed - дублирует прежний знаковый бит, т.е. 010 >> 1 == 001, но 110 >> 1 == 111. Компилятор выбирает одну из этих инструкций в зависимости от типа, над которым производится операция. Что-то такое помню с времен, когда учил ассемблер, но это не точно)
вообще, сишка - low-level тема, и чтоб полноценно понимать, желательно таки испачкать руки в асме. Любая нормальная книжка по ASM начинается с теории, которая раздувает все эти странности. Не обязательно много кодить, просто пару вечеров покурить литературу, поиграться с gdb (в т.ч. disassemble), писать дальше на Си и быть счастливым. Про float тоже интересно, да и про организацию стека вызова функций. Соотношение затрат времени и просветительской пользы однозначно говорит в пользу must глянуть.
>При том если в числе 10 и более знаков выводится пикрил.
Сдвигом влево ты устанавливаешь старший бит. Как только это происходит, система/компилятор начинает рассматривать всё эту хуергу как отрицательное число. Дальше ты делаешь сдвиг справо и всё сдвигается... всё, кроме старшего бита; по по-прежнему остаётся установленным (т.е. вся хуерга по-прежнему рассматривается как отрицательное число).
Вот, смотри-ка, следи старшим битом (выделен жирным):
0100 1001 1001 0110 0000 0010 1101 0011 ( десятичное '1234567891' в памяти, размер слова - 32 бита)
1001 0011 0010 1100 0000 0101 1010 0110 (после сдвижки влево на один бит. Старший/верхний бит установлен, теперь это '-1825831514')
1100 1001 1001 0110 0000 0010 1101 0011 (сдвигаем обратно вправо. Сравни эту херь с тем, что было в самом начале; особое внимание на старший/верхний бит. И таки да, это десятичное '-912915757')
> Почему, вроде только сдвиг влево UB
Ну я о нем и говорю. >>14193 вот тут в первой строчке k может быть отрицательным, и тогда сдвиг влево - это UB. Если в числе k стоит бит, который после сдвига станет старшим - это опять UB. Ну если, конечно, там signed int, а не unsigned.
> сдвиг вправо всегда даёт тебе положительное число
Сдвиг вправо отрицательного числа - implementation defined, потому что sign extension не гарантируется (хотя и выполняется абсолютно всеми популярными процессорами).
И вообще, смотри:
int foo = 0xc0000000;
foo <<= 1; // Допустим, что у нас нет UB, после сдвига: foo = 0x80000000.
foo >>= 1; // После сдвига и sign extension: foo = 0xc0000000.
В чем тогда суть этого куска кода?
просто две восьмилитровые бадьи чая, не понимаю "учите си и вы поймете глубины" и в итоге пишут и в целом подходят к си как к ещё одному высокоуровневому, но неудобному языку - надо обязательно накатывать асм + архитектура устройства + ОС, иначе смысла нету от слова совсем
Этот двач, кстати, на ANSI C написан
>надо обязательно накатывать асм + архитектура устройства + ОС
Ни! Точнее, зависит от задач. Если у человека задача - работать с железом, то да, ему обязательно надо вкурить всё, что ты перечислил. Если же человек пишет софт для обработки данных, к примеру, то ему просто надо как следует = указатели, динамическое распределение памяти, структуры, пользовательские типы данных Си освоить. Архитектура и асм во втором случае будут тупо избыточны.
ещё раз: вопрос об обучении, о том, когда человек решает разбираться с си для того чтобы как-то понять уровень ниже - но си сама по себе без асма и архитектуры этого знания дать не может, максимум что непосредственно даёт именно язык, это какая-нибудь концепция указателей, которая говорить что есть такая вещь как память, есть адреса и т.д. и то на довольно высоко абстрактном уровне.
Да-да, и потом цифровую электронику впридачу, и аналоговую еще. И математикой с физикой приправить. Ну а чего, если уж копать, то копать до конца! Невозможно эффективно писать на Си, не зная физики.
Я другой анон, но отвечу. На си пишу год, до этого писал лоу левел дичь на асме(fasm) под винду. Так вот, чтобы вкатиться в си мне понадобилась неделя. Ассемблер считаю избыточным, да. Но как теорию, его знать надо. Помогает во многом понимать как будет работать код
Ну, это уже крайность, товарищ. Есть четкий раздел между {C, ASM, x86} и устройством транзисторов. Пока архитектура фон Неймана акутальна, этот уровень абстракции остается незыблемым, и копать под него - уже принципиально другая предметная область. А вот на уровне инструкций еще могут возникать нюансы. Та же оптимизация не может быть проделана так точно на уровне Си. И не надо возражать про -O3. Как бы вам ни не хотелось, примеры, когда программист может сделать лучше, есть. Компилятор - набор шаблонов, не умеющий в анализ задачи.
вообще, вы тезис подменяете. Речь шла об изучении Си для постижения глубин, в чем мало смысла без ASM, архитектуры и интерфейса ОС (syscall). А вы передергиваете со стебом "невозможно эффективно писать на Си без знаний физики..." Не надо демагогии в технарьском треде, вам в политику. Да, иногда Си играет роль high-level языка, в котором нет ничего лишнего, на котором удобно реализовать грамотно спроектированную эффективную реализацию, но речь не об этом шла...
что в этом хорошего? куча нубасов вкатываются и начинают гуглить нипанятное
По сложности сравним с питоном, по скорости с крестами, по безопасности с ржавчиной. Но лучше знать сишку перед вкатом в него, а то будешь писать бездумно в стиле макаки. Считай что это си++ здорового человека.
Мань, я тот анон, который тебе изначально по поводу asm-а возражал.
>вообще, вы тезис подменяете
Ты тоже, только в обратную сторону.
>Речь шла об изучении Си для постижения глубин
Ога, только глубины у каждого свои: у анона, пищущего софт под обработку данных одни, а у анона, работающего с железом, другие. И, соответственно, объём необходимых для успешной работы знаний разный.
>на котором удобно реализовать грамотно спроектированную эффективную реализацию
И эффективная реализация тоже у каждого своя. Условному обработчику данных достаточно уметь грамотно пользоваться памятью (= указатели, динамическое распределение и кастомные структуры данных). Он может полезть и ниже, и начать высчитывать количество тактов, затрачиваемое на каждый чих, но только нахуя?! Такой уровень оптимизации задачи будет тупо избыточен. Соответственно, уровень архитектуры и ассемблера тащемта нахуй здесь не нужен. Достаточно уметь грамотно укладывать данные в памяти.
Другое дело, железячник. У того в микроконтроллере несколько десятков килобайт памяти, плюс, ему надо окучивать некую real-time парашу. В этом случае просто необходимо грузиться глубокой оптимизацией по объёму и скорости выполнения. И пердолиться в архитектуру а асм здесь просто необходимо.
ты в какую-то не ту сторону воюеешь. ты написал в целом верные утверждения, но на какой-то абсолютно другой тезис.
> фон Неймана
Везде давно гарвард с плюшками.
> этот уровень абстракции остается незыблемым
Грани между хардпроцессорами и софтпроцессорами все больше стираются. Если ты копаешься в асме, то рано или поздно коснешься FPGA. Играть с FPGA без понимания цифровой логики - ну это как на Си писать, не зная ассемблера, лол.
> Компилятор - набор шаблонов
Вся низкоуровневая оптимизация - набор шаблонов. Причем памяти человека (и оперативной, и долговременной) может не хватить, чтобы учесть все нюансы архитектуры. У компилятора такой проблемы нет. Да и хорошо вылизанный код, написанный человеком вручную, модифицировать или адаптировать под другое семейство архитектуры тем сложнее, чем лучше он вылизан.
> фон Неймана
>Везде давно гарвард с плюшками.
>
таки зависит от уровня абстракции
на одном можно говорить что фон нейман, на другом - гарвард
в любом случае это полезно что мы все понимаем о чем говорится
хоть немножко
> почему инт, не double, т.д.
Потому что в стандарте так прописано, что среда (ОС или что там у тебя вместо нее) должна ожидать int. И с тех пор, как среда ожидает int, все должны возвращать int. Если бы стандартизировали complex float, ты бы возвращал complex float.
> Она же должна возвpащать ноль
EXIT_SUCCESS (обычно 0), EXIT_FAILURE (обычно 1) или любое другое implementation-defined значение. Алсо, начиная с C99, можно не писать return 0 в main (и только в ней) - если его нет, он подразумевается.
> И может ли быть она void?
В теории да, какой-нибудь конкретный компилятор может разрешить тебе объявлять main еще как-то, в том числе и с void (тогда он будет сам как-нибудь придумывать тебе код возврата). Но как и любая привязка к нестандартным особенностям компилятора - это плохо, так делать не нужно.
> среда должна ожидать int.
значит все дополнительные функции, котоpые используются в main тоже должны быть int по канону или как?
Можно в любом другом месте в программе сделать системный вызов exit с каким-то значением, для чего есть функция-обертка exit(int). Иначе выполнение, рано или поздно, "спустится" до возврата из main, который в свою очередь был вызван куском кода под меткой _start, и тогда _start сделает exit с кодом, который main оставил своим return. Технически можно вообще забить по-черному, хоть string возвращай (если C++), ничто не мешает "выплюнуть" любой мусор, находящийся в rax. Вопрос лишь в строгости компилятора на предмет подобных неграмотных моментов, он может просто ругнуться (warning), а может настойчиво ругнуться (error).
> значит все дополнительные функции, котоpые используются в main тоже должны быть int
Если ты возвращаешь их значение из main - да (т.е., например, ты делаешь какой-нибудь if (argc < 2) return usage();. А если сам возвращаемое значение обрабатываешь - можешь хоть Go косплеить и возвращать struct { sometype result; bool error; }, дело твое.
то же самое, что и чтение из и запись в консоль (терминал, командная строка). Простой случай: в in файл заранее впечатано то, что ты печатал бы в ходе запуска проги, а out файл в итоге содержит все, что выводилось бы на экран. Разница в том, что можно открыть много разных файлов, и что можно возвращаться назад или забегать вперед, например, при чтении.
Чтоб открыть, создаешь структуру типа FILE *file; и открываешь fopen (file, "r"); "r" для read - чтения, "w" для write - записи, после чего, почти как обычно, но вместо printf (...); пишешь fprintf (file, ...); а вместо scanf (...); пишешь fscanf (file, ...); Вообще, и в консоль / из консоли тоже можно так делать fprintf (stdout, ...); fscanf (stdin, ...);
Я, конечно понимаю, что сейчас напишу фрическифееричную хуйню полную шизофазического бреда, но я со своей колокольни постараюсь объяснить, почему для сей нужен фундамент из асма. И почему существуют кресты. Смотри, ёпты. Раз ты знаешь про "уровень абстракции языка", то значит и уловишь такую концепцию:
Гиперуровень: Любой естственный язык, т.е. типикал лингвистика без особого упора на грамматику и синтаксис. МБ обыденное общение и счётный анализ общения.
Сверхвысокоуровневый язык - потолок: голосовые помощники, которые позволяли бы программировать машины. МБ сильный ИИ. Но тут можно порассуждать на тему того, каким должен быть сверхвысокоуровневый язык программирования. Быть может макропроцессоры откуда-нибудь отсюда.
Где-то между сверхвысокоуровневым ЯП и высокоуровневым я бы разместил Bash(и все остальные шеллы для управления средой, как и повершел), заодно и мерзкий CMD сюда припихнём, но он теряет свою концепцию, при которой ты будто бы общаешься со средой компьютера. А вот пинусовские оболочки свой шарм сохраняют. Если бы ангельцкий был моим родным языком, то я бы искренне офигевал, что я машине отдаю приказы по-человечески, а она берёт и выполняет их, за исключением каких-то узкоспециализированных утилит.
Высокоуровенвый язык: Python, хотя питон где-то между сверхвысокоуровневыми языками и высокоуровневыми языками, но чуть пониже оболочек. Здесь же все мейнстримные и не очень языки: C++, сисярп, Java, JS, Obj-C, функциональщина, может быть Go и пр. Но высокоуровневые языки имеют свои градации само собой и отнесение их к категории высокоуровневых тоже условно, как и вообще всё деление на какие-то уровни.
Средний уровень: Непосредственно сам Си и какие-то подобные языки, но я их не могу вспомнить. Хотя был ещё когда-то BCPL. Ещё быть может Фортран такой же, хотя не совсем уверен на его счёт. Ещё, может быть Форт.
Низкоуровенвый язык: ассемблеры: gas, MASM, FASM, TASM и пр.
Нулевой уровень-пол: Архитектуры: ARM, X86, MIPS и пр. Здесь ты тупо хуяришь машинные коды и раскидываешь их по областям памяти, чтобы процессоры их правильно исполняли и не путали с данными. Вот здесь кончается сфера айти и начинается уже более анальный пердоленг на уровне радиотехники. И дальше уже идут подпольные уровни типо фундамента или свай для дома, думаю аналогию с домами без фундамента проводить уже не нужно. Где-то здесь же на нулевом написание прошивок для микроконтроллеров и умение проектировать операционки.
минус-первый уровень: цифровая схемотехника. И где-то тут, под архитектурами и машинными кодами процессоров ПЛИСостроение распологается.
Минус-второй уровень: аналаговая электротехника. Хотя два верхних уровня абстракции радиоэлектронщики объединяют и разбивают на свои условные уровни: энергетика, бытовая электроника, непосредственно радач и др.
Минус-третий уровень: Здесь можно, конечно, это опустить, но я обязан вставить этот интеруровень, как переходный. Анальная физика в вакууме, которая на своём переднем крае стирает грань с...
Минус-четвёртый уровень: сферическая математика в вакууме. Стоит ли что-либо объяснять на этот счёт? Хотя, конечно, для программиста и не обязательно знать пространственную математику и какие-то узкоспециализированные темы, но я думаю, что из математики любые знания приветствуются.
Гиперуровень: И тут мы снова возвращаемся к лингвистике и естественным языкам с этимологией любой математической категории, ведь без знания истории создания термина и цели его создания трудно будет понимать термин. И на этом гиперуровне начинается цикл и снова начинаешь отсюда спускаться в потолок уровней абстракции. Хотя гиперуровень пронизывает все остальные на всём цикле этой концепции.
И, как мне кажется, чем больше ты пытаешься перепрыгнуть уровней абстракций, то тем больше ты тратишь усилий на это. Мне кажется, трудовремязатраты либо экспонецниально, либо факториально зависят от количества перепрыгиваемых уровней. Как если у тебя есть языки, которые находятся на своём уровне абстракции и они хорошо подходят для решения задач из этого же уровня. И при попытке применить язык к другим уровням опять же увеличивается количество времени для этого. Как например писать компиляторы для кастомных архитектур на JS, или на уровне маш.кодов собирать свой инетпретатор Джавы, хотя второе кажется более обыденным, но бывалые повертят пальцем у виска и скажут, что лучше оттачивать уже годами оттачиваемый JVM.
Работа с уровнями языков идёт в зависимости от задач, которые тебе нужны. Для разработки и имплементации каких-то решений ты идёшь от низких уровней к высшим. А чтобы понять принип работы решений, то ты идёшь от высших уровней к низшим. Тут уже один писал, что паттерны в Си становятся шаблонами в крестах. Это типичный восходящий принцип, когда частоиспользуемая концепция выражается более кратко, как например функции, которые отстутсвуют на нулевом уровне, но появляются как макросы в ассемблере и как нормальные функции после среднего уровня.
А по итогу тебе будет очень эффективно развиваться в двух соседних уровнях, относительно основного, ведь трудозатраты на это хоть и увеличиваются, но не смертельны и можно ими обмазываться. А так как Си предполагается средним, то тебе нужен первый(низкий уровень) ассемблеров и архитектур, но до МК дойти уже, если по вкусу придётся, и всё, что ниже в этой концепции уже будет требовать от тебя больше затрат, но даст тебе более глубокое понимание работы, если изучать будешь нисходяще, либо умение пилить уберкрутые фичи и продавать свою высерыписанину, если будешь учиться восходящим способом.
Пруф ми вронг, если прочитал мой уебанский высер.
Я, конечно понимаю, что сейчас напишу фрическифееричную хуйню полную шизофазического бреда, но я со своей колокольни постараюсь объяснить, почему для сей нужен фундамент из асма. И почему существуют кресты. Смотри, ёпты. Раз ты знаешь про "уровень абстракции языка", то значит и уловишь такую концепцию:
Гиперуровень: Любой естственный язык, т.е. типикал лингвистика без особого упора на грамматику и синтаксис. МБ обыденное общение и счётный анализ общения.
Сверхвысокоуровневый язык - потолок: голосовые помощники, которые позволяли бы программировать машины. МБ сильный ИИ. Но тут можно порассуждать на тему того, каким должен быть сверхвысокоуровневый язык программирования. Быть может макропроцессоры откуда-нибудь отсюда.
Где-то между сверхвысокоуровневым ЯП и высокоуровневым я бы разместил Bash(и все остальные шеллы для управления средой, как и повершел), заодно и мерзкий CMD сюда припихнём, но он теряет свою концепцию, при которой ты будто бы общаешься со средой компьютера. А вот пинусовские оболочки свой шарм сохраняют. Если бы ангельцкий был моим родным языком, то я бы искренне офигевал, что я машине отдаю приказы по-человечески, а она берёт и выполняет их, за исключением каких-то узкоспециализированных утилит.
Высокоуровенвый язык: Python, хотя питон где-то между сверхвысокоуровневыми языками и высокоуровневыми языками, но чуть пониже оболочек. Здесь же все мейнстримные и не очень языки: C++, сисярп, Java, JS, Obj-C, функциональщина, может быть Go и пр. Но высокоуровневые языки имеют свои градации само собой и отнесение их к категории высокоуровневых тоже условно, как и вообще всё деление на какие-то уровни.
Средний уровень: Непосредственно сам Си и какие-то подобные языки, но я их не могу вспомнить. Хотя был ещё когда-то BCPL. Ещё быть может Фортран такой же, хотя не совсем уверен на его счёт. Ещё, может быть Форт.
Низкоуровенвый язык: ассемблеры: gas, MASM, FASM, TASM и пр.
Нулевой уровень-пол: Архитектуры: ARM, X86, MIPS и пр. Здесь ты тупо хуяришь машинные коды и раскидываешь их по областям памяти, чтобы процессоры их правильно исполняли и не путали с данными. Вот здесь кончается сфера айти и начинается уже более анальный пердоленг на уровне радиотехники. И дальше уже идут подпольные уровни типо фундамента или свай для дома, думаю аналогию с домами без фундамента проводить уже не нужно. Где-то здесь же на нулевом написание прошивок для микроконтроллеров и умение проектировать операционки.
минус-первый уровень: цифровая схемотехника. И где-то тут, под архитектурами и машинными кодами процессоров ПЛИСостроение распологается.
Минус-второй уровень: аналаговая электротехника. Хотя два верхних уровня абстракции радиоэлектронщики объединяют и разбивают на свои условные уровни: энергетика, бытовая электроника, непосредственно радач и др.
Минус-третий уровень: Здесь можно, конечно, это опустить, но я обязан вставить этот интеруровень, как переходный. Анальная физика в вакууме, которая на своём переднем крае стирает грань с...
Минус-четвёртый уровень: сферическая математика в вакууме. Стоит ли что-либо объяснять на этот счёт? Хотя, конечно, для программиста и не обязательно знать пространственную математику и какие-то узкоспециализированные темы, но я думаю, что из математики любые знания приветствуются.
Гиперуровень: И тут мы снова возвращаемся к лингвистике и естественным языкам с этимологией любой математической категории, ведь без знания истории создания термина и цели его создания трудно будет понимать термин. И на этом гиперуровне начинается цикл и снова начинаешь отсюда спускаться в потолок уровней абстракции. Хотя гиперуровень пронизывает все остальные на всём цикле этой концепции.
И, как мне кажется, чем больше ты пытаешься перепрыгнуть уровней абстракций, то тем больше ты тратишь усилий на это. Мне кажется, трудовремязатраты либо экспонецниально, либо факториально зависят от количества перепрыгиваемых уровней. Как если у тебя есть языки, которые находятся на своём уровне абстракции и они хорошо подходят для решения задач из этого же уровня. И при попытке применить язык к другим уровням опять же увеличивается количество времени для этого. Как например писать компиляторы для кастомных архитектур на JS, или на уровне маш.кодов собирать свой инетпретатор Джавы, хотя второе кажется более обыденным, но бывалые повертят пальцем у виска и скажут, что лучше оттачивать уже годами оттачиваемый JVM.
Работа с уровнями языков идёт в зависимости от задач, которые тебе нужны. Для разработки и имплементации каких-то решений ты идёшь от низких уровней к высшим. А чтобы понять принип работы решений, то ты идёшь от высших уровней к низшим. Тут уже один писал, что паттерны в Си становятся шаблонами в крестах. Это типичный восходящий принцип, когда частоиспользуемая концепция выражается более кратко, как например функции, которые отстутсвуют на нулевом уровне, но появляются как макросы в ассемблере и как нормальные функции после среднего уровня.
А по итогу тебе будет очень эффективно развиваться в двух соседних уровнях, относительно основного, ведь трудозатраты на это хоть и увеличиваются, но не смертельны и можно ими обмазываться. А так как Си предполагается средним, то тебе нужен первый(низкий уровень) ассемблеров и архитектур, но до МК дойти уже, если по вкусу придётся, и всё, что ниже в этой концепции уже будет требовать от тебя больше затрат, но даст тебе более глубокое понимание работы, если изучать будешь нисходяще, либо умение пилить уберкрутые фичи и продавать свою высерыписанину, если будешь учиться восходящим способом.
Пруф ми вронг, если прочитал мой уебанский высер.
>Гиперуровень
Ебануться. Это скорее всего будут самопрограммирующиеся нейронные сети и ты пойдешь нахуй со своими умениями программирования и будешь никому не нужен от слова совсем.
>Сверхвысокоуровневый язык
Это касается только божественный Пролог, и поэтому ты сразу идёшь нахуй со своим невъебически градусным высером.
Машинные коды являются также низкоуровневым программированием.
Всё начиная описанного тобой с "минус первого уровня" и до "минус второго уровня" - то это вообще не относится к программированию, так как этот предмет называется схемотехника и электротехника, то есть данная абстракция вытекает за края области программирования, что противоречит области сечения рассматриваемого вопроса.
>Минус-третий уровень
>Минус-четвёртый уровень
У пациента развивается острое шизофреническое расстройство реальности через призму слабоумия и самопомрачения.
>Пруф ми вронг, если прочитал мой уебанский высер.
Ты пидор который не разбирается в данном вопросе и прежде чем написать данный высер даже не удосужился осведомится и
достаточно просветиться, чтобы этот бред хоть как-то выглядел правдоподобно.
>Я, конечно понимаю, что сейчас напишу фрическифееричную хуйню полную шизофазического бреда.
>бреда
Тебе с такой хуйнёй быстро, решительно и нахуй в раздел /b.
не усну, пока не исправлю
#define PRINTF_WITH_PROBEL putchar (' '), printf
теперь можно даже return нормально получать
count_zaebisfuly_printed_chars = (PRINTF_WITH_PROBEL ("%i", x));
Может.
А если аргументы целые, а результат нужен дробный, кастуешь один из аргументов в дробный, умножать ничего не надо.
>Высокоуровенвый язык:
>C++
>Средний уровень:
>Ещё, может быть Форт.
Иксперд в треде, все на галеру!
YAAAAAAAAAAAAAAAAAAAAAARRRRRRRRR
>Gtk -- это боль
Ну не сказал бы, там столько макросов и функций, что gtk превращается в своеобразный скриптовый язык уровня objective-c
Хочу портировать Fallout на Донди и Спектрум. Вот X-COM и WarCraft ("Черный Ворон") перенесли же, а фолыч устроен куда проще.
>Насколько хороший код выдают компиляторы?
Напиши какую-нибудь простенькую фигнюшку типа бегающего по экрану квадратика на Си и на ассемблере, и сравни размер и скорость исполнения.
>Для 8-битных систем, типа NES и ZX Spectrum есть ли смысл использовать Си?
В зависимости от первого пункта. На Си поудобнее канеш писать было бы, чем на ассемблере.
int p = malloc(sizeof(int));
или
int p = (int*)malloc(sizeof(int));
???
На том же цппреференс в примерах как в первом коде, без приведения. В пользу же приведения слышал мнение, что если маллок возвращает указатель типа войд, то нужно явно его привоить к нужному типу. Это вполне логично.
У себя пишу с приведением, но ведь это удлиняет код, и такая запись смотрится чуточку хуже чем без приведения. Так что хотелось бы услышать мнение на счет этого.
для начала неплохо бы объявить p как указатель
int p;
а не просто
int p;
что не только warning вызовет, но и не заработает нормально на машине с 64-битными адресами.
А кастовать ничего не надо, void для того и есть, чтоб без ругани присваивать другим указателям, объявленным как угодно.
В данном случае каст нужен только для лучшей читаемости.
int #p = тут без каста, т.к. у нас слева и так написано, что p это указатель на инт.
Если ты заранее обяъвил p, а уже дальше далешь малоок, типа p = malloc..., вот тут можно сделать каст, чтобы читающий сразу видел, что p это указатель на инт, а не возвращался к тому месту, где ты его объявил и сам смотрел.
Тоже недавно захотелось написать что-нибудь для спектрума. Вроде нагуглил какой-то msx c, который тоже под zilog. Но понял, что если захочу запилить что-то крупное, то это надолго, даже если использовать си.
Анончи, подкинте идею как можно эффективно применить к тексту охуллиард регулярок? Можно их как то транслировать?
> как можно эффективно применить к тексту охуллиард регулярок
Поиск или замена? Для поиска можно через | объединить. А в целом, движок и так таблицу состояний генерирует, а в PCRE есть JIT, быстрее уже некуда.
>>17777
> В общем, делаю без каста
Я не то чтобы агитировал за каст, скорее наоборот. Но есть такая порочная практика собирать сишный код как крестовый. В крестах каст нужен, поэтому его некоторые и втыкают. Но делать так не стоит.
>Для поиска можно через | объединить. А в целом, движок и так таблицу состояний генерирует
Хуйня, самих регулярок которых нужно применить ахулиард, похоже без тупого прохода в цикле не обойтись
>Но делать так не стоит.
Просто я еще дополнительно изучил этот вопрос, абсолютное большинство говорит что каст в си избыточен и часто не нужен и порой не безопасен.
В некоторых местах каст вызывал у меня ворнинги при компиляции с флагом -Wall, что намекает на ненужность. И во многих примерах, в том числе на cppreference каст не используется.
Это копия, сохраненная 21 января 2019 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.