Комментарии 72
Вы случайно не по этой цитате bash.im/quote/415836 нашли указанную статью? :)
Нет, на bash жалко времени :-) Вот от сюда: habrahabr.ru/blogs/ui/138940/, первый первый комментарий туда ведет.
habrahabr.ru/blogs/programming/133352/
Вот ещё статейка которая наверно «заденет тебя за живое».
Впрочем чего нам там до мнения какого-то Дейкстры, не говоря уж о Торвальдсе и прочих Беллрдах
Вот ещё статейка которая наверно «заденет тебя за живое».
Впрочем чего нам там до мнения какого-то Дейкстры, не говоря уж о Торвальдсе и прочих Беллрдах
Ну-ну, обьектно-ориентированный подход можно использовать и на ассемблере. Это всего-лишь идеология архитектуры программы. Как и RAII. Я пишу на C в стиле ООП и RAII. Кстати, в следствие чего уже давно никаких утечек не допускал.
Далее, чето вы конкретно так обманываете, указав только 2 недостатка С++ в списке. Ведь чуть выше вы же сами огласили еще один недостаток — невероятная сложность. Сами же признались, что много лет программируете на C++, и до сих пор не можете сказать, что его знаете. Я после года на си уже мог сказать, что знаю язык от корки до корки. Ну исключая платвормозависимые тонкости, которые нужно манить на каждой конкретной машине\системе.
А вот с ненавистью к С++ я с вами согласен — главная проблема языка на мой взгляд в том, что он разрабатывался не как самостоятельный язык, а как «си с картами и девушками». Это тупиковый подход. Отсюда и жуткие конструкции и тупая система *.h файлов вместо модулей и прочие неприятные моменты.
Далее, чето вы конкретно так обманываете, указав только 2 недостатка С++ в списке. Ведь чуть выше вы же сами огласили еще один недостаток — невероятная сложность. Сами же признались, что много лет программируете на C++, и до сих пор не можете сказать, что его знаете. Я после года на си уже мог сказать, что знаю язык от корки до корки. Ну исключая платвормозависимые тонкости, которые нужно манить на каждой конкретной машине\системе.
А вот с ненавистью к С++ я с вами согласен — главная проблема языка на мой взгляд в том, что он разрабатывался не как самостоятельный язык, а как «си с картами и девушками». Это тупиковый подход. Отсюда и жуткие конструкции и тупая система *.h файлов вместо модулей и прочие неприятные моменты.
> Ну-ну, обьектно-ориентированный подход можно использовать и на ассемблере.
> Это всего-лишь идеология архитектуры программы.
Можно. Но ведь далеко не так удобно, как это делается в C++. И тем более в настоящих ОО-языках. Хотя, тут кому как нравится.
> Далее, чето вы конкретно так обманываете, указав только 2 недостатка С++ в списке.
> Ведь чуть выше вы же сами огласили еще один недостаток — невероятная сложность
Каюсь, к каким-то недостаткам я привык и могу их не замечать. На счет сложности, вроде слова «невероятная» я не употреблял :-) Одно дело — знать синтаксис языка. И совсем другое то, как оно себя ведет на разных платформах и разных компиляторах. Основные мои пробелы — в «шаблонной магии». И в основном потому, что приходится писать код, совместимый с VC6, который корректировки стандарта 2003 не полностью поддерживает. Так что «шаблонная магия» в работе просто исключена.
> Это всего-лишь идеология архитектуры программы.
Можно. Но ведь далеко не так удобно, как это делается в C++. И тем более в настоящих ОО-языках. Хотя, тут кому как нравится.
> Далее, чето вы конкретно так обманываете, указав только 2 недостатка С++ в списке.
> Ведь чуть выше вы же сами огласили еще один недостаток — невероятная сложность
Каюсь, к каким-то недостаткам я привык и могу их не замечать. На счет сложности, вроде слова «невероятная» я не употреблял :-) Одно дело — знать синтаксис языка. И совсем другое то, как оно себя ведет на разных платформах и разных компиляторах. Основные мои пробелы — в «шаблонной магии». И в основном потому, что приходится писать код, совместимый с VC6, который корректировки стандарта 2003 не полностью поддерживает. Так что «шаблонная магия» в работе просто исключена.
Что-то вы опять обманываете, какая еще VC6, если основная ОС у вас — linux? :)
Основная ОС дома — Linux, основной компилятор g++-4.6. На работе основная ОС Windows и компилятор VC6. Но если программа пишется с нуля, то скорее всего она будет написана сначала в Linux, а потом собрана в VC6 потому, что мне так удобней. И собственно рабочая Windows, что в офисе, что дома, запущена в VirtualBox, когда а Host системой выступает Linux.
Как реализуется RAII в C, если не секрет?
На мой взгляд, да и из статьи это видно, каждый язык служит для своих целей и, если не заходить на чужую территорию, то ненависти сильно поубавиться :-).
А типы ptrdiff_t и size_t Вы любите?
Зачем все это, если вы фанат бейсика?
> Сразу уточняю, что моя ненависть берет начало еще со времен C89.
> Как только я пригляделся к этому языку, сразу понял, что ненавижу его. Особенно вот такие конструкции:
Вам для справки: такие конструкции — это K&R C; начиная с C89 типы переменных указываются в списке параметров функции.
И правило неявного int тоже уже не существует начиная с C99.
Смешные у вас придирки. Можно также поругать C за то, что в нем длина идентификаторов не может быть длиннее 8ми символов (K&R) :-)
> Как только я пригляделся к этому языку, сразу понял, что ненавижу его. Особенно вот такие конструкции:
Вам для справки: такие конструкции — это K&R C; начиная с C89 типы переменных указываются в списке параметров функции.
И правило неявного int тоже уже не существует начиная с C99.
Смешные у вас придирки. Можно также поругать C за то, что в нем длина идентификаторов не может быть длиннее 8ми символов (K&R) :-)
> Вам для справки: такие конструкции — это K&R C; начиная с C89 типы
> переменных указываются в списке параметров функции.
Это я знаю. Но я говорю о своих первых впечатлениях о языке C. Не смотря на С89 указанный код корректен до сих пор и даже встречается в исходниках. Вот например из очень неплохой библиотеки discount:
Ну и на самом то деле, разумеется я не испытываю никакой ненависти по отношению к языку C. Это был ответ на пост, да и не ожидал я вообще инвайта. Просто проснулся в 3 утра и захотелось что-нибудь почитать, а потом и написать. Хоть сам на C практически пишу, зато постоянно использую libc или библиотеки написанные на C :-)
> переменных указываются в списке параметров функции.
Это я знаю. Но я говорю о своих первых впечатлениях о языке C. Не смотря на С89 указанный код корректен до сих пор и даже встречается в исходниках. Вот например из очень неплохой библиотеки discount:
/* helper function for php markdown extra footnotes; allow the user to
* define a prefix tag instead of just `fn`
*/
static char *
p_or_nothing(p)
MMIOT *p;
{
return p->ref_prefix ? p->ref_prefix : "fn";
}
Ну и на самом то деле, разумеется я не испытываю никакой ненависти по отношению к языку C. Это был ответ на пост, да и не ожидал я вообще инвайта. Просто проснулся в 3 утра и захотелось что-нибудь почитать, а потом и написать. Хоть сам на C практически пишу, зато постоянно использую libc или библиотеки написанные на C :-)
Жесть какая. Давайте, что ли, по-порядку.
Про C. У языка есть своя конкретная ниша, и он очень чётко в неё вписывается. Непонятная типизация? Ну не знаю, как там в C89, но лично я такого кода никогда не видел — везде объявлены типы, везде всё достаточно чётко. В C нет ООП, сборшика мусора, умных указателей? Ну так а кто вам мешает их добавить? Серьёзно, если вы профессионально пишете на C, то грех не иметь пары-тройки персональных библиотек, которые бы полностью удовлетворяли вас и при этом не тянули за собой кучу того, что вы не используете.
Про Java. А есть разница между адептами C++, которые кричат про непонятность мира Java и адептами Java, которые кричат про запутанность C++? Java the language — прост как палено, Java the world — не менее сложен, чем C++. Но и то, и другое нужно знать и уметь этим пользоваться на практике. В Java меня точно также раздражают невнятные непойманные эксепшены, но не меньше меня раздражают ошибки сборки C++ программы (особенно под Linux — ммм, как много нам мгновений чудных...).
Ну и да, скорость программы на Java определяется исключительно пряморукостью программиста и правильностью архитектуры. Современные JVM, такие как HotSpot, умеют очень и очень неплохо оптимизировать код, причём прямо в рантайме и в зависимости от условий выполнения.
Про сложность. Есть 2 сложности — сложность изучения и сложность использования. Haskell сложен для изучения. Одного только изречения про монады достаточно, чтобы понять, сколько времени у вас уйдёт на понимание всех фишек этого языка. Однако если вы справились с изучением, программирование на этом языке превращается в сказку — свобода выражения мысли, практически никакой отладки (если скомпилировалось, то 99%, что программа корректна) и ясный красивый код. C++ в свою очередь сложен как для изучения, так и для использования. Для изучения — потому что фич много. Для использования — потому что эти фичи плохо друг с другом совместимы. Мне особо доставляет количество вариантов представления строки. В С++ тонны фич, дублирующих функциональность, но имеющих чуть-чуть другую семантику, и про всех них нужно помнить и явно описывать варианты использования. А при композиции функций количество вариантов использования растёт экспоненциально, и программист очень быстро теряет возможность держать в голове и контролировать систему. Всё это следствие мультипарадигменности и общей философии C++, в которой считается абсолютной необходимостью иметь фичу на абсолютно любой случай. В Haskell такой проблемы нет: вы всегда знаете, что над аргументами вашей функции можно совершить чётко определённые операции, что вычисляться они всегда будут лениво, что неиспользуемыми ресурсами займётся сборщик мусора и т.д. У вас есть набор гарантий, а это значит что 1) вам не надо держать в голове несколько десятков вариантов использования; 2) вы можете серьёзно оптимизировать свой код. В C++ таких гарантий просто нет. Даже в C есть, а в C++ нет. (Здесь ещё интересно сравнить другую пару языков — Common Lisp и Scheme. В CL также намного мощнее своего оппонента, но в то же время из-за мультипарадигменности с ним зачастую очень сложно работать).
Про время компиляции и модульность. Проект компилируется всего за 15 минут?! Пардон, 15 минут — это мало? Нет, я в курсе, что для С++ это нормально, но вы с другими то языками сравните. Проблема в C++ в том, что в нём напрочь отсутствует модульность и раздельная компиляция. Я не говорю про хитрости типа precompiled headers и компании, я говорю про сам язык. Отсутствие модульности не только усложняет процесс разработки крупных программ (ок, неймспейсы и классы в целом помогают), но и накладывают серьёзные ограничения на технические возможности систем. Java позволяет на ходу подменить один класс другим (см. JRabel, а также иерархию класслоадеров), Lisp позволяет переопределять функции прямо в REPL. Как сделать такое на C++? Довольно непросто, не так ли?
Не поймите превратно. Я не люблю и не ненавижу C++. Я отношусь к нему как к инструменту. Как к лопате или швейцарскому ножу. Но не как ко всему сразу — если мне ныжно выкопать яму, я всё-таки схожу за лопатой, а не буду ковыряться в земле ножиком.
Про C. У языка есть своя конкретная ниша, и он очень чётко в неё вписывается. Непонятная типизация? Ну не знаю, как там в C89, но лично я такого кода никогда не видел — везде объявлены типы, везде всё достаточно чётко. В C нет ООП, сборшика мусора, умных указателей? Ну так а кто вам мешает их добавить? Серьёзно, если вы профессионально пишете на C, то грех не иметь пары-тройки персональных библиотек, которые бы полностью удовлетворяли вас и при этом не тянули за собой кучу того, что вы не используете.
Про Java. А есть разница между адептами C++, которые кричат про непонятность мира Java и адептами Java, которые кричат про запутанность C++? Java the language — прост как палено, Java the world — не менее сложен, чем C++. Но и то, и другое нужно знать и уметь этим пользоваться на практике. В Java меня точно также раздражают невнятные непойманные эксепшены, но не меньше меня раздражают ошибки сборки C++ программы (особенно под Linux — ммм, как много нам мгновений чудных...).
Ну и да, скорость программы на Java определяется исключительно пряморукостью программиста и правильностью архитектуры. Современные JVM, такие как HotSpot, умеют очень и очень неплохо оптимизировать код, причём прямо в рантайме и в зависимости от условий выполнения.
Про сложность. Есть 2 сложности — сложность изучения и сложность использования. Haskell сложен для изучения. Одного только изречения про монады достаточно, чтобы понять, сколько времени у вас уйдёт на понимание всех фишек этого языка. Однако если вы справились с изучением, программирование на этом языке превращается в сказку — свобода выражения мысли, практически никакой отладки (если скомпилировалось, то 99%, что программа корректна) и ясный красивый код. C++ в свою очередь сложен как для изучения, так и для использования. Для изучения — потому что фич много. Для использования — потому что эти фичи плохо друг с другом совместимы. Мне особо доставляет количество вариантов представления строки. В С++ тонны фич, дублирующих функциональность, но имеющих чуть-чуть другую семантику, и про всех них нужно помнить и явно описывать варианты использования. А при композиции функций количество вариантов использования растёт экспоненциально, и программист очень быстро теряет возможность держать в голове и контролировать систему. Всё это следствие мультипарадигменности и общей философии C++, в которой считается абсолютной необходимостью иметь фичу на абсолютно любой случай. В Haskell такой проблемы нет: вы всегда знаете, что над аргументами вашей функции можно совершить чётко определённые операции, что вычисляться они всегда будут лениво, что неиспользуемыми ресурсами займётся сборщик мусора и т.д. У вас есть набор гарантий, а это значит что 1) вам не надо держать в голове несколько десятков вариантов использования; 2) вы можете серьёзно оптимизировать свой код. В C++ таких гарантий просто нет. Даже в C есть, а в C++ нет. (Здесь ещё интересно сравнить другую пару языков — Common Lisp и Scheme. В CL также намного мощнее своего оппонента, но в то же время из-за мультипарадигменности с ним зачастую очень сложно работать).
Про время компиляции и модульность. Проект компилируется всего за 15 минут?! Пардон, 15 минут — это мало? Нет, я в курсе, что для С++ это нормально, но вы с другими то языками сравните. Проблема в C++ в том, что в нём напрочь отсутствует модульность и раздельная компиляция. Я не говорю про хитрости типа precompiled headers и компании, я говорю про сам язык. Отсутствие модульности не только усложняет процесс разработки крупных программ (ок, неймспейсы и классы в целом помогают), но и накладывают серьёзные ограничения на технические возможности систем. Java позволяет на ходу подменить один класс другим (см. JRabel, а также иерархию класслоадеров), Lisp позволяет переопределять функции прямо в REPL. Как сделать такое на C++? Довольно непросто, не так ли?
Не поймите превратно. Я не люблю и не ненавижу C++. Я отношусь к нему как к инструменту. Как к лопате или швейцарскому ножу. Но не как ко всему сразу — если мне ныжно выкопать яму, я всё-таки схожу за лопатой, а не буду ковыряться в земле ножиком.
Даешь D в массы!
Споры про преимущества C и C++ лишены смысла, когда есть такой инструмент, как D, и лишь интертность общества останавливает повсеместное внедрение этого языка.
Ссылки для тебя, хабраюзер: статья в Википедии, сайт языка, статьи на Хабре.
Споры про преимущества C и C++ лишены смысла, когда есть такой инструмент, как D, и лишь интертность общества останавливает повсеместное внедрение этого языка.
Ссылки для тебя, хабраюзер: статья в Википедии, сайт языка, статьи на Хабре.
Интересный язык. Подскажите, а как у него с взаимодействием с С/С++ библиотеками? Возможно ли использовать готовые кодовые базы с D?
Когда я читаю про D, мне в нём всё почти нарвится. Но вот, я скачал DMD, плагин VisualD, создал проект HelloWord, запускаю:
Сначала он инициализирует чего-то там, секунд 5-10 (экран пуст), когда появляется заветная строчка, смотрю в менеджер программ: эта хрень отожрала 20 Mb! Не знаю чего они там понаделали, у D1 проблем не было, helloWorld памяти ел ~1Mb (приемлимо) и запускался мгновенно.
Т.е., пока С++.
Сначала он инициализирует чего-то там, секунд 5-10 (экран пуст), когда появляется заветная строчка, смотрю в менеджер программ: эта хрень отожрала 20 Mb! Не знаю чего они там понаделали, у D1 проблем не было, helloWorld памяти ел ~1Mb (приемлимо) и запускался мгновенно.
Т.е., пока С++.
D, конечно, крут. Но меня лично останавливает мусоросборщик (мне он просто не нужен), неоптимальность реализации базовых классов и ещё пара вещей. Если поддержка всех этих вещей будет на уровне языка (без извращений, в смысле), если будет хороший оптимизатор — то велкам.
неоптимальность реализации базовых классов
Что имеется в виду? Любопытно.
Что имеется в виду? Любопытно.
Например, вот это.
Честно говоря мутный тест, что на сайте D, что у них. Не ясно, включена ли во время инициализация runtime'а, не ясно что за контейнеры в версии U++ (как у них с многопоточностью, насколько «жадные» массивы), не ясно какая операция больше всего тормозит (может файловый ввод, а может поиск по map). И, в добавок, он двухлетней давности.
Контейнеры достаточно быстрые. Быстрее, чем STL, в несколько раз (сравнение есть на сайте).
Поскольку U++ пользуюсь достаточно активно, готов совместно с Вами сделать тест и сравнить реальное быстродействие на других примерах. Мне тоже очень интересно сравнить быстродействие и затраты памяти.
Поскольку U++ пользуюсь достаточно активно, готов совместно с Вами сделать тест и сравнить реальное быстродействие на других примерах. Мне тоже очень интересно сравнить быстродействие и затраты памяти.
Я на винде могу сравнить, nix'ов дома нет. что касается памяти, не знаю какой адекватный тест придумать.
Давайте сравним на Винде.
Я могу выслать нужные бинарники + исходники для самостоятельной сборки, если нужно.
В качестве примера можно взять следующую задачу: берём хэш-таблицу. Заполняем её строками вида а, аа, ааа, аааа,… (всего строк, скажем, 100 000).
Далее в цикле (1 000 000 итераций) генерируем ключ из рандомного числа букв «а» (от 1 до 100 000) и обеспечиваем поиск по хэшу.
Замеряем время работы программы (создание хэша + цикл выборок), а по тому же диспетчеру задач получаем некое сильно примерное значение объёма занимаемой программой памяти.
Я могу выслать нужные бинарники + исходники для самостоятельной сборки, если нужно.
В качестве примера можно взять следующую задачу: берём хэш-таблицу. Заполняем её строками вида а, аа, ааа, аааа,… (всего строк, скажем, 100 000).
Далее в цикле (1 000 000 итераций) генерируем ключ из рандомного числа букв «а» (от 1 до 100 000) и обеспечиваем поиск по хэшу.
Замеряем время работы программы (создание хэша + цикл выборок), а по тому же диспетчеру задач получаем некое сильно примерное значение объёма занимаемой программой памяти.
Кроме того, как я уже говорил, по целому ряду причин мне лично мусоросборщик просто вреден.
Плюс, недостаток мощности, когда речь идёт о таких техниках как разрушающее копирование при передаче параметров. Указатели без обёрток тоже не имеют себе равных по производительности (нужно лишь соблюдать два главных правила безопасности — как писал в одной из статей).
Плюс, недостаток мощности, когда речь идёт о таких техниках как разрушающее копирование при передаче параметров. Указатели без обёрток тоже не имеют себе равных по производительности (нужно лишь соблюдать два главных правила безопасности — как писал в одной из статей).
Один вопрос: как соотносится производительность D с C#/Java?
Да, Eclipse раньше был не очень. Тоже, где-то в 2007-2008 году пробовал его (как IDE для С++), ужасно не понравился — тормоза, косячный автокомплит, на netbeans тогда перешел. А вот сейчас eclipse намного лучше стал (я им пользуюсь почти год как основной ide для плюсов), во всяком случае он гораздо лучше чем голая visual studio. Ну, а под linux и подавно. Единственное, что 64 битные версии какие-то не очень. Под виндой они у меня крашились часто, поэтому сейчас использую 32 битную. Под линуксом такой проблемы не заметил.
Ну жрёт памяти и тормозит он до сих пор — это если сравнивать другие IDE.
Но пользоваться можно.
Но всё равно ява тормознутее.
Простой пример — есть редактор анимаций для игры, на яве. К нему экспортер — пакует кучу спрайтов в атласы.
Переписали с явы его на плюсы — на порядок быстрее стало.
Это не значит что я её ненавижу :)
Но пользоваться можно.
Но всё равно ява тормознутее.
Простой пример — есть редактор анимаций для игры, на яве. К нему экспортер — пакует кучу спрайтов в атласы.
Переписали с явы его на плюсы — на порядок быстрее стало.
Это не значит что я её ненавижу :)
Недавно написал для сравнения. Код в цикле просто выводит 10 000 раз значение итерации. В джава — 6 секунд это все дело длиться. В С++ — меньше секунды. Платформа линукс 64 бит. Вирт машина оракловская, самая свежая версия. В чем проблема?
Причем в вджаве делал и через Sustem.out.println и через System.out.format — результат плачевный
Простите, что я делаю не так:
600-1000 мсек.
600-1000 мсек.
import java.util.Calendar;
public class temp {
public static void main(String... args) {
long time = Calendar.getInstance().getTimeInMillis();
for (int i = 0 ; i < 10000 ; i++)
System.out.println(i);
long difftime = Calendar.getInstance().getTimeInMillis() - time;
System.out.println(difftime);
}
}
О, неделя любви к c++!
Нет ссылок (которые безопасней указателей), нет типобезопасности (сплошные void *)… много чего нет. А то, что есть, только способствует ошибкам: strcat, printf, gets…
Если руки прямые, а извилины — кривые, то ошибок не будет,
Если наоборот, то и в c++, и в java, и в питоне, и даже просто в алгоритме можно полнейший бред понаписать. Умные указатели медленнее простых.
Указательная арифметика, быстрые функции стандартной библиотеки (да, я о принтф, сканф, мемсэт, atoi и даже нестандартизированной itoa,(тем не менее в 2х самых популярных компиляторах реализации совместимые))
Сишные функции много быстрее плюсовых, и следует всегда юзать сишные (если это необременительно).
Более того, маллок предпочтительней new для простых типов (кстати, для простых типов конструкторы содержат вызов malloc в реализации от VS2010).
Короче, основные плюсы «плюсов» — возможность писать код как удобно разработчику, органмчно смешивая функциии, ООП и работу с памятью.
Ну а объем… необходимая жертва.
Вот поэтому я почти никогда не юзаю шаблоны.
В с++ я особенно ненавижу дебильную, устаревшую, оставленную только из-за совместимости, архитектуру компилятора, когда единица компиляции — отпрепроцессеренный файл.
имхо
1 единицей трансляции должен быть проект
то есть при трансляции проект анализируется как единое целое, а не только то, что в текущем файле
2 #include должен остаться для всяких извращений, а для включения должно быть добавлено ключевое слово import, делающее именно то, что от него ожидают — связывание символов в текущем файле с символами в импортируемым, если в текущем они объявлены, а в импортируемым — определены (или наоборот), и объявление и связывание, если в текущем они не объявлены, а в импортируемом объявлены или определены.
таким образом решатся многие проблемы с ошибками компиляции, ускорится сама компиляция, да и логичнее это.
Правда это поломает многие скрипты сборки, но невелика проблема.
Достаточно ведь просто файла проекта исходников и немного флагов.
Скрипты таким образом тоже упростятся, так как не нужно будет для каждого файла вызывать отдельно компилятор, потом линковщик и весь тулчейн.
3 отсутствие стандарта на ооп в shared libraries
Если руки прямые, а извилины — кривые, то ошибок не будет,
Если наоборот, то и в c++, и в java, и в питоне, и даже просто в алгоритме можно полнейший бред понаписать. Умные указатели медленнее простых.
Указательная арифметика, быстрые функции стандартной библиотеки (да, я о принтф, сканф, мемсэт, atoi и даже нестандартизированной itoa,(тем не менее в 2х самых популярных компиляторах реализации совместимые))
Сишные функции много быстрее плюсовых, и следует всегда юзать сишные (если это необременительно).
Более того, маллок предпочтительней new для простых типов (кстати, для простых типов конструкторы содержат вызов malloc в реализации от VS2010).
Короче, основные плюсы «плюсов» — возможность писать код как удобно разработчику, органмчно смешивая функциии, ООП и работу с памятью.
Ну а объем… необходимая жертва.
Вот поэтому я почти никогда не юзаю шаблоны.
В с++ я особенно ненавижу дебильную, устаревшую, оставленную только из-за совместимости, архитектуру компилятора, когда единица компиляции — отпрепроцессеренный файл.
имхо
1 единицей трансляции должен быть проект
то есть при трансляции проект анализируется как единое целое, а не только то, что в текущем файле
2 #include должен остаться для всяких извращений, а для включения должно быть добавлено ключевое слово import, делающее именно то, что от него ожидают — связывание символов в текущем файле с символами в импортируемым, если в текущем они объявлены, а в импортируемым — определены (или наоборот), и объявление и связывание, если в текущем они не объявлены, а в импортируемом объявлены или определены.
таким образом решатся многие проблемы с ошибками компиляции, ускорится сама компиляция, да и логичнее это.
Правда это поломает многие скрипты сборки, но невелика проблема.
Достаточно ведь просто файла проекта исходников и немного флагов.
Скрипты таким образом тоже упростятся, так как не нужно будет для каждого файла вызывать отдельно компилятор, потом линковщик и весь тулчейн.
3 отсутствие стандарта на ооп в shared libraries
> GW-Basic. Первая любовь — это на всю жизнь.
You made my day…
You made my day…
> За что я ненавижу Java.
> С помощью eclipse.exe оно не запускалось. Уже не помню, что там была за ошибка, но работать отказывался.
Ненавижу Java за то что эклипс не получилось запустить в 2008 году? :-) Я большой сторонник C++, но статья как-то совсем не
> С помощью eclipse.exe оно не запускалось. Уже не помню, что там была за ошибка, но работать отказывался.
Ненавижу Java за то что эклипс не получилось запустить в 2008 году? :-) Я большой сторонник C++, но статья как-то совсем не
Ох, убил бы нахрен. Си самый чистый и красивый язык.
Вот список того, что в ваших плюсах похерили.
По-моему, это про ассамблер :).
В плюсах пункты 1,4,6 остались как наследие си.
Не похерили.
Не похерили.
Можете писать на нем сколько угодно. Однако C достаточно плохо позволяет переиспользовать код, в результате нужно городить макросы, делать copy/paste или смиряться с потерей производительности. Взять тот же пример с qsort, что вариант реализации в стандартной библиотеки С++ работает чаще всего быстрее чем void* подход из С.
«Нет ни RAII, ни сборки мусора, от сюда и множество утечек»
простите, в с++ есть сборка мусора?
простите, в с++ есть сборка мусора?
Точнее не почему-то, причины понятны: нет ссылок (которые безопасней указателей), нет типобезопасности (сплошные void *)… много чего нет. А то, что есть, только способствует ошибкам: strcat, printf, gets…
1. Как ссылки безопаснее указателей? Между ними вся разница лишь в том, что компилятор неявно делает преобразование «переменная <-> указатель», да декорирует функцию (для линкера) немного по-другому.
2. void* тем и хорош, что не требует бессмысленного кода по преобразованию типов. Да и какая разница, на что указатель? Тем более, они используются в функциях вроде «скопируй N байт».
3. Используйте их безопасные аналоги вроде strncat. А в большинстве случаев программа проверила соответствие размеров чуть раньше и не нужно тратить такты на дополнительные лишние проверки.
А почему никто не вспомнил вырвиглазный синтаксис плюсов?
if(param)pause=!pause, pause?Show():Hide();
if(param)pause=!pause, pause?Show():Hide();
Где вы здесь плюсы увидели?
А вы докажите мне что этого нельзя встретить в С++ сорце )))
Ну можно, конечно, поскольку С++ достаточно хорошо совместим с Си. Вы привели кусок Сишного кода и зачем-то утверждаете, что это «вырвиглазный синтаксис плюсов».
Ну ладно, ладно — скажем так, у с++ есть многочисленные проблемы с синтаксисом унаследованые от си создающие определенные сложности в понимании кода, втом числе и вконтексте ООП.
(!(namespace::class1*)(this->Method())->method1()->class2::method2())?(this->A==this->atrr.class3::method4()):(this->Y!=Alfa->method5())
(!(namespace::class1*)(this->Method())->method1()->class2::method2())?(this->A==this->atrr.class3::method4()):(this->Y!=Alfa->method5())
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Причины любить C++