У нас тут с павлентусом очередной спор вышел в топе язык программирования. Я подумал что неплохо бы открыть новый топ и обсудить здесь преимущества и недостатки этих двух языков.
И конечно выделить лидера ( хотя помоему и так все ясно;) )
Вид для печати
У нас тут с павлентусом очередной спор вышел в топе язык программирования. Я подумал что неплохо бы открыть новый топ и обсудить здесь преимущества и недостатки этих двух языков.
И конечно выделить лидера ( хотя помоему и так все ясно;) )
Начнем-с
1. Производительность Java в два раза меньше чем у С++ ( если брать большие серверные приложения, требовательные игрушки и проги для серьезных вычислений ).
2. Отсутствие множественного наследования.
3. Отсутствие перегрузки операторов.
4. Отсутствие шаблонов.
5. На Java не напишешь драйвера и другие системные программы
[QUOTE=THRESHE]Начнем-с
1. Производительность Java в два раза меньше чем у С++ ( если брать большие серверные приложения, требовательные игрушки и проги для серьезных вычислений ).
[/QUOTE]
откуда дровишки???
[url]http://www.codenet.ru/webmast/java/javavscpp.php[/url]
[QUOTE=THRESHE]
2. Отсутствие множественного наследования.
3. Отсутствие перегрузки операторов.
4. Отсутствие шаблонов.
5. На Java не напишешь драйвера и другие системные программы[/QUOTE]
гм ;), хочу я посмотреть как ты на си напишеш сложную распределенную и запутанную логикой систему... ;)
мораль: у каждого свои плюсы и минусы.. ;)
[QUOTE=THRESHE]Начнем-с
1. Производительность Java в два раза меньше чем у С++ ( если брать большие серверные приложения, требовательные игрушки и проги для серьезных вычислений ).
2. Отсутствие множественного наследования.
3. Отсутствие перегрузки операторов.
4. Отсутствие шаблонов.
5. На Java не напишешь драйвера и другие системные программы[/QUOTE]
Чтоб такие заявления делать, надо хотя бы быть компетентным в обеих областях.
1. Т.е. у вас есть набор тестов доказывающих, что производительность Java программы(_любой_) ровно в 2 раза меньше, нежели аналогичной(по алгоритмам и архтектуре) на C++? Если так - то это революция! Выложите свои материалы.
2. Это спасительное свойство явы, это упрощение показывает логичность языка и его простоту, по сравнению с С++.
3. За 3 года разработки на Java не возникало острой нобходимости иметь такую возможность.
4. Уже около 2х лет как вышла Java 5, где появились generics - они аналогичны шаблонам, опять Вы показали свою некомпетентность. При этом их использование никак не отражается на быстродействии собранных программ, в отличие от использования их в C++.
5. На Java пишут даже ОС. Хотя им и нужен небольшой загрузчик на ассемблере, но это мелочь, дрова писать можно, хотя и нет необходимости.
И самое главное что Вы не учли, это разные секторы рынка и области применения языков, у Java и С++ они совершенно разные. Пересекаются они очень редко.
н-а-ч-а-л-о-с-ь :)
THRESHE,
сразу видно что с javoй вы либо вообще незнакомы, либо поверхностно.
[QUOTE=optic]
гм ;), хочу я посмотреть как ты на си напишеш сложную распределенную и запутанную логикой систему... ;)
[/QUOTE]
OS GNU/Linux
Как я и говорил: "С++талинизм" :)
Кстати, на любые тесты Java vs C(++) надо делать поправку.
Потому что Java - технология, в раскрутку которой (в т.ч. и публикацией таких тестов и созданием программерских сообществ) вкладыватся огромные деньги.
В раскуртку С++ Б.С. насколько мне известно не вложил ни копейки и никакая фирма не была напрямую заинтересована во вложениях в пиар-компанию С++ (хотя косвенные вложения были).
Для Sun и MS идет война в мозгах программеров за продвижение собственных средств разработки, а на войне все средства хороши... ИМХО на войне лучше держаться подальше от начальства - и поближе к кухне. ;-)
Не то, что я не доверяю ничему публикуемому, но то, с чем я лично сталкивался в мире джава-программ выглядело потрясающе. Если у вас стоит суперкомп класса DeepBlue.
Для реальных приложений оно давало много денег и комфорта программистам (и сертифицированным преподавателям). И огромный геморрой заказчикам. Всегда. Я не видел ни одной эффективной реализации, которая бы не демонстрировалась на сайтах и презентациях, а стояла на рабочем столе директора или в серверной.
Зато видел много примеров, когда такие системы умирали перед сдачей либо сразу после сдачи заказчику.
Это не означает, что таких систем нет, но увы, мне они не попадались.
[quote]И самое главное что Вы не учли, это разные секторы рынка и области применения языков, у Java и С++ они совершенно разные. Пересекаются они очень редко.[/quote] Вот с этого и надо начинать, поэтому считаю что топик нужно ЗАКРЫТЬ , пока не разгорелась [B]религиозная война.[/B]
Потому как люди, "компетентные в обеих областях" не будут устраивать спор C++ vs Java, так как "у каждого свои плюсы и минусы.. "
На счет "системные программы" - не совсем то, но все же : [URL="http://www.tivo.com/1.0.asp"]вот[/URL] - как вы дуамете ЧТО там внутри ??
З.Ы. а вообще из подписи автора " C++ & AMD forever" - сразу ясно, что фанат .. а с фанатами спорить бесполезно
Откровенно говоря, я - любитель С++. Однако, как уже неоднократно здесь сказали, нельзя категорично заявлять, что С++ лучше Java или наоборот. У каждого из этих средств есть свои сильные и слабые стороны. И любой квалифицированный специалист должен это понимать, и пользоваться этими инструментами наиболее подходящим образом. Представьте себе, что будет, если люди начнут спорить о том, что лучше, вантуз или бензопила? Я согласен с тем, что области применения этих технологий сейчас практически не пересекаются. Однако, с появлением Java-технологии, С++ несколько утратил свои позиции на рынке серверных приложений.
А что касается отсутствия в Java множественного наследования, перегрузки операторов и других возможностей С++, так это объясняется тем, что в Java это просто не нужно. У каждого из этих языков своя идеология и методы проектирования. И если, THRESHE, вы чувствуете, что вам не хватает в Java, скажем, виртуального наследования, то читайте книги или документацию по паттернам проектирования на Java.
Почему бесполезно ? Может вы меня переубедите :) В С++ я пришел тоже после Паскаля так что сменить язык не страшно (тем более что они похожи)
А насчет того где пересекаются например в серверных приложениях
[B]Религиозной войны[/B] не будет не волнуйтесь я просто предложил обсудить плюсы и минусы этих языков
А насчет некомпетентности то в каком то смысле вы правы потому что пробовал программировать на Java всего две недели и перешел обратно так как не понравилось
А очередной спор возник не по моей вине [url]https://forumodua.com/showpost.php?p=932558&postcount=189[/url]
[quote=THRESHE]
А очередной спор возник не по моей вине [URL="https://forumodua.com/showpost.php?p=932558&postcount=189"]https://forumodua.com/showpost.php?p=932558&postcount=189[/URL][/quote]
для этого существует приват (ЛС - личные сообщения).
А почему не обсудить этот вопрос всем вместе ? Ведь я только студент, а у нас на форуме тусуются уже сформировавшиеся программеры :)
Интересно услышать мнение не только павлентуса Java-ортодокса но и других :)
[QUOTE=THRESHE]А почему не обсудить этот вопрос всем вместе ? Ведь я только студент, а унас на форуме тусуются уже сформировавшиеся программеры :)
Интересно услышать мнение не только павлентуса Java-ортодокса на и других :)[/QUOTE]
Как тебя еще не забанили :) Фразочки выбирай :)
[QUOTE=Gothy]
1. Т.е. у вас есть набор тестов доказывающих, что производительность Java программы(_любой_) ровно в 2 раза меньше, нежели аналогичной(по алгоритмам и архтектуре) на C++? Если так - то это революция! Выложите свои материалы.
[/quote]
конечно, все программы на java тормозят по разному, но некоторые и поболе ;)
[quote]
2. Это спасительное свойство явы, это упрощение показывает логичность языка и его простоту, по сравнению с С++.
[/quote]
меня всегда забавляли подобные извинения
одно дело, если бы в с++ все классы надо было наследовать от как минимум двух, так нет же: надо один - используй один, надо десять - используй десять.
а если в недоязыке десять нельзя, то это никак нельзя считать плюсом, т.к. один можно и там и там.
проблемы сборщиков мусора не волнуют тех, кто ими не пользуется
[quote]
3. За 3 года разработки на Java не возникало острой нобходимости иметь такую возможность.
[/quote]
не удивительно, т.к. во-первых, эта возможность нацелена на разработчиков библиотек, а во-вторых, наиболее эффективна совместно с нормальной реализацией шаблонов
[quote]
4. Уже около 2х лет как вышла Java 5, где появились generics - они аналогичны шаблонам, опять Вы показали свою некомпетентность. При этом их использование никак не отражается на быстродействии собранных программ, в отличие от использования их в C++.
[/quote]
в чем-то вы правы, т.к. в с++ шаблоны поддерживают static polymorphism и по сравнением с dynamic polymorphism ( виртуальными функциями ), благоприятно отражаются на быстродействии программы. generics же с шаблонами имеют мало общего, а гораздо ближе к виртуальным функциям. потому и тормозят и к [url]http://en.wikipedia.org/wiki/Template_metaprogramming[/url] никаким боком. "The technique is used by a number of languages, including C++, D, Eiffel, Haskell, ML and XL, of which the C++ programming language is probably the most prominent"
ни java ни с# не просматривается ;)
[quote]
5. На Java пишут даже ОС. Хотя им и нужен небольшой загрузчик на ассемблере, но это мелочь, дрова писать можно, хотя и нет необходимости.
[/quote]
много чего пишут на непредназначенных для этого языках
[quote]
И самое главное что Вы не учли, это разные секторы рынка и области применения языков, у Java и С++ они совершенно разные. Пересекаются они очень редко.[/QUOTE]
это верно. сектор java - апплеты.
раньше я думал, что java это для rad. типа сляпать что-то одноразовое по быстрому. однако, это как раз технология, по которой производится большинство игр.
и почему-то их пишут на с++. арканоиды и прочие кваки для телефонов не рассматриваем - это ближе к апплетам.
Тема на самом деле не корректна.
Оба языка хороши.
Ява, как более поздний язык - проще и красивей.
Но дело не в языках, а в задачах,
требованиях заказчика и т.п.
В идеале, программист должен знать одну технологию,
но очень досконально. И находить под нее работодателя.
На деле фирмам часто приходится переключаться:
появился новый заказчик,
или у старого появился новый бзык,
или директору вещий сон приснился,
и тогда - вперед на мины: ать, два и завтра пишем на Smalltalk + Objective C.
Папы всякие важны,
папы всякие нужны.
Подброшу-ка я полешко в дискуссию :)
[url="http://local.joelonsoftware.com/mediawiki/Опасности_обучения_на_Java"]Опасности обучения на Java[/url]
[QUOTE=fenikso]Подброшу-ка я полешко в дискуссию :)
[url="http://local.joelonsoftware.com/mediawiki/Опасности_обучения_на_Java"]Опасности обучения на Java[/url][/QUOTE]
Битая ссылка =(
похоже ссылка бьется, лучше перейти из [url]http://local.joelonsoftware.com/mediawiki/index.php/Russian[/url]
на пункт "Опасности обучения на Java".
[QUOTE]Счастливые выпускники школ Java никогда не возьмутся за ужасные, выходящие за границы их понимания операции с основанными на указателях хеш-таблицами. Они никогда не будут делать великолепных, безумных, сумасшедших попыток упаковать что-то в несколько битов. Они никогда не будут загружать свои головы мыслями о том, как, в полностью функциональных программах, значение переменной никогда не изменяется, и все-таки, оно постоянно изменяется! Парадокс! [/QUOTE]
:rzhu_nimagu:
Коллеги как по мне спор ни о чем.
У той и другой технологии масса достоинств и недостатков, а также свои сферы применения.
Об этом можно спорить вечно, использование того или иного средства зависит от множества факторов.
[QUOTE=pal]конечно, все программы на java тормозят по разному, но некоторые и поболе ;)[/QUOTE]
конечно, все программы на C++ тормозят по разному, но некоторые и поболе ;)
[QUOTE=pal]
меня всегда забавляли подобные извинения
одно дело, если бы в с++ все классы надо было наследовать от как минимум двух, так нет же: надо один - используй один, надо десять - используй десять.
а если в недоязыке десять нельзя, то это никак нельзя считать плюсом, т.к. один можно и там и там.
проблемы сборщиков мусора не волнуют тех, кто ими не пользуется
[/QUOTE]
Не за что мне перед Вами извиняться. У меня только лишь сочувствие :)
Почему-то у многих людей складывается мнение "больше значит лучше" относительно едва ли не всех сфер жизни. Думаю объяснять, что такое мнение не всегда верно не нужно.
Всё что я знаю, это то, что выстроить логичное, стройное дерево наследования я могу в java не напрягаясь вопросами "скрещения" нескольких классов, я сделаю эту структуру на интерфейсах, и их методах. В такой структуре разбираться на порядок легче.
[QUOTE=pal]
не удивительно, т.к. во-первых, эта возможность нацелена на разработчиков библиотек, а во-вторых, наиболее эффективна совместно с нормальной реализацией шаблонов
[/QUOTE]
Для меня это удивительно, и библиотеки я разрабатывал даже не задумываясь над перегрузкой операторов. Наверно я что-то не так делаю... и тысячи других явистов тоже. Давайте разгоним Apache Foundation, а то слишком они много библиотек на яве написали, они наверно гавно, без шаблонов и перегрузки операторов.
[QUOTE=pal]
в чем-то вы правы, т.к. в с++ шаблоны поддерживают static polymorphism и по сравнением с dynamic polymorphism ( виртуальными функциями ), благоприятно отражаются на быстродействии программы. generics же с шаблонами имеют мало общего, а гораздо ближе к виртуальным функциям. потому и тормозят и к [url]http://en.wikipedia.org/wiki/Template_metaprogramming[/url] никаким боком. "The technique is used by a number of languages, including C++, D, Eiffel, Haskell, ML and XL, of which the C++ programming language is probably the most prominent"
ни java ни с# не просматривается ;)
[/QUOTE]
Вы хотите сказать, что на C++ применение шаблонов ускоряет работу программы? :) Добавление любых возможностей в мета-программировании, естественно влияет на производительность не самым лучшим образом.
Давайте будем объективными и поглядим, что в Википедии пишут про генериксы [url]http://en.wikipedia.org/wiki/Generic_programming[/url]
"The authors of the influential 1995 book Design Patterns refer to generics as 'parameterized types', which are also known as 'generics' (Ada, Eiffel, Java, C#) or 'templates' (C++)". Да, релизации разные, но суть и цели использования - те же.
А вообще если честно, имхо, изуродовали красивый и чистый язык.
Кстати, не скажете, почему в C# использовали именно генериксы? Ведь он унаследовал многое из С++, вроде как потомок считается? Может быть не только в производительности дело, а надо смотреть шире и захватывать другие выгоды? Если гоняться за производительностью, то надо брать в руки ассемблер и "ассемблировать".
[QUOTE=pal]
много чего пишут на непредназначенных для этого языках
[/QUOTE]
Угум, на C++ тоже пишут всё подряд от бестолковости или по незнанию альтернатив.
[QUOTE=pal]
это верно. сектор java - апплеты.
раньше я думал, что java это для rad. типа сляпать что-то одноразовое по быстрому. однако, это как раз технология, по которой производится большинство игр.
и почему-то их пишут на с++. арканоиды и прочие кваки для телефонов не рассматриваем - это ближе к апплетам.[/QUOTE]
[/QUOTE]
Дедушка, вы вспомнили апплеты? Когда последний раз вы видели апплеты на сайтах? Они умерли году в 98м кажется. И слава Богу.
Игры... да, как-то не сложилось. Из того, что знаю более-менее известное это Ил-2 Штурмовик, сам не видел, но народ _очень_ удивляется, когда узнаёт что написал движок на яве. Это просто штампы в мозгах пользователей, их надо вычищать оттуда.
Главная ниша явы сейчас - это серверсайд, написать можно ВСЁ что потребуется, буквально. Все инструменты есть, в огромном количестве и хорошего качества, с комьюнити вокруг этих инструментов. С версией 6.0 Сан ещё хочет закрепиться на десктопах, где ява до сих пор проигрывала по части скорости отрисовки GUI. В шестёрке сделали что-то невероятное, и теперь даже самые монстроидальные IDE у меня работаю с реактивностью Notepad'a.
арканоиды и кваки для телефонов это ниша микроявы, согласен. Кстати, почему если игры для десктопов пишут на С++ в основном, так с ним плохо обошлись на телефонах? ОС на тлефонах думаю на с+асм пишется, а они туда JVM пихают, java API реализуют, вот дураки...
[QUOTE=Gothy]Игры... да, как-то не сложилось. Из того, что знаю более-менее известное это Ил-2 Штурмовик, сам не видел, но народ _очень_ удивляется, когда узнаёт что написал движок на яве. Это просто штампы в мозгах пользователей, их надо вычищать оттуда.
[/QUOTE]
А я то думаю чего у меня Ил-2 тормозит, а квейк 4 - нет :rzhu_nimagu:
Ну теперь все ясно
[QUOTE=Gothy]
Всё что я знаю, это то, что выстроить логичное, стройное дерево наследования я могу в java не напрягаясь вопросами "скрещения" нескольких классов, я сделаю эту структуру на интерфейсах, и их методах. В такой структуре разбираться на порядок легче.[/QUOTE]
Я бы не сказал...
[QUOTE=Gothy]конечно, все программы на C++ тормозят по разному, но некоторые и поболе
[/quote]
медленные программы на с++ написанны людьми, не умеющими их оптимизировать. например, явистами, проводящими сравнительное тестирование.
в то же время ява ограничивает скорость by design
это четко прослеживается в вашей ненависти к шаблонам после знакомства с generics
можете назвать что-нибудь, что нельзя сделать на с++ быстрее, или так же ( если ява поступит идеально ) ?
привести пример обратного тривиально
[quote]
Не за что мне перед Вами извиняться. У меня только лишь сочувствие
Почему-то у многих людей складывается мнение "больше значит лучше" относительно едва ли не всех сфер жизни. Думаю объяснять, что такое мнение не всегда верно не нужно.
[/quote]
вы так и не поняли, чем отличается "больше" от "на усмотрение программиста".
это примерно как утверждать, что все функции должны состоять из одного оператора, потому что много операторов на функцию делают программу малопонятной, а с одним - все стройно и красиво, и компилятору легче.
и я ведь не говорю, что таких функций быть не должно, я говорю, что иногда требуются и другие. даже если не вам лично - ваши функции из одного оператора от этого не становятся менее красивыми или более медленными. т.е. минусов то никаких, кроме того, что компилятору приходится обрабатывать произвольное количество операторов в функции, грубо говоря, вместо одной переменной хранить их в массиве при обработке. но ваша программа от этого ничего не теряет
[quote]
Всё что я знаю, это то, что выстроить логичное, стройное дерево наследования я могу в java не напрягаясь вопросами "скрещения" нескольких классов, я сделаю эту структуру на интерфейсах, и их методах. В такой структуре разбираться на порядок легче.
[/quote]
лет 100 назад людям компьютеры были не нужны, потому что они мыслили другими категориями. даже если вам это не надо не потому, что вы к этому не привыкли, а потому, что на самом деле в ваших задачах не находит применения, все равно это нужно кому-то другому, потому и было включено в язык. причем, таким образом, чтобы вы никак не пострадали - без усложнения синтаксиса и прочих накладных расходов. в частности, множественное наследование применяется в iostreams, поэтому коссвенно используется в большинстве программ.
и, нет, это сделано не потому, что есть множественное наследование, а наоборот - множественное наследование есть потому, что там оно позволило добиться лучших результатов.
[quote]
Для меня это удивительно, и библиотеки я разрабатывал даже не задумываясь над перегрузкой операторов. Наверно я что-то не так делаю... и тысячи других явистов тоже. Давайте разгоним Apache Foundation, а то слишком они много библиотек на яве написали, они наверно гавно, без шаблонов и перегрузки операторов.
[/quote]
тысячи явистов делают то, чему их научили, а как мы знаем из ссылок выше по теме, учили их тому, чему научиться не трудно ;). у них же нет expression templates, используемых в идеальных бустовских библиотеках, так и перегрузка особо не нужна.
а апачи на разных языках пишут, в том числе и на с/с++
[quote]
Вы хотите сказать, что на C++ применение шаблонов ускоряет работу программы? Добавление любых возможностей в мета-программировании, естественно влияет на производительность не самым лучшим образом.
[/quote]
вы правы, я бы даже усилил это высказывание - Добавление любых возможностей _НЕ ТОЛЬКО_ в мета-программировании, естественно влияет на производительность _JAVA_ не самым лучшим образом.
а вот в с++ с помощью шаблонов вообще и частичной специализации в частности, производительность очень даже повышают. более того, в с++ просто не вводят средства, которые нельзя реализовать без накладных расходов - это один из принципов дизайна языка
[quote]
Давайте будем объективными и поглядим, что в Википедии пишут про генериксы [url]http://en.wikipedia.org/wiki/Generic_programming[/url]
"The authors of the influential 1995 book Design Patterns refer to generics as 'parameterized types', which are also known as 'generics' (Ada, Eiffel, Java, C#) or 'templates' (C++)". Да, релизации разные, но суть и цели использования - те же.
А вообще если честно, имхо, изуродовали красивый и чистый язык.
[/quote]
давайте не будем смотреть на то, что писали 12 лет назад о всего лишь одной из областей применения шаблонов. посмотрите на то, что с ними делают на с++ сейчас, и какое убожество предлагает ява
[quote]
Кстати, не скажете, почему в C# использовали именно генериксы? Ведь он унаследовал многое из С++, вроде как потомок считается?
[/quote]
еще спросите, почему генериксы из с# это совсем не такой обман трудящихся, как генериксы из явы
если бы они преследовали те же цели, что и создатели с++, то им не пришлось бы создавать новый язык.
что же до наследственности, то мне трудно сказать, кто у кого больше унаследовал - с# у явы или ява у с++.
[quote]
Может быть не только в производительности дело, а надо смотреть шире и захватывать другие выгоды? Если гоняться за производительностью, то надо брать в руки ассемблер и "ассемблировать".
[/quote]
скорость с++ - не единственное его преимущество, он еще гибче и мощнее.
писать на с++ по разному, а если хочется производительности, то это все равно будет значительно удобнее, чем на ассемблере. да и inline assembler никто не отменял, хоть это и не портабельно
[quote]
Угум, на C++ тоже пишут всё подряд от бестолковости или по незнанию альтернатив.
[/quote]
вообще-то, это язык общего назначения, так что на нем можно написать что угодно
другое дело, что узкоспециализированные инструменты могут быть эффективнее. а могут и не быть, если их надо слишком много
[QUOTE]
Дедушка, вы вспомнили апплеты? Когда последний раз вы видели апплеты на сайтах? Они умерли году в 98м кажется. И слава Богу.
[/quote]
апплету не обязательно выполняться в браузере, хотя и там они далеко не вымерли, правда большую часть пишут уже на флеше
[quote]
Игры... да, как-то не сложилось. Из того, что знаю более-менее известное это Ил-2 Штурмовик, сам не видел, но народ _очень_ удивляется, когда узнаёт что написал движок на яве. Это просто штампы в мозгах пользователей, их надо вычищать оттуда.
[/quote]
а я не удивлен, т.к. наслышан о его тормознутости ;)
[quote]
Главная ниша явы сейчас - это серверсайд, написать можно ВСЁ что потребуется, буквально. Все инструменты есть, в огромном количестве и хорошего качества, с комьюнити вокруг этих инструментов. С версией 6.0 Сан ещё хочет закрепиться на десктопах, где ява до сих пор проигрывала по части скорости отрисовки GUI. В шестёрке сделали что-то невероятное, и теперь даже самые монстроидальные IDE у меня работаю с реактивностью Notepad'a.
[/quote]
я все таки думаю, что самые большие надежды сантехники возлагают на gpl ;)
что там крутится на сервере не должно волновать никого кроме владельца сервера. некоторые пишут на лиспе и тащатся. я даже рад популярности явы в этом секторе - это мне дополнительное конкурентное преимущество ;)
но вот я имею опыт тесного общения с парой десктопных продуктов и временами хочется выть. не знаю, проблема в яве или в руках, но мне непонятно, как на таком якобы безопасном языке можно писать программы, которые либо зависают на неопределенный срок, либо падают, а в промежутках отъедают гигабайты, несмотря на хваленые сборщики мусора. наверное, как и всегда, это комплексная проблема.
[quote]
арканоиды и кваки для телефонов это ниша микроявы, согласен. Кстати, почему если игры для десктопов пишут на С++ в основном, так с ним плохо обошлись на телефонах? ОС на тлефонах думаю на с+асм пишется, а они туда JVM пихают, java API реализуют, вот дураки...[/QUOTE]
странно что вы не знаете основную цель создания вашего любимого языка. программу на ява не надо перекомпилировать под каждую новую микроволновку, это упрощает распространение программ для микроволновок с доступом в интернет и вертикальным взлетом
[QUOTE=pal]медленные программы на с++ написанны людьми, не умеющими их оптимизировать. например, явистами, проводящими сравнительное тестирование.
в то же время ява ограничивает скорость by design
это четко прослеживается в вашей ненависти к шаблонам после знакомства с generics
можете назвать что-нибудь, что нельзя сделать на с++ быстрее, или так же ( если ява поступит идеально ) ?
привести пример обратного тривиально
[/QUOTE]
С первым предложением согласен на 100%, могу добавить абсолютно тоже самое про программы написаные на Java.
Вы считаете, что все тесты, показывающие превосходство явы (в нек-рых аспектах) неадекватные? Я думаю можно поискать такие тесты и обнаужим там исходники для каждого теста на с++ и яве.
Ява ограничивает скорость? Я надеюсь что Вы просто написали не подумав. Ява ничего не ограничивает, наоборот, стремится от релиза к релизу быть быстрее, и пока это получается отлично. Единственная вина, которую можно яве выставить - это прослойка в виде jvm между ОС и программой, да эта прослойка не может влиять положительно на скорость выполнения, но это плата за удобство языка, скорость разработки и кроссплатформенность. Имхо, вполне адекватная плата.
И генериксы я совсем не из-за скорости не люблю, они просто уродуют код, документацию и нарушают целостность языка, который уже лет 10 практически не менялся, при этом став самым популярным на планете Земля.
На С++ думаю почти всё можно сделать быстрее, иначе бы не на нём писали опрационки, кроме того, в мире open source все с++ программы можно собрать с различными оптимизациями под свою систему, что ещё может повлиять на скорость выполнения. Кроме этого плюса в скорости и сомнительной полезности его "мощщи указателей" у с++ нет плюсов перед явой. Где эти плюсы лучше реализовать? Правильно, в системных приложениях, где ему и место. Хотя о ядрах ОС речь не идёт даже для него.
[QUOTE=pal]
лет 100 назад людям компьютеры были не нужны, потому что они мыслили другими категориями. даже если вам это не надо не потому, что вы к этому не привыкли, а потому, что на самом деле в ваших задачах не находит применения, все равно это нужно кому-то другому, потому и было включено в язык. причем, таким образом, чтобы вы никак не пострадали - без усложнения синтаксиса и прочих накладных расходов. в частности, множественное наследование применяется в iostreams, поэтому коссвенно используется в большинстве программ.
и, нет, это сделано не потому, что есть множественное наследование, а наоборот - множественное наследование есть потому, что там оно позволило добиться лучших результатов.
[/QUOTE]
Нагуглил тред на форуме, тред про С++ и "радости множественного наследования", это для подтверждения того, что я слышал уже не от одного знакомого с++ника. Странно, что остались люди, которые считают множестенное наследование плюсом С++.
[url]http://www.uic.rsu.ru/forum/msg.php?grp_id=1447[/url]
[QUOTE=pal]
тысячи явистов делают то, чему их научили, а как мы знаем из ссылок выше по теме, учили их тому, чему научиться не трудно ;). у них же нет expression templates, используемых в идеальных бустовских библиотеках, так и перегрузка особо не нужна.
а апачи на разных языках пишут, в том числе и на с/с++
[/QUOTE]
Интересно, что делают тысячи с++ников? Не то, чему учили? :)
Ничего идеального нет, это касается и библиотек.
На с++ они пишут только WebServer и плагины к нему, просто потому что так повелось с 94го года, когда начали его писать.
[QUOTE=pal]
более того, в с++ просто не вводят средства, которые нельзя реализовать без накладных расходов - это один из принципов дизайна языка
[/QUOTE]
Если бы этим принципом руководствовался Страуструп, то С++ вообще не появился бы.
[QUOTE=pal]
давайте не будем смотреть на то, что писали 12 лет назад о всего лишь одной из областей применения шаблонов. посмотрите на то, что с ними делают на с++ сейчас, и какое убожество предлагает ява
[/QUOTE]
Имхо, они убоги по своей сути, и от языка это не зависит.
[QUOTE=pal]
скорость с++ - не единственное его преимущество, он еще гибче и мощнее.
писать на с++ по разному, а если хочется производительности, то это все равно будет значительно удобнее, чем на ассемблере. да и inline assembler никто не отменял, хоть это и не портабельно
[/QUOTE]
Опять же, это я заметил за многими c++ программистами, вас тянет написать что-то, полезность чего довольно сомнительна. Вот сейчас предлагаете делать ассемблерные вставки. При этом сами же указываете на главный их минус.
Если бы С++ всё было так радужно, то с какой стати вообще появились бы Java и C#? Может всё-таки пора осознать, что программирование тоже должно эволюционировать, приобретая новые удобства и избавляясь от старых проблем. Сейчас не стоит проблема производительности вычислительных систем с которой надо было бороться 10 лет назад ассемблерными вставками. Ещё одна беда С++ - это поддержка кода, думаю Вы согласитесь, что в чужом коде разбираться трудно. Так вот в чужом коде на C++ трудность эта порой возрастает в разы. Это не было проблемой, когда над софтом работала кучка программистов в университетах и лабораториях, но сейчас это уже индустрия и нужны другие подходы, в частности - удобный стандартизированный и чистый язык, коим является Java.
[QUOTE=pal]
вообще-то, это язык общего назначения, так что на нем можно написать что угодно
другое дело, что узкоспециализированные инструменты могут быть эффективнее. а могут и не быть, если их надо слишком много
[/QUOTE]
Да, написать можно что угодно. Если цель просто написать - то вперёд.
В современном мире к производству ПО выдвигают побольше требований.
[QUOTE=pal]
апплету не обязательно выполняться в браузере, хотя и там они далеко не вымерли, правда большую часть пишут уже на флеше
[/QUOTE]
Забудьте про апплеты, это был просто страшный сон, коим сейчас стал флеш.
[QUOTE=pal]
а я не удивлен, т.к. наслышан о его тормознутости ;)
[/QUOTE]
А я наслышан о тормознутости doom3. А он вроде как и не на Java совсем...
[QUOTE=pal]
я все таки думаю, что самые большие надежды сантехники возлагают на gpl
что там крутится на сервере не должно волновать никого кроме владельца сервера. некоторые пишут на лиспе и тащатся. я даже рад популярности явы в этом секторе - это мне дополнительное конкурентное преимущество
но вот я имею опыт тесного общения с парой десктопных продуктов и временами хочется выть. не знаю, проблема в яве или в руках, но мне непонятно, как на таком якобы безопасном языке можно писать программы, которые либо зависают на неопределенный срок, либо падают, а в промежутках отъедают гигабайты, несмотря на хваленые сборщики мусора. наверное, как и всегда, это комплексная проблема.
[/QUOTE]
Программисты - вот главная беда, плохих - везде хватает.
Они и дедлок организуют, и вечный цикл, и утечки памяти и java тут н панацея, она может только помочь выявить эти вещи на этапе исполнения. В частности за эти воможности диагностики её и любят на серверах.
Для примера хороших десктопных приложений могу указать
[url]http://azureus.sourceforge.net/[/url] - лучший битторрент клиент, работает быстро и ещё не было замечено проблем с ним.
Конечно же, среды для разработки - Netbeans, Eclipse. Тоже не были замечены проблемы, разве что у Эклипсы из-за несовместимости версий модулей могут быть проблемы. Но это уже надо самому постараться так эти модули поставить.
Вот ещё список open-source проектов [url]http://www.java-source.net/[/url]
Опять же, больше наверно интересный для разработчиков. Мало десктопного софта сейчас пишут на яве, это как правило софт для внутреннего использования на производстве или в банках.
[QUOTE=pal]
странно что вы не знаете основную цель создания вашего любимого языка. программу на ява не надо перекомпилировать под каждую новую микроволновку, это упрощает распространение программ для микроволновок с доступом в интернет и вертикальным взлетом
[/QUOTE]
Я знаю эту цель, только я ещё знаю реальную ситуацию на мобильных телефонах. Там производителям насрать на эту совместимость, они длают то, что хотят и порой программа написаная по стандартной схеме, работающая на эмуляторах и, допустим, нокиях, оказывается кривой на Motorola. Так что полная кроссплатформенность пока нам только снится.
Радует то, что не надо прикладывать много усилий, для того, чтобы поддержать ещё 50 девайсов, это делается просто.
Меня этот спор уже начинает утомлять.
Мы к общему мнению не придём, как не приходят к нему же 15 лет :)
[QUOTE=Gothy]
А я наслышан о тормознутости doom3. А он вроде как и не на Java совсем...[/QUOTE]
:rzhu_nimagu: Не могу... Сравнили убогий Ил-2 с новым Doom 3. Сначала поиграйте потом поймете :rtfm:
[QUOTE=Gothy]
Имхо, они убоги по своей сути, и от языка это не зависит.[/QUOTE]
Оригинальное мнение "шаблоны - убоги" :)
[QUOTE=Gothy]при этом став самым популярным на планете Земля.[/QUOTE]
популярность смотрим [URL="http://www.tiobe.com/tpci.htm"]тут[/URL] ;)
[QUOTE=Gothy]
Если бы этим принципом руководствовался Страуструп, то С++ вообще не появился бы.
[/QUOTE]
Кстати, о Страуструпе. Вот, что он говорит в оригинале 3-го издания "The C++ Programming Language":
"One language is not necessarily better than another because it possesses a feature the other does not. There are many examples to the contrary. The important issue is not so much what features a language possesses, but that the features it does possess are sufficient to support the desired programming styles in the desired application areas"
Может, пора прислушаться к мнению умного человека и прекратить этот бессмысленный спор?
[QUOTE=Gothy]
Вы считаете, что все тесты, показывающие превосходство явы (в нек-рых аспектах) неадекватные? Я думаю можно поискать такие тесты и обнаужим там исходники для каждого теста на с++ и яве.
[/quote]
да, я так считаю. потому что на с++ за счет его гибкости можно сделать точно так же, как и на ява, а можно сделать и лучше, если ява поступает не оптимально
[quote]
Ява ограничивает скорость? Я надеюсь что Вы просто написали не подумав. Ява ничего не ограничивает, наоборот, стремится от релиза к релизу быть быстрее, и пока это получается отлично. Единственная вина, которую можно яве выставить - это прослойка в виде jvm между ОС и программой[/quote]
я как раз подумал. о том что jvm совершенно перпендикулярна языку. gcj компилирует яву напрямую в исполняемый код, а мелкомягкие компилируют с++ в байткод. компилировать можно любой язык как угодно, проблемы ява высокоуровневые а не в оптимизаторе.
например - все обьекты выделяются в куче, причем в одной и той же. в с++ обьект может располагаться в стеке, а может в куче, но при этом может использовать специальный аллокатор, в том числе и аналогичный явовскому со сборкой мусора. хоть это и не лучший вариант в большинстве приложений. специальный - это значит такой, как надо в данном конкретном случае. и это может быть очень быстро, вплоть до того, что выделение памяти компилируется в пару инструкций, а освобождение вообще представляет noop. и совершенно не важно, jvm там или нет: исправлением алгоритмов добиваются бОльших успехов, чем исправлением оптимизаторов.
[quote]
И генериксы я совсем не из-за скорости не люблю, они просто уродуют код, документацию и нарушают целостность языка, который уже лет 10 практически не менялся, при этом став самым популярным на планете Земля.
[/quote]
если бы они решились "изуродовать" еще и jvm, то и генериксы могли бы сделать на уровне с#. а так платят за совместимость уродством ;)
[quote]
Хотя о ядрах ОС речь не идёт даже для него.
[/quote]
я не проверял, но говорят, что beos написан на с++ с небольшим количеством асма в самом низу.
а одна из причин, по которой линух написан не на с++ - в то время gcc не совсем умел с++, а переписывать уже никто не будет.
[quote]
Нагуглил тред на форуме, тред про С++ и "радости множественного наследования", это для подтверждения того, что я слышал уже не от одного знакомого с++ника. Странно, что остались люди, которые считают множестенное наследование плюсом С++.
[url]http://www.uic.rsu.ru/forum/msg.php?grp_id=1447[/url]
[/quote]
на этом форуме васи жалуются на то, как они не разбираются в с++ или на то, какие убогие компиляторы у мелкомягких, а пети им указывают, что основные проблемы в васях. и что теперь ?
еще в каменном веке фирма багланд выпускала библиотеку turbovision. одновременно на c++ и паскале. в с++ они виртуально наследовали еще один класс для реализации аналога виртуального конструктора. а в паскале не могли и преимущество множественного наследования просто бросалось глаза. хотя, кто-то может подумать, что в с++ они старательно извращались чтобы продемонстрировать его недостатки перед паскалем ;)
[quote]
Интересно, что делают тысячи с++ников? Не то, чему учили? :)
Ничего идеального нет, это касается и библиотек.
На с++ они пишут только WebServer и плагины к нему, просто потому что так повелось с 94го года, когда начали его писать.
[/quote]
среди тысяч с++ников, много таких, которые не в состоянии осилить с++, но почему-то не переходят на что-то попроще, вроде явы.
как правило программы из прошлого тысячелетия пишут не на с++, а на чем-то странном, больше похожем на смесь с с явой, чем на с++. особенно, если стараются добиться переносимости на компиляторы странных фирм той же эпохи.
[quote]
Если бы этим принципом руководствовался Страуструп, то С++ вообще не появился бы.
[/quote]
он автор этого принципа и пока что его отлично придерживался. на с++ можно сделать все, что можно сделать на с
[quote]
Имхо, они убоги по своей сути, и от языка это не зависит.
[/quote]
вы ж не знакомы с их сутью. вы знакомы с сутью костыля из ява, а с убожеством костылей никто не спорит
[quote]
Опять же, это я заметил за многими c++ программистами, вас тянет написать что-то, полезность чего довольно сомнительна. Вот сейчас предлагаете делать ассемблерные вставки. При этом сами же указываете на главный их минус.
[/quote]
я не предлагал делать ассемблерных всавок, как и не предлагал пользоваться множественным наследованием или каким-то другим средством. я говорил, что этим можно воспользоваться при необходимости. а знать недостатки надо, чтобы сравнивать их с получаемыми преимуществами
[quote]
Если бы С++ всё было так радужно, то с какой стати вообще появились бы Java и C#?
[/quote]
во первых, с с++ не все радужно, хоть и по радужнее, чем с явой. во вторых, ява с с# появились потому что сантехники с мелкомягкими хотели зарабатывать деньги, контролируя языки.
в третьих, языков вообще миллион, и некоторые даже существуют не зря. но это не значит, что каждый новый лучше старого, тем более, что старые тоже не стоят на месте.
[quote]
Может всё-таки пора осознать, что программирование тоже должно эволюционировать, приобретая новые удобства и избавляясь от старых проблем.
[/quote]
c++ эволюционирует, с# эволюционирует, а в яве, ради сохранения совместимости jvm, генериксы сделали такими, что ими никто не хочет пользоваться ;) а ведь могли бы сделать на уровне с с#
[quote]
Сейчас не стоит проблема производительности вычислительных систем с которой надо было бороться 10 лет назад ассемблерными вставками.
[/quote]
lol
google://Software becomes slower faster than hardware becomes faster
[quote]
Ещё одна беда С++ - это поддержка кода, думаю Вы согласитесь, что в чужом коде разбираться трудно. Так вот в чужом коде на C++ трудность эта порой возрастает в разы.
[/quote]
c++ вообще сложнее для понимания, но это не значит, что на нем нельзя писать код, легко понятный тем, кто знаком с языком
[quote]
Это не было проблемой, когда над софтом работала кучка программистов в университетах и лабораториях, но сейчас это уже индустрия и нужны другие подходы, в частности - удобный стандартизированный и чистый язык, коим является Java.
[/quote]
индустрия по утилизации легкодоступной необразованной рабочей силы
ява не является стандартизированным языком, в отличие от с++
чист он только с точки зрения его маркетологов
удобен он только тем, что ему легче обучить людей, неспособных писать приличные программы
[quote]
Да, написать можно что угодно. Если цель просто написать - то вперёд.
В современном мире к производству ПО выдвигают побольше требований.
[/quote]
в данном случае одно требование - найти миллион индусов, способных на этом писать. естественно, что людей, способных хорошо писать на с++, на порядок меньше.
[quote]
А я наслышан о тормознутости doom3. А он вроде как и не на Java совсем...
[/quote]
про д3 я могу много рассказать, но это не по теме
[quote]
Программисты - вот главная беда, плохих - везде хватает.
Они и дедлок организуют, и вечный цикл, и утечки памяти
[/quote]
но, как доступно описал joel, при обучении ява такие товарищи не осознают своей бесполезности и не отсеиваются
[quote]
и java тут н панацея, она может только помочь выявить эти вещи на этапе исполнения. В частности за эти воможности диагностики её и любят на серверах.
[/quote]
c++ при желании может все то же самое и даже больше
[quote]
Для примера хороших десктопных приложений могу указать
[url]http://azureus.sourceforge.net/[/url] - лучший битторрент клиент, работает быстро и ещё не было замечено проблем с ним.
Конечно же, среды для разработки - Netbeans, Eclipse.
[/quote]
к несчастью, azureus и eclipse - мои самые используемые программы на яве и я их просто ненавижу
[quote]
Меня этот спор уже начинает утомлять.
Мы к общему мнению не придём, как не приходят к нему же 15 лет :)[/QUOTE]
мне все равно, на чем вы пишите, только не рассказывайте мне о недостатках с++, которых в нем нет. не то, чтобы в нем не было недостатков, просто вам они скорей всего неизвестны, т.к. находятся в областях, с которыми вы не знакомы.
Жуть, ну и спор раскатился на 10-ки страниц. Вместо того, чтобы спорить, вспомните все полезные приложения, созданные для мобильника и мультимедийные приложения для винды.
На сегодняшний день Ява популярна лишь своей простотой, которая позволяет не напрягаясь создавать прилодения не залязя в ресурсы ОС.
При улучшении процессоров и оперативы на ней все и будет писаться.
Конкуренция - СиШарп.
Думаю, что спор исчерпан, и опускание одними программистами других - абсурд. Прошу заметить создетеля данного топика.
[QUOTE=pavlentus]
При улучшении процессоров и оперативы на ней все и будет писаться.
[/QUOTE]
можно было бы прочесть предыдущий пост, чтобы не повторять глупости ;)
[QUOTE=firejump]Коллеги как по мне спор ни о чем.
У той и другой технологии масса достоинств и недостатков, а также [b]свои сферы применения[/b].[/QUOTE]
хоть один человек здравую мысль написал. сравниваете порш кайен с камазом и спорите до посинения.
[QUOTE=pavlentus]Думаю, что спор исчерпан, и опускание одними программистами других - абсурд. Прошу заметить создетеля данного топика.[/QUOTE]
Не нравится не пиши ;) И прошу других тоже заметить что никто никого не заставляет.
[QUOTE=pal]
мне все равно, на чем вы пишите, только не рассказывайте мне о недостатках с++, которых в нем нет. не то, чтобы в нем не было недостатков, просто вам они скорей всего неизвестны, т.к. находятся в областях, с которыми вы не знакомы.[/QUOTE]
Расскажи о недостатках ! :) (достоинства я знаю ;))
[url]http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html[/url]
[QUOTE=pal][url]http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html[/url][/QUOTE]
И что это ?
Alien vs Predator продолжается :)
[QUOTE=THRESHE]
популярность смотрим [URL="http://www.tiobe.com/tpci.htm"]тут[/URL] ;)[/QUOTE]
Угум, именно там смотрим и... видим надеюсь, кто на первом месте?
[QUOTE=Gothy]Угум, именно там смотрим и... видим надеюсь, кто на первом месте?[/QUOTE]
Если не учитывать что С и С++ должны идти вместе ;)
Вообще-то я и вовсе не хотел влезать в топик, спор действительно бессмысленен. С++ может быть 100 раз хорош, но кушать пока на яве можно сытнее, при этом получая наслаждение от работы :)
[QUOTE=Gothy]Вообще-то я и вовсе не хотел влезать в топик, спор действительно бессмысленен.:)[/QUOTE]
Тогда пока, удачи !
[QUOTE=Gothy]
при этом получая наслаждение от работы :)[/QUOTE]
Да мы Сишники на работе как на каторге :)
[QUOTE=THRESHE]
Да мы Сишники на работе как на каторге :)[/QUOTE]
Я знаю! Каждый день вас бедных наблюдаю :)
[QUOTE=THRESHE]Не нравится не пиши ;) И прошу других тоже заметить что никто никого не заставляет.
Расскажи о недостатках ! :) (достоинства я знаю ;))[/QUOTE]
Это о С++? - На раз-два.
1) точка с запятой в конце объявления класса. Убил бы.
2) два синтаксиса доступа к статическим и не статическим членам
(:: и .) , причем, :: еще используется для открытия области видимости.
3) Си-шный двумерный массив, который передавать можно только как одномерный.
4) Задолбенистый способ ограничения видимости через два спецификатора, один в заголовке объявления, другой - внутри.
5) Несколько способов объявления inline.
6) Аппаратно-зхависимая интерпритация размерности основных типов.
(во радость-то, int на разных платформах может быть 16,32,64...)
7) Два способа инициализации членов класса: после двояточия и через
равенстово в конструкторе.
8) Отсутствие инициализации членов при объявлении.
9) Несколько разных синтаксисов объявления inline.
10) Отсутствие в языке нормальных строк.
Да, еще обожаю писать class template в объявлении темплейтов
на каждом углу.
Это так, на вскидку - не задумываясь.
[QUOTE=lexar]точка с запятой в конце объявления класса. Убил бы.[/QUOTE]
Это большая помеха ?
[QUOTE=lexar]Аппаратно-зависимая интерпритация размерности основных типов.
(во радость-то, int на разных платформах может быть 16,32,64...)
[/QUOTE]
Для этого есть sizeof () ;)
[QUOTE=lexar]Отсутствие в языке нормальных строк.[/QUOTE]
что это за ненормальные строки ? :)
[QUOTE=lexar]Два способа инициализации членов класса: после двояточия и через
равенстово в конструкторе.[/QUOTE]
Тоже мне недостаток =)
[QUOTE=lexar]
1) точка с запятой в конце объявления класса. Убил бы.
[/quote]
#include <iostream>
int f = 1;
void g ( ) {
class C { public: C ( int ) { } } f = 0;
}
int main ( ) {
g();
std :: cout << f << std :: endl;
}
что по вашему должна выводить эта программа ? ;)
врядли необходимость вписывать один символ можно считать проблемой, т.к. компилятор сообщает о пропущенных точках с запятой
[quote]
2) два синтаксиса доступа к статическим и не статическим членам
(:: и .) , причем, :: еще используется для открытия области видимости.
[/quote]
#include <iostream>
int main ( ) {
class B { public: static void f ( ) { std :: cout << "B\n"; } };
class A { public: void f ( ) { std :: cout << "A\n"; } };
A B;
B.f ( );
}
а эта ?
[quote]
3) Си-шный двумерный массив, который передавать можно только как одномерный.
[/quote]
с этого момента поподробнее
[quote]
4) Задолбенистый способ ограничения видимости через два спецификатора, один в заголовке объявления, другой - внутри.
[/quote]
тоже непонятно, о чем речь
[quote]
5) Несколько способов объявления inline.
[/quote]
это о том, что функции, описанные внутри класса получают inline по умолчанию ? дык, это ж тот самый syntactic shugar, за отсутствие которого ругают с++ ;)
не говоря уже о том, что оптимизирующий компилятор сам инлайнит все, что сочтет нужным и не инлайнит все, что не сочтет
[quote]
6) Аппаратно-зхависимая интерпритация размерности основных типов.
(во радость-то, int на разных платформах может быть 16,32,64...)
[/quote]
int имеет размер натурального машинного слова платформы. и не припомню, чтобы он мог быть 64 бит.
даже в с есть стандартные типы int{8,16,32,64}_t и компания
пользуйтесь на здоровье
[quote]
7) Два способа инициализации членов класса: после двояточия и через
равенстово в конструкторе.
[/quote]
не путайте инициализацию и присваивание, это совершенно разные вещи. инициалицировать можно только после двоеточия, в том числе и неявно
[quote]
8) Отсутствие инициализации членов при объявлении.
[/quote]
опять непонятно, о чем речь
[quote]
9) Несколько разных синтаксисов объявления inline.
[/quote]
это вроде уже было
[quote]
10) Отсутствие в языке нормальных строк.
[/quote]
нормальные строки входят в состав стандартной библитеки, которая поставляется с каждым компилятором. в качестве бонуса, каждый может реализовать еще более нормальные нестандартные строки по своему усмотрению
[quote]
Да, еще обожаю писать class template в объявлении темплейтов
на каждом углу.
[/quote]
если приведете конкретный пример, я объясню, зачем это нужно.
[quote]
Это так, на вскидку - не задумываясь.[/QUOTE]
такое впечатление, что вы знакомы с языком поверхностно и возмущены тем, что компилятор не догадывается о вашем желании писать на подмножестве языка
[QUOTE=THRESHE]И что это ?[/QUOTE]
судя по названию, список недостатков ;)
[QUOTE=pal]
такое впечатление, что вы знакомы с языком поверхностно и возмущены тем, что компилятор не догадывается о вашем желании писать на подмножестве языка[/QUOTE]
Неа.
Все гораздо проще:
я просто, может не совсем корректно, перечислил то,
что поправили в более поздних языках.
Извините, не напрягался и более подробно расшифровывать свои пункты не буду (типа и не напрягусь)
Но идея простая:
языки развиваются.
И С++, послуживший основой для Java и C#,
имеет достаточно кривых синтаксических и семантических конструкций,
которые поправили.
Поэтому - недостатки есть, отрицать их бессмысленно.
И вообще, идеальных решений не бывает.
Говорить "не вижу недостатков" в какой-либо области,
это либо лукавить, либо ... действительно не видеть :)
Но лучше видеть :rolleyes:
[QUOTE=lexar]Неа.
я просто, может не совсем корректно, перечислил то,
что поправили в более поздних языках.
[/QUOTE]
поправили так, что теперь вместо
class A { } a;
надо писать
class A { }
A a;
?
или что теперь нельзя объявлять локальные классы внутри функций ?
голову отрубили а насморк остался ;)
[QUOTE=pal]поправили так, что теперь вместо
class A { } a;
надо писать
class A { }
A a;
?
или что теперь нельзя объявлять локальные классы внутри функций ?
голову отрубили а насморк остался ;)[/QUOTE]
А я и не говорил, что насморк не останется.
Просто, языки развиваются.
Для совместимости остается весь старый синтаксис.
Естественно это местами криво.
Есть более серьезные проблемы.
Например, С++ - однопоточный язык.
Все поточные средства - внешние.
Ява и C# - многопоточные,
что уже приятно.
[QUOTE=pal]
не говоря уже о том, что оптимизирующий компилятор сам инлайнит все, что сочтет нужным и не инлайнит все, что не сочтет :rzhu_nimagu:
[/QUOTE]
Повеселили.
Ваше утверждение противоречить принципу раздельной компиляции.
Компилятор не может инлайнить все что сочтет нужным -
потому как не знает, кто рвется к вашей функции из другого объектного модуля.
Он может пытаться инлайнить только явный инлайн!
Если получится :)
[QUOTE=lexar]С++ - однопоточный язык.
Все поточные средства - внешние.
Ява и C# - многопоточные,
что уже приятно.[/QUOTE]
пока что ни один язык с родной поддержкой потоков не делал этого полноценно. примерно как с вводом/выводом
[quote]
Повеселили.
Ваше утверждение противоречить принципу раздельной компиляции.
Компилятор не может инлайнить все что сочтет нужным -
потому как не знает, кто рвется к вашей функции из другого объектного модуля.
Он может пытаться инлайнить только явный инлайн!
Если получится
[/quote]
при такой безграмотности в пору плакать а не веселиться ;)
ничто не мешает рваться из другого модуля даже к функции, явно объявленной inline. так что в любом случае все функции, которые должны быть видны снаружи, будут видны снаружи, независимо от того, сколько раз они подставлялись внутри модуля.
[QUOTE=pal]судя по названию, список недостатков ;)[/QUOTE]
Не похоже ;) Или недостатков на несколько десятков страниц :confusion:
[QUOTE=pal]пока что ни один язык с родной поддержкой потоков не делал этого полноценно. примерно как с вводом/выводом
при такой безграмотности в пору плакать а не веселиться ;)
ничто не мешает рваться из другого модуля даже к функции, явно объявленной inline. так что в любом случае все функции, которые должны быть видны снаружи, будут видны снаружи, независимо от того, сколько раз они подставлялись внутри модуля.[/QUOTE]
Господин хороший, вы говорили не о явном объявлении,
а об "умном компиляторе", который сам решает.
Что будет если я построю библиотеку,
в которой компилятор по своему усмотрению
решил реализовать какую-то функцию, как инлайн?
Ее просто не будет!
К ней не прилинкуешься.
Так что инлайн реализуется по возможности при явном
объявлении функции в качестве inline.
И то только по возможности.
Это рекомендательное объявление.
Прежде чем на меня наезжать,
следите пожалуйста за собственными утверждениями.
[QUOTE=lexar]Господин хороший, вы говорили не о явном объявлении,
а об "умном компиляторе", который сам решает.
Что будет если я построю библиотеку,
в которой компилятор по своему усмотрению
решил реализовать какую-то функцию, как инлайн?
Ее просто не будет!
К ней не прилинкуешься.
Так что инлайн реализуется по возможности при явном
объявлении функции в качестве inline.
И то только по возможности.
Это рекомендательное объявление.
Прежде чем на меня наезжать,
следите пожалуйста за собственными утверждениями.[/QUOTE]
читайте внимательно, а то я утомлюсь повторяться.
к любой не статик функции можно будет прилинковаться, независимо от того инлайн она или нет. то, что компилятор подставляет функцию вместо вызова, никак не мешает ему сгенерить ее тело для внешней связи.
может вам показать, как это выглядит в промежуточном ассемблерном исходнике, чтобы вы успокоились ?
[QUOTE=THRESHE]Не похоже ;) Или недостатков на несколько десятков страниц :confusion:[/QUOTE]
ну, на список достоинств тоже не похоже ;)
[QUOTE=pal]ну, на список достоинств тоже не похоже ;)[/QUOTE]
Помоему это просто изложение стандарта С++
[QUOTE=THRESHE]Помоему это просто изложение стандарта С++[/QUOTE]
нет, active issues - это неразрешенные разногласия
в стандарт могут попасть только их разрешения
[QUOTE=pal]читайте внимательно, а то я утомлюсь повторяться.
к любой не статик функции можно будет прилинковаться, независимо от того инлайн она или нет. то, что компилятор подставляет функцию вместо вызова, никак не мешает ему сгенерить ее тело для внешней связи.
может вам показать, как это выглядит в промежуточном ассемблерном исходнике, чтобы вы успокоились ?[/QUOTE]
Вы утверждаете что это определено стандартом языка?
Что это справедливо для всех компиляторов?
[QUOTE=pal]читайте внимательно, а то я утомлюсь повторяться.
к любой не статик функции можно будет прилинковаться, независимо от того инлайн она или нет. то, что компилятор подставляет функцию вместо вызова, никак не мешает ему сгенерить ее тело для внешней связи.
может вам показать, как это выглядит в промежуточном ассемблерном исходнике, чтобы вы успокоились ?[/QUOTE]
Что бы не быть голословным.
Только что. Мелкомягкая студия 2005
Консольное приложение на с++
Файл 1:
#include "stdafx.h"
#include <iostream>
using namespace std;
void f();
void z();
int _tmain(int argc, _TCHAR* argv[])
{
z();
return 0;
}
inline void f() {cout << "aaa"<<endl;}
Файл 2:
#include "stdafx.h"
void f();
void z()
{
f();
}
КАК И СЛЕДОВАЛО ОЖИДАТЬ
ЕСЛИ УБРАТЬ INLINE - ВСЕ РАБОТАЕТ
C INLINE - ОШИБКА ЛИНКОВКИ.
Error 1 error LNK2019: unresolved external symbol "void __cdecl f(void)" (?f@@YAXXZ) referenced in function "void __cdecl z(void)" (?z@@YAXXZ) z.obj
БОЛЕЕ ТОГО: ТАК ОНО И ДОЛЖНО БЫТЬ.
КОМПИЛЯТОР НЕ ОБЯЗАН ЛЕПИТЬ ГОРБАТОГО,
ТАМ ГДЕ ЕМУ ЭТОГО НЕ УКАЗЫВАЛИ.
[QUOTE=lexar]Вы утверждаете что это определено стандартом языка?
Что это справедливо для всех компиляторов?[/QUOTE]
ээ
я полагаю, что стандартом определено, что если функция обьявлена не статик, то она должна быть доступна из других единиц трансляции. а вот, вызывать ее напрямую или подставлять ее код, стандарт не оговаривает - это проблемы разработчиков компилятора.
я говорил не о всех компиляторах, а об оптимизирующих.
наверняка, какая-нибудь фирма багланд выпускает компиляторы, не умеющие самостоятельно встраивать функции, но мы не будем эти пародии считать оптимизирующими компиляторами ;)
[QUOTE=pal]ээ
я полагаю, что стандартом определено, что если функция обьявлена не статик, то она должна быть доступна из других единиц трансляции. а вот, вызывать ее напрямую или подставлять ее код, стандарт не оговаривает - это проблемы разработчиков компилятора.
я говорил не о всех компиляторах, а об оптимизирующих.
наверняка, какая-нибудь фирма багланд выпускает компиляторы, не умеющие самостоятельно встраивать функции, но мы не будем эти пародии считать оптимизирующими компиляторами ;)[/QUOTE]
Да доступна она,
доступна.
Только через #include.
Потому их всегда и объявляют в h файлах,
хотя стандартом это не определено.
Но я уверен, что мало найдется компиляторов,
которые вздумают генерировать ее как внешнюю.
Бред это.
А в каком месте, извините,
если она будет включена в несколько файлов?
Это же будет дупликат, линковка опять не пройдет.
[QUOTE=lexar]
КАК И СЛЕДОВАЛО ОЖИДАТЬ
ЕСЛИ УБРАТЬ INLINE - ВСЕ РАБОТАЕТ
C INLINE - ОШИБКА ЛИНКОВКИ.
[/QUOTE]
попробуйте вызвать функцию в том файле, где она определена. примерно так
[pal@underdark tmp]$ cat a.cpp
void g ( );
inline void f ( ) { }
int main ( ) {
f ( );
g ( );
}
[pal@underdark tmp]$ cat b.cpp
void f ( );
void g ( ) {
f ( );
}
[pal@underdark tmp]$ g++ -Wall -Wextra -o a a.cpp b.cpp
[pal@underdark tmp]$ ./a
это несколько надуманный пример, реальный пример будет с использованием #pragma interface/implementation и там будет все в порядке.
однако, мы отклонились от темы.
началось с того, что вы утверждали, что компилятор не может встраивать функции по собственному желанию,
а пример несколько о другом!
[QUOTE=lexar]Да доступна она,
доступна.
Только через #include.
Потому их всегда и объявляют в h файлах,
хотя стандартом это не определено.
[/quote]
когда я говорил "доступна", речь шла о стадии линковки
при чем тут заголовки ?
[quote]
Но я уверен, что мало найдется компиляторов,
которые вздумают генерировать ее как внешнюю.
[/quote]
вы сами с собой разговариваете ?
с чего функцию, которая не статик генерить как не статик ?
не знаю. наверное потому, что она не статик
[quote]
Бред это.
[/quote]
согласен
[quote]
А в каком месте, извините,
если она будет включена в несколько файлов?
Это же будет дупликат, линковка опять не пройдет.[/QUOTE]
внимание, вопрос. если есть функция
inline int f ( ) {
static int counter = 0;
return ++ counter;
}
то где генерить этот counter и будет ли каждый файл считать его отдельно от других?
(spoiler warning: ответ: у всех адекватных линкеров есть некоторое понятие о common sections и они совмещаются при линковке )
в общем, чего тут спорить
смотрим стандарт
7.1.2.6
---------------
An inline function with external linkage
shall have the same address in all translation units. A static local variable in an extern inline function always
refers to the same object
-----------------
что такое external linkage и во что выливается shall have the same address in all translation units, объяснять или самми разберетесь ?
а так же
7.1.2.2
A function declaration (8.3.5, 9.3, 11.4) with an inline specifier declares an inline function. The inline specifier indicates to the implementation that inline substitution of the function body at the point of call is to be preferred to the
usual function call mechanism. An implementation is not required to perform this inline substitution at the point of
call; however, even if this inline substitution is omitted, the other rules for inline functions defined by 7.1.2 shall still be
respected.
An inline function with external linkage :rtfm:
Ход мыслей правильный, но вывод не верный :)
Речь идет о функциях с внешней линковкой,
которые так и описываются, как
extern inline,
что я собственно и утверждал:
компилятор не будет гнать пургу без дополнительного указания (extern).
Скажем, что бы мой пример приведенный выше заработал,
я должен был в файле 1 написать:
extern inline void f() {cout << "aaa"<<endl;}
а в файле 2:
extern inline void f();
void z()
{
f();
}
Другими словами, вы пытаетесь доказать более общее утверждение частным примером (вы утверждали, что компилятор сам решает, что лепить в инлайн, и при этом еще и сам реализует для инлайн внешнюю
линковку). На деле же, все иначе. Для внешней линковки нужно
специальное объявление.
Кстати, вы продемонстрировали еще один
семантический недостаток языка С++:
он позволяет описать inline-функию так,
что она явно будет не inline.
[QUOTE=lexar]An inline function with external linkage :rtfm:
Ход мыслей правильный, но вывод не верный :)
Речь идет о функциях с внешней линковкой,
которые так и описываются, как
extern inline,
что я собственно и утверждал:
компилятор не будет гнать пургу без дополнительного указания (extern).
Скажем, что бы мой пример приведенный выше заработал,
я должен был в файле 1 написать:
extern inline void f() {cout << "aaa"<<endl;}
а в файле 2:
extern inline void f();
void z()
{
f();
}
[/quote]
двойка
все функции extern, если явно не указано, что они static.
чтобы пример заработал, я вам сказал использовать функцию в том файле, иначе компилятор ее генерить не будет; а указывание ей избыточного спецификатора ничего не изменит.
[quote]
Другими словами, вы пытаетесь доказать более общее утверждение частным примером (вы утверждали, что компилятор сам решает, что лепить в инлайн
[/quote]
я это утверждал об оптимизирующих компиляторах. и до сих пор утверждаю - это легко увидеть, посмотрев на генерируемый код. но пример с внешней линковкой совсем не доказывает мое утверждение, а всего лишь опровергает ваш нелепый аргумент о том, что inline имеет какое-то отношение к linkage specification.
[quote]
, и при этом еще и сам реализует для инлайн внешнюю
линковку)
[/quote]
сам он этого не делает, инлайн и линковка - независимые понятия.
[quote]
На деле же, все иначе. Для внешней линковки нужно
специальное объявление.
[/quote]
в каком пту вас научили, что inline значит static ? хватит демонстрировать свою безграмотность, подучите предмет.
[quote]
Кстати, вы продемонстрировали еще один
семантический недостаток языка С++:
он позволяет описать inline-функию так,
что она явно будет не inline.[/QUOTE]
я не понимаю, для кого я цитировал стандарт. inline это совет(hint), что желательно(но необязательно!) функцию подставлять. какое отношение этот совет имеет к семантике ?
язык с++ позволяет собирать отладочные версии быстрее и так что их потом легче отлаживать - это не только не семантический, но и не недостаток вообще
[QUOTE=pal]двойка
все функции extern, если явно не указано, что они static.
чтобы пример заработал, я вам сказал использовать функцию в том файле, иначе компилятор ее генерить не будет; а указывание ей избыточного спецификатора ничего не изменит.[/QUOTE]
Блин,
да возмите компилятор и проверьте,
чем отличается
inline
от
extern inline
Перед тем как вам отвечать я не поленился перечитать стандарт
и все проверить на примере в проекте.
Чего и вам желаю.
смотрим, что пишут в стандарте
[quote]
7.1.1
The specifiers that can be used in a declaration are
decl-specifier:
storage-class-specifier
type-specifier
function-specifier
friend
typedef
[/quote]
storage-class-specifier и function-specifier - разные вещи
[quote]
7.1.2.1
Function-specifiers can be used only in function declarations.
function-specifier:
inline
virtual
explicit
[/quote]
inline это function-specifier
[quote]
7.1.1.1
The storage class specifiers are
storage-class-specifier:
auto
register
static
extern
mutable
[/quote]
static i extern это storage-class-specifier
[quote]
7.1.1.6
A name declared in a namespace scope without a storage-class-specifier has external linkage unless it has internal
linkage because of a previous declaration and provided it is not declared const. Objects declared const and not
explicitly declared extern have internal linkage.
[/quote]
и так, по умолчанию, in a namespace scope все что не const, ролучает external linkage
[quote]
7.1.1.7
The linkages implied by successive declarations for a given entity shall agree. That is, within a given scope, each
declaration declaring the same object name or the same overloading of a function name shall imply the same linkage.
Each function in a given set of overloaded functions can have a different linkage, however. [ Example:
static char * f (); / / f() has internal linkage
char * f () / / f() still has internal linkage
{ /∗ . . . ∗/ }
char * g (); / / g() has external linkage
static char * g () / / error: inconsistent linkage
{ /∗ . . . ∗/ }
void h ();
inline void h (); / / external linkage
inline void l ();
void l (); / / external linkage
inline void m ();
extern void m (); / / external linkage
static void n ();
inline void n (); / / internal linkage
[/quote]
как бы вы объяснили / / external linkage напротив инлайн функций h, l и m ?
вы какой-то не тот стандарт читаете
c компилятором я проверил еще на первом примере
static inline отличается от inline, а extern inline - не отличается
у вас не только стандарт странный, но и компилятор. может, это стандарт вашего компилятора ? ;)
Согласен, ваши цитаты можно интерпретировать так:
inline всегда имеет extern linkage
Я тестируют на MS студии 2005
В принципе, то что по умолчанию inline вообще не имеет linkage,
очевидно - она подставляется.
Если бы было иначе - то инклюд файла с инлайн-функцией
в нескольких сpp файлах приводил бы к дупликату внешних ссылок
и ошибокам линковки.
Сам при прграммировании сталкивался с этим не раз,
когда случайно пропускал объявление inline.
Ваши возражения? Как избегаются дупликаты?
я уже говорил, как они избегаются
так же как и дубликаты статических переменных внутри инлайн функций
стандарт не говорит о том, какой должен быть линкер, он говорит только о том, чего надо добиться, а как это сделать - забота разработчиков
в частности, если стандарт говорит, что инлайн функция во всех модулях должна иметь один и тот же адрес, то натуральное решение - привлечь на помощь линкер, т.к. именно он и назначает адреса. соответственно, функция помещается в специальную секцию, в которой при линковке все символы с одним именем из разных модулей совмещаются
естественно, если адрес функции в модуле не используется, то и не надо добиваться его идентичности с адресами из других модулей, в частности поэтому gcc не генерирует тело функции если не было его вызова, или если вызов был, но оптимизатор заметил, что функция пустая и ее можно и не вызывать
простой способ добиться 100% использования адреса:
inline void f ( ) { }
typedef void ( * vfp ) ( );
vfp g ( ) {
return f;
}
однако, это все имеет мало отношения к изначальному вопросу о том, могут ли компиляторы (не)подставлять функции по своему усмотрению ( в том числе и при использовании соответсвующих параметров компилятора, регулирующих уровень оптимизации )
Согласен, что такая реализация линкера возможна,
хотя я и не сталкивался.
Впрочем, все это наверняка должно управляться.
С точки зрения оптимизации по памяти не нормально
делать подстановку и одновременно генерировать тело фукции для внешней ссылки,
если в этом нет необходимости.
[QUOTE=lexar]
С точки зрения оптимизации по памяти не нормально
делать подстановку и одновременно генерировать тело фукции для внешней ссылки[/QUOTE]
ну, тут не все просто.
в другом файле может браться адрес этой функции, а т.к. для этого не нужно знать тело функции, то там может быть доступен только прототип. и этому указателю надо на что-то указывать, т.е. где-то тело функции должно быть. в теории это все решается, но на практике это не просто и требуется помощь программиста в виде специфических параметров компилятору.
на bash.org нашел:
У каждого языка есть свои плюсы - но у С++ их целых 2!
;-)
[QUOTE=homo ludens]на bash.org нашел:
У каждого языка есть свои плюсы - но у С++ их целых 2!
;-)[/QUOTE]
Это точно :rzhu_nimagu:
Вы все еще стираете на Си++? Мы к Вам прийдем и покажем как надо стирать качественным стиральным языком Медвед.
[QUOTE=homo ludens]на bash.org нашел:
У каждого языка есть свои плюсы - но у С++ их целых 2!
;-)[/QUOTE]
Исходя из такой мнемоники C# - это C в тюремной камере :)
[QUOTE=lexar]Исходя из такой мнемоники C# - это C в тюремной камере :)[/QUOTE]
Бедняга, на хлебу и воде :)
"The C Programming Language -- A language which combines the
flexibility of assembly language with the power of assembly language."
о пользе garbage collector'ов
не то, чтобы с++ не мог их использовать, но тут, по крайней мере, есть выбор
я только что узнал причину одного из неисправимых преимуществ программ на яве - регулярных свопометов
если программа сознательно что-то кеширует в памяти или если просто хранит много данных, только маленькая часть из которых используется часто, то современные операционные системы вытесняют неиспользуемые данные в своп и там они никому не мешают
но не тут-то было: сборщик мусора будет с упорством, достойным лучшего применения, их сканировать, вытесняя реально полезную память других программ
другими словами, использование сборщиков мусора иначе, как вредительством, и не назовешь
[QUOTE=pal]о пользе garbage collector'ов
не то, чтобы с++ не мог и использовать, но тут, по крайней мере, есть выбор
я только что узнал причину одного из неисправимых преимуществ программ на яве - регулярных свопометов
если программа сознательно что-то кеширует в памяти или если просто хранит много данных, только маленькая часть из которых используется часто, то современные операционные системы вытесняют неиспользуемые данные в своп и там они никому не мешают
но не тут-то было: сборщик мусора будет с упорством, достойным лучшего применения, их сканировать, вытесняя реально полезную память других программ
другими словами, использование сборщиков мусора иначе, как вредительством, и не назовешь[/QUOTE]
а ссылка есть? надо сильно :)
Наиболее часто используемый сборщик мусора для С и С++ - gc
[url]http://directory.fsf.org/boehm_garbage_collector.html[/url]
Не то, чтобы он мне хоть когда-то реально пригодился... :-)
Давно понял, хочешь быстрый комп - отключай своп навсегда. ;-)
Что со сборщиком, что без сборщика...
с одной стороны где ж взять столько памяти, с другой, вытеснив неисользуемые данные в своп, освободившееся место можно использовать под дисковый кеш, что улучшит производительность
у меня другая теория: хочешь быстрый комп - покупай быстрый винчестер. правда, в последнее время для ускорения винчестеры, как и процессоры, приходится распараллеливать
[QUOTE=traveller]а ссылка есть? надо сильно :)[/QUOTE]
навредить ? ;)
явным вызовом mlock/mlockall можно блокировать регион памяти от свопирования, но тогда опять возникает проблема -
... [QUOTE=pal] где ж взять столько памяти[/QUOTE] ...
так что 4Г RAM - не роскошь, а средство быстрого передвижения к очередному дидлайну. :-)
[url]http://www.gnu.org/software/libc/manual/html_node/Locking-Pages.html[/url]
к сожалению, 4г это не 640к и не для всех достаточно ;)
:-)
наткнулся про сборщики мусора и джава:
[url]http://bash.org.ru/quote.php?num=811[/url]
еще понравилось:
[url]http://bash.org.ru/quote.php?num=5844[/url]
"C++ Is my favorite garbage collected language because it generates so little garbage" (c) bs
[QUOTE=homo ludens;933728]OS GNU/Linux[/QUOTE]
ОС Linux написана на обычном С без С++ )))
[QUOTE=SWARM;1136922]ОС Linux написана на обычном С без С++ )))[/QUOTE]
И слава богу, иначе сборка ядра занимала бы сутки... :-)
А уж про глючность не говорю...
[QUOTE=SWARM;1136922]ОС Linux написана на обычном С без С++ )))[/QUOTE]
Unix написан на С в те времена когда С++ еще в помине не было. Видно Linux решили писать на нем же
[QUOTE=homo ludens;1137140]И слава богу, иначе сборка ядра занимала бы сутки... :-)
А уж про глючность не говорю...[/QUOTE]
Прямо уж сутки :laugh: а глючность зависит от разработчика, а не от С++
[QUOTE=THRESHE;1137531]Unix написан на С в те времена когда С++ еще в помине не было. Видно Linux решили писать на нем же[/QUOTE]
Странно, как люди до С++ жили... :-)
Провел эксперимент - перевел программеров с С++ на С.
Результат - количество глюков заметно уменьшилось.
Факт... Для некоторых наверное неожиданный...
В конце 90-х был обзор крупных проектов которые писались с использованием ООП и без него. Сроки разработки, количество ошибок и т.п. Результаты были вполне предсказуемы...
[QUOTE]
Also, remember that the fastest parts of a program are those that are done before the pro-gram even starts. In general, you should:
• Catch errors during translation time (compiling and linking) rather than at run time. You should make the most of type checking and access checking, which means you should avoid using casts and void *.
• Simplify run-time computations by doing what you can at compile time.
• If you must do computations at run-time, shift them from the most time-critical parts to the least time-critical parts of the program (which is often, but not always, program start-up).
• When all else fails, try using C++ as just C.
[/QUOTE]
(c) Reducing Run-Time Overhead in C++ Programs
Embedded Systems Conference San Francisco 2002
os linux написана раньше чем ее компилятор с++
[QUOTE=homo ludens;1137859]Странно, как люди до С++ жили... :-)
[/quote]
так же как и до фортрана
[quote]
Провел эксперимент - перевел программеров с С++ на С.
Результат - количество глюков заметно уменьшилось.
Факт... Для некоторых наверное неожиданный...
[/quote]
это не делает чести этим программерам ;)
[quote]
В конце 90-х был обзор крупных проектов которые писались с использованием ООП и без него. Сроки разработки, количество ошибок и т.п. Результаты были вполне предсказуемы...
[/quote]
все крупные проекты, приходящие на ум в конце десятых, используют ооп в той или иной мере
[quote]
• When all else fails, try using C++ as just C.
[/quote]
ну, это ведь не значит "используйте malloc вместо new или fabs вместо std :: abs" , скорее что-то типа "не передавайте структуры по значению и не используйте исключений в качестве альтернативного возврата"
[QUOTE=SWARM;1136922]ОС Linux написана на обычном С без С++ )))[/QUOTE]
А что такое ОС Linux?
Только ядро,
или к примеру, KBD окна?
Я бы не стал так огульно утверждениями разбрасываться.
OS Linux состоит из двух основных частей - ядра Торвальдса и кучи пакетов GNU
Сам Столлман утверждает, что правильное название - OS GNU/Linux. :-) Ядро написано на С. С GNU частью сложнее, однако и там С доминирует.
Разумеется там есть и С++ код, только вот встречается он как ни странно редко и преимущественно в двух областях (исключение - mysql).
Первая область - это ГУИ разных вариантов и пользовательские прибамбасы. Я всегда сомневался в жизненности идеи сделать из линукса виндоуз, однако именно здесь С++ оправдан, так как со времен Смоллтока любой гуй несет каинову печать с яркой надписью по кругу - Ugly by Design. :-)
Вторая область - это многочисленные оболочки над существующим кодом (обычно С), которые позволяют 00-программерам не напрягаться и мыслить в привычном русле. Собственной функциональности у таких пакетов - 0.
Возьмите любой репозиторий Линукса и проверьте сами.
Есть исключения и из этих двух правил, однако большинство из них несут характерные признаки непонимания авторами софта одной маленькой, но очень поганой разницы в понятиях. Есть софт, делающий жизнь удобнее. Есть софт, который расширяет возможности. И большинство ОО-проектов пишутся так, как будто вторая категория включена в первую. А это неправда.
Несколько замечаний по предыдущим постам.
1. Торвальдс начал писать Линукс в октябре 91. Страуструп начал писать С++ в 83-м. Очевидно, Торвальдс хорошо понимал разницу между языками и сделал правильный выбор. :-)
2. В защиту фортрана (и умершего в прошлом месяце его автора - небезизвестного Бэкуса) могу привести очень характерный пример.
Есть очень старая библиотека - называется BLAS. Библиотека линейной алгебры. Любой серьезный производитель процессоров дает свою версию библиотеки оптимизированную под себя. Есть она и у Intel и у AMD. Что характерно - пишется на фортране с ассемблером. Интерфейсы - фортрановские. Мне почему-то кажется, что человека, который раскроет глаза Intel что надо ее писать на С++ в объектном стиле выгонят не дослушав. :-)
Интересно, что любой программист, который приходит с института и которому я даю задачу написать какую-то математику почему-то начинает строчить свою реализацию TMatrix. :-) Приходится очень долго бить по рукам, чтобы отучить от этой пагубной привычки.
Вопрос - где на самом деле повторное использование кода выше - в фортране или С++?
Учитывая количество программ в мире использующих векторные и матричные операции (любая обработка изображений например и т.п.).
3. В защиту malloc против new.
Работа с new вместо malloc хуже! Потому что new абстрактно атомарен и следовательно при невозможности создать объект генерирует эксепшн. Затратный до одурения. 5 лет назад большинство компилеров оборачивало ЛЮБОЙ вызов конструктора в трай-кетч, а программист про это и не знал. Что давало падение производительности до 40 раз! Сейчас ситуация получше, но смысл в использовании этих вещей, кроме синтаксического сахара? Делать из С Бейсик? Работая с malloc можно пользоваться статическим чекером splint, разработчики которого официально заявили, что не будут поддерживать С++ по причине сложности его модели памяти. Работая с malloc можно использовать тонны наработанного кода по отладке памяти. А с new/delete? Последний статический чекер С++ который я видел стоил всех бабок и имел переполненные баглисты за каждый месяц.
про std:abs и крупные проекты на ООП напишу, если не размажут по стенке за этот пост. :-)
[QUOTE=homo ludens;1138602]
если не размажут по стенке за этот пост. :-)[/QUOTE]
Ща мы с [B]pal[/B] размажем :tommy:
Если бы new был настолько хуже чем malloc его бы не придумали :)
[QUOTE=homo ludens;1138602]
про std:abs и крупные проекты на ООП напишу, если не размажут по стенке за этот пост. :-)[/QUOTE]
пиши, я лично вот очень внимательно слушаю :)
как сказал мне когда-то очень давно, один очень продвинутый дядька,
при вызове new автоматически вызывается конструктор, а при вызове delete - деструктор (см. следующий пункт). Так что нововведение можно описать формулой: new = malloc + конструктор, delete = free + деструктор.
[QUOTE=traveller;1139198]пиши, я лично вот очень внимательно слушаю :)
как сказал мне когда-то очень давно, один очень продвинутый дядька,
при вызове new автоматически вызывается конструктор, а при вызове delete - деструктор (см. следующий пункт). Так что нововведение можно описать формулой: new = malloc + конструктор, delete = free + деструктор.[/QUOTE]
есть еще возможность переопределения
обычно делается для пулирования, но возможны и другие применения
управление жизненным циклом объекта - это не прерогатива ООП. Инициализацию и освобождение ресурсов писали еще на ассемблере задолго до Страуструпа. ООП дал этой технике новую синтаксическую нотацию и расширил семантику, гарантировав атомарность операции.
malloc, если нельзя получить память возвращает 0. Что возвратит инициализатор на С? А что захотим, то и вернет. Принято, что указатель, либо 0 в случае ошибки. А что в этом случае делает конструктор С++? А вот хз. У Страуструпа почему-то про это не написано. Разве что в приложении, которое почему-то на русском языке раньше издавалось отдельно, а сейчас похоже вообще не издается. :-) Сейчас полез в последний драфт стандарта, тоже не нашел...
Вернуть значение конструктору нельзя. С++ Faq-lite рекомендует переводить объект в зомби путем установки внутреннего состояния в "полуоткрытый". Либо юзать внешний exception с контролем уже распределенных ресурсов. В результате имеем классный выбор - либо дикий геморрой либо гемморой с понижением производительности. И все только за тем, чтобы с помощью трюка обойти ограничения языка и вернуть одно значение ошибки (в виде индикатора состояния или кода exception). И вот оно нам надо? Может все-таки malloc с классическим инициализатором и полной свободой реализации попроще будет?
:-)
Кстати а если конструктор самого exception не сработал, что будет? :-) А там ведь временный объект создается...
Будет время - обязательно поэкспериментирую... Люблю вивисекцией заниматься. :-)
И еще люблю перечитывать [url]http://local.joelonsoftware.com/mediawiki/index.php/Russian[/url] пункт 36... :-)