Международная Организация по Стандартам (ISO) опубликовала (http://www.open-std.org/jtc1/sc22/wg14/) обновлённый вариант стандарта для языка Си - ISO / IEC 9899:2011 (http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_... развиваемый под кодовым именем C1X (http://en.wikipedia.org/wiki/C1X) и пришедший на смену стандарту C99. Так как стандарт развивается уже достаточно давно, пройдя стадии выпуска нескольких черновых редакций, современные компиляторы, такие как GCC 4.6 и LLVM 3.0, уже поддерживают большинство описанных в спецификации возможностей.
В новой спецификации увеличена совместимость с языком С++ и представлены некоторые новые возможности, такие как поддержка многопоточности, Unicode, удаление функции gets, интерфейс для проверки допустимых границ и диапазонов значений, анонимные структуры и объединения (например, можно вложить блок union в struct), дополнительная функция для мгновенного выхода из программы quick_exit, статические утвержден...URL: http://www.open-std.org/jtc1/sc22/wg14/
Новость: http://www.opennet.dev/opennews/art.shtml?num=32644
Внезапно так. Почему ни одного срача, ни одной новости о черновиках? Или все просто используют C89 и не жужжат?
Вы таки предполагаете, что многие из читателей ОпенНета им действительно пользуются? До степени чтобы устраивать здесь срач на эту тему? :)
Си устаканился в 99, теперь ма-а-аленькие плюшки доделывают. Какой срач-то?!
> Си устаканился в 99, теперь ма-а-аленькие плюшки доделывают. Какой срач-то?!Я имею ввиду язык C как таковой :)
Эм... Вы ещё придумайте холивар про то, что компьютеры опасны - излучают смертельные дозы радиации!
Ну вообще то так и есть - это чистая правда. Указанный научный факт вывели ещё бухгалтера в середине 90х, обсаживая свои CRT мониторы кактусами. Которые как известно оное вредное излучение поглащают и преобразуют в полезное.
> Которые как известно оное вредное излучение поглащают и преобразуют в полезное.Особенно если их сожрать.
Так вот откуда слова "жрать кактус" !!! :-)
Давно-давно Фоменко на Русском радио произносил разные весёлости, и среди них была такая:
Мыши плакали кололись, но продолжали жрать кактус.
Думается, что выражение повелось отсель.
Автор - не Фоменко, впервые это появилось как минимум в Красной Бурде в начале 90-х.
А вовсе не от Кастанеды :)
> Я имею ввиду язык C как таковой :)А что - си? На си написаны все современные операционки. Не знать его - глупо и сильно ограничивает возможности. Тем более что на том же синтаксисе основана еще дюжина более-менее общеупотребительных языков.
Не все, винда на крестах, макось на obj-c
И в винде и в макоси большая часть кода на простом си.
Ну ты лолка. Про виндовс не знаю (код закрыт), а ядро макос 10 написано на СИ. Да и ядро виндовс скорее всего тоже.
Когда вовсю юзалась 3-я винда (3.11) и на подходе была 95-я, никаких плюсов у майкрософт практически не было. Тот C7.0, в котором появились элементы C++, ни на что не был способен. Это было поделие, в котором темплейты и обработка исключений были реализованы в виде макросов обычного С. Работало оно медленно и производило на выходе туеву хучу бинарного говна -- хеловорлд занимал почти 150 килобайт. А именно в 3-й винде было заложено все, что сейчас в win32. Там все на сях, включая окна, коммуникации, управление памятью и прочее. Мало того, есть подозрение, что исходников многих вещей вообще нет -- иначе никак не объяснить десятилетиями непофиксенные вещи, типа кривой языковой поддержки (я бы сказал -- ее вообще в виндах нет) и наличие горы 16 битного кода. Говно, одним словом.
ой, вот только не надо про языки. хуже, чем xkb, придумать сложно, наверное.
> ой, вот только не надо про языки. хуже, чем xkb, придумать сложно, наверное.В винде очень даже можно! Как тебе представление русиша в 1251, 866 и Unicode в зависимости от того где и как это происходит? В _одной_ системе можеи быть аж _три_ напрочь разных представления имен файлов, например. For the lulz, как ты мог догадаться, маппинг одних в других довольно приблизителен. И удачи тебе отмапить весь unicode в 1251, допустим. Сколько там глюков можно словить - нетрудно догадаться. В общем свои кретинизмы есть у всех.
> И удачи тебе отмапить весь unicode в 1251, допустима зачем? мне религия не запрещает пользоваться уникодным API и библиотеками с поддержкой оного.
а вот как, например, у иксов получить список установленых раскладок? при этом не полные имена, а двухбуквенные аббревиатуры? решение, конечно, есть, и кривость его потрясает даже закалённого в боях программиста.
Все что снизу там на C, включая по ходу железный уровень. Во всяком случае, еще во времена 3.11 они выпустили DDK на c'ях, который я тогда будучи еще веселым зеленым пионером пробовал поковырять, сломал зубы на бредовых структурах и остался на вполне боеспособных masm|tasm. Да и вообще работать с периферией на чем-то выше макроассемблеров бред, т.к. влечет за собой тонны неэффективного кода (тот же masm как сейчас помню производил тогда бинарники с кратным 16k размером).
Насчет закрытого кода - IDA в зубы, поделия на сях трудно с чем-то спутать - main(), однако.
> Не все, винда на крестахНу да, щаз. Ядро и многие либы вполне себе на си.
> макось на obj-c
См. выше про винду.
хм.. Оберон?
Аноним видимо имел ввиду операционки промышленного уровня. А так можно вспомнить и какой-нибудь JNode, написанный на джаве, или Singularity, которая вообще на С#... Oo
> хм.. Оберон?Эй, благородный дон! Где же ты и твой Оберон?
>> хм.. Оберон?
> Эй, благородный дон! Где же ты и твой Оберон?Работают себе и не жужжат фигню на опенсурсных форумах.
>> Я имею ввиду язык C как таковой :)
> А что - си? На си написаны все современные операционки. Не знать
> его - глупо и сильно ограничивает возможности. Тем более что на
> том же синтаксисе основана еще дюжина более-менее общеупотребительных языков.Да. да.. к сожалению миллионы леммингов похоронили уже не одну хорошую идею.
> Почему ни одного срача, ни одной новости о черновиках? Или все просто используют C89 и не жужжат?Ретроградим на Ц89, не жужжим.
> Или все просто используют C89 и не жужжат?Я использую C99, он не так уж отличается от C1x :)
Я использую ASNI Си.
Меня наверно уже поджидают динозавры, но я не знаю зачем нужен С99 не говоря о С11.
Милости прошу, уткните меня носом в спеки которые убедят меня выучить новые версии в которых описаны преимущества вышестоящих.з.ы. в гугле не забанен, просто хочу советов экспертов.
> Я использую ASNI Си.Хоть K&R, кому-то жалко чтоли?
> Милости прошу, уткните меня носом в спеки которые убедят меня выучить
> новые версии в которых описаны преимущества вышестоящих.Однострочный комент как в C++ (удобнее для вырубания единичных строк). Inline функции тоже не вредно иногда.
В ASNI нет многих прелестей, самые частовстречаемые:
* snprintf нет в ANSI C.
* единый вид коментов /* */, т.е. КО утверждает что "//" коментить нельзяА так там много ещё минусов
Желаю вам ещё много минусов.
ANSI приучает к порядку.
Равно как отказ от электрички приучает к бегу.
> ANSI приучает к порядку.Ага, только ставить комент в начале и конце строки в 2 раза менее удобно чем только в начале. А как только вы поюзали такой комент - это уже не менее чем C99, в котором такое было регламентировано. Более старые компилеры просто не обязаны жрать это.
>> ANSI приучает к порядку.
> Ага, только ставить комент в начале и конце строки в 2 раза
> менее удобно чем только в начале.Дело даже не в этом: всё равно у программиста комментирование-раскомментирование на шоткатах. А вот то, что если вы хотите закомментировать какой-то участок, который уже содержит комментарий, то в случае с /*...*/ всё либо сломается, либо будет уродливо выглядеть. Здравствуй, #if 0, ага.
> Милости прошу, уткните меня носом в спеки которые убедят меня выучить новые
> версии в которых описаны преимущества вышестоящих.
> з.ы. в гугле не забанен, просто хочу советов экспертов.Ну я например во всю использую:
- анонимные массивы
- инициализацию полей структур через "."
- возможность объявления переменных в "любом" месте программы. "for(int i=..." например.
- типы *int_*_t (stdint.h), а то немного напрягает когда каждая библиотека таскает за собой свои дефайны
- "//" - однострочные комменты у меня не прижились, но иногда действительно удобно так закомментить на время одну строчку.А вообще убеждать неблагодарное дело, почитай хотябы википедию и сразу станет ясно надо тебе это или нет.
В целом, т.к. Си до сих пор широко используется, то развитие радует.
Вообще меня удивляет опеннет, столько коммнетов и Ява пока не всплыла.
> В целом, т.к. Си до сих пор широко используется, то развитие радует.А куда он денется? Прошла куча времени, а для системного программирования по прежнему не придумали более хорошего языка. K&R зачетно отожгли в свое время.
> А куда он денется? Прошла куча времени, а для системного программирования по
> прежнему не придумали более хорошего языка. K&R зачетно отожгли в
> свое время.Так вот возможно стоило бы запилить, простой, лаконичный, без недостатков Си, без необходимости тянуть груз совместимости, но простым подключением сишных либ. А то сплошь одни Ява клоны выпускают.
> простым подключением сишных либВроде андроидового Bionic?
Наоборот, бионик — это урезанный libc. Расширением чего-либо там и не пахнет.
>> простым подключением сишных либ
> Вроде андроидового Bionic?Нет, я вообще имел ввиду простое, допускающее автоматизацию, создание "биндингов" к сишным либам.
>Так вот возможно стоило бы запилить, простой, лаконичный, без недостатков Си, без необходимости тянуть груз совместимости, но простым подключением сишных либ.Какой ты гениальный парень! Осталась сущая фигня - взять и сделать! К завтра успеешь?
:)
>> А куда он денется? Прошла куча времени, а для системного программирования по
>> прежнему не придумали более хорошего языка. K&R зачетно отожгли в
>> свое время.
> Так вот возможно стоило бы запилить, простой, лаконичный, без недостатков Си, без
> необходимости тянуть груз совместимости, но простым подключением сишных либ. А то
> сплошь одни Ява клоны выпускают.Запилили уже. D называется. Вот только опять забыли арифметическое ветвление сделать. Типа
compare(a, b: less(), equal(), greater());
Ну еще переходы по значению переменной типа "метка", дополнительные точки входа, механизм сопрограмм и дальние переходы.
> Типа
> compare(a, b: less(), equal(), greater());А не проканает #define'ом такое определить? Ну да, будет не из стандарта, но работать будет у всех.
> А не проканает #define'ом такое определить?как минимум синтаксис ограничен: с двоеточием удобней.
а вот, кстати, взять исходники D да добавить — особых проблем не составит, это не мегагиперизменение.
Не говорите глупостей. А куда вы денете аппратные плюшки? LowEndian, BigEndian - адресное пространство 32/64бит?
java потому и "такая java" что там под каждую архитектуру лепят JVM внутри у которых позволено не запариваться.
*) Однострочные коменты
*) Переменные можно объявлять в любом месте, а не только в начале.
*) Комплексный тип данных и функций
*) long double функции
*) long long int
*) inline функции
*) Объявление переменных вида: for(unsigned int ecx=0;;)
*) В некоторых моментах более строгие правила
и т.д.
Еще забыл что можно делать так:
unsigned int a;
scanf("%u", &a);
unsigned char tmp[a];
> Еще забыл что можно делать так:
> unsigned int a;
> scanf("%u", &a);
> unsigned char tmp[a];Жесть жестяная. У вас бесконечные патрон^W стек? Если такое есть в ваших проектах, скажите их названия, чтоб держаться от них подальше.
>> Еще забыл что можно делать так:
>> unsigned int a;
>> scanf("%u", &a);
>> unsigned char tmp[a];
> Жесть жестяная. У вас бесконечные патрон^W стек? Если такое есть в ваших
> проектах, скажите их названия, чтоб держаться от них подальше.Угу. Нужно было собрать статистику выделения памяти за десять минут, аппроксимировать полиномом, экстраполировать на предполагаемое время жизни процесса, зарезервировать 10% под root процессы, а потом разрешить захватить немного стека.
Что только не придумают, чтобы man limits.conf не читать...
Я хочу A байтов памяти. Грёбаный hello_world должен или отдать их мне или сдохнуть по нарушению защиты памяти, а не рассказывать, что он думает про то, сколько стека положено захватывать в фашистской деревне.
> scanf("%u", &a);
> unsigned char tmp[a];Нормальный такой г@внокод, эталонный: выделение памяти под массив, объем которого контролируется внешними сущностями чуть более чем полностью. И никакой вам валидации ввода. Т.е. жри сколко хошь. В теории. На практике при вводе больших чисел будут лулзы :)
> На практике при вводе больших чисел будут лулзы :)на практике при больших числах шарик, как и полагается, лопнет. с чего ты решил, что автора не устраивает такой вариант?
> *) Переменные можно объявлять в любом месте, а не только в начале.
> ...
> *) Объявление переменных вида: for(unsigned int ecx=0;;)Это одно и то же.
>> *) Переменные можно объявлять в любом месте, а не только в начале.
>> …
>> *) Объявление переменных вида: for(unsigned int ecx=0;;)
> Это одно и то же.нет. одно дело, когда декларации могут быть перемешаны с кодом, и совсем другое — декларации в инициализационных выражениях (с соответствующим scope).
>>> *) Переменные можно объявлять в любом месте, а не только в начале.
>>> …
>>> *) Объявление переменных вида: for(unsigned int ecx=0;;)
>> Это одно и то же.
> нет. одно дело, когда декларации могут быть перемешаны с кодом, и совсем другое — декларации в инициализационных выражениях (с соответствующим scope).Оба приведенных вами случая подходят под "Переменные можно объявлять в любом месте". Что конкретно имел ввиду автор я не в курсе, но выразился он именно так.
ANSI C.
Изучаю не так давно Си, пришлось под специфичное железо писать исключительно АНСИ-89... Как же мне это открыло глаза на мир! Теперь не берусь что-то делать на плюсах, пока не упрусь с пределы Си99. Юнион в структурах - это гуд, как-то не догадывался юзать))
> Как же мне это открыло глаза на мир! Теперь не берусь
> что-то делать на плюсах, пока не упрусь с пределы Си99.C++ имеет смысл только в заведомо больших и масштабных проектах, имхо. Где преимущества ООП имеют хоть какие-то шансы проявить себя.
>C++ имеет смысл только в заведомо больших и масштабных проектах, имхо. Где преимущества ООП имеют хоть какие-то шансы проявить себя.У вас видимо опыта недостаточно потому что обстоят дела с точностью до наоборот. С++ имеет смысл использовать в небольших программах. В больших и сложных системах (тем более в развивающихся) С++ вам создаст проблем.
Какие диаметрально противоположные мнения))
Я совсем не вижу смысла использовать Си++ в проектах, где достаточно Си-шных либ (читай - везде, кроме проприетарщины).
Писать на плюсах, как мне кажется, можно только в хорошо сработанной команде, используя ограниченное количество технологий ООП...
Где я не прав?
> Я совсем не вижу смысла использовать Си++ в проектах, где
> достаточно Си-шных либОтносительно крупные проекты чувствительные к производительности на плюсах в ряде случаев лучше писать. Скажем игры всякие - там объекты могут заметно упростить дело. Их обычно на плюсах пишут, хотя маньяки типа Кармака и на си могут :)
>Какие диаметрально противоположные мнения))
> Я совсем не вижу смысла использовать Си++ в проектах, где достаточно Си-шных либ (читай - везде, кроме проприетарщины).
> Писать на плюсах, как мне кажется, можно только в хорошо сработанной команде, используя ограниченное количество технологий ООП...
>Где я не прав?Я же вам пишу что у вас недостаточно опыта (недостаточность не в "длину" - а в "ширину", то есть разнообразие). Если 100500 лет делать сходные действия (к примеру, писать однотипные системы с однотипной архитектурой) то опыт будет такой же однотипный. Именно поэтому вы и не видите проблем с ООП. У ООП есть непреодолимые проблемы из-за чего, я думаю, написать Linux Kernel попросту не получится (из-за чрезмерного количества разных связей подсистем ядра). Я раньше болел ООП и предпочитал писать на С++ чем на С в силу многих причин (в т.ч. новомодность ООП и все такое ...) бросил использовать С++ и "традиционное" ООП после одного случая. Несколько лет назад был заказ на разработку системы состоящей из двух подсистем управления (все подробности не помню, но суть постараюсь передать). Разработал обе подсистемы на С++ в рамках "нормального" ООП без проблем. Внезапно появляется задача требующая сопряжение этих подсистем. Крутил я эти ровные архитектуры систем до тех пор пока не доказал себе что решить задачу можно лишь нарушив принципы объектного программирования (либо переделав архитектуру одной из подсистем). Я считаю что если необходимая задача не решается в рамках методов которые приняты - значит принятые методы плохие при условии корректного решения. Чуть позже я наткнулся на проект (название не сохранилось) программиста из японии (специально глянул страну автора) который писал проект на С++, но обильно использовал технику подобную тому которую использовал я в своих последних проектах на С++. Ну а дальше погуглил и почитал форумы и дискуссии умных и опытных людей и решил закончить писать на С++. Сейчас свободно пишу на Си придерживаясь объектной нотации. С гибкостью Си сопоставим только Perl (возможно есть еще языки вроде фортрана, PL/1, ...), ну а превосходит Си только Asm.
Полностью Вас поддерживаю, у меня тоже были не единичные случаи такого рода.
Asm,C + какой-нибудь скриптовый язык - наше все! :)
Если в итоге у Вас получилась архитектура, которую сложно преобразовать под новые требования, проблема либо в требованиях (кардинально отличаются от всего, что было до этого), либо в архитектуре, которая изначально оказалась не гибкой.
При чем тут ООП?
Почитай классиков."При пользовании ООП __ВСЕ__ классы, их свойства и методы должны быть тщательно проработаны __ДО НАЧАЛА__ кодирования". Уж не помню кто, но кто-то из основоположников UML.
это Гради Буч, наверное
>это Гради Буч, наверноеДля фанатов Гради Буча расскажу историю на тему нестандартного применения ООП. Необходимо было организовать документооборот (квитанции и платежки) на предприятии. Задача можно сказать тривиальная, однако все документы хранились в "своих" (думается что наследие со времен Лексикона и WD) форматах. Однако среди множества возможных структур хранения наблюдались некоторые общие признаки. Потратив вечер на анализ форматов и выделив общности я решил решить вопрос загрузки данных из файла нестандартным путем но в рамках ООП (как понимаете на входе может быть файл с любым из форматов). Сделано было следующим образом: объект reader загружал данные и определял формат и отдавал данные на парсер соответствующего класса. Однако все "рабочие" парсеры были реализованы в виде конечных классов, наследующих свойства родителей, которые являлись на деле обработчиками найденных общих структур форматов. Организовалась своего рода "потоковая" обработка данных по иерархии классов (если рассматривать дерево наследования в абстракции обработки данных). Вся эта структура была воспринята очень негативно другими программистами, которые пытались аргументировать свой ответ теориями "как надо" взятых из книг. Такие дела...
Это точно. Когда я пишу на Си, я думаю, как мне решить задачу. Когда я пишу на на С++, я думаю, как мне её запихать в классы.
Решить задачу - цель.
Запихать в классы - инструмент, средство.
В том-то и дело. Некоторые адепты С++ и ООП путают цель и средство.
В ООП архитектура определяется на уровне классов и интерфейсов. В функциональном программировании - на уровне данных и функций (данные + функции их обработки ~= класс). Найди 10 отличий.Не все понимают системный подход, не все понимают ООП, зато все имеют своё мнение.
>В ООП архитектура определяется на уровне классов и интерфейсов. В функциональном программировании - на уровне данных и функций (данные + функции их обработки ~= класс). >Найди 10 отличий.Ваня как всегда в своем духе хелоуворлдщика. То что вы написали - это уже реализация. Тьфу!
>Не все понимают системный подход, не все понимают ООП, зато все имеют своё мнение.
Это отлично когда у человека свое собственное мнение и уж еще лучше если оно выработано на опыте методом проб и ошибок. Мне лично (как и других матерым программистам) уже давно глубоко плевать что там пишут в книгах и советуют Вани на форумах. Я написал вам о своем опыте когда архитектура ООП споткнулась. Как я могу верить чьим-то пустым словам когда у меня на деле факты?
> Мне лично уже давно глубоко плевать что там пишут в книгахПопробуйте писать её первой строкой резюме и в письмах своему руководителю/заказчику. Результаты вас удивят.
>> Мне лично уже давно глубоко плевать что там пишут в книгах
>Попробуйте писать её первой строкой резюме и в письмах своему руководителю/заказчику. Результаты вас удивят.Вот я еще ерундой не занимался. Заказчику нужен работающий проект с ожидаемой надежностью работы системы - это и есть цель.
Я сильно сомневаюсь, что заказчика в конечном счёте удовлетворит проект, который нереально поддерживать и развивать в виду того, что весь код в нём представляет собой лапшу на C. И вот ещё: что-то в последнее время склерозом страдаю, потому точно вспомнить не могу, но что-то такое недавно я слышал, типа этот ваш Торвальдс говорил что линуховское ядро на этом вашем C скатилось в верблюжий кал...
> в виду того, что весь код в нём представляет собой лапшу на Cтак для этого есть отличное решение: не писать лапшу. впрочем, тут где-то уже говорили, что опытный программист может написать нечитаемый код на чём угодно.
>Я сильно сомневаюсь, что заказчика в конечном счёте удовлетворит проект, который нереально поддерживать и развивать в виду того, что весь код в нём представляет собой лапшу на C. И вот ещё: что-то в последнее время склерозом страдаю, потому точно вспомнить не могу, но что-то такое недавно я слышал, типа этот ваш Торвальдс говорил что линуховское ядро на этом вашем C скатилось в верблюжий кал...Вы правы. Лапшу на С поддерживать очень мерзко. Еще очень невозможно простоить систему с определенной архитектурой и требованиями использую технику быдлокодерства, которая дает на выходе авральный лапшеобразный код (но такую систему можно довести до ума циклами "тестирование-отладка" что, в конечном счете, размажет любую архитектуру). И чтобы такое не случалось программисту следует быть не просто программистом. Если же вы ограничиваетесь "просто программированием" 0 то вы почти обречены строить лапшеобразный быдлокод (и, вероятно, ваш код лучше не открывать). К сожалению, я таких "простых программистов" повидал воочию. Они говорили примерно так: "Мне платят за то что я пишу код и большего мне не надо".
> В ООП архитектура определяется на уровне классов и интерфейсов. В функциональном программировании
> - на уровне данных и функций (данные + функции их обработки
> ~= класс). Найди 10 отличий.
> Не все понимают системный подход, не все понимают ООП, зато все имеют
> своё мнение.Дело не совсем в том. Просто последовательность операторов/функций, обрабатывающих некие данные - так работает "железо". Объекты, взаимодействующие между собой - якобы так мыслят люди. Изначально, ООП это попытка сделать так чтобы описывать в стиле "как мыслят люди", а компилятор сам сделает из этого "как работает железо".
Чтобы хорошо писать без ООП надо в существенной мере "думать как машина". Заблуждение состоит в том, что, с ООП этого якобы не надо.
В реальности ООП (чуть дальше от hello,world и базовых книжных примеров) получается, что все-таки надо бы "думать как машина", но парадигма ООП заставляет мыслить по-другому. То что получается в итоге примерно одинаково не похоже ни на то как работает железо, ни на то как мыслят люди. Получается, что "обычным людям" недоступно (без усилий) ни то ни другое, а "адептам" разных парадигм сложнее понимать происходящее в другой "системе".
Я не знаю что пишете вы, но рассмотрим напр. математическую формулу.class Операция
- наследний линейная: +-*
- наследник /
- наследник скобки
...class Формула {Операция оп;}
Отрисовка в ООП:
формула.Нарисовать();Отрисовка в функциональном программировании:
Нарисовать(&формула);Видите разницу? Или ещё не дошло?
Реализация для функционального:
Нарисовать(формула)
{
если тип=линейная тогда
НарисоватьЛинейную(ОперацияЛинейная(формула));
иначеесли тип=делить тогда
НарисоватьДелить(ОперацияДеления(формула));
....
}И для ООП:
Нарисовать()
{
ptr=НайтиПоТипу();
ptr->Нарисовать()
}НайтиПоТипу()
{
если тип=линейная тогда
возврат ОперацияЛинейная(this); // преобразование типа ссылки из родителя в детей
иначеесли тип=делить тогда
возврат ОперацияДеление(this);
....
}Остальные функции будут аналогичны функции Нарисовать(). Заметно что для ООП код на порядок красивее и логичнее, мы лишних ссылок не передаёт, мы преобразование к нужному типу делаем в коде один единственный раз в функции НайтиПоТипу, соотв. добавлять новые операции можно элементарно.
И чем больше и сложнее проект, тем явнее ООП будет дрючить функциональное. Есть исключения.
Странно что я вообще это объясняю, это проходят на 2-ом курсе профильного ВУЗа, всего курсов 6 :).
Ваши суждения - глупы.Все делается через указатели на функции - а-ля виртуальные методы, а не так, как вы показали.
Налажал для функционального:Нарисовать(формула)
{
если формула.тип=линейная тогда
НарисоватьЛинейную(формула);
иначеесли формула.тип=делить тогда
НарисоватьДелить(формула);
...
}Также для функционального придётся в одну структуру Операция запихать данные все операций и соотв. неэффективно расходовать память. Для классов - есть общие (наследуются от класса Операция, напр. тип) и специфические для данного класса.
> Налажал для функционального:ах, если бы только… лучше бы ты вообще не брался приводить какие-то «доказательства»: ведь работодатель может нечаянно понять, на какое ты себя посмешище этим выставляешь и выкинет на мороз.
> функционального?!
PS: не знаю, кто и зачем снёс #235 -- но в "функциональности" важнее , что гругря типично делается
f1(f2(f3(x,f4(y))))и неres4 = f4(y)...и ветвление тоже реализовано функциями, а не языковыми конструкциями -- см., например, http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme-Z-H-...
res3 = f3(x,res4)
res2 = f2(res3)
res1 = f1(res1)PPS re #236: размышлять над различиями (что не равно "забивать голову") человеку полезно, чтоб бараном часом не оказаться. Особенно считающим себя самостоятельным и при этом ведомым на убой.
>> функционального
> ?!оно считает, что если без объектов, используя только функции — это «функциональный».
>"При пользовании ООП __ВСЕ__ классы, их свойства и методы должны быть тщательно проработаны __ДО НАЧАЛА__ кодирования". Уж не помню кто, но кто-то из основоположников UML.Сами читайте про эти костылеобразные технологии до тех пор пока не поймете что они костылеоборазные. Ну а понять эту костылеобразность очень просто если задуматься над дальнейшим развитием готового проекта, причем дальнейшая задача в рамках ООП (без отхода от концепции) не решаема. Концепция ООП (как вы сказали) требует новой переработки __ВСЕХ__ классов __ДО НАЧАЛА__ доработки уже готового проекта? Пишу на Си (и буду на нем писать) именно потому что концепция ООП становится "диктатором", тогда как Си и дальше остается "другом".
Я вам пример привел из личной жизни а не из книги.
P.S.: Пишите вы на чем хотите и как хотите (точнее на чем можете и как можете). А для меня ООП'шные штанишки уже малы - сильно жмут.
Это всё замечательно, только вот работодателей Си интересует только для драйверов в ядре. В остальном почему-то требуют плюсы, с аргументацией "на нём создавать ПО проще, причём приемлемо производительное и эффективное".P.S. Тошнит от ООП, прибитого гвоздями к плюсам и упоротых погромистов, пихающих это плюсовое ООП во всё подряд, даже не задумываясь, нужно ли оно там.
> Почитай классиков.Алана Кея, например. чтобы заплакать от тоски и перестать уже считать плюсанутые костыли «объектно-ориентироваными».
если программер сам на костылях по самые помидоры, то плюсы будут костыльными, да
> если программер сам на костылях по самые помидоры, то плюсы будут костыльными,
> даплюсы всегда будут костыльными, потому что никакого ООП там нет, только потуги оное изобразить. иди, покури Smalltalk. или Objective C хотя бы, если творение Кея религия курить не позволяет.
на ObjC я программирую в рамках своего хобби, плюсы - на работе.
а плохому танцору всегда что-нибудь да помешает, особенно - танцорам, которым религия уж больно много чего позволяет. :-D
то есть, ты таки знаешь, что такое ООП (ну, если Objective C используешь верно), и при этом продолжаешь утверждать, что в c++ — не костыли, неудачно маскирующиеся под реализацию ООП? O_Oникогда я вас, людей, не пойму.
>Если в итоге у Вас получилась архитектура, которую сложно преобразовать под новые требования, проблема либо в требованиях (кардинально отличаются от всего, что было до этого), либо в архитектуре, которая изначально оказалась не гибкой.
>При чем тут ООП?Гибкость архитектуры и проблемы в требованиях - это все чушь академическая. Особенно в контексте того что эти аргументы часто при разработке минимум второстепенные. Проблема именно в ООП, так как не дает решать задачи. Вам не удастся меня убедить ничем, потому что в Си таких проблем там не найдете.
Наверное потому в этом вашем ядре линуха сплошь и рядом на этом вашем C эмулируются объекты в виде монстрообразного трэшово-лапшового кода?
proof or GTFO. и да, на «сплошь и рядом» тоже пруф. нет, структуры и функции работы с ними не считаются «эмуляцией» и «монстрообразным трэшово-лапшовым кодом».
>Наверное потому в этом вашем ядре линуха сплошь и рядом на этом вашем C эмулируются объекты в виде монстрообразного трэшово-лапшового кода?Помню себя как программиста когда еще был хеллоуворлдщиком но не осознавал этого так как мыслил лишь в рамках того что мне известно. Так вот, в тот период мне не только сорцы линукса, но даже урезанный код входящий в MS Platform SDK казался "монтрообразно трэшово-лапшевым кодом". Но я еще допускал то что если кто-то пишет такой код на Си который я не могу воспринять - то проблема однозначно во мне. Сейчас я понимаю что был прав в том что прблема была во мне. Но достиг я это молча изучая, развиваясь и набираясь опыта. Намек понятен?
У вас много общих слов без конкретных примеров. Как у классика - "вы ставите проблемы космического масштаба..." ну и далее по тексту.> У ООП есть непреодолимые проблемы
Это какие конкретно?
(остальной бессвязный поток сознания комментировать трудно)
>У вас много общих слов без конкретных примеров. Как у классика - "вы ставите проблемы >космического масштаба..." ну и далее по тексту.
>> У ООП есть непреодолимые проблемы
>Это какие конкретно?
>(остальной бессвязный поток сознания комментировать трудно)А вы не рефлексируйте на сообщение - а прочтите вдумчиво и найдете конкретный (но обобщенный) пример. Если не хотите разбираться/думать сами - я вам на блюдечке хрен приподнесу. Информации в сообщении достаточно (при наличии достаточного реального опыта программирования).
Я пока вижу только "поверьте моему опыту" и что-то расплывчатое про каких-то программистов из японии и неизвестные проекты, над которыми вы якобы работали (да еще и выбирали на чем писать). Я не вижу от вас реальных пояснений, почему ООП не подходит для написания ядра ОС (и да, вы писали ОС?).Не обижайтесь, но если вы не можете четко и ясно изложить ваши претензии к ООП, в виде 1) 2) 3) по первой же просьбе (а не лепить отмазки), всю эту воду всерьез воспринимать невозможно.
>Я пока вижу только "поверьте моему опыту" и что-то расплывчатое про каких-то программистов из японии и неизвестные проекты, над которыми вы якобы работали (да еще и выбирали на чем писать). Я не вижу от вас реальных пояснений, почему ООП не подходит для написания ядра ОС (и да, вы писали ОС?).Вы - либо невнимательный читатель, либо плохо понимаете содержание, либо плохо восстанавливаете первоначальный смысл сообщении (такое бывает, к примеру, если человек мало читал и довольствовался лишь поверхностными (на уровне слов) пониманием содержания). Если вы дилетант в разработке (или хеллоуволдщик) то объяснить вашу рефлекторность содержание остутствием (недостаточностью) опыта чтобы понять содержание моих ответов. Прошу заметить что некоторые читатели опеннета понимают содержание моих сообщении (номера 5.43 и 8.116 - однозначно излагают мысль). Ну а то что вы не можете понять то что понимают другие - есть свидетельство того что проблема с пониманием находится именно в вас. Но я уверен, что вы так не считаете, так как такие вам подобные более предрасположены к рефлексированию нежели к вдумчивому анализу.
>Не обижайтесь, но если вы не можете четко и ясно изложить ваши претензии к ООП, в виде 1) 2) 3) по первой же просьбе (а не лепить отмазки), всю эту воду всерьез воспринимать невозможно.
Обидеть меня могут лишь родные и/или близкие. В содержании сообщения 5.43 есть конкретная претензия к ООП но через пример на основании моего опыта, а в содержании 8.116 уже последовало обобщение. Вам этого недостаточно? А по пунктам вам раскладывать никто ничего не будет (и уж тем более на фоне того что те причины из-за чего вы проявили синдром неосилятора кроется именно в ваших способностях).
А как вы дальше будете ли вы рефлексировать на этот ответ (через попытки подвести его к отмазкам или через попытку усомнения о подлинности моего личного опыта) - мне глубоко фиолетово. Я вовсе не собираюсь вас "таскать за ноздри". Если вы не хотите сами приложить усилия к пониманию то и оставайтесь дальше с тем что имеете.
P.S.: Есть вероятность что вы меня просто троллите, поэтому дальнейшие ваши подобные выпады будут оставлены без внимания и отправлены к модератору с пометкой "троллинг".
ну, человек же признался, что «выбирать, на чём писать» для него — ненаучная фантастика. откуда вполне понятен его уровень и квалификация. в лучшем случае это какой-нибудь жабакодер, который в свободное время пишет скриптики на питоне и втайне мечтает, что когда-нибудь он таки выучит C++ и сразу пойдёт на работу, где платят Бешеные Деньги.
Для меня это не "фантастика", просто в большинстве случаев выбор это роскошь - т.к. в предметной области инфраструктура и руки кодеров в основном заточены под конкретный инструмент (сейчас у меня это C++ и даже конкретней MS тулчейн, у людей, работающих с эмбеддовкой - обычно Си, и т.п.).Если вы работаете один и имеете возможность выбирать между Си, Java, Haskell и С++ - я вам искренее завидую. Впрочем тут же перестану, когда вам понадобятся еще люди для проекта на Haskell.
> Дальнейший разговор бессмысленен.конечно, бессмысленен: ты так и будешь повторять то, что я сказал, пытаясь при этом убедить меня, что ты сказал совсем другое.
Слушайте, вы издеваетесь?> Прошу заметить что некоторые читатели опеннета понимают содержание моих сообщении (номера 5.43 и 8.116 - однозначно излагают мысль).
Прошу заметить, что на 5.43 я как раз и отвечал, там ни одного аргумента, только пространные рассуждения а-ля "я, Аноним, использовал ООП и мне не понравилось". 8.116 вообще сплошные метафоры.
Давайте так - "объектно-ориентированный подход не годится для ядра ОС, потому что..."
1)...
2)...
3)...?
До этого момента будем считать, что вы просто слили.
А также поясните, где вы увидели в С++ нормальный ООП, и что вам мешает использовать только его подмножество.
> Есть вероятность что вы меня просто троллите
Тролли у вас под кроватью, уважаемый (точнее пока не очень). Перестаньте их видеть всюду. Вам задали конкретный вопрос, вы на него вместо прямого ответа разводите воду.
>Прошу заметить, что на 5.43 я как раз и отвечал, там ни одного аргумента, только пространные рассуждения а-ля "я, Аноним, использовал ООП и мне не понравилось". 8.116 вообще сплошные метафоры.давай так: сначала въезжаешь в содержание сообщении а потом уже поговорим.
>До этого момента будем считать, что вы просто слили.
Да плевать. Считайте как хотите. Вы до сих пор не понимаете что сливаете как раз вы тем что не можете уловить основную мысль сообщении.
>А также поясните, где вы увидели в С++ нормальный ООП, и что вам мешает использовать только его подмножество.
Если вдуматься то в С++ немного больше (есть лишнее) ООП.
>Тролли у вас под кроватью, уважаемый (точнее пока не очень). Перестаньте их видеть всюду. Вам задали конкретный вопрос, вы на него вместо прямого ответа разводите воду.
Точно троллите. Чтобы получить прямой ответ вам следует осилить содержание сообщении и задать прямой вопрос по теме. В сообщениях рассказывается об архитектуре (намек чтобы было полегче). Пережевывать уже написанное чтобы кому-то что-то доказывать мне, минимум, времени жалко. Спросить я также не буду по этой причине, тогда как любые конструктивные дискуссии поддерживаю.
Последнии раз пишу и далее не буду отвечать на ваши рефлекторные выпады: либо осиливаете содержание собщении и далее пишите по делу, либо проходите мимо.
> Да плевать. Считайте как хотите. Вы до сих пор не понимаете что сливаете как раз вы тем что не можете уловить основную мысль сообщении.Дык ты поясни, раз мы уловить не можем. На пальцах покажи. Потому что ты умный, а мы дети безграмотные.
А если показывать и объяснять не хочешь, то непонятно к чему эти пространные калоизлияния.
Пока что выглядит всё так: "вы дураки... да-да, вы дураки... я знаю это... у меня есть доказательства.... но я вам их не скажу...... просто верьте мне, я шарю".
>> Да плевать. Считайте как хотите. Вы до сих пор не понимаете что сливаете как раз вы тем что не можете уловить основную мысль сообщении.
>Дык ты поясни, раз мы уловить не можем. На пальцах покажи. Потому что ты умный, а мы дети безграмотные.Для чего объяснять?
>А если показывать и объяснять не хочешь, то непонятно к чему эти пространные калоизлияния.
Это информация к обуждению. В основном адресовано тем кто хоть и не понял но уже взял на заметку на будущее и попытается сам разобраться. Также адресовано людями которые уже подобное встречали и понимают. Ну а насчет оставшихся (те кто не понял но просит объяснить) я предлагаю два варианта: либо приложите усилия к развитию и подойдете до уровня через свою рефлексию, либо проходите мимо.
>Пока что выглядит всё так: "вы дураки... да-да, вы дураки... я знаю это... у меня есть доказательства.... но я вам их не скажу...... просто верьте мне, я шарю".Забыли добавить ключевое "ИМХО" потому что так выглядит для вас несмотря на то что моя позиция определена явно и однозначно (в текущем сообщении оно последним предложением абзаца повыше).
Ты ведёшь себя как религиозный проповедник. Типа бог есть и всё тут. А кто не уверует - получит кадилом по лбу.
>Ты ведёшь себя как религиозный проповедник. Типа бог есть и всё тут. А кто не уверует - получит кадилом по лбу.Интеллект который выдает шаблоны вместо того чтобы думать (вы внезапно оказались в числе XY% людей планеты).
А вы еще и выбираете на чем писать? Везет же вам.
а не могли бы вы подсказать какую-то литературу, где можно почитать о проектированию больших и сложных систем на С? а то С++/ООП/UML более-менее знаю, а вот на С - не шарю
>а не могли бы вы подсказать какую-то литературу, где можно почитать о проектированию больших и сложных систем на С? а то С++/ООП/UML более-менее знаю, а вот на С - не шарюПоверьте, вам это (пока) не нужно.
к примеру Reza Azimi "Organizing Large C programs" (презентация, но основные моменты расписаны)
> проектированию больших и сложных систем на С? а то С++/ООП/UML более-менее
> знаю, а вот на С - не шарюЕсли вы думаете что знаете си++ и при этом не знаете си - вы себя где-то очень жестоко нае...ли, сами того не осознавая.
Вопрос был не о знании C, а об организации сложных программ на нем.
> Если вы думаете что знаете си++ и при этом не знаете си
> - вы себя где-то очень жестоко нае...ли, сами того не осознавая.Если вы думаете что знаете Java и при этом не знаете асма - вы...
Если вы думаете что знаете архитектуру PC и при этом не знаете как то же самое собрать на релюшках - вы...А вообще да, на Си - тоже самое, что на С++ (ООП/UML), только сначала вы изобретаете ООП (где-то видал статью как чувак на макросах родил почти полнофункциональное ООП, при удобоваримом способе записи) или функциональный подход (тоже проскакивала статейка), а затем всё как по накатанной...
> только сначала вы изобретаете ООП (где-то видал статью как чувак на
> макросах родил почти полнофункциональное ООП, при удобоваримом способе записи)Да чего там - посмотри GNOME - пишут на C но юзая ООП 8-)
(может от этого и изобрели Vala :)
>Если вы думаете что знаете си++ и при этом не знаете си - вы себя где-то очень жестоко нае...ли, сами того не осознавая.Ээээ - НЕТ!
Если знаете си++ и при этом вы думаете что знаете си - вы себя где-то очень жестоко нае...ли, сами того не осознавая. Разные это языки - РАЗНЫЕ!
> Если знаете си++ и при этом вы думаете что знаете си - вы себя где-то очень жестоко нае...ли, сами того не осознавая. Разные это языки - РАЗНЫЕ!Если у вас есть голова и вы при этом думаете, что у вас есть мозг — вы себя где-то очень жестоко нае...ли, сами того не осознавая. Разные это части тела - РАЗНЫЕ!
> Если у вас есть голова и вы при этом думаете, что у
> вас есть мозг — вы себя где-то очень жестоко нае...ли, сами
> того не осознавая. Разные это части тела - РАЗНЫЕ!Лучше и не скажешь! //предыдущий аноним
>Если у вас есть голова и вы при этом думаете, что у вас есть мозг — вы себя где-то очень жестоко нае...ли, сами того не осознавая. Разные это части тела - РАЗНЫЕ!Человек вам по делу писал про случай знания С++ и незнания Си. Вероятно вам не хватает квалификации для того чтобы понять какие детали имел ввиду автор сообщения и о чем умолчал. А вы в бред школьника начальных классов в ответ.
>[оверквотинг удален]
> задача не решается в рамках методов которые приняты - значит принятые
> методы плохие при условии корректного решения. Чуть позже я наткнулся на
> проект (название не сохранилось) программиста из японии (специально глянул страну автора)
> который писал проект на С++, но обильно использовал технику подобную тому
> которую использовал я в своих последних проектах на С++. Ну а
> дальше погуглил и почитал форумы и дискуссии умных и опытных людей
> и решил закончить писать на С++. Сейчас свободно пишу на Си
> придерживаясь объектной нотации. С гибкостью Си сопоставим только Perl (возможно есть
> еще языки вроде фортрана, PL/1, ...), ну а превосходит Си только
> Asm.С++ -- язык, имеющий к ООП крайне отдаленное отношение. Он не поддерживает один из двух основных краеугольных камней ООП -- механизм обмена сообщениями. Объекты между собой в ОО парадигме взаимодействуют, исключительно обмениваясь сообщениями и это есть единственный способ их взаимодействия. Если же подходить менее строго, то есть еще и системные коммуникации типа совместно используемой памяти и всего остального, если сообщений окажется недостаточно. По моему этого более чем достаточно. тем не менее, в C++ нет ни операторов, ни протоколов. Зато есть полиморфизм, никакого отношения к ООП не имеющий, но активно, прямо таки надрывным криком выдваемый за признак ООП.
Наследование, несомненно, облегчает жизнь программисту, но никакого отношения к ООП оно опять же не имеет. Неомненно, это удобно и в языке должно быть. Но все это должно обрабатываться статически и не добавлять лишних проверок и вызова темных функций из темных шареных либ. Иначе эффективнее возложить синхронизацию на внешний по отношению к языку механизм.
Кто-то где-то отрыгнул, что сообшения в C++ заменены во сто крат более эффективным механизмомм -- объект, который хочет послать сообщение другому, может залезть в его адресное пространство через специальную дырку (с помощью специально предоставленного получаюшщим сообщение объектом метода) и посрать там как он хочет -- глваное, чтобы оба понимали, какая кучка что означает. Тут конечно мы спрашиваем -- т.е это я сам должен реализовавать ту часть протокола взаимодействия, которая отвечает за установелние соединения, его обслуживание и завершение? Но таки этот процесс должен быть скрыт от пользователя. В ООП языке должен присутствовать оператор установления соединения между объектами и оператор бродкаста. Ну или чтото-то похожее. Иначе два объекта не смогут обмениваться друг с другом. В C++ ничего похожего нет. Зато там есть хрень типа template, которая облегчая жизнь ленивому программисту, оставляет гору подводных камней в отношении производительности -- часто код годами работает у клиента, будучи собранным в отладочном режиме. И когда на замечание о вычислительной производительности компилята из-под С++ я слышу мантры об оптимизации кода, я говорю -- возможно этот код всегда будет собираться с опцией -O0, но это никак не должно отражаться на юзабилити. И тогда я слышу сладкое -- ну тогда его надо было писать на голых сях -- а кто вам мешал? -- а как-то в падлу -- ну так прописывайся у клиента и ремонтируй.
> и решил закончить писать на С++.Ну и дурак. Для начала научись использовать данный тебе инструмент. Неумелое использование инструмента не по месту не означает, что инструмент плох.
>Ну и дурак. Для начала научись использовать данный тебе инструмент. Неумелое использование инструмента не по месту не означает, что инструмент плох.Есть тип людей которые позволяют себе судить о чем-либо не разобравшись в вопросе как следует. Вы же не знаете мой уровень программирования на С++ и не знаете мой уровень на Си. То что я заикнулся об архитектуре должно было вас немного насторожить. Но вам все это либо мелочи либо не имеющие значения детали. Исходя из этого я не могу сказать какой вы программист на деле (возможно, вы даже хорошии кодер в рамках определенного круга прикладных задач). Но я точно вам могу сказать что вы здесь показали способности быдла. Вывод: дурак я или нет - это еще спорный момент, ну а бесспорным получается утверждение что вы являетесь быдлом.
P.S.: Не пишите больше ответы на мои сообщения. Никогда.
Поработаю компилятором...
ЕГГОГ: не инициализирована переменная "мои".
Если уж требуете от человека молча внимать именно вашим откровениям, потрудитесь хотя бы залогиниться ;)
>Поработаю компилятором...s/компилятором/интерпретатором/
>ЕГГОГ: не инициализирована переменная "мои".s/интерпретатором/примитивным интерпретатором/
>Если уж требуете от человека молча внимать именно вашим откровениям, потрудитесь хотя бы залогиниться ;)Ничего не требую. Лишь рассказал как есть. Распарсили вы (другой) или нет - мне побоку (кому надо - тот въедет).
Другими словами, теперь вы строите систему на тех же принципах ООП при этом используя Си. Это нормально. И такой подход более чем оправдан. По крайней мере по моему собственному опыту. С другой стороны... Хочется плюшек языков Вирта. Таких как модула/объектный Паскаль.. Описание языка занимает чуть больше 30-ти страниц. И как же я был разочарован когда узнал, что нормальных компиляторов под него не существует. По крайней мере под Unix like системы. :(
Может с приходом llvm что-то изменится и эти уродцы C/C++ отомрут окончательно. Либо наконец-то впитают в себя нормальную модульную архитектуру вместо костылей - namespace-ов и глобальной области видимости.. Жесткую типизацию. Иерархию классов не более чем одного уровня вложенности, частично синтаксис...
Уж очень-на они "свободные" сейчас.. Половина программы в *.h заголовках на крестах - обычное дело.
>Другими словами, теперь вы строите систему на тех же принципах ООП при этом используя Си. Это нормально. И такой подход более чем оправдан. По крайней мере по моему собственному опыту.Согласен. Однако здесь работает тот же принцип: "Большаие возможностри требуют большой ответственности". Другими словами, если не разбираться в проектировании ПО и архитектурных решениях то очень высока вероятность вообще не завершить проект и забросить Си навсегда и застрять на уровне быдлокодера.
>С другой стороны... Хочется плюшек языков Вирта. Таких как модула/объектный Паскаль.. Описание языка занимает чуть больше 30-ти страниц. И как же я был разочарован когда узнал, что нормальных компиляторов под него не существует. По крайней мере под Unix like системы. :(
Не знаком с виртом, но за упоминание благодарю (поставил его кандидатом на освоение языка и его модели перед обероном).
> сложных системах (тем более в развивающихся) С++ вам создаст проблем.Да ну бросьте, игрушечники пишут огроменные и архисложные пепелацы с приличной производительностью на плюсах. На сях такое писать можно и подзадолбаться, хотя маньяки типа кармака на си осиливают запросто.
А в мелких программах этим наворотам с классами, шаблонами и прочим просто негде развернуться и они больше мешают чем помогают.
> маньяки типа кармака на си осиливают запросто.Последнее, что написал Кармак на Си - это был Quake 3. Уже DOOM III был на C++.
добавлю: можете также почитать его мысли по этому поводу в его .plan-файлах. Собсно, ничего хорошего о выборе Си в качестве основного языка для Q3 он там не говорит.
> Последнее, что написал Кармак на Си - это был Quake 3. Уже
> DOOM III был на C++.А тем не менее xonotic и по сей день очень недурен. Тут вам и вагон современных эффектов, и текстуры с нормальным разрешением, и просто доставляющий геймплей. И орава маппаров которые делают годные карты, аццки допиливают скрипты на QuakeC и прочая. В общем дело Кармака живет и как видим на этом вполне можно сделать весьма годную игру, если захотеть :)
> C++ имеет смысл только в заведомо больших и масштабных проектах, имхо. Где преимущества ООП имеют хоть какие-то шансы проявить себя.Использовать преимущества ООП можно (и нужно) не смотря на язык разработки (ли ж бы был аналог struct).
Правильно организованный код на С, написанный опытным программистом, получается проще и легче в сопровождении,
чем код на C++/Java/C#, написанный пионером, начитавшимся Гради Буча и на каждом углу кричащим "ООП!".
>> C++ имеет смысл только в заведомо больших и масштабных проектах, имхо. Где преимущества ООП имеют хоть какие-то шансы проявить себя.
> Использовать преимущества ООП можно (и нужно) не смотря на язык разработки (ли
> ж бы был аналог struct).
> Правильно организованный код на С, написанный опытным программистом, получается проще
> и легче в сопровождении,
> чем код на C++/Java/C#, написанный пионером, начитавшимся Гради Буча и на каждом
> углу кричащим "ООП!".согласен почти полностью, хотя и настораживает непринужденное использование оборота "ли ж бы". Дело в том, что в С++ гораздо проще писать максимально нечитаемый код. Как правило, его пишут в надежде, что коллеги изумятся и скажут "вау! вот это шарит пацанчик а! Внатури давайте ему немедленно поднимем зп и никогда не будем спрашивать о сроках!". Как бы детская болезнь.
Настоящий профессионал умеет писать нечитабельный код на любом языке.
>> Настоящий профессионал умеет писать нечитабельный код на любом языке.В мемориез :)
>>> Настоящий профессионал умеет писать нечитабельный код на любом языке.
> В мемориез :)На башорг срочно! :)
Как-то скромно пропустили, что C++ != ООП.
И уж тем более - не обязательно использовать "классический" ООП с навороченными иерархиями наследования, фабриками, виртуальными методами и т.п.Частенько плюсы просто добавляют удобств - STL тот же, RAII использовать - милое дело. Да и самодельные просты шаблоны хороши вместо макросов, а семиэтажные писать никто не заставляет.
В общем как обычно - если голова на плечах есть, то больше возможностей в языке - только на пользу. А если две извилины - то таких либо гнать, либо забивать в рамки "шаг влево, шаг вправо - попытка бегства" - и пусть рутину молотят...
Правильно организованный код на C++/Java/C#, написанный опытным программистом, получается проще и легче в сопровождении,
чем код на C, написанный пионером, не начитавшимся Гради Буча и на каждом углу кричащим "Долой ООП!".Т.е. для вас откровение, что специалист пишет код лучше, чем начинающий?
> пришлось под специфичное железо писать исключительно АНСИ-89...Как связано железо и версия стандарта языка?
Особо интересно, что можно в ANSI-89, чего низя в ISO/IEC 9899:1999 ?
Очевидно же, что компилятором под данное железо, который поддерживает только ANSI-89.
Сов. верно, спасибо за пояснение. Уточню, что дело было с проприетарной ОСРВ под жутко хитрое железо, которое в музей пора сдать...
> Очевидно же, что компилятором под данное железо, который поддерживает только ANSI-89.НекромантЪ в студии!
Добро пожаловать в реальность, друг.
> Добро пожаловать в реальность, друг.Реальность - такая какую вы себе ее создадите. Можно конечно и в окаменелом г-вне мамонта колупаться. Но я этим заниматься не буду. Потому что это не имеет перспектив.
Я просто пользуюсь камнями поддерживаемыми gcc
1) Потому что он есть под симпатичные мне операционки.
2) Потому что он понимает кучу архитектур и я могу выучить 1 набор тулзов, особенности и закидоны оных на нормальном уровне, нежели учить десяток разномастных и не похожих друг на друга глюкастиков. Половина из которых еще и денег стоят, отсутствует под удобную мне ОС или сто лет не поддерживается никем.
3) Потому что копаться в окаменелом дерьме - неперспективно.
4) Потому что я тоже человек и хочу удобные/полезные плюшки из C99.Копание в г-не и раритетах имхо привилегия копрофилов и некрофилов, соответственно :)
User294, залогиньтесь!> Я просто пользуюсь камнями поддерживаемыми gcc
Я не видел, чтобы gcc генерил хороший код для использовавшихся мною архитектур. Конечно, для тех, для которых gcc существовал :-D
> Копание в г-не и раритетах имхо привилегия копрофилов и некрофилов, соответственно :)
В процессорах тоже бывают баги, вычищаемые со временем. Как Вы думаете, что используют в критических по безопасности системах?
> Как Вы думаете, что используют в критических по безопасности системах?шестерёнки и рычажки.
>> Как Вы думаете, что используют в критических по безопасности системах?
> шестерёнки и рычажки.Собственно, электроника, там где она есть (а она там есть) такая же кондовая и неубиваемая, как те самые шестеренки и рычажки.
> Финальный текст стандарта не доступен для свободной загрузки (только платная загрузка)Стандарт, который показывают только за деньги — это никакой не стандарт, это экспонат музея.
Практические все стандарты ISO не доступны для публичного просмотра, и ничего все кому они действительно нужны их имеют.
Если вы не знали, ISO продают стандарты. Для свободного доступа доступны только черновики.
Это не RFC =(
Внезапно! Все в этом мире стоит денег. Особенно чужое время и чужие ресурсы, используемые в производствах чего угодно.
> Внезапно! Все в этом мире стоит денег. Особенно чужое время и чужие
> ресурсы, используемые в производствах чего угодно.Деньги за стандарты - маразм. По идее это должно оплачиваться государствами из бюджетов. Как раз потому что настолько повсеместно используется.
> Деньги за стандарты - маразм. По идее это должно оплачиваться государствами из
> бюджетов. Как раз потому что настолько повсеместно используется.Ну предложи Росии оплатить все стандарты ISO :) "для открытия доступа". Должны же :)
Я согласен если их откроют за налоги уплаченные тобой :)Персонально тебе промышленный стандарт будет нужет только если ты собираешься что то производить и продавать с наклейкой Compliance with ISO-XXX - а значит бабло для этого должно быть в бизнес плане.
PS: Насколько я помню, ГОСТЫ в России - тоже только за деньги? Или уже переиграли обратно?
> Я согласен если их откроют за налоги уплаченные тобой :)Я тоже согласен. Это лучше чем какие-то фильтры петрика и роснанораспилы.
> Внезапно! Все в этом мире стоит денег.Не пробовали друга прикупить?
Легко. За банку (пару-тройку халявных банок пива + сухарики) в день можно закоришиться с любым студентом. С работающими немного дороже.Также друга можно продать. А подругу.... :)
(задумчиво) а ведь ты на самом деле очень одинокий и несчастный человек, ванюша.
> (задумчиво) а ведь ты на самом деле очень одинокий и несчастный человек, ванюша.Он просто еще не понял кое-чего. Правда, некоторым это понимание очень дорого обходится.
> Легко. За банку (пару-тройку халявных банок пива + сухарики) в день можно
> закоришиться с любым студентом. С работающими немного дороже.В наших краях это называется собутыльник, а уж никак не друг. Если вы не видите разницы - искренне сочувствую.
> Также друга можно продать. А подругу.... :)Это не дружба, это взаимообман.
>> Также друга можно продать. А подругу…. :)
> Это не дружба, это взаимообман.не всегда. если все о подобных возможных действиях осведомлены — то нормальные торговые отношения. зачем сразу «обман»…
>>> Также друга можно продать. А подругу…. :)
>> Это не дружба, это взаимообман.
> не всегда. если все о подобных возможных действиях осведомлены — то нормальные
> торговые отношения. зачем сразу «обман»…(c иронией) Внезапно - основой всех отношений в этом мире являются товарно-денежные. В тех или иных вариациях. Опачки?
многих. но не всех. опачки.внезапно, основой всех отношений в этом мире является желание личного комфорта. а дальше рекомендую почитать Эрика Берна, он годный популяризатор в том числе.
> основой всех отношений в этом мире являются товарно-денежные.Циничная ложь. Такое можно думать только в том случае, если вам это реально выгодно.
Но даже в этом случае думать так - очень вредно для здоровья.
что вы трясетесь? уже через неделю все эти платные стандарты лежат в сети
Те, кто не могут заработать написанием компиляторов, зарабатывают написанием стандартов к ним :)
> Те, кто не могут заработать написанием компиляторов, зарабатывают написанием стандартов к ним :)А зарабатыванием написания стандартов на написание стандартов можно? :)
> А зарабатыванием написания стандартов на написание стандартов можно? :)Ищщо как!(С) Забыли уже как принимался OpenDocument?
https://www.varnish-cache.org/docs/trunk/phk/thetoolsweworkw...
> https://www.varnish-cache.org/docs/trunk/phk/thetoolsweworkw...
>Now, don't get me wrong: There are lot of ways to improve the C language that would make sense: Bitmaps, defined structure packing (think: communication protocol packets), big/little endian variables (data sharing), sensible handling of linked lists etc.Вот тут согласен с PHK на все 100. Битовые поля и структуры задолбали уже.
CHF 338,00
> CHF 338,00WTF 100500?
>> CHF 338,00
> WTF 100500?Полад Бюль-Бюль Оглы
>>> CHF 338,00
>> WTF 100500?
> Полад Бюль-Бюль ОглыНу он франки тоже принимает я считаю :)
Для тормозов - павлин цену дал на стандарт. А CHF - это вотЪ http://en.wikipedia.org/wiki/Swiss_franc
Как гром среди ясного неба 0_0
> интерфейс для проверки допустимых границ и диапазонов значенийКто-нить может подскать что это? Это значит что теперь есть штатный способ вычислить длинну массива?
>> интерфейс для проверки допустимых границ и диапазонов значений
> Кто-нить может подскать что это? Это значит что теперь есть штатный способ
> вычислить длинну массива?Нет. Смотрите Annex K в черновом варианте стандарта, на него есть ссылка в новости.
"This annex provides alternative library functions that promote safer, more secure programming. The alternative functions verify that output buffers are large enough for the intended result and return a failure indicator if they are not. Data is never written past the end of an array. All string results are null terminated."
Чтобы появился универсальный способ определения длины массива, нужно либо добавить в представление структурных типов информацию о границах, либо усилить систему типов и ввести проверки времени компиляции. Ни то, ни другое не позволит сохранить обратную совместимость с ABI и семантикой кода уже написанных программ.
В коде указано "unsigned int var". Внимание, вопрос: какое максимальное значение можно записать в var? Вопрос нетривиальный, т.к. при компиляции под 16-бит это будет 2 байта и соотв. 65536, под 32-бита - 4 байта и 4 млрд., и т.д.Пример:
unsigned int sum(unsigned int a,unsigned int b)
{
unsigned int c=a+b;
return c;
}Что если a+b превысят пределы "unsigned int"? Сейчас это делают через задницу.
Для статического массива: sizeof(массив)/sizeof(массив[0]). Для динамических никак.
>[оверквотинг удален]
> записать в var? Вопрос нетривиальный, т.к. при компиляции под 16-бит это
> будет 2 байта и соотв. 65536, под 32-бита - 4 байта
> и 4 млрд., и т.д.
> Пример:
> unsigned int sum(unsigned int a,unsigned int b)
> {
> unsigned int c=a+b;
> return c;
> }
> Что если a+b превысят пределы "unsigned int"? Сейчас это делают через задницу.
#include <sys/types.h>
u_int64_t sum(u_int32_t a, u_int32_t b){
u_int64_t c = a + b;
return c;
}
ЧЯДНТ?
> #include <sys/types.h>
> u_int64_t sum(u_int32_t a, u_int32_t b){
> u_int64_t c = a + b;
> return c;
> }
> ЧЯДНТ?А теперь все то же самое, но для a и b int64_t
>> #include <sys/types.h>
>> u_int64_t sum(u_int32_t a, u_int32_t b){
>> u_int64_t c = a + b;
>> return c;
>> }
>> ЧЯДНТ?
> А теперь все то же самое, но для a и b int64_t__int128 sum(int64_t a, int64_t b) {
return (a + b);
}
Хмм... У цикл суммирований, 200 элементов массива типа word. Следуя вашей логике финальный результат будет 200*2 = 400-битный. Круто берёте, есть более элегантные решения.
> Хмм... У цикл суммирований, 200 элементов массива типа word. Следуя вашей логике
> финальный результат будет 200*2 = 400-битный. Круто берёте, есть более элегантные
> решения.Это по Вашей логике типы суммируются :D
> Хмм... У цикл суммирований, 200 элементов массива типа word. Следуя вашей логике
> финальный результат будет 200*2 = 400-битный. Круто берёте, есть более элегантные
> решения.Странно. У меня результат суммирования двухсот элементов массива типа word при худшем раскладе укладывается в 24 разряда. И даже 256-ти элементов тоже уложится. Безо всяких "элегантных" решений.
Вы всё сделали правильно, указав тип данных строго определённого размера. К сожалению, не все поступают так как вы.Но для напр. double проблема остаётся. Также она остаётся для сложных типов данных (классов напр.) по единообразию с элементарными типами. Предположим у нас есть класс, хранящий значение даты, или структура, хранящая позицию на экране (на экране, а не за его пределами), и т.д.
Я уже С/С++ не занимаюсь, так что не могу сказать как далеко они зашли и как именно это реализовали.
Оппонируя сам себе: с другой стороны лишив проблему переполнения вы лишили свой код переносимости. А ведь именно это сильная сторона ЯВУ.
> Внимание, вопрос: какое максимальное значение можно записать в var?Откройте для себя limits.h и UINT_MAX, а также http://c-faq.com/misc/intovf.html
> Что если a+b превысят пределы "unsigned int"?
А что будет, если вы попытаетесь записать на диск больше данных, чем он может вместить? Вы таким вопросом не задавались? Ответ: ничего хорошего не будет, а нюансы зависят от конкретной архитектуры.
> Откройте для себя limits.h и UINT_MAX, а также http://c-faq.com/misc/intovf.htmlУже давно об этом знаю, нам это давали ещё на 1-ом курсе, но это не решение проблемы. Повторю: double вы так не проверите, т.к. он с плавающей точкой и точность зависит от размера числа. Проблема единообразия также не решена. А для union и вовсе обломаетесь...
>> Что если a+b превысят пределы "unsigned int"?
> А что будет, если вы попытаетесь записать на диск больше данных, чем
> он может вместить? Вы таким вопросом не задавались? Ответ: ничего хорошего
> не будет, а нюансы зависят от конкретной архитектуры.Хмм... Если это ваш ответ как программиста, я бы не хотел пользоваться вашими программами. Задача программы проверить и предупредить. А то видеть код типа:
dc=BeginPaint(..);
brush=CreateBrush(..);
SetBrush(dc,brush);Просто противно! Кто сказал что dc и brush определены после вызова функций? Никто! А потом удивляются глючности ПО и переносят эту глючность на ОС.
> Никто! А потом удивляются глючности ПО и переносят эту глючность на ОС.А для виндузятников нормально так писать. У них бескультурье - по дефолту просто. Вот например написанный вами код уже заведомо не кроссплатформенный. Ну и какая культура программирования при этом может быть? Ежу понятно какая - такие господа и порядком байтов не парятся, как и размерами переменных. Наивно думая что в мире есть только винда и i386. А потом мс вдруг бабах и заявляет - чуваки, а вот х64 и ARM. Хавайте! А чуваки то и обнаруживают что их г-нокод надо переписывать нафиг.
Может приведёте пример кросс-платформеного кода с аналогичным функционалом с непосредтвенным вызовом API ОС?Переписывать для ARM под Win как раз ничего не надо. В этом "фишка".
> Может приведёте пример кросс-платформеного кода с аналогичным функционалом с непосредтвенным
> вызовом API ОС?WinAPI — это не непосредственный API ОС. Между ним и ОС есть посредник — NativeAPI. Рискнёте привести пример кроссплатформенного кода с аналогичным функционалом с непосредственным использованием нестандартизованного и недокументированного NativeAPI?
> вызовом API ОС?Если юзать какую-то либу прослойки типа Qt/GTK+/SDL/WxWidgets (в зависимости от хотелок) это даже реально. Примерно так кроссплатофрменные программы и пишут ;)
> Переписывать для ARM под Win как раз ничего не надо. В этом "фишка".
Ну да, щаз. Особенно хорошо было заметно как abbyy "портировало" свой г-нокод на "якобы 64 бита". У них там настолько эпический шит что им вообще не светит его спортировать нормально. И так у каждого первого виндузятника, который не может себе вообразить что у указателя размер не обязательно 4, например.
> А что будет, если вы попытаетесь записать на диск больше данных, чем
> он может вместить? Вы таким вопросом не задавались? Ответ: ничего хорошего
> не будет, а нюансы зависят от конкретной архитектуры.Программа проверит наличие свободного места на диске и выдаст ошибку. Если это не сделает программа, это сделает Windows, а програма получит ошибку в коде возврата. Только вот многие программы (см.меня же выше) игнорят коды возвратов, считая что они исполняются на машинах Тьюринга и отказов с ними не случается. Сравни: "я никогда не делаю резервных копий т.к. у меня ничего не теряется".
> Повторю: double вы так не проверите, т.к. он с плавающей точкой и точность зависит от размера числа.Сначала вам был нужен unsigned int, теперь уже double. Вы уж разберитесь сами для начала, что вам нужно, а потом спрашивайте. Кстати, для double есть float.h и DBL_MAX.
> Задача программы проверить и предупредить.
Это задача программиста, а не программы. А задача программы - делать то, что ждёт от неё пользователь. Вам показали, как программист может в данном случае проверить и предупредить. Если он этого не делает, то это не проблема языка программирования.
> Кто сказал что dc и brush определены после вызова функций?
Ещё раз: криворукие программисты - не проблема языка программирования. Сдуру можно и Питон сломать ;)
uint использовался как пример для проблемы проверки допустимых границ и диапазонов значений.double - тип с плавающей точкой и после сложения двух double возможна ситуация резкой потери точности. К тому же double может хранить числа вида 5е20. DBL_MAX - максимальное целое число, для хранения целых чисел использование double не рекомендуется.
Именно это и отличает школьника от школоты. Школота знает, школьник знает и понимает.
>> Задача программы проверить и предупредить.
> Это задача программиста, а не программы.Гы. Так и представляю как после неудавшегося выделения памяти из шкафа выпрыгивает голый небритый программист и "предупреждает".
> К тому же double может хранить числа вида 5е20.Равно как и вида 500000000000000000000.0 ;)
> DBL_MAX - максимальное целое число,
Учите матчасть:
#define DBL_MAX 1.7976931348623157e+308
> Именно это и отличает школьника от школоты. Школота знает, школьник знает и понимает.
Судя по вашим познаниям, вы уже не школьник, а студент приблизительно 2-го курса. Желаю вам успешно доучиться и стать хорошим программистом. Всего наилучшего :)
> Учите матчасть:
> #define DBL_MAX 1.7976931348623157e+308Сам бы подучился, 16 знаков после запятой на 10 в 308 (!!!) степени по твоему стало дробным числом. Степени изучают в 6 (?) классе - вот он ваш уровень.
И число 500000000000000000000 вы в double не запихнёте, оно будет преобразовано к 5е20 в момент записи.Хочешь, не хочешь, С/С++ опирается на проц, и даже операции i++ введены для точного отражения "inc al". Конкретно double хранятся и вычисляются в регистрах FPU/MMX (это одни и те же регистры). Раньше MMX был 8-байтным, сейчас он уже 16-байтный. Не факт что размер double не изменился. Но это к начальному вопросу, с которого началось наше с вами общения учителя и школоты.
Нет, зря я с вами распрощался. С вами весело ;)> 16 знаков после запятой на 10 в 308 (!!!) степени по твоему стало дробным числом.
Вы не поверите, но число с 16 знаками после запятой - всегда дробное число! ;)
> Степени изучают в 6 (?) классе
Десятичные дроби изучают в начальной школе, если не ошибаюсь? ;)
> И число 500000000000000000000 вы в double не запихнёте, оно будет преобразовано к 5е20 в момент записи.
Да-да. Именно в момент записи! :D
>Хочешь, не хочешь, С/С++ опирается на проц, и даже операции i++ введены для точного отражения "inc al". Конкретно double хранятся и вычисляются в регистрах FPU/MMX (это одни и те же регистры). Раньше MMX был 8-байтным, сейчас он уже 16-байтный. Не факт что размер double не изменился. Но это к начальному вопросу, с которого началось наше с вами общения учителя и школоты.
Кто бы мог подумать!.. :D
>> 16 знаков после запятой на 10 в 308 (!!!) степени по твоему стало дробным числом.
> Вы не поверите, но число с 16 знаками после запятой - всегда
> дробное число! ;)...
>> И число 500000000000000000000 вы в double не запихнёте, оно будет преобразовано к 5е20 в момент записи.
> Да-да. Именно в момент записи! :DИменно в момент записи.
mem64 dq 500000000000000000000
movq mm0,[mem64]
; mm0 = 5e20
Ну да, так оно и происходит! В mem64 оно лежит в виде 500000000000000000000, а в mm0 оно - именно в момент записи! - преобразуется в 5e20! :))))))))))Совет: с 10-ичными дробями разберитесь :)
> Ну да, так оно и происходит! В mem64 оно лежит в виде 500000000000000000000, а в mm0 оно - именно в момент записи! - преобразуется в 5e20! :))))))))))
Python 3.2.2 (default, Nov 21 2011, 16:50:59)
[GCC 4.6.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> x = 500000000000000000000
>>> x500000000000000000000
>>> type(x)<class 'int'>
>>> import math
>>> math.log(x,2)68.7604899926346
Не поместится 500000000000000000000 как целое число в 64 бита. Нужно хотя бы 69.
это же ванюша, ему некогда разбираться. он и так-то ерунду писать не успевает, куда уж тут… зато он пишет ерунду на абсолютно любую тему. стабильность.
> стабильность.А, так вот что он под стабильностью винды имел в виду...
МОМЕНТ ИСТИНЫ!> Именно в момент записи.
> mem64 dq 500000000000000000000
> movq mm0,[mem64]
> ; mm0 = 5e20Вы знаете что у современных программеров из России репутация ниже бангалорских индо-быдло кодеров? Вон в верху ответ - почему.
> Вы знаете что у современных программеров из России репутация ниже бангалорских индо-быдло
> кодеров? Вон в верху ответ - почему.Благодаря таким вот иванам-дуракам.
>> Вы знаете что у современных программеров из России репутация ниже бангалорских индо-быдло
>> кодеров? Вон в верху ответ - почему.
> Благодаря таким вот иванам-дуракам.Требую продолжения сказки!!!
> В коде указано "unsigned int var". Внимание, вопрос: какое максимальное значение можно
> записать в var?Ответ: так пишут только му...ки и долб...бы. Нормальные люди пишут примерно так: uint32_t something. И при этом заведомо знают сколько вешать в граммах.
Мир перешёл на 64-битное ПО одной макродирективой и перекомпиляцией кода, а у вы нет.
> Мир перешёл на 64-битное ПО одной макродирективой и перекомпиляцией кода, а у вы нет.Особенно заметно как переходило abbyy. Они на хабре писали. Там такой типичный для виндузятников лютобешеный здец, от господ которые привыкли к win32@i386 и ничего иного себе приницпиально не мыслили. Они так и не смогли честно все пересобрать - сделали турбокостыли для вызова из 64-бит кода 32-битного.
А в указанном выше случае, uint32_t указан как раз в случае когда я хочу быть четко уверен что диапазон допустимых значений именно такой как мне был нужен и переменная имеет заведомо известный мне размер, что важно например при передаче по сети или сохранении на диск ("serialization/deserialization"). В случае int можно отхватить кучу багов если его размер не совпадет с желаемым, а то и скушать integer overflow vulnerability, чреватый, извините, возможонстью ремотного эксплойтирования, если это например протокольный код какой-то. Ну и кроссплатформенно слить его на диск, при том что оно может быть разного размера - уже головняк сплошной.
прикололо
??=define arraycheck(a, b) a??(b??) ??!??! b??(a??)
> прикололо
> ??=define arraycheck(a, b) a??(b??) ??!??! b??(a??)#define TRUE FALSE // have a nice debugging session, bitches!
>> TRUE
>> FALSEгангнам-индус-стайл
Вижу, что большая часть вышеописанных изменений относится не к языку, а к стандартным библиотекам.
Где замыкания и функции как объекты первого класса?!
> Где замыканияВ функциональный языках, где им и место.
> и функции как объекты первого класса?!
typedef int (*void_function_t)();
С чего это замыканиям место в функциональных языках? Функции как объекты первого класса точно так же относятся к функциональным языкам, как и замыкания, но они, тем не менее, в C есть.Ваш аргумент разбит, давайте новый.
> но они, тем не менее, в C есть.нет. есть очень кривой полурабочий эмулятор с костылеуказателями. но ты, похоже, настолько «не в теме», что даже не знаешь, что такое first class citizen.
> «не в теме», что даже не знаешь, что такое first class citizen.Это американец в гондурасе, да?
Дааа, поглядел описание стандарта... Отзывы. Печаль, особенно много вопросов вызывает внедрение нитей, причем с API несовместимым posix.В списках рассылки FreeBSD уже эпичный срач начался: http://lists.freebsd.org/pipermail/freebsd-arch/2011-Decembe...
"I have never fully understood what goal these sequential obesity-binges
from ISO-C serve.Structure packing ?
Nahh, nobody uses that.
Big/Little Endian API ?
Naah, nobody moves binary data between computers.
Ohhh, but I know: Lets make a rival to the POSIX threads, we can do it
much better and slightly incompatible, big market there I'm sure.What ?
A "assert mutex is held" facility ?
Why would you want that ? Just write perfect code to begin with!
Bang! Bang! Bang! &c &c..."
И ведь действительно, кто писал реализацию протоколов, знает сколько гемора с упаковкой структур, битовыми полями и т. д. Лучше бы они наконец эти дела поправили.
Для себя из всего стандарта пока только анонимные структуры и объединения отметил.
> Для себя из всего стандарта пока только анонимные структуры и объединения отметил.что, в принципе, gcc и так умеет столетвобед.
Кто-нибудь может объяснить?
Зачем удалили функцию gets()?
> Кто-нибудь может объяснить?
> Зачем удалили функцию gets()?я могу. потому что это верный источник buffer overflow.