Цитата: Алексей Гринь от октября 17, 2009, 13:43
Стоило мне упомянуть евреев
Цитата: myst от сентября 29, 2009, 15:20Цитата: Алексей Гринь от сентября 29, 2009, 15:11Ну ничего, скоро наешься убунты, ка́каться начнёшь. ;)
Теперь всё работает, в том числе Компиз :) Писаю от счастья.
Цитата: Алексей Гринь от октября 17, 2009, 14:02Не прошло и месяца. ;D
Как и сам линупс :)
ЦитироватьИзвините Гость, Вы забанены и не можете оставлять сообщения на форуме!
Создание нового ника после бана
Цитата: myst от ноября 6, 2009, 19:50Почитал я их вики, сблеванул. Столько орфографических ошибок я видел последний раз в школе.
Меня Arch прикалывает, но зачем они сэкономили на документации?! :wall:
Цитата: Алексей Гринь от ноября 6, 2009, 20:47Нормально там всё.
Юзать операционку красноглазых школьников не хочется :)
Цитата: Алексей Гринь от ноября 8, 2009, 06:10доставило.
Будь рядом Страус-труп, с удовольствием бы дал лопатой по лицу.
Цитата: Алексей Гринь от ноября 8, 2009, 06:10:??? Он тебе или ты ему?
Будь рядом Страус-труп, с удовольствием бы дал лопатой по лицу.
Цитата: myst от ноября 8, 2009, 16:30:o :green:Цитата: Алексей Гринь от ноября 8, 2009, 06:10:??? Он тебе или ты ему?
Будь рядом Страус-труп, с удовольствием бы дал лопатой по лицу.
Цитата: Алексей Гринь от ноября 8, 2009, 05:56Компилятор какбэ не телепат.
А в main.cpp есть вот так:
MyCoolClass<int>* l = new MyCoolClass<int>();
l->add(10);
Так это чучело мне пишет: undefined reference to `MyCoolClass<int>::MyCoolClass()', при том что на add не жалуется,
т.е. какбэ сам фаел подключён и линкуется (ибо он в том же файле, что и конструктор).
Цитата: myst:??? Он тебе или ты ему? | :E: |
Цитата: myst от ноября 8, 2009, 16:33Вы не ответили на вопрос:
Компилятор какбэ не телепат.
Цитата: Алексей Гринь от ноября 8, 2009, 05:56;)
Внимание, вопрос: кто имбецил?
Цитата: Karakurt от ноября 8, 2009, 18:06(http://upload.wikimedia.org/wikipedia/ru/thumb/8/82/%D0%AD%D0%BB%D1%8C%D0%B4%D0%B0%D1%80_%D0%96%D0%B8%D0%BD%D0%B4%D0%B0%D1%80%D1%91%D0%B2.jpg/180px-%D0%AD%D0%BB%D1%8C%D0%B4%D0%B0%D1%80_%D0%96%D0%B8%D0%BD%D0%B4%D0%B0%D1%80%D1%91%D0%B2.jpg): Не хотелось бы никого обижать...Цитата: myst от ноября 8, 2009, 16:33Вы не ответили на вопрос:
Компилятор какбэ не телепат.Цитата: Алексей Гринь от ноября 8, 2009, 05:56;)
Внимание, вопрос: кто имбецил?
Цитата: Triton от ноября 8, 2009, 07:53В реализации каждого метода нужно писать каждый раз template <class T>, как имбецил. Мегакрутой c++ иначе не воткнёт (имбецил же).
А почему у вас тела методов шаблона в cpp вынесены, они ж как бы в h всю жизнь были.
Цитата: myst от ноября 8, 2009, 16:33Чо? Компилятор всё видит, ибо compile-time ошибок не выдаёт. Вопит линкер, который в том же файле видит метод add. Если пошутить, он внезапно перестаёт видеть add. Я пытаюсь понять, что я сделал не так... За ходом афазической мысли олигофренов очень сложно следить, но я пытаюсь осмыслить как-то, люблю психиатрию.
Компилятор какбэ не телепат.
Цитата: Алексей Гринь от ноября 9, 2009, 01:20Не удосужился прочитать учебник. Марш читать Страуса! (Поторопись, он уже идёт в сарай за лопатой... ;))
Я пытаюсь понять, что я сделал не так...
Цитата: myst от ноября 9, 2009, 02:04Не-а, я делаю всё правильно. Имбецил тут, похоже, Code::Blocks. Потому что если в main.cpp вместо
Не удосужился прочитать учебник. Марш читать Страуса! (Поторопись, он уже идёт в сарай за лопатой... ;))
Цитата: Triton от ноября 9, 2009, 08:37Можно, но надо помнить: первое, выхлоп компилятора — машинный код, никаких шаблонов в объектных файлах уже нет; второе, компилятор создаёт только экземпляры шаблона, необходимые в данной единице компиляции. Если нужен экземпляр шаблона для другой единицы, надо сказать об этом компилятору. Так как это зело негибко, это почти не практикуется, и шаблоны хранят в заголовочниках.
Шаблоны надо писать именно в хэдерах, потому что они по своей сути - макросы, подставляемые во время компиляции. Вынести их cpp не представляется возможным.
Цитата: Triton от ноября 9, 2009, 08:37Не, когда используешь некий инструмент, 90% времени идёт руководствование ЗДРАВЫМ СМЫСЛОМ (некие общепринятые стандарты, интуитивность интерфейсов и т. д.), когда же в 10% ЗДРАВЫЙ СМЫСЛ отсутствует, нужно читать маны. Когда же у какого-то инструмента всё ровно наоборот — костылей больше, чем здравого смысла — то это уже херня на постном масле, а не «инструмент».
Гринь, извините, но прежде чем называть кого-то имбецилом, не помешает прочитать инструкцию на пользуемый инструмент.
Цитата: Triton от ноября 9, 2009, 08:37Есть куча языков, в которых почему-то шаблоны (называемые чаще макросами) могут вполне нормально находиться в файле реализации.
Шаблоны надо писать именно в хэдерах, потому что они по своей сути - макросы, подставляемые во время компиляции
Цитата: Triton от ноября 9, 2009, 08:37Какой костыль? Хедеры это вообще-то элемент хорошей, годной архитектуры отделения интерфейса от реализации. Почему это круто — см. гугл.
только костыль в виде хэдеров
Цитата: Алексей Гринь от ноября 11, 2009, 12:49Вот тебе статья на злобу дня (http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=52&rll=1).
Они идиоты: осилили раздельную компиляцию *.cpp-файлов в *.o файлы с последующей общей линковкой, но сделать что-то подобное с шаблонами не осилили, а ведь могли сделать формат *.tem, который бы тоже делался в некий объектный метакод, а потом линкером всё бы скреплялось. Ан нет, такого нету.
Цитата: Алексей Гринь от ноября 11, 2009, 12:49Годной?! :o
Хедеры это вообще-то элемент хорошей, годной архитектуры отделения интерфейса от реализации. Почему это круто — см. гугл.
Цитата: Алексей Гринь от ноября 11, 2009, 12:49О да! Си — это предел совершенства, когда нужно загубить несколько тысяч человеко-лет. (http://www.kolobok.us/smiles/madhouse/sarcastic.gif)
Поэтому я снова возвращаюсь к сяхе, попытка полюбить цэпэпэ не удалась.
Цитата: myst от ноября 11, 2009, 13:33Что-такое про него слышал, но его покупать ещё надо :) И не знаю, насколько он совестим с gcc, а люблю расширения gcc.
А вот тебе прямая ссылка на компилер, который умеет раздельную компиляцию шаблонов: http://www.comeaucomputing.com/
Цитата: myst от ноября 11, 2009, 13:38Неправда. Система исключений делается одним человеком за пару часов, система наследования, виртуальные методы и даже приведение типов с рантайм-проверкой при умелом подходе делаются одним человеком за рабочий день.
О да! Си — это предел совершенства, когда нужно загубить несколько тысяч человеко-лет.
Цитата: myst от ноября 11, 2009, 13:34Э-э. Я говорю, что отделение интерфейса от реализации — это круто. Я не говорю, что то, как это реализовано в Си, мегакруто. В цэпопе там вообще всё в кучу, ещё хуже. Тут надо вдуматься в значение слова "хедер": заголовок.
Годной?! :o
Механическая вставка файла в файл препроцессором — это самый наикостыльнейший костыль. Как и препроцессор в целом...
Цитата: myst от ноября 11, 2009, 13:34Так то же самое и делает СиПлюс. Та же механическая вставка, только типизированная (с проверкой типов аргументов макросов). Я же не в абсолютных величинах сравниваю (ясно, что в Си макросы кривые по сравнению с какой-нибудь Немерлей), а конкретно СиПлюс с СиКавай. И СиПлюс посасывает в таком сравнении
Механическая вставка файла в файл препроцессором — это самый наикостыльнейший костыль. Как и препроцессор в целом...
Цитата: Алексей Гринь от ноября 11, 2009, 13:54У меня нет стандарта. По-моему, жадные стандартизаторы его зажали.
И, кстати, что насчёт компиляции шаблонов в стандарте? Это как-то оговаривается, или implementation-dependent?
Цитата: Алексей Гринь от ноября 11, 2009, 13:54В том, что людям надо программный продукт делать, а не обработку исключений, наследование, виртуальные методы, ..., ну ты понял. :)
в чём проблема?
Цитироватьв чём проблема?О да. Эти люди лучше потратят ВРЕМЯ и ДЕНЬГИ на обучение работников цпп-галлюцинациям (не удивлюсь, если к тому же цпп-программист стоит дороже, чем с-онли-программист), нежели они потратят ОДИН день и ОДНОГО адекватного человека на написание простого фреймворка, который реализует практически ВСЕ свистелки и перделки, за которые на цпп покупаются.
В том, что людям надо программный продукт делать, а не обработку исключений, наследование, виртуальные методы, ..., ну ты понял.
Цитата: myst от ноября 11, 2009, 13:34+100.Цитата: Алексей Гринь от ноября 11, 2009, 12:49Годной?! :o
Хедеры это вообще-то элемент хорошей, годной архитектуры отделения интерфейса от реализации. Почему это круто — см. гугл.
Механическая вставка файла в файл препроцессором — это самый наикостыльнейший костыль. Как и препроцессор в целом...
Цитата: Алексей Гринь от ноября 11, 2009, 12:49
Шаблоны это самые обычные допотопные сишные макросы, только типизированные — и всё.
Цитата: Алексей Гринь от ноября 11, 2009, 12:49Взаимоисключающие параграфы детектед.
Хедеры это вообще-то элемент хорошей, годной архитектуры отделения интерфейса от реализации.
Цитата: Алексей Гринь отОни это кто: Кернинган и Ричи, Страустрап, стандартизаторы ISO, разработчики компиляторов?.. К кому обращено ваше праведное негодование?
Они идиоты: осилили раздельную компиляцию *.cpp-файлов в *.o файлы с последующей общей линковкой, но сделать что-то подобное с шаблонами не осилили, а ведь могли сделать формат *.tem, который бы тоже делался в некий объектный метакод, а потом линкером всё бы скреплялось. Ан нет, такого нету.
Цитата: Triton от ноября 11, 2009, 16:06Человек, не отличающий понятия «хедер» от понятия «макрос», детектед.ЦитироватьШаблоны это самые обычные допотопные сишные макросы, только типизированные — и всё.Цитата: Алексей Гринь от Сегодня в 13:49ЦитироватьХедеры это вообще-то элемент хорошей, годной архитектуры отделения интерфейса от реализации.Взаимоисключающие параграфы детектед.
Цитата: Triton от ноября 11, 2009, 16:06Если реализация шаблонов никак не оговорена в стандартах, то разработчики компиляторов. Comeau же умеет. А Кернинган и Ричи тут вообще причём?
Они это кто: Кернинган и Ричи, Страустрап, стандартизаторы ISO, разработчики компиляторов?.. К кому обращено ваше праведное негодование?
Цитата: Triton от ноября 11, 2009, 16:06Да-а, что самое забавное, ДВУХпроходные компиляторы зачастую компилируют быстрее, чем ОДНОпроходные сишные.
Глядя, например, на приложения на QT, компилирующиеся по 10-15 минут, хочется сделать с разработчиками библиотеки что-нибудь радикальное.
Цитата: Triton от ноября 11, 2009, 16:06А кто вас заставляет производить полную перекомпиляцию?
Глядя, например, на приложения на QT, компилирующиеся по 10-15 минут
Цитата: Алексей Гринь от ноября 11, 2009, 17:32Человек, не знающий, чем занимается команда cpp, детектед.
Человек, не отличающий понятия «хедер» от понятия «макрос», детектед.
Цитата: Алексей Гринь от ноября 11, 2009, 17:32Там и частичной хватает выши крыши, чтобы начать оглядываться в поисках топора.
А кто вас заставляет производить полную перекомпиляцию?
Цитата: Алексей Гринь от ноября 11, 2009, 17:32Хм, компиляторы чего?
ДВУХпроходные компиляторы
Цитата: Алексей Гринь от ноября 11, 2009, 17:52Угу, Си и Си++ прямо таки замечательные языки: сначала программист пишет свою реализацию ООП, свой тип данных для строк, свой механизм управления памятью, свой RTTI... а потом берёт другой язык, и приступает таки к решению поставленной задачи.
Ещё вчера я вон, набыдлокодил макросы для быстрого протипирования классов (а то много ручной работы выходит).
Цитата: Алексей Гринь от ноября 11, 2009, 17:32У тебя и пруфы есть? :eat:
Да-а, что самое забавное, ДВУХпроходные компиляторы зачастую компилируют быстрее, чем ОДНОпроходные сишные.
Цитата: Алексей Гринь от ноября 11, 2009, 17:52As you wish. ;)
О да, называйте меня садомазером :D
Цитата: arseniiv от ноября 11, 2009, 19:18А?
Кстати, насколько быстро работает преобразователь текста вместе с компилятором?
Цитата: arseniiv от ноября 11, 2009, 19:18Object Pascal... увольте.) Для прикладных задач всегда Java, Ruby, Tcl...
Я вам и говорю: Delphi, переделанный синтаксисом под Си! Мне бы такой язык жутко понравился. ;D Нет-нет, не пинайте меня.
Цитата: arseniiv от ноября 11, 2009, 19:18А можно сделать свою ОС... Да куда там - свою аппаратную платформу! Вот только зачем? :eat:
А можно ещё сделать другой язык.
Цитата: arseniiv от ноября 11, 2009, 19:18Таки достаточно легко.
Свой собственный компилятор всё же не очень легко написать.
Цитата: arseniiv от ноября 11, 2009, 21:03Это компилятор и есть, трансляция не обязательно в машинный код делается.
Ну, синтаксис вида си преобразуется к другому желаемому и тем компилятором обраба...
Цитата: myst от ноября 11, 2009, 21:09Студенты такой компилер на 3-м курсе пишут :yes:Цитата: arseniiv от ноября 11, 2009, 21:03Это компилятор и есть, трансляция не обязательно в машинный код делается.
Ну, синтаксис вида си преобразуется к другому желаемому и тем компилятором обраба...
Цитата: Triton от ноября 11, 2009, 18:34А другие отчего-то или медленные, или памяти жрут немерено.
Угу, Си и Си++ прямо таки замечательные языки: сначала программист пишет свою реализацию ООП, свой тип данных для строк, свой механизм управления памятью, свой RTTI... а потом берёт другой язык, и приступает таки к решению поставленной задачи.
Цитата: myst от ноября 11, 2009, 21:13ЛОР почитываем, в курсе. goto в списке «фич» веселит
Пока Гринь бороздит просторы препроцессора C, старики сражаются со змием окаянным, C++. Подробности. Реинкарнация Limbo, не иначе
Цитата: Алексей Гринь от ноября 12, 2009, 23:15Медленные... А куда торопиться-то? ;) Посмотрите на приложения, которые у вас обычно запущены в системе — 99.9% процентов времени они проводят в ожидании порции данных из потока или сообщения от оконной подсистемы. Ну будут они на обработку данных тратить пусть даже в 10, в 20 раз больше времени — никто не заметит.
А другие отчего-то или медленные, или памяти жрут немерено.
Цитата: Алексей Гринь от ноября 12, 2009, 23:15Заглянул в википедию:
GNU костылит Vala, со стороны годный язычок, но не пробовал ещё. Из минусов — привязка к GTK, которая выльется в 8 МБ (ЕМНИП) балласта под Windows.
Цитировать"Язык... на основе библиотеки" и "транслируется в программу на языке C" - этапять, как говорится.
Vala — язык программирования, предназначенный для прикладного и системного программирования на основе библиотек GLib Object System (GObject) рабочей среды GNOME/GTK+. Он был разработан Йюргом Биллетером и Раффаэле Сандрини.
Vala по своему синтаксису очень похож на C# и полностью реализует объектно-ориентированный подход. Программа на языке Vala транслируется в программу на языке C, которая в свою очередь компилируется в бинарный код целевой платформы со стандартными библиотеками C и GTK+ и выполняется со скоростью нативного приложения C.
Цитата: Triton от ноября 13, 2009, 00:09Чисто российский менталитет. Сожрём то, что дадут, и не подавимся. Мне есть куда торопиться, да и не только мне: погуглите «Windows тормозит».
Медленные... А куда торопиться-то? ;)
Цитата: Triton от ноября 13, 2009, 00:09Мне не очевидна :) Расскажите подробнее.
Бредовость идеи писать полноценное веб-приложение на Си очевидна всем
Цитата: Triton от ноября 13, 2009, 00:09Я не телепат, ваших суеверий не знаю. Что не так?
"Язык... на основе библиотеки" и "транслируется в программу на языке C" - этапять, как говорится.
Цитата: Triton от ноября 13, 2009, 00:09Не, они тормозят. Валу специально делают для написания gtk-софта, работающего со скоростью си. Обычно его и пишут на си, но на си получается слишком много ручной писанины. А тут ещё автоматическая работа с памятью, но без сборщика мусора, а на основе подсчёта ссылок + выхода/невыхода из области видимости. Прямо как то, о чём я мечтал :)
Или разработчикам просто хочется изобрести свой собственный С#, Java или Object Pascal? :what:
Цитата: Triton от ноября 13, 2009, 00:09Скорость, родное понимание GTK, отсутствие рукоблудия.
Какие проблемы, стоящие перед другими языками, оно решает?
Цитата: Triton от ноября 13, 2009, 00:09Кабы Си обладал совсем уж низкоуровневыми возможностями. ;)
И то в своей нише Си хорош только там, где нужно уж совсем низкоуровневые и системные вещи писать
Цитата: Алексей Гринь от ноября 13, 2009, 00:39Object Pascal тормозит?
Не, они тормозят.
Цитата: myst от ноября 11, 2009, 20:51Вижу, пруфов таки нет. (http://kolobok.us/smiles/personal/beach.gif)Цитата: Алексей Гринь от ноября 11, 2009, 17:32У тебя и пруфы есть? :eat:
Да-а, что самое забавное, ДВУХпроходные компиляторы зачастую компилируют быстрее, чем ОДНОпроходные сишные.
Цитата: myst от ноября 13, 2009, 00:55А зачем тогда forward declarations?
Только сейчас заметил. Это сишные компиляторы-то однопроходные? :o :o :o
Цитироватьstruct A
{
struct B b;
};
struct B
{
struct A a;
};
Цитироватьerror: field 'b' has incomplete type
Цитата: Алексей Гринь от ноября 13, 2009, 01:29:uzhos:Цитироватьstruct A
{
struct B b;
};
struct B
{
struct A a;
};
Цитата: Алексей Гринь от ноября 13, 2009, 00:39Тормознутость программы в наименьшей степени зависит от языка реализации. Если, скажем, в алгоритме стоит квадратичная зависимость времени работы или требуемой памяти от объема входных данных, то какой там будет дополнительно множитель - 1 или 20 - уже абсолютно без разницы.
Чисто российский менталитет. Сожрём то, что дадут, и не подавимся. Мне есть куда торопиться, да и не только мне: погуглите «Windows тормозит».
Цитата: Алексей Гринь от ноября 13, 2009, 00:39Не так давно вы хвалили Си и порывались писать собственный ООП слой на макросах (изобретать синтаксис). В Си очень и очень маленький словарь стандартной библиотеки (а в freestanding варианте - и вовсе почти весь отсутствует).
"Язык... на основе библиотеки" — о да, язык с синтаксисом, но без словаря — это мегакруто! :)
Цитата: Алексей Гринь от ноября 13, 2009, 00:39Знаете, сколько уже таких языков... Начиная от академически строго Cyclone, через простую как пень Java и "философский" D и заканчивая десятком поделок на основе dotNET.
Не, они тормозят. Валу специально делают для написания gtk-софта, работающего со скоростью си. Обычно его и пишут на си, но на си получается слишком много ручной писанины. А тут ещё автоматическая работа с памятью, но без сборщика мусора, а на основе подсчёта ссылок + выхода/невыхода из области видимости. Прямо как то, о чём я мечтал :)
Цитата: myst от ноября 13, 2009, 00:51А каких именно не хватает, по вашему мнению?Цитата: Triton от ноября 13, 2009, 00:09Кабы Си обладал совсем уж низкоуровневыми возможностями. ;)
И то в своей нише Си хорош только там, где нужно уж совсем низкоуровневые и системные вещи писать
Цитата: Алексей Гринь от ноября 13, 2009, 01:24forward declarations присутствуют by design. Если вы имеете ввиду многопроходный анализ семантики программы, то в Си++ этого добра выше крыши, благодаря неоднозначности грамматики. Даже имея перед собой полный набор классов и шаблонов, компилятор зачастую просто вынужден гадать на кофейной гуще, что за конструкция перед ним. И жутко тормозить.Цитата: myst от ноября 13, 2009, 00:55А зачем тогда forward declarations?
Только сейчас заметил. Это сишные компиляторы-то однопроходные? :o :o :o
Цитата: Алексей Гринь от ноября 13, 2009, 01:24Это ещё не значит, что они однопроходные. Назови конкретные компиляторы.
А зачем тогда forward declarations?
...
Цитата: Triton от ноября 13, 2009, 10:22http://lingvoforum.net/index.php/topic,20180.msg402247.html#msg402247
А каких именно не хватает, по вашему мнению?
Цитата: Triton от ноября 13, 2009, 12:51Проверка задним числом — постфактум — в таких делах не уместна. Проверяйте заранее пределы. Средствами языка Си возможно всё.
и возможности средствами языка отслеживать арифметическое переполнение
Цитата: Triton от ноября 13, 2009, 09:40?
Вы сами-то поняли, что написали?
Цитата: Triton от ноября 13, 2009, 10:13Ой лол. Взаимоисключающим параграфом было бы, если бы библиотеки у Си не было вообще. А она есть.
Не так давно вы хвалили Си и порывались писать собственный ООП слой на макросах (изобретать синтаксис). В Си очень и очень маленький словарь стандартной библиотеки (а в freestanding варианте - и вовсе почти весь отсутствует).
В общем, опять взаимоисключающие параграфы.
Цитата: Triton от ноября 13, 2009, 10:13Тем, что это рукоблудие. Vala — родной для gtk язык без оверхеда и без синтаксиса больного дисграфией имбецила. Биндинги — костыли и говно.
Что мешает сделать gtk-биндинг для любого языка (собственно, они и есть для многих языков) и не изобретать велосипед?
Цитата: Алексей Гринь от ноября 13, 2009, 13:36Давайте тогда уж и обращение по нулевому указателю средствами ОС не отслеживать, и деление на ноль оставлять как есть, и игнорировать запись данных в невыделенную страницу памяти. Будте последовательны. Это же тоже проверки задним числом, а средствами языка Си возможно всё.Цитата: Triton от ноября 13, 2009, 12:51Проверка задним числом — постфактум — в таких делах не уместна. Проверяйте заранее пределы. Средствами языка Си возможно всё.
и возможности средствами языка отслеживать арифметическое переполнение
Цитата: Алексей Гринь от ноября 13, 2009, 13:36Значит не поняли...Цитата: Triton от ноября 13, 2009, 09:40?
Вы сами-то поняли, что написали?
Цитата: Алексей Гринь от ноября 13, 2009, 13:36Уровень аргументации вполне ясен, спасибо.
Тем, что это рукоблудие. Vala — родной для gtk язык без оверхеда и без синтаксиса больного дисграфией имбецила. Биндинги — костыли и говно.
Цитата: Triton от ноября 13, 2009, 13:56А вы поясните, если такой умный.
Значит не поняли...
Цитата: Triton от ноября 13, 2009, 13:56Ололо, ОС как раз и написана на Си, так что вы опять фейлите. Всё это реализовно как раз средствами языка Си :D
Давайте тогда уж и обращение по нулевому указателю средствами ОС не отслеживать, и деление на ноль оставлять как есть, и игнорировать запись данных в невыделенную страницу памяти. Будте последовательны. Это же тоже проверки задним числом, а средствами языка Си возможно всё.
Цитата: myst от ноября 13, 2009, 15:07С фигов ли? Отличай compile-time-проверку от run-time-проверки. Транслятор балуется с compile-time, а это НИКАК не проверка задним числом. Более того, код вообще не запустится, если что не так: проверки не будет ВООБЩЕ. Вот run-time — проверка задним числом, да. Но как раз она Сяхой не поддерживается.
Контроль типов транслятором — это тоже проверка задним числом.
Цитата: Алексей Гринь от ноября 13, 2009, 15:48Бесконечная рекурсия, всего и делов.Цитата: Triton от ноября 13, 2009, 13:56А вы поясните, если такой умный.
Значит не поняли...
Цитата: Алексей Гринь от ноября 13, 2009, 15:48Гринь, спокойно, санитары уже выехали. :DЦитата: Triton от ноября 13, 2009, 13:56Ололо, ОС как раз и написана на Си, так что вы опять фейлите. Всё это реализовно как раз средствами языка Си :D
Давайте тогда уж и обращение по нулевому указателю средствами ОС не отслеживать, и деление на ноль оставлять как есть, и игнорировать запись данных в невыделенную страницу памяти. Будте последовательны. Это же тоже проверки задним числом, а средствами языка Си возможно всё.
Цитата: Алексей Гринь от ноября 13, 2009, 15:48Которая?
Ололо, ОС как раз и написана на Си, так что вы опять фейлите. Всё это реализовно как раз средствами языка Си :D
Цитата: Алексей Гринь от ноября 13, 2009, 15:48Всё, что после написания кода, задним числом. Грамотное проектирование, грамотное кодирование — 0 ошибок, так? д'Артаньяны же не ошибаются. ;)
С фигов ли? Отличай compile-time-проверку от run-time-проверки. Транслятор балуется с compile-time, а это НИКАК не проверка задним числом.
Цитироватьrun-time — проверкаКогда ваш файловый менеджер обнулит при переносе файл с вашими-очень-важными-данными, вместо того, чтобы свалиться по эксепшену; когда ваш сервер отдаст злоумышленникам все приватные данные (после банального переполнения буфера или же, например, в результате атаки на переполнения умножения в calloc), вместо того чтобы упасть и своим трупом закрыть проход врагу, вот тогда вы мне расскажете про ненужность автоматических проверок целочисленной арифметики.
Цитата: Triton от ноября 13, 2009, 16:12Ну, блин, введите в пример третью структуру, не то важно. Компилер останавливается сразу же, даже не войдя в рекурсию, потому что он не знает, какой это такой тип - struct B. Ему нужно делать пинка под зад, то бишь форвард-декларейшен. Будь он двухпроходным, вошёл бы в рекурсию, да так бы и написал, что рекурсия.ЦитироватьБесконечная рекурсия, всего и делов.ЦитироватьЗначит не поняли...А вы поясните, если такой умный.
Цитата: Triton от ноября 13, 2009, 16:12Ну вы-то можете говорить о чём угодно, только вот делаете вы не по теме. Обсуждались ограничения си. Вы в пример приводите вещи, как раз в 99.9% случаев реализованные на си.
Гринь, спокойно, санитары уже выехали. :D
Фейлите как раз вы, вы даже не понимаете, о чём я говорю.
Цитата: Triton от ноября 13, 2009, 16:25Атаки переполнения и умножения в calloc существуют как раз из-за нежелания делать предпроверку, о которой я благую весть несу. Наличие в мире такой вещи, как "исключения", никак на это не влияет.
Когда ваш файловый менеджер обнулит при переносе файл с вашими-очень-важными-данными, вместо того, чтобы свалиться по эксепшену; когда ваш сервер отдаст злоумышленникам все приватные данные (после банального переполнения буфера или же, например, в результате атаки на переполнения умножения в calloc), вместо того чтобы упасть и своим трупом закрыть проход врагу, вот тогда вы мне расскажете про ненужность автоматических проверок целочисленной арифметики.
Цитата: Алексей Гринь от ноября 13, 2009, 16:45Вы отличайте всё же палец от сами знаете чего. "Реализовано в языке" (как механизм с определённой семантикой) и "реализовано на языке" (как произвольный алгоритм) - это вещи разные совершенно.Цитата: Triton от ноября 13, 2009, 16:12Ну вы-то можете говорить о чём угодно, только вот делаете вы не по теме. Обсуждались ограничения си. Вы в пример приводите вещи, как раз в 99.9% случаев реализованные на си.
Гринь, спокойно, санитары уже выехали. :D
Фейлите как раз вы, вы даже не понимаете, о чём я говорю.
Цитата: Алексей Гринь от ноября 13, 2009, 16:45Атаки переполнения существуют потому, что выбранный язык реализации настолько беспомощен, что не может гарантировать ровным счётом ничего.
Атаки переполнения и умножения в calloc существуют как раз из-за нежелания делать предпроверку, о которой я благую весть несу.
Цитата: Triton от ноября 13, 2009, 17:04Кстати, из Oberon'а можно было бы сделать очень неплохой системный язык... Но гигатонны кода на C...
Попробуйте переписать тот же багнутый алгоритм на Оберон, а потом его хакнуть - успехов.
Цитата: http://en.wikipedia.org/wiki/BitCНу точно стух. :'(
In April 2009, Shapiro - driving force behind both BitC and Coyotos.[2] - announced that he had accepted a position at Microsoft to work on the Midori project, and that after August 2009 he would not be working further on BitC[3].
BitC is no longer under active development.
Цитата: Алексей Гринь от ноября 13, 2009, 16:45В моновом Сишарпе, нопремер:
Будь он двухпроходным, вошёл бы в рекурсию, да так бы и написал, что рекурсия.
Цитата: Triton от ноября 13, 2009, 17:04Это, уважаемый, фелософея и димагогея. Любое 2 + 2 в итоге «реализованы аппаратурой процессора». Что вы хотите этим доказать?
Эти "вещи" реализованы аппаратурой процессора, ядром и принятой моделью исполнения процессов.
Цитата: Triton от ноября 13, 2009, 17:04Ухты, налицо путание семантики и синтаксиса. Если си синтаксически не понимает исключений, переполнений или ООПа, это не значит, что оно нереализуемо семантически.
Вы отличайте всё же палец от сами знаете чего. "Реализовано в языке" (как механизм с определённой семантикой) и "реализовано на языке" (как произвольный алгоритм) - это вещи разные совершенно.
Цитироватьif(a == 0)
fatal("Divide by zero!");
result = b / a;
Цитироватьtry
{
result = b / a;
}
catch(DivideByZeroException e)
{
fatal("Divide by zero!");
}
ЦитироватьАтаки переполнения существуют потому, что выбранный язык реализации настолько беспомощен, что не может гарантировать ровным счётом ничего.Вы, похоже, не поняли, придётся повторить: атаки переполнения существуют как раз из-за нерасторопности делать предпроверки. Неужели так сложно проверить длину буфера?
Цитата: Triton от ноября 13, 2009, 17:31Да, это ваша ошибка, а не си.
Тоже нерадивый программист в моём лице виноват?
ЦитироватьCF_CATCHEDfacepalm.bmp
Цитата: sknente от ноября 14, 2009, 03:44Предмет спора не имеет значения, важен процесс. ;)
Еще один спор ни о чем?