Представлен (http://blog.llvm.org/2010/05/new-libc-c-standard-library.html) новый, развиваемый в рамках инициативы LLVM, проект - "libc++ (http://libcxx.llvm.org/)", представляющий собой реализацию стандартной библиотеки классов C++, распространяемую под BSD-подобной лицензией и нацеленную на максимальное обеспечение совместимости с существующими и будущими стандартами и высокоэффективную генерацию кода.
Основные цели проекта:
- Поддержание совместимости с черновиком будущего промышленного стандарта C++0X;
- Минимальное потребление памяти;
- Высокая скорость выполнения функций;
- Быстрая компиляция;
- Полная совместимость на уровне ABI с libstdc++ из состава GCC, включая поддержку таких низкоуровневых возможностей, как объекты-исключения (exception objects), rtti и распределение памяти;
- Расширенный набор unit-тестов.
В настоящий момент готовность библиотеки libc++ до финального релиза оценивается на 85%, включая планы по поддержке новшеств стандарта...URL: http://blog.llvm.org/2010/05/new-libc-c-standard-library.html
Новость: http://www.opennet.me/opennews/art.shtml?num=26560
одно из двух, или народ серьезно взялся или одно из двух...
...либо кто-то из спонсоров вбросил ломоть сорца, либо снова одно из двух...
>одно из двух, или народ серьезно взялся или одно из двух...Народ в лице ... корпорации Эппл? Той, которая два раза сорсы дарвиновского ядра закрывала т.к. видите ли хакинтоши им помешали? :)
Пусть открывает и дальше. В отличие от дарвиновского ядра, куски которого никому даром не нужны, компоненты инфраструктуры llvm/clang могут быть потом интегрированы в gcc, а судьба llvm побоку:) Так что пуст работают, потенциальные доноры:)
>В отличие от дарвиновского ядра, куски которого никому даром не нужны,Ну кому-то оно было нужно, но Эппл жабой давился - как это так?! На нашем ядре - хакинтоши?! Закопать! Закрыть! В итоге после двух фортелей с закрытием-переоткрытием - дарвиновское ядро стало действительно никому нафиг не нужно: дураков среди програмеров - немного.
Такая уж сутьба вендоролокнутых технологий и их пользователей, то есть анальных рабов:). В случае llvm всё же чуточку лучше, закрывать они то, что опубликовали не смогут. Хотя конечно прекратить публиковать улучшения - запросто:)
Есть ещё третий вариант: вывалить такую кучу сорца, которую ни один "коллектив энтузиасов" не поднимет форкнуть -- и крути ими как хочешь, хошь под BSDL, хошь под GPL.mozilla, OOo, ...
> Полная совместимость на уровне ABI с libstdc++ из состава GCCхм, интересно как они этого добьются?
> Полная совместимость на уровне ABI с libstdc++ из состава GCC, включая поддержку таких низкоуровневых возможностей, как объекты-исключения (exception objects), rtti и распределение памятиВ оригинале новости идет речь ТОЛЬКО о бинарной совместимости для НЕКОТОРЫХ низкоуровневых возможностей, таких как объекты исключений, RTTI и управление распределением памятью (а далеко не о полной бинарной совместимости). А этого добиться не так и сложно.
Наверное используя такую же систему именования функций как и в GCC
Это уровень API
libc++ is known to work on the following platforms, using g++-4.2 and clang...
* Mac OS X i386
* Mac OS X x86_64И все?!
Порты для других ОС видимо придется сообществу развивать. Apple их развивать врядли будет.
Правильно, а то не хаит Apple только ленивый, а как доходит до дела, начинают спрашивать "а где под линукс?". Опен-сорс товарищи, развивайте своими силами или кушайте что дают.
а кому кроме эппла это надо? развивать? под bsdl? кто-то хочет бесплатно поработать на эппл, который потом сорс зажмет? тогда вам сюда :). с ядром макоси эппл уже показал что они за фрукты, два раза открывая-закрывая ядро.
опенсорс паранойа? Вы наверное сами ПО не разрабатываете. Все адекватные программисты которых я знаю пишут весь свой код под BSD, а то и под более позволяющей лицензией Boost.
Круто, адекватный программист - это тот кто позволяет Эпплу зажопить свои исходники задаром? Хаха, боюсь этот критерий адекватности устраивает только Эппл.
>Круто, адекватный программист - это тот кто позволяет Эпплу зажопить свои исходники
>задаром? Хаха, боюсь этот критерий адекватности устраивает только Эппл.Усер выпили у себя из системы x.org, Apache/nginx, Firefox и успокойся. Кстати этот сайт работает на FreeBSD. Некошерно ? Тебя здесь никто не держит.
К счастью упомянутые проекты не пилятся конторкой с названием Эппл и в их списках поддерживаемых систем не значится "макось, а остальные выгребайте как умеете" :P. Сама по себе BSDL проблемой не является. Проблемы начинаются когда центром развития BSDL софта становятся жлобы начинающие зажимательство. После этого софт проприетаризуется и вы можете выбрать из бесплатных объедков или недоносков или купить нормальный вариант у Единственно Правильного Вендора (tm).
слив что называется засчитан
>слив что называется засчитанОфигенная аргументация :-)
>Сама по себе BSDL проблемой не является.НЕ ВЕРЮ! Признайся - ты фейк User294-го :)
Нет, я не фэйк 294-го. Я он сам. И, блин, если уж так интересно то в дебрях ломок копий с наиболее вменяемыми из бсдшников можно найти эту точку зрения. Просто BSDL - это анархия и кто сильнее, тот и прав. Вот в этом случае прав будет Эппл. А в случае нжинксы или опача, пардон, сильнее - их авторы и сообщества. Но всегда есть риск что высрется акулка покрупнее и скажет всем спасибо за то что выросли, специально для, вкусной кормежкой. GPL - некая сетка от акул, дающая определенные гарантии отсутствия акул желающих вас сожрать с потрохами. С ней на лично мое имхо как-то спокойнее. Хотя некоторые и без нее обходятся и даже не все из них были съедены акулами. Что-то не так?
>Но всегда есть риск что высрется акулка покрупнее и скажет всем спасибо
>за то что выросли, специально для, вкусной кормежкой.1001 раз: всё что было под BSDL - под ней же и останется.
>GPL - некая сетка от акул, дающая определенные гарантии отсутствия акул
>желающих вас сожрать с потрохами. С ней на лично мое имхо как-то спокойнее.1001 раз: до тех пор тока не требуют передать права на код "хозяину". Вот линукс ако кернел - не требует, его хрен сожрут! Но большинство GPL проектов - таки можно, ибо жадность ...
>Хотя некоторые и без нее обходятся и даже не все из них были съедены акулами.
>Что-то не так?Не так. Некоторые другие были съедены акулами и "за сетями" (мыскль) - можешь сказать что это исключение из правила, а как по мне - это неудобный, противный такой фактик, ломающий стройную теорию в хлам.
>1001 раз: всё что было под BSDL - под ней же и останется.А jumiper и прочие эпплы и майкрософты с панасониками - в курсе? oO
А то знаете, их свобода показать мне фигу - мне как-то никуда не впилась, строго говоря.>1001 раз: до тех пор тока не требуют передать права на код "хозяину".
О да, логично. Это требование частично аннулирует свойства GPL и если кто не хочет слать смс на короткий номер с текстом "не лох" - условия на которых передаешь код проекту надо все-таки читать.
>Вот линукс ако кернел - не требует, его хрен сожрут!
Собссно одна из причина почему он так бурно развивается: его растаскивать низзя, можно только совместно развивать :-)
>Но большинство GPL проектов - таки можно, ибо жадность ...
Большинство? А статистика откуда? Как сие считалось?
Данная добавка - до некоторой степени портит смысл существования GPL, повышая риск захапа. Исключение мне известно одно - отдача прав FSF с целью делегации им полномочий по защите интересов автора (тогда они смогут судиться с нарушителями вместо автора, как я понимаю).>Не так. Некоторые другие были съедены акулами и "за сетями" (мыскль) -
А примеры тех кто был съеден окончательно и бесповоротно, так чтобы изменения и улучшения не отдавали - можно в студию?
>- это неудобный, противный такой фактик, ломающий стройную теорию в хлам.
Противный и неудобный фактик. Только в хлам все-таки ничего не ломается. Во всяком случае почему-то линухи популярностью пользуются да еще и развивается семимильными шагами. Стало быть теория подтверждается практикой. При том развивается настолько сурово что часть проприетарщиков например повыбрасывало свои закрытые форки бздей и перешло на линухи. Особенно в эмбеддед заметно. Там вообще сейчас стало правилом хорошего тона поддерживать для более-менее мощных платформ линух в референсном дизайне.
Каждый раз, когда я вижу новость о LLVM, в комментариях я обязательно увижу холивар о лицензиях.
>Что-то не так?Всё так. Просто проявлена нехарактерная рациональность и трезвость суждений :-).
А не покажете ли пальцем где в лицензии bsd стоит пункт о передаче прав автора кода эпплу?
>А не покажете ли пальцем где в лицензии bsd стоит пункт о
>передаче прав автора кода эпплу?В BSDL как бы зажопить чужой код можно и без передачи прав - лицензия сие позволяет. Захотел и зажопил. Главное не втирай что это ты сам написал. Ну эпплы и не втирают - они на видном месте пищут копирайт себя любимых и свои логотипчики. А там где не светит солнце - так и быть, может и упомянут всех прочих. Чисто номинально все честно а для юзера все выглядит как будто всю эту круть Эппл накатал, а вовсе не...
>Ну эпплы и не втирают - они
>на видном месте пищут копирайт себя любимых и свои логотипчики. А
>там где не светит солнце - так и быть, может и
>упомянут всех прочих. Чисто номинально все честно а для юзера все
>выглядит как будто всю эту круть Эппл накатал, а вовсе не...Это ты про CUPS сейчас рассказал? ;)
>Это ты про CUPS сейчас рассказал? ;)Чё ж тя так с того КУПСа прёт-то? Наглый проприертарщик Эппл купил права на купс в 2007 году, и он всё ещё свободен под GPL2+LGPL2. В википедиях пишут, что "в дистрибутивы" он попал несколькими годами ранее. Радуемся вместе -- во проприертарщики лоханулись-то.
>Радуемся вместе -- во проприертарщики лоханулись-то.Чему?
Ведь:
>они на видном месте пищут копирайт себя любимых и свои логотипчики.По-мне, так уж лучше бы стояли имена разработчиков на самом видном месте, чем копирайт Apple. Однако имущественные права на продукт под GPL принадлежат Эпплу, разработчики вычеркнуты из брэнда и превратились в наёмную и бесплатную рабочие силы, продвигающую брэнд Apple.
>>Радуемся вместе
>Чему?Гм, ну, значит вместе не получилось. Персонально Вы радуетесь, что у проприертарщиков Apple _есть целый один(!) живой проект под GPL. И Вы его можете показывать каждому, кто косо посмотрел на любимого проприертарщика Apple.
Господин Джобс, перелогиньтесь
Как бы история с MySQL говорит об том, что не всё так просто с лицензиями. Для защиты одной лицензии мало.MySQL под GPL, однако автор, после продажи проекта Sun'у, всё время плачется: спасите ваш MySQL, а то жадные капиталисты сорцы зажмут.
PostgreSQL (BSDL) что-то никто зажимать не торопится. Странно, да?
О! это пришел изин> PostgreSQL (BSDL) что-то никто зажимать не торопится. Странно, да?
В гугле забанили? Зажимают, еще как зажимают: хакер официально обьявил что задержка разрабатываемых фич - 2 года после внедрения (собственно это и есть его бизнес).
А сколько ещё компаний кормиться на закрытых форках!!!!
По большому счету PostgreSQL - базовый продукт для студентов, на котором строят свой бизнес целая куча народу - т.к. голый движок мало полезен, важны разработка, подгонка движка и внедрение решений.
И в общем-то хорошая модель для небольшого, но очень дорогого сегмента рынка.
>Как бы история с MySQL говорит об том, что не всё так
>просто с лицензиями. Для защиты одной лицензии мало.
>
>MySQL под GPL, однако автор, после продажи проекта Sun'у, всё время плачется:
>спасите ваш MySQL, а то жадные капиталисты сорцы зажмут.
>
>PostgreSQL (BSDL) что-то никто зажимать не торопится. Странно, да?iZEN ты и User294 не один и тот же человек ? Вы постоянно одновременно вбрасываете на вентилятор биоотхотды с разных сторон. Успокойтесь уже а ?
>iZEN ты и User294 не один и тот же человек ?Скорее, антиподы. Изен ни в зуб ногой в железе и низкоуровневых делах, файловых сисьемах и прочая и ищет в опенсорсе сугубо свободу урвать кусочек и уволочь в свой темный уголок (поэтому GPL для него как шило в задницу). А мне понравилось как опенсорсники работают - общение с командами оных и совместная работа - порой изрядно доставляют.
>постоянно одновременно вбрасываете на вентилятор биоотхотды с разных сторон.
Ну да, у нас разные точки зрения, по этому поводу и бывают пикировки. Я кстати вроде стараюсь избегать сильно некультурных или совсем уж провокационных комментариев. Если не всегда получается - I'm sorry.
Привет. Ты вообще редко, что пропускаешь :) Откуда столько свободного времени?
Да вообще-то много чего пропускаю :) на половину пикировок я отвечать тупо не успеваю и забываю или забиваю в итоге на некоторой точке на кидание какашками.На вашем месте я бы радовался, т.к. чего ж хорошего в этом? :)
>Как бы история с MySQL говорит об том, что не всё так
>просто с лицензиями. Для защиты одной лицензии мало.
>
>MySQL под GPL, однако автор, после продажи проекта Sun'у, всё время плачется:
>спасите ваш MySQL, а то жадные капиталисты сорцы зажмут.
>
>PostgreSQL (BSDL) что-то никто зажимать не торопится. Странно, да?http://askmonty.org - наш ответ. GPL позволяет безболезненно форкнуть проект, никто его зажать не сможет. Кроме того, пока проект под GPL, та же Oracle не может закрывать обновляемые исходники проекта при условии, что его распространяет.
P.S. URL fixed
Если Вы о MySQL, то Oracle нынче- копирайт холдер, а значит может делать с исходниками все, что ей в голову взбредет.
>Если Вы о MySQL, то Oracle нынче- копирайт холдер, а значит может
>делать с исходниками все, что ей в голову взбредет.Они могут делать с ними что угодно, но та часть кода, что ушла под GPL, уже закрытой стать не сможет. Поскольку основные разработчики MySQL собрались в другую команду, что будет с исходниками Oracle - их мало волнует.
Одна из причин, кстати, по которой я тихонько пересаживаю продакшн именно на MariaDB. Благо для юзеров отличий никаких.
Для MySQL есть прекрасная альтернатива — InterBase и её опенсурсные реализации.
>Если Вы о MySQL, то Oracle нынче- копирайт холдер,Они, конечно, холдер, но они пожалуй будут выбирать между местечковой жабой и внедрежом наработок сторонних програмеров. Думается програмеров которые были готовы дать права MySQL AB сильно больше чем програмеров которые готовы сдать все права ораклу, а общим знаменателем остается только GPL, ага? При том уж что-что а если Монти выпустил эту СУБД - ну уж наверное он и развитие продолжить может :)
>Как бы история с MySQL говорит об том, что не всё так
>просто с лицензиями. Для защиты одной лицензии мало.
>
>MySQL под GPL, однако автор, после продажи проекта Sun'у, всё время плачется:
>спасите ваш MySQL, а то жадные капиталисты сорцы зажмут.
>
>PostgreSQL (BSDL) что-то никто зажимать не торопится. Странно, да?Опубликованные под открытой лицензией сорцы зажать нельзя, даже если разработчики все права на код передали компании. Просто можно сменить лицензию у последующих версий. Впринципе если какая-то компания купит торговую марку постгрес и вместе с этим купит 90% разработчиков постгреса, то эффект будет тот же как и с мускулем. Для максимальной живучести опенсорсного продукта он должен быть как раз под гпл и при этом иметь огромное количество разработчиков. Линукс в этом смысле является хорошим примером. Впрочем, лицензия вторична. Так как любой опенсорсный продукт может легко загнуться если увести от него ключевых разработчиков.
90% разработчиков постгреса (даже основных, а их тоже не мало) купить проблематично, учитывая что они все работают в разных компаниях разных стран мира. Собственно, об этом когда-то говорил мейнтер посгреса, даже здесь статья пробегала по этому поводу.
>Порты для других ОС видимо придется сообществу развивать. Apple их развивать врядли
>будет.у сообщества есть такая либа, и возможность эппла зажать сорс сообществу не нужна. вот эппл пусть и развивает. ядро вон уже доразвивались, всех интересующихся разогнали двумя закрытиями сорсов.
он умрёт - када умрёт Страуструппс: С# - альтернатива
>он умрёт - када умрёт СтрауструпА си уже с восьмидесятых все хоронят. И еще столько же хоронить будут. Думается он вас переживет еще :). И си++ вероятно тоже.
>пс: С# - альтернатива
Да хрена там. Нормально работает только в винде. Какая это нафиг альтернатива? Кроссплатформенность - в полной заднице. А писать "только под винду" нынче ну совсем не модно. Есть куча других достойных систем, мобильных девайсов и прочая.
>>И еще столько же хоронить будут. Думается он вас переживет еще :)говорят асм тоже вымер )))))))
>>Да хрена там. Нормально работает только в винде. Какая это нафиг альтернатива? Кроссплатформенность - в полной заднице.
это потому-что Столман не осилил C# ))))))))))
пс: Си темболее похоронили когда Страуструп решил создат С++ )))
а С++ похоронили када создали Java
а Java-у похоронили когда создали C#пс2: что по вашему придёт на смену ООП (ХОП)
>пс: Си темболее похоронили когда Страуструп решил создат С++ )))
>а С++ похоронили када создали Java
>а Java-у похоронили когда создали C#когда перепишут Kernel 2.6.x на C#, ну или хотя бы Java - тогда с ними и поговорим
>>пс: Си темболее похоронили когда Страуструп решил создат С++ )))
>>а С++ похоронили када создали Java
>>а Java-у похоронили когда создали C#
>
>когда перепишут Kernel 2.6.x на C#, ну или хотя бы Java -
>тогда с ними и поговорим)))))))) лучше б кернель написали на асм
>>>пс: Си темболее похоронили когда Страуструп решил создат С++ )))
>>>а С++ похоронили када создали Java
>>>а Java-у похоронили когда создали C#
>>
>>когда перепишут Kernel 2.6.x на C#, ну или хотя бы Java -
>>тогда с ними и поговорим
>
>)))))))) лучше б кернель написали на асмПоиск *.S по исходникам ядра должен открыть Вам глаза. Не все из архитектурного кода получается правильно реализовать даже на C.
>)))))))) лучше б кернель написали на асмМайкрософт частично писал, в '95. И как ни странно на именно этой системе они и стали гигантом. Правда потом железо стало мощнее и можно стало позволить себе более портабельный код.Хоть и менее оптимальный, ессно.
что такое по вашему портабельность ????нет и не будет никакой портабельности
есть понятие совместимости
пс: думаете байт код портабельный ???? а виртуалка что разве не под каждую архитектуру пишется ???
>что такое по вашему портабельность ????портабильность - это сколько нужно сделать движений ручками что бы код заработал на новом железе.
>нет и не будет никакой портабельности
угу, расскажите еще.
>пс: думаете байт код портабельный ???? а виртуалка что разве не под
>каждую архитектуру пишется ???неизменный байт код, выполняемый под любой системой и платформой не есть портабельный или не портабельный код, так же как и скрипты. вот когда ваш байт код нужно будет править, что бы он заработал под конкретной системой, тогда и можно будет оперировать термином "портабельность".
>>вот когда ваш байт код нужно будет править, что бы он заработал под конкретной системой, тогда и можно будет оперировать термином "портабельность".вы сами уже ответили за меня ))))))))
>>портабильность - это сколько нужно сделать движений ручками что бы код заработал на новом железе.
))))))) может мозгами ???? и не добавлять код тогда када программа не будет работать при переносе, а делать это в момент написания программы
>))))))) может мозгами ???? и не добавлять код тогда када программа не будет работать при переносе, а делать это в момент написания программысвятая наивность
>что такое по вашему портабельность ????Возможность использования программы на иной архитектуре/платформе/системе без полного переписывания. Вот ассемблер - совершенно непортабелен. Тупо поток команд которые проц должен смолотить в виде как есть. Можно сгенерить его очень оптимально, но для каждой платформы придется упираться "с нуля".
>нет и не будет никакой портабельности
См. выше что я понимаю под этим словом. В таком виде - есть. Ну вот например я могу запустить wget в винде, макоси, линуксе, *бсд и почти везде где поддерживается POSIX. Это пример портабельной программы. И не надо переписывать wget, независимо от того MIPS там у меня или AMD64. Я им к слову действительно пользуюсь и на том и на другом. А вот например программу на винапи черта с два перенесешь куда-то еще кроме писюка с i386 или как максимум AMD64 (если повезет).
>есть понятие совместимости
Есть понятие кроссплатформенности.
>пс: думаете байт код портабельный ???? а виртуалка что разве не под
>каждую архитектуру пишется ???Правильно говорите. Самое смешное - что рантайм обычно осиливают сделать под пару платформ, не забывая вопить о портабельности. А для сравнения - чисто-алгоритмический блок на си написаный без юзежа платформенной специфики адекватным програмером - можно скомпилить вообще не переписывая и под 8-лапого 8-битного "таракана"-однокристалку и для суперкомпьютера. Лишь бы по ресурсам влезло. На асме - увы, придется переписывать с нуля каждый раз. Некоторые эмбеддеры рассматривают си как некий портабельный ассемблер :)
>>Можно сгенерить его очень оптимально, но для каждой платформы придется упираться "с нуля".а я это не знал что интел выпускает свои процы без обратной совместимости
и не знал что амд это интел совместимый процессор
учите матчасть (вы будете писать с нуля лиш в том случае если будете переносить на другие оси или использовать иной транслятор ассеблера)
>>Ну вот например я могу запустить wget в винде, макоси, линуксе, *бсд и почти везде где поддерживается POSIX.
а компилятор С под каждую архитектуру не создавали ????
современные языки программирования это всего лишь врапперы и не более
загляните внутрь как работает программа и ваще как устроен процессор>>Есть понятие кроссплатформенности.
АМД - ИНТЕЛ совместимый и писать на асм как под интел так и под амд не составляет труда
>>Некоторые эмбеддеры рассматривают си как некий портабельный ассемблер :)
расмматривают потомучто не они писали С
им не надо было изучать архитектуру процессора
и теперь представьте если не будет поддержка и развитие языка С что будет тогда ????
вы сможете использовать свои программы на новых процессорах ???
а асм он развивается нога-вногу с самим процессором.
что бывает когда интел вносит новую супер-пупер фичу гипер трединга - правильно программисты ждут выхода новой версии GCC ))))пс: дальнейшёю дискуссию считаю бессмысленной так как это уже перерастает в понятие что асм вымер и он не нужен
>а я это не знал что интел выпускает свои процы без обратной совместимостиВ мире есть не только интель и амд. Вы об этом не знали? Алсо, в 64-битных системах поддержка 32-битных приложений - не обязательна. Это нечто такое сильно опциональное вообще. Вот у меня в моем 64-битном линухе тупо нет 32-битных либ. А зачем мне набор архаичных либ под древнюю архитектуру? У меня весь софт в системе собран под АМД64. Вы готовы переписать софт с нуля на новый набор команд и измененную архитектуру?
>и не знал что амд это интел совместимый процессор
Для тех кто не отпускает ручник, объясняю: я не собираюсь привязывться к одному несчастному х86. В мире еще куча архитектур есть. Хороших и разных. ARM, MIPS, PPC, ... :). Вот только набор команд и регистров там другой. Впрочем оно отличается даже в просто AMD64 и просто перкомпилить 32бит прогу на асме в 64 бита - не выйдет.Придется переписывать.При том почти все.
>учите матчасть
Хаха, ну и наглость. Если что, я знаю с пяток ассемблеров разных процов. Правда х86 асм я знаю хреново, потому как УГ этот ваш х86, пардон. На фоне более нормальных камней с нормальным набором команд, под который хотя-бы писать не блевотно.
>(вы будете писать с нуля лиш в том случае если будете переносить на другие
>оси или использовать иной транслятор ассеблера)Или другой процессор с другой системой команд. Да даже тот же самый АМД64 - уже попадос на переписывание в значительном объеме. Я себе враг, чтобы закладываться на одну ось, проц и систему команд? Вообще-то i386 скоро наверное вымрет в пользу AMD64 (память типвого писюшника уже вплотную подошла к барьеру 2^32 и оперировать оной в 32-битном виде попросту некомфортно). Останется только у некрофилов которым нужен всякий там мсдос. В итоге имхо сейчас на асме имеет смысл писать только небольшие критиыные куски где полкило асма дает выигрыш в разы. Такие куски и переписать не в облом, и эффект приличный при небольших затратах сил. А писать большую прогу на асме - тупое начинание. Человек теряется в большой портянке и может даже в целом проиграть компилеру который может по глобальной оптимизации выделения регистров даже уделать человека. А вот в маленьком кусочке в полкило - натянуть тот бред который генерится компилером в тугой цикл - не проблема ни разу.
>а компилятор С под каждую архитектуру не создавали ????
Создавали. Но что доставляет в этом плане - по старинной традиции, окончательный вариант компилятора си как правило собран ... этим самым компилятором си. Это такой юмор програмерский, чтоли, на тему яйца и курицы :-). А что до создания компилеров - так пардон, нынче *трудно* найти процессорную архитектуру под которую бы не было компилятора языка си (а кому эта архитектура тогда будет нужна?). Это надо *сильно* постараться. То есть, си портабелен не только в теории (как явы и прочие дотнеты), но и на практике. Кстати некоторые архитектуры процов откровенно оптимизят под си. Например те же атмелские камни с кучкой регистров и аппаратными индексными регистрами - явно затачивались на то чтобы сям было удобно и регистры раскидывать и операции с массивами с постинкрементом делать и прочая.
>современные языки программирования это всего лишь врапперы и не более
Да как бы сказать то? Ну, в конечном итоге - проц умеет выполнять только поток бинарных команд. А вот методы получения этого потока команд, степень оптимальности оного и трудозатрат на его получение - варьируется. В общем случае - каждый сам решает какой баланс между геморроем и качеством результата его устроит. С моей точки зрения писать на асме целиком - не оправдано. Лично я юзаю асм только в однокристалках и только если фимваре заведомо менее 4-8 кило. Больше, извините, сильно геморно и можно писать на си без особого просирака в параметрах (если где-то он все-таки случается, можно так и быть, полкило оптимизнутого асма воткнуть для критичного к скорости куска). А потом переписать полкило асма - это не переписать вообще все, блин. В итоге при уходе на другую архитектуру - проект почти не изменится кроме несчастного полкило которое придется переписать.
>загляните внутрь как работает программа и ваще как устроен процессор
Я это сделал long long ago :). Еще когда они были 8-битными. Нормально так?
>АМД - ИНТЕЛ совместимый и писать на асм как под интел так
>и под амд не составляет трудаА что мне делать если я захочу поюзать иной проц? В моем кармане лежит девайс с Linux. На ARM, разумеется. Кто ж еще будучи карманных габаритов проработает вменяемое время от батареи? Ну наверное не х86, правда? :) А на столе стоит роутер. С MIPSовским процессором. А кто еще сможет без вентилятора пакеты гонять? Ну наверное не х86, а? :)
Да и собссно все популярные операционки уже пишут на сях. Ну наверное не потому что дураки, а?
>расмматривают потомучто не они писали С им не надо было изучать архитектуру процессора
Да вообще-то надо как правило - в embedded в случае програминга без операционки совсем уйти от знания архитектуры железки довольно проблематично. Но вот как бы переписывать при случае большой кус кода с нуля захочет только полный дурак, имхо. А что, кто-то любит мартышкин труд?
>и теперь представьте если не будет поддержка и развитие языка С что будет тогда ????
Куда ж он денется то? Сейчас при выпуске новой архитектуры процессора считается не то что хорошим тоном а по сути обязательным правилом дать к нему хотя-бы сишный компилер. Исключения разве что совсем примитивные процессоры (и то, даже под процы с парой кило флеша и считанными байтами оперативы - умудряются писать на си, приколитесь?) да сильно специфичные процы под которые не получается написать сишный компилер нормально или трудозатраты на это не оправданы.
>вы сможете использовать свои программы на новых процессорах ???
Конечно. Потому что если какой-то дуб выпустит свой процессор не озаботившись сишным компилером - кто и где будет юзать его процессор, пардон? Как вы себе это представляете? Мне как, показать парочку сравнительно недавних чипов под которые вендоры сразу GCC предоставили? Или так поверите?
>а асм он развивается нога-вногу с самим процессором.
Ну и сишные компилеры постепенно обучают юзать инструкции + кому надо реально ядреную производительность (кодеки, etc) - доделывают асмовые вставки. Но целиком писать большую программу на асме - нафиг-нафиг.
>программисты ждут выхода новой версии GCC ))))
И что?Кому сильно невтерпеж - может вставку на асме написать. Если уж так прется от асма и считает что оно даст реальный выигрыш. Авторы кодеков так и делают. Рантайм детект проца и юзеж наилучшего асм-оптимизированного куска под этот проц в узких местах. Разумно, геморроя не сильно много и результат - отличный. Не сильно хуже гольного асма но куда быстрее (имхо вы вообще ниасилите видеокодек на гольном асме написать - пупок развяжется).
>что асм вымер и он не нужен
Да ладно вам. Как это он вымер если я им пользуюсь порой? oO
вот это троллинг - толсто очень>>В мире есть не только интель и амд. Вы об этом не знали? Алсо, в 64-битных системах поддержка 32-битных приложений - не обязательна.
интел не поддерживает 64 бита ?
ARM Ltd. (сокр. Advanced RISC Machines; LSE: ARM, NYSE: ARMHY) — британская корпорация, один из крупнейших разработчиков и лицензиаров архитектуры 32-разрядных RISC-процессоров (ARM), ориентированных на использование в портативных и мобильных устройствах (телефонах, органайзерах и т. п.).
вы порой эмбеддед путаете с обычным писи
ну и на досуг http://ru.wikipedia.org/wiki/%D0%A1%D0%B...
такое ощущение что АМД - символизирует 64 битную разрядность
http://ru.wikipedia.org/wiki/%D0%A1%D0%B...
>>У меня весь софт в системе собран под АМД64. Вы готовы переписать софт с нуля на новый набор команд и измененную архитектуру?
зачем у меня и 64 и 32
>>Для тех кто не отпускает ручник, объясняю: я не собираюсь привязывться к одному несчастному х86
ваши притензии к 86 я не пойму (не вы ли им пользовались ?)
внимательно почитайте историю процессоров интел
думаю вы не отрицаете что он первый на рынке>>Хороших и разных. ARM, MIPS, PPC, ... :). Вот только набор команд и регистров там другой. Впрочем оно отличается даже в просто AMD64 и просто перкомпилить 32бит прогу на асме в 64 бита - не выйдет.Придется переписывать.При том почти все.
определитесь - эмбеддед или писи ?
в интел - это просто (все интел процессоры они совместимы даже ваш любимый амд)>>Если что, я знаю с пяток ассемблеров разных процов. Правда х86 асм я знаю хреново, потому как УГ этот ваш х86, пардон.
прочтите ссылочку выше ещё с десяток узнаете
>>память типвого писюшника уже вплотную подошла к барьеру 2^32 и оперировать оной в 32-битном виде попросту некомфортно
это было известно уже в момент создания проца
вот тока на рынке сразу 64 бита не выпустят кошерно было в то время ну и технология только 32 давала>>Останется только у некрофилов которым нужен всякий там мсдос.
ООО купите тады суперкомпьютер крей если вам гамать не начем
>>В итоге имхо сейчас на асме имеет смысл писать только небольшие критиыные куски где полкило асма дает выигрыш в разы.
а что геморой отсидите ??? признайте свою слабость
на каком уровне вы знаете асм ??? под тот же ваш любимый амд>>А писать большую прогу на асме - тупое начинание.
а не знание асм это тупое продолжение програмМистической жизни
>>То есть, си портабелен не только в теории (как явы и прочие дотнеты), но и на практике.писать отдельный компилятор под каждую архитектуру вы считаете портабельностью ?
>>В общем случае - каждый сам решает какой баланс между геморроем и качеством результата его устроит.
вам легко говрить не вы же С компилятор создавали и геморой не натирали
что вы Столмену не говорили - хватит мужик не рви жопу на асм ??? )))))))))>>Я это сделал long long ago :). Еще когда они были 8-битными. Нормально так?
чушь такую тогда не несли бы
правильно восьми битные а остальные вы не осилили>>А что мне делать если я захочу поюзать иной проц?
определитесь с понятием писи и эмбеддед
вы считаете АРм или МИпс круче интела ? ))))))))))))) ржунимагу
>>Да и собссно все популярные операционки уже пишут на сях. Ну наверное не потому что дураки, а?
потому-что компилятор С за них уже придумали
вы считаете тех людей дураками которые пишут на асм ???а вам слабо хотя бы написать 1% того же компилятора Си ? да хоть на том же Си не на асм
>>А что, кто-то любит мартышкин труд?
))))))))))))))))))))))))))))))а знаете что вы живёте в матрице и вся ваша жизнь не имеет смысла ))))))))))
>>да сильно специфичные процы под которые не получается написать сишный компилер нормально или трудозатраты на это не оправданы.
как по вашему туго приходится Столмену когда интел выпускает новый тип проца ???
>>Конечно. Потому что если какой-то дуб выпустит свой процессор не озаботившись сишным компилером - кто и где будет юзать его процессор, пардон? Как вы себе это представляете? Мне как, показать парочку сравнительно недавних чипов под которые вендоры сразу GCC предоставили? Или так поверите?
а вы представьте себе такую ситуацию
или каждый вендор (не тока проца) предоставляет к примеру дрова для линукса ??>>Но целиком писать большую программу на асме - нафиг-нафиг.
вы как я понял программист-одиночка ибо если бы линус писал один сам кернель - то он тоже нафиг-нафиг никому не нужен был бы ))))))))))))))))
ну вот ситуация с миниксом писал её один Таннебаум так и не дописал и вам тут легче сказать нафиг-нафиг>>И что?Кому сильно невтерпеж - может вставку на асме написать.
это не в вашем стиле - может совсем отказаться ))
>>Да ладно вам. Как это он вымер если я им пользуюсь порой? oO
хеловорлд показываете ученикам ??? вы же сами говорите нафиг-нафиг отсюда вывод вы ничего вменяемого на асм не пишите
встречал одну девушку которая писала на асм базу данных (ну и я говорил нафиг-нафиг)
>когда перепишут Kernel 2.6.x на C#, ну или хотя бы Java -
>тогда с ними и поговоримЯ тебя наверное удивлю, но существуют ядра как на Java, так и на C#. Так что -- фейл.
>>когда перепишут Kernel 2.6.x на C#, ну или хотя бы Java -
>>тогда с ними и поговорим
>
>Я тебя наверное удивлю, но существуют ядра как на Java, так и
>на C#. Так что -- фейл.Пруфлинк?
>Пруфлинк?http://ru.wikipedia.org/wiki/Microsoft_Singularity
http://ru.wikipedia.org/wiki/JNode
Нэ?
>>Пруфлинк?
>
>http://ru.wikipedia.org/wiki/Microsoft_Singularity
>http://ru.wikipedia.org/wiki/JNode
>Нэ?1. "Низкоуровневый код обработки прерываний x86 написан на языке ассемблера и C". Просто не может Managed-среда заменить низкоуровневое программирование полностью.
2. JNode is a free, open source Java technology based operating system implemented in the Java language with a very small assembler nano-kernel. - внимательно читаем последние 4-6 слов.
Так, еще варианты?
Клоню к тому, что PoC, конечно, наличествует, но есть две вещи:
а) от не-managed кода в ядрах ОС полностью все равно не уйти
б) перфтесты никто не публикует, ибо 1) PoC, 2) на них просто смотреть страшно будет
>Просто не может Managed-среда заменить низкоуровневое программирование полностью.Может. Просто для этого необходима соответствующая поддержка от железа.
>Может. Просто для этого необходима соответствующая поддержка от железа.Вот только нахрен это нужно? Оно пришло к чуть иным схемам - виртуализация и гипервизоры. Только опять же - гипервизор не есть managed :)
Столлман, кстати, уже работает над созданием свободного .NET инструментария:
http://www.gnu.org/software/dotgnu/
>Столлман, кстати, уже работает над созданием свободного .NET инструментария:
>http://www.gnu.org/software/dotgnu/+1
>говорят асм тоже вымер )))))))Oh, really? А что это за асм-оптимизация в кодеках тогда? Да и алгоритмы хеширования и шифрования порой не гнушаются оптимизнуть. Выигрыш в пару раз в горячем цикле то не лишний. Полкило асма написать - вообще не проблема ни разу. Ну разве что для ретардов которые ниасилили понять как работает CPU, это да.
>это потому-что Столман не осилил C# ))))))))))
Фу, слишком примитивный вброс, вы получаете -1 к скиллу троллинга и +1 к толщине.
>пс: Си темболее похоронили когда Страуструп решил создат С++ )))
Да, а корпорация Майкрософт то в курсе?Ну или какого фига они ядро, дрова и системные сервисы до сих пор пишут на них? Ну или хотя-бы Линус? Или бсдшники? Или еще 100500 ОСей? :)
>а С++ похоронили када создали Java
Геймдевам это расскажите, только смотрите чтобы они вас не поколотили :)
>а Java-у похоронили когда создали C#
Угу, помню-помню:
Get The Facts @ 2006: корпорация майкрософт заменяет систему на LSE, блаблабла! Крутые серверные системы от супер-корпорации! Какие времена транзакций! Какой дотнет!
Get The Facts @ 2009-2010: корпорация Майкрософт послана с LSE! Да, за хреновые времена транзакций и заваливане работы биржи.Хо-хо, сразу видно силу новых технологий. Epic win микрософтовских технологий на LSE, не иначе? :)
>пс2: что по вашему придёт на смену ООП (ХОП)
Забодали уже сменщики. Некоторым людям настолько тяжело дается осознание того что в мире может быть выбор из нескольких парадигм, языков и т.п. на разные вкусы и задачи? Надо нечто одно втюхивать как единственно верное, заменяющее все и вся? Нафиг-нафиг!
>[оверквотинг удален]
>Хо-хо, сразу видно силу новых технологий. Epic win микрософтовских технологий на LSE,
>не иначе? :)
>
>>пс2: что по вашему придёт на смену ООП (ХОП)
>
>Забодали уже сменщики. Некоторым людям настолько тяжело дается осознание того что в
>мире может быть выбор из нескольких парадигм, языков и т.п. на
>разные вкусы и задачи? Надо нечто одно втюхивать как единственно верное,
>заменяющее все и вся? Нафиг-нафиг!
>>Фу, слишком примитивный вброс, вы получаете -1 к скиллу троллинга и +1 к толщине.кстате вы хорошо описали Столмана
>Некоторым людям настолько тяжело дается осознание того что в
>мире может быть выбор из нескольких парадигм, языков и т.п. на
>разные вкусы и задачи? Надо нечто одно втюхивать как единственно верное,
>заменяющее все и вся? Нафиг-нафиг!
>> майкрософтSUX - о нём речи не идёт и C# с мелеомягкими ассоциировать крайне бредово
то что им пользуются нетчики ничего не говорит
возьми сравните возможности C# и C++>Геймдевам это расскажите, только смотрите чтобы они вас не поколотили :)
на то и геймдевелопперы и всё равно на чём писать хоть на пхп (главное чтоб картинка показывала)
>Ну или какого фига они ядро,
>дрова и системные сервисы до сих пор пишут на них?а зачем не на асм ???? или чем плох был BCPL ?
>кстате вы хорошо описали СтолманаДавайте Столлмана все-таки оставим в покое? Он умный мужик, поэтому свои права - ценит и готов их отставать при необходимости. Что выгодно отличает его от всяких размазней, у которых как правило кишка тонка или мозга маловато. И кстати если кто-то слишком слаб мозгом чтобы понять что вызывает те или иные действия другого человека - это как бы не фэйл того человека, а фэйл того чьего мозга не хватило на осознание.
>SUX - о нём речи не идёт и C# с мелеомягкими ассоциировать крайне бредово
Я не виноват что его разработали и продвигают именно они и нормально работает это только в их системе. Поэтому в теории C# кроссплатформенный, а на практике - всем кому оно надо всерьез - идут стройными рядами в винды. А для сравнения почему-то какаянить кутя выпускается под ВАГОН разных платформ где более-менее одинаково работает. И вендор оной не предлагает всем портировать ее под свои системы лично, как MS.
>то что им пользуются нетчики ничего не говорит возьми сравните возможности C# и C++
С прагматической точки зрения: прога на скажем плюсах и куте заработает на симбиане, n900, десктопном линухе (при том пофиг какой там проц, хоть powerpc), макоси, винде, ... А теперь то же самое для C#. Тут то и обнаруживаем что нормально его поюзать можно только в винде. И то - в винде винформсы, в гноме предлагается GTK#. А что предложат в макоси? Симбиане? Или там еще где? Все морду программы переписывать заново? Как по мне - так это на фичу совсем не тянет. Скорее, отсутствие кроссплатформенного тулкита который был бы одинаков для всех систем и распостранялся на вменяемых условиях - суровый изъян. Ну понятно что Майкрософт это не нужно (если все программы будут портабельны - никто не будет покупать у них винду и поюзают более дешевые системы).
>на то и геймдевелопперы и всё равно на чём писать хоть на пхп (главное
>чтоб картинка показывала)Просто на си++ код получается относительно быстрый и предсказуемый. А то припрет гарбаж колектору мусор собрать в неподходящий момент, и ... правильно, гамеза стормозит невовремя. Да и просто managed природа кода, пардон, на рантайм проверках ресурсы хавает. В тугом цикле рантайм проверки составляют значительный кусок потока команд видимо. В итоге все интенсивные рассчеты и доступ к памяти проседают буквально в разы (достаточно посмотреть на любые архиваторы, шифрование, хеширование, ...).
>а зачем не на асм ????
Асм не портабелен - переписывать все и вся досадно будет. Я вот например юзаю одни и те же дрова скажем usb high-speed на писюке под AMD64 и на железяке-роутере, с MIPS процессором. Вы как, перепишете дрова на мипсовский асм? А пупок не развяжется? :)
>или чем плох был BCPL ?
А фиг бы его знает - сильно древняя сущность. Собссно си на него похож и так получилось что си занял свое место. И как-то отдавать его и не собирается особо. При том я не вижу чем си плох для системных дел. По-моему он там на своем месте. Во всяком случае я могу проинструктировать сишный компилер положить код вон туда, данные вон туда а оперативку брать вон там. Кстати черта с два такой уровень гибкости выжмешь из managed языка без адских костылей и геморроя, что заведомо сужает сферу применения и портабельность (восьмибитник на манагед языке не попрограммишь, а на сях - запросто).
>>Давайте Столлмана все-таки оставим в покое?давайте! пенсионеров не трогать и отдать ему должное - человек революционер
>>Я не виноват что его разработали и продвигают именно они и нормально работает это только в их системе.это политика мелкомягких - делать всё для себя и под себя
их не волнует будет ли С# под линукс или мак ось
зато их волнует будет ли под амд или интел (вот понятие кросплатформенности)и я думаю это правильно - раз линукс появился как (может быть) альтернатива и новый взгляд на современные ОС пусть и имеет собственные новые альтернативные языки
>>С прагматической точки зрения: прога на скажем плюсах и куте заработает на симбиане, n900, десктопном линухе (при том пофиг какой там проц, хоть powerpc), макоси, винде, ... А теперь то же самое для C#.повторюсь - на любой архитектуре под которую имеется винда (платформа нет) и компилятор С# - да будут работать
мелкомягких не волнует линукс и мак ось
любую архитектуру поддерживает ???? - значть кросплатформенныйа на счёт плюсов просто достаточно сравнить периоды развития двух языков
за свой короткий период С# вобрал очень многое из ООП (хотя один большой минус вижу в отказе от множественного наследования)
если в С++ только реализовали замыкания то в С# это было изначальной задумкой.>>Я вот например юзаю одни и те же дрова скажем usb high-speed на писюке под AMD64 и на железяке-роутере, с MIPS процессором. Вы как, перепишете дрова на мипсовский асм? А пупок не развяжется? :)
непонял юмора как использовать одни и теже дрова при этом ихх переписывая ???
достаточно изучит архитектуру каждого проца и всё а "ЮСБ он и в Африке ЮСБ" теже айэркю, димиэй, порты ввода-вывода и диапазон памяти.>>А фиг бы его знает - сильно древняя сущность. Собссно си на него похож и так получилось что си занял свое место. И как-то отдавать его и не собирается особо. При том я не вижу чем си плох для системных дел.
я не говорю что С плох и что я категорически против него. новые языки это метод облегчения труда программиста (незря ЛЕНЬ двигатель прогресса). И программа на С не уступает программам на асм (ну немножко в скорости и гибкости) и поэтому в С реализовали инлайн ассемблинг
>>(восьмибитник на манагед языке не попрограммишь, а на сях - запросто).
тока под какую ОС ???
>давайте! пенсионеров не трогать и отдать ему должное - человек революционерВай, сколько апломба. Лучше б столько же достижений было :)
>это политика мелкомягких - делать всё для себя и под себя
>их не волнует будет ли С# под линукс или мак осьТогда вполне честно если остальных не будут волновать продвигаемые ими стандарты. И я не вижу ни 1 причины почему кому-то надо упереться и ... помочь MS остаться в лидерах. Ну или зачем играть в заведомо проигрышную игру где стартовые условия неравные? Нахрена мне например осваивать MS-ориентированный рантайм и язык продвигаемый только MS или их шестерками? Я хочу со временем уйти от юзежа винды СОВСЕМ. Пингвины в качестве оси мне как-то куда больше доставляют. А вот быть отбросами второго сорта мне не улыбается. Приветы Майкрософту, ага. А нокия почему-то не делит на сорта юзеров своей либы.
>зато их волнует будет ли под амд или интел (вот понятие кросплатформенности)А как насчет MIPS или ARM? А чтобы еще и не под виндами? Или в этом месте ус нечаянно отклеивается и кроссплатформеннсть оказывается лишь маркетинговым пщиком?
>новые альтернативные языки
Во всяком случае - я не вижу на кой бы хрен линуксоидам тратить силы на левые догонялки MS. Простите, а почему формат бинарей в "кроссплатформенной" среде не платформонейтральный а виндовое EXE пардон? Сани же вон сделали платформенно-нейтральные форматы файлов, например. А MS ... ну как обычно: гребут под себя делая так чтобы остальные соснули.
>повторюсь - на любой архитектуре под которую имеется винда (платформа нет) и
>компилятор С# - да будут работатьДа, только винда есть для не сильно многих архитектур, так что никакого спича о портабельности тут не иде. Ну нет винды для арм, мипс и ппц. Вообще. Поддержка полутора процессорных архитектур - не портабельность и не кроссплатформенность а жалкая пародия.
>мелкомягких не волнует линукс и мак ось
>любую архитектуру поддерживает ???? - значть кросплатформенныйДык не любую. Где обычная винда для ARM, MIPS или PPC например? Не вижу.
>если в С++ только реализовали замыкания то в С# это было изначальной задумкой.
И чего?Как я уже сказал, для лично меня то что оно нигде толком кроме винды и i386/AMD64 не работает - уже отличная заявка на фэйл.
>непонял юмора как использовать одни и теже дрова при этом ихх переписывая ???
Если дрова на асме - их придется переписать. С нуля. Что гемор нереальный. А на сях ... простите, только перекомпилить. Что как-то ну совсем не гемор.
>достаточно изучит архитектуру каждого проца и всё а "ЮСБ он и в
>Африке ЮСБ" теже айэркю, димиэй, порты ввода-вывода и диапазон памяти.Вы не поверите но в линухе зачастую достаточно пересобрать драйвер. Возможно с какими-то небольшими адаптациями, но основная масса логики - изменений не потребует. Например драйвер какогонить usb mass storage class - будет получен для мипсового или PPCшного линукса просто тупой компилежкой его сорса. Да, совсем платформоспецифичные вещи придется ессно переписать или написать. Те же IRQ, DMA и прочая разными процессорами понимаются по разному, факт. А вот какойнить usb mass storage с EHCI контроллером - он и в африке mass storage, с EHCI контроллером. И основная масса логики там останется неизменна. Ну а вы можете переписывать если вам не влом. Ну или шина PCI и логика работы с PCI девайсами как правило везде достатчно одинаковая например - ARM, MIPS или кто там еще обычно реализуют более-менее стандартные сущности. Переписывать с нуля дрова в свете этого было бы достаточно не умно.
>я не говорю что С плох и что я категорически против него.
>новые языки это метод облегчения труда программиста (незря ЛЕНЬ двигатель прогресса).В итоге большая часть дотнетчиков не способны даже примитивный base64 декодер написать... и на все стандартные отмазы вида "для этого у MS нет класса". По-моему называть таких упырей программистами - сильно жирно. Это генераторы glue-кода между MSовскими классами. Не способные сами генерить никаких вменяемых алгоритмов.
>И программа на С не уступает программам на асм (ну немножко в скорости и гибкости)
Насчет скорости - да, при том иногда - не так уж и немножко. Скажем чисто-сишный XVID сливает си+асм варианту чуть ли не в разы. Просто потому что сишный компилер может сгенерить хрен знает какой код в узком цикле и человек зная что критичное место вон там - может вон там и написать оптимально, возможно чуть просадив этим оптимальность в месте где это имело куда меньшую цену. Насчет гибкости - на си такое заворачивают что диву даешься. Ткнуть сишный компилер "вот тут у нас readonly code в флеше, вот тут статичные данные в флеше, а вон там - переменные в оперативке" - совершенно не вопрос. Как не вопрос убедить его выдать эти блоки в каком угодно виде. То есть, по сути сишный компилер типа GCC может своим линкером чуть ли не готовый RAW образ фирмвари изобразить, пардон. И строго говоря - сишная программа написанная должным образом не нуждается в стандартных либах, файлах и прочая. Чисто-алгоритмические куски - весьма портабельны.
>и поэтому в С реализовали инлайн ассемблинг
Ну вы просто ARMовское ядро Cortex-M3 не видели :). Оказывается если чутка подыграть сям ... в этом ядре можно извините самые первые инструкции выполнять именно сгенеренные сишным компилером. Т.е. данное ядро при желании можно программить вообще без асма по сути. Нужно ли... думаю каждый сам найдет ответ на этот вопрос. Ради справедливости замечу что другие процессоры более капризны к последовательностям раннего старта и сразу после включения не предоставляют окружение годное для выполнения сишной программы. Но тем не менее какойнить CoreBOOT и то в основном писан на сях :).
>тока под какую ОС ???
А ни под какую. Bare metal там зачастую. Бывают RTOS но сие на любителя(чем сложнее система и больше сущностей, тем больше секаса с отладкой). И да, сишная программа может работать в окружении где...
- Нет printf, стандартного ввода-вывода, файловой системы, etc. Правда круто? В эмбеддед такое на каждом углу в мелких однокристальниках. А си позволяет и такое зафигачить. Это к вопросу о гибкости :)
- Нет malloc и подобных. Все статически, сразу на старте (попробуйте так в манагед языках изобразить, ага).
- Всякая там инициализация периферии и работа с ней напрямую - без вопросов.В общем то вещей которые можно сделать на асме и нельзя на си - не так уж и много. Си изначально был задуман как язык системщиков и он с этой ролью справляется на 5 баллов имхо.
>>Нахрена мне например осваивать MS-ориентированный рантайм и язык продвигаемый только MS или их шестерками? Я хочу со временем уйти от юзежа винды СОВСЕМ. Пингвины в качестве оси мне как-то куда больше доставляют.фанатизм таки прёт ))))) поехали дальше
>>А как насчет MIPS или ARM? А чтобы еще и не под виндами? Или в этом месте ус нечаянно отклеивается и кроссплатформеннсть оказывается лишь маркетинговым пщиком?
несёте чушь
http://www.arm.com/community/software-enablement/microsoft/w...
http://www.arm.com/community/partners/display_company/rw/Com.../а вот сюда советую заглянуть повнимательнее
http://www.microsoft.com/windowsembedded/en-us/products/wind...
Windows Embedded CE Overview:
Small Footprint: 300KB/ 700 Components
Processor: ARM, MIPS, x86 ,SH4 (up to CE 6.0 R2)
Real-time OS: 32-bit Native Real-Time Support Unified Kernel
Run Win32 Apps: Customized Win 32 Applications
>>Где обычная винда для ARM, MIPS или PPC например? Не вижу.
вы знаете что такое эмбеддед ???? или у вас дома поверписи стоит ???
>>Если дрова на асме - их придется переписать. С нуля. Что гемор нереальный. А на сях ... простите, только перекомпилить. Что как-то ну совсем не гемор.
этож тупа использовать дрова написанные на асм под один тип процессора на другом ))))
может вы откомпилируете программу компилятором для другого проца ???>>Вы не поверите но в линухе зачастую достаточно пересобрать драйвер. Возможно с какими-то небольшими адаптациями, но основная масса логики - изменений не потребует. Например драйвер какогонить usb mass storage class - будет получен для мипсового или PPCшного линукса просто тупой компилежкой его сорса. Да, совсем платформоспецифичные вещи придется ессно переписать или написать. Те же IRQ, DMA и прочая разными процессорами понимаются по разному, факт. А вот какойнить usb mass storage с EHCI контроллером - он и в африке mass storage, с EHCI контроллером. И основная масса логики там останется неизменна. Ну а вы можете переписывать если вам не влом. Ну или шина PCI и логика работы с PCI девайсами как правило везде достатчно одинаковая например - ARM, MIPS или кто там еще обычно реализуют более-менее стандартные сущности. Переписывать с нуля дрова в свете этого было бы достаточно не умно.
очень толсто
знаете ни один из процессоров принципом работы не отличается
у всех есть регистры есть стек и всякого рода команд (принцип один и тот же)
отличается лишь синтаксис>>В итоге большая часть дотнетчиков не способны даже примитивный base64 декодер написать... и на все стандартные отмазы вида "для этого у MS нет класса".
создавать клас ради одной функции ??? некошерно ???
http://msdn.microsoft.com/en-us/library/dhx0d524.aspx
http://msdn.microsoft.com/en-us/library/system.convert.fromb...>>По-моему называть таких упырей программистами - сильно жирно
редмондовцы вполне вменяемые проггеры
>>В общем то вещей которые можно сделать на асме и нельзя на си - не так уж и много. Си изначально был задуман как язык системщиков и он с этой ролью справляется на 5 баллов имхо.
))) вы из протектед мод на Си программе выйте сможете ?
>>>Если дрова на асме - их придется переписать. С нуля. Что гемор нереальный. А на сях ... простите, только перекомпилить. Что как-то ну совсем не гемор.
>
>этож тупа использовать дрова написанные на асм под один тип процессора на
>другом ))))
>может вы откомпилируете программу компилятором для другого проца ???Как вы собрались компилировать программу написанную на х86-ассемблере компилятором ARM-ассемблера ???
>>>>Если дрова на асме - их придется переписать. С нуля. Что гемор нереальный. А на сях ... простите, только перекомпилить. Что как-то ну совсем не гемор.
>>
>>этож тупа использовать дрова написанные на асм под один тип процессора на
>>другом ))))
>>может вы откомпилируете программу компилятором для другого проца ???
>
>Как вы собрались компилировать программу написанную на х86-ассемблере компилятором ARM-ассемблера ???я это у вас и спрашивал
>Oh, really? А что это за асм-оптимизация в кодеках тогда?Ну чего ты на такую толстоту ведешься?
>>а С++ похоронили када создали Java
>Геймдевам это расскажите, только смотрите чтобы они вас не поколотили :)Геймдевелоперы -- вообще очень специфичный народ. На крестах сейчас только олдовые фанаты жанра ради фана балуются. Думают, что это еще реально, написать игру на C++. Сейчас ведь нельзя сделать небюджетную, но культовую игру -- не выйдешь на рынок. Не те времена. Геймдев это давно серьезный бизнес, где работают соответствующие законы. Новички почти не выходят, рулят опытные хрычи закалки последних 10-15 лет. Но объем кода задают все же толпы среднеквалифицированных кодеров. Движки покупаются готовыми, остается только в кратчайшие сроки наклепать обвязку. Поэтому высокоуровневые фреймворки и биндинги на таких же высокоуровневых языках уже сейчас в полном ходу.
>Забодали уже сменщики. Некоторым людям настолько тяжело дается осознание того что в
>мире может быть выбор из нескольких парадигм, языков и т.п. на
>разные вкусы и задачи? Надо нечто одно втюхивать как единственно верное,
>заменяющее все и вся? Нафиг-нафиг!А вот тут соглашусь. Для всего есть наиболее подходящее применение. Ядро -- на си; сайты на JS.
>Геймдевелоперы -- вообще очень специфичный народ. На крестах сейчас только олдовые
>фанаты жанра ради фана балуются.Дык на другом как-то гамез и не попадается. Наверное потому что всякие красивые эффекты и прочая требуют задействования мозга.
>Думают, что это еще реально, написать игру на C++.
И ведь правы, сцуки, потому что все нормальные игры на них и писаны почему-то.
>Сейчас ведь нельзя сделать небюджетную, но культовую игру --
>не выйдешь на рынок. Не те времена.А вон indie миллион наскребли :) миллион то тоже на дороге не валяется. А для культовой игры как бы положен хороший движок и прочая. Ни на чем кроме плюсов вы его тупо не сделаете. Ну, во всяком случае - я не видел оных с приемлимыми параметрами на C# или Java. На си - видел, кармак суровый тип. Да еще и внутреннюю логику на сях по сути реализовал - "quake C" :).
>Геймдев это давно серьезный бизнес, где работают соответствующие законы.
Угу, особенно приставки. Там железо не меняют годами, выдавливая из него максимум. Какое уж там ява с сишарпом, когда они там упираются...
>Новички почти не выходят,
Выходят. Просто дураков почему-то всегда больше чем реально крутых перцев.
>остается только в кратчайшие сроки наклепать обвязку.
И много культовых игр именно купило себе движки? И вообще много ли тех кто в кратчайшие сроки наклепал обвязку и стал культовой игрой? oO
>Поэтому высокоуровневые фреймворки и биндинги на таких же высокоуровневых
>языках уже сейчас в полном ходу.Я не вижу ничего страшного в юзании относительно высокоуровневого языка (типа скриптов на луа) там где это осмысленно и не тормозит, типа медленной общей логики и прочего, которой скорострельность нафиг не нужна а нужна простота при частой модификации.
>Ядро -- на си; сайты на JS.
Вообще не понимаю мании срочно все заменять на новую парадигму/язык/.... - а это зачем, собственно?
>пс: Си темболее похоронили когда Страуструп решил создат С++ )))
>а С++ похоронили када создали Java
>а Java-у похоронили когда создали C#И вот, теперь программисты ходят и поднимают зомби...
Альтернатива чему? ))) Basic-у? С# с С++ схожи только первый буквы в названии. Уж лучше я на Objective-C буду писать.
>Альтернатива чему? ))) Basic-у? С# с С++ схожи только первый буквы в
>названии. Уж лучше я на Objective-C буду писать.Шутки шутками, а C# действительно альтернатива Visual Basic и FoxPro, судя по сфере применения.
>>Альтернатива чему? ))) Basic-у? С# с С++ схожи только первый буквы в
>>названии. Уж лучше я на Objective-C буду писать.
>
>Шутки шутками, а C# действительно альтернатива Visual Basic и FoxPro, судя по
>сфере применения.вы уже заменили в 1С вижуал бейсик на C# ?
>вы уже заменили в 1С вижуал бейсик на C# ?А Гоблин уже перевел C# на русский?
А что переводил Гоблин чтобы получился 1С? :)
>Альтернатива чему? ))) Basic-у? С# с С++ схожи только первый буквы в
>названии. Уж лучше я на Objective-C буду писать.)))))) ржунимагу
а парадигма какая ???
или вы отличие видите только в синтаксисе ???
ну был С была Симула нахрена надо было создавать С++ ??Срауструп правильно сказал в одном из своих интервью - для того что бы программисты писали программы очень долго и тем самым зарабатывали больше денег
>>Уж лучше я на Objective-C буду писать.
вам удачи а я лучше буду писать на неоспаримом асм
>>>Уж лучше я на Objective-C буду писать.
> вам удачи а я лучше буду писать на неоспаримом асмСсылку на вменяемый проект авторства автора в студию!
http://cs.mipt.ru/docs/comp/rus/develop/other/stroustrup_int...Хотя уважаемая Алёна считает эт олжеинтервью
http://alenacpp.blogspot.com/2006/06/blog-post.html
Таки ссылку на ваш проект на асме или перестаньте петросянить в треде.Спасибо!
>)))))) ржунимагу
>а парадигма какая ???
>или вы отличие видите только в синтаксисе ???
>ну был С была Симула нахрена надо было создавать С++ ??Кресты может и отстойное гогно мамонта, но абсолютно закономерно успешен для своего времени. Да, сейчас уже безнадежно устарел, но вспомни, какие объемы памяти были в ходу всего 5 лет назад. А то был 1985й, когда компьютеры были большими. Кресты это сочетание относительной мощности и возможность еще актуальных тогда низкоуровневых оптимизаций.
>>Кресты может и отстойное гогно мамонта,с первой частью не соглашусь - я сам сторонник плюсов
>>но абсолютно закономерно успешен для своего времени.
а тут не соглашусь - кто хочет "быстро" писать проги он уже давн оперешёл на Java и C#
>>Да, сейчас уже безнадежно устарел, но вспомни, какие объемы памяти были в ходу всего 5 лет назад. А то был 1985й, когда компьютеры были большими. Кресты это сочетание относительной мощности и возможность еще актуальных тогда низкоуровневых оптимизаций.
а чем был плох С или BCPL (в случае ООП - Симула)?
правильно типа синтаксисом и недостатками, которые якобы исправили в плюсах
Люди задают одни и теже вопросы, поэтому приходится цитировать самого себя>> В любом случае сложившая ситуация в индустрии ПО не отменяет факта, что С++ как язык программирования УГ.
То что С++ на данный момент нет сто-процентной замены не делает его правильным языком. Сходу можно назвать десятки его недостатков
>Люди задают одни и теже вопросы, поэтому приходится цитировать самого себя
>
>>> В любом случае сложившая ситуация в индустрии ПО не отменяет факта, что С++ как язык программирования УГ.
>
>То что С++ на данный момент нет сто-процентной замены не делает его
>правильным языком. Сходу можно назвать десятки его недостатковИ все эти недостатки - не повод уходить на C# или жабу, у которых их еще больше.
Нахрен раздувать флейм а ? У всего есть свои недостатки.
Языки отличаются по концепции и сделаны для принципиально разных задач.
Сравнивать их - обычная некомпетентность.
>Нахрен раздувать флейм а ? У всего есть свои недостатки.
>Языки отличаются по концепции и сделаны для принципиально разных задач.
>Сравнивать их - обычная некомпетентность.там нечего сравнивать
если обрать внимание на то что все выше сказанные языки в основном используются программистами типа ООП (ХОП) и что стандарта так называемого ООП (ХОП) нет и соответсвенно любой язык который косит под ООП будет извращаться над ним как хочет
и отсюда люди делают выводы что мол какой-то недостаток в С++ имеется в С#-пе
считать, к примеру, ужасный синтаксис языка недостатком это бред
пс: пишите люди на асм
>То что С++ на данный момент нет сто-процентной замены не делает его
>правильным языком. Сходу можно назвать десятки его недостаткови какой язык не 100% замена C++ ?
>>То что С++ на данный момент нет сто-процентной замены не делает его
>>правильным языком. Сходу можно назвать десятки его недостатков
>
>и какой язык не 100% замена C++ ?Тебе и намекнули что среди популярных в данный момент языков программирования нет ни одного конкурента С и С++. Сейчас в моде JIT компиляция и виртуальные машины. Все это хорош подходит для web и мобильных телефонов, а вот драйвера на PHP, Java, Python и С# писать проблематично.
>>>То что С++ на данный момент нет сто-процентной замены не делает его
>>>правильным языком. Сходу можно назвать десятки его недостатков
>>
>>и какой язык не 100% замена C++ ?
>
>Тебе и намекнули что среди популярных в данный момент языков программирования нет
>ни одного конкурента С и С++. Сейчас в моде JIT компиляция
>и виртуальные машины. Все это хорош подходит для web и мобильных
>телефонов, а вот драйвера на PHP, Java, Python и С# писать
>проблематично.а на асм проблематично ????
>а вот драйвера на PHP, Java, Python и С# писать
>проблематично.На ЦПП их тоже писать проблематично, тут обычный С (или обжектив) и асм никуда не делись пока.
>
>>а вот драйвера на PHP, Java, Python и С# писать
>>проблематично.
>
>На ЦПП их тоже писать проблематично, тут обычный С (или обжектив) и
>асм никуда не делись пока.Повторю мысль - у сравниваемых языков разные сферы применения. Их нельзя сравнить. Что еще непонятно ?
>телефонов, а вот драйвера на PHP, Java, Python и С# писать
>проблематично.Зачем так узколобо мыслишь? В Google вон например сайты на Java пишут и транслируют в JavaScript. Писать драйверы (и все остальное) можно на любом, перечисленном тобой языке.
>Зачем так узколобо мыслишь? В Google вон например сайты на Java пишут
>и транслируют в JavaScript. Писать драйверы (и все остальное) можно на
>любом, перечисленном тобой языке.Я не мыслю узколобо. Я пытаюсь донести очевидные вещи. Java отлично подходит для написания сайтов. Java и JavaScript это совершенно разные программные платформы. Все низкоуровневые компоненты, драйверы, а также большая часть компонентов операционных систем на текущий момент написаны на C/С++ и ассемблере. Писать такие вещи на интерпретируемых языках невозможно.
Нельзя сравнивать языки, ориентированные на разные сферы применения, это как сравнить гоночный болид с карьерным грузовиком.
Я хочу сказать, что для написания драйверов достаточно выразительных средств любого популярного сейчас языка. Все различия в рантайме, который они тащат. Просто не люблю, когда говорят, мол, вот все ядра написана на C и Asm, значит это лучшие языки. А вообще я с тобой не спорю, про разные сферы применения согласен.
>Сходу можно назвать десятки его недостатковВсе бы ничего, только у других недостатков еще больше и они фатальнее. Остальные как правило сильно менее универсальны (а учить 20 велосипедиков на все случаи жизни - голова вспухнет), тормозны, малопредсказуемы, жрут кучу ресурсов, есть под полторы платформы или просто оказались никому нафиг не нужны. При том эти недостатки фатальнее чем костыльность. Если нечто вообще не позволяет реализовать задумку в желаемом виде - тут уже вообще насрать насколько там забористее синтаксис и прочая, ибо mission failed сразу при старте.
Ты хоть раз отлаживал что-нибудь на С++?
Ну, я отлаживал, отлаживаю и буду отлаживать... И что с того?
пока ты отлаживаешь я сделаю работу быстрее и качественнее и пойду пить пиво.
>пока ты отлаживаешь я сделаю работу быстрее и качественнее и пойду пить
>пиво.и на скока быстро будет работать твоя программа ???
пс: ПОЙМИТЕ ЖЕ ЧТО ПОНЯТИЕ БЫСТРОТА ДОЛЖНО ОТНОСИТСЯ НЕ К ЧЕЛОВЕКУ КОТОРЫЙ БЫСТРО НАПИШЕТ А К ПРОГРАММЕ КОТОРАЯ БЫСТРО И ОПТИМАЛЬН ОБУДЕТ РАБОТАТЬ
пс: БЫСТРОТА - это слова гламурных менеджеров
Еще раз: Под каждую задачу свой язык. Какой смысл писать например интерактив на крестах. Там прекрасно справится и скриптовый язык при меньшем геморрое
Гламурные менеджеры понимают цену сопровождения такой программы и цену квалифицированного специалиста.
>пока ты отлаживаешь я сделаю работу быстрее и качественнее и пойду пить
>пиво.да точно программы типа хелло ворлд можно писать с бутылкой пива под рукой и бегать не придётся
пс: можно и обкуриться
Вообще напоминает "мыши плакали кололись но продолжали жрать кактус". Никогда не задумывался, что может быть быть что-то не так?
>Никогда не задумывался, что может быть быть что-то не так?Никогда, поскольку предпочитаю писать так, чтоб сразу работало. Последнее время, отладчиком практически не пользуюсь. Хватает отладочного вывода.
Так что, делай "быстрее и качественнее", а я уже пошел пиво пить. Удачи! :-)
Да ты уникум получается, немного таких людей которые пишут без багов! Тогда никаких претензий нет, пиво заслужил
> ... немного таких людей которые пишут без багов!Я этого не утверждал, я ,лишь, сказал, что для их локализации хватает отладочного вывода.
> Да ты уникум получается...
Не угадал. :-)
"Термоядерная отладка в Linux и xBSD" ( http://www.insidepro.com/kk/337/337r.shtml , что-то более авторитетное искать лень, но подобное высказывание пролетало и у Р.Лава, в его буке по ядру ):
"Причина в том, что Линус Торвальдс (до сих пор стоящий у руля и принимающий решение о включении тех или иных компонентов в ядро) не доверяет интерактивным отладчикам и считает, что у "правильных" программистов таких потребностей просто не возникает. Типа, есть же отладочная печать (см. man printk) и ее, типа, вполне достаточно."
При всем этом, я бы не сказал, что ядро глючная поделка -- у меня, вот, на ноуте сейчас аптайм почти 46 дней.Впрочем, похоже Торвальдса, таки, достали плачем -- "Ядерный таймлайн. Обзор нововведений в последних ядрах Linux" ( http://www.magxak.ru/xa123/084/1.htm ):
"2.6.26 - 14 июля
.....
Наконец, Линус Торвальдс нисходит с небес к обычному люду и позволяет включить в ядро отладчик KGDB, требующий отдельную машину для трассировки происходящих событий. Этого события многие ждали с момента выхода первой версии ядра!"
>>Никогда не задумывался, что может быть быть что-то не так?
>
>Никогда, поскольку предпочитаю писать так, чтоб сразу работало. Последнее время, отладчиком практически
>не пользуюсь. Хватает отладочного вывода.
>Так что, делай "быстрее и качественнее", а я уже пошел пиво пить.
>Удачи! :-)как отладит хелло ворлд без отладчика ?
>Хватает отладочного вывода.!!! програмерам на заметку, кстати. Вербозные логи на каждый пук порой лучше любого отладчика! Когда оно реализовано нормально - это по сути трейс исполнения программы в реальном времени, где видно что, куда и нафига происходило и что и где пошло не так как хотелось бы. По многолетнему опыту отлова багов - локализовать проблему в программе с грамотным логгингом в 100500 раз проще чем только ффтыкая в дебаггере. Поубивал бы тех кому впадлу писать вербозные логи предпринимаемой активности.
>По многолетнему опыту отлова багов - локализовать проблему в программе с
>грамотным логгингом в 100500 раз проще чем только ффтыкая в дебаггере.
>Поубивал бы тех кому впадлу писать вербозные логи предпринимаемой активности.Ты сегодня на удивление правильные мысли выражаешь. Согласен на 80%. Сам сейчас пишу на JS, где практически невозможно в силу environment ставить точки останова и ходить по программе. Успел освоить и привыкнуть к отладке по логам. В некоторых случаях (несколько потоков исполнения) бывает нагляднее обычного дебаггера; ловил довольно "вредные" вещи. Но опять же слышал про "многопоточных отладчик" в новой VS и "обратное выполнение" в последнем GDB и иногда подозреваю, что это тоже очень мощные вещи.
Вы хоть представляете как работает дебаггер ???
или можетет предсказать как будет действовать компилятор с использованием всякой оптимизации??
может ваши дебаг логи это покажут ??пс: нех засорять программу ненужным кодом
всёравно программа будет выполняться так как компилятор захочет
и тут чтобы решить всякие появившиеся траблы можно только с помощью дебаггерапс: учите асм чтобы уметь пользоваться дебаггером
Пиши на современных языках и забудь про эти проблемы.
>>Пиши на современных языках и забудь про эти проблемы.это типа пэхэпэ ???
пс: а коментарий ниже неасилил ?
>это типа пэхэпэ ???У тебя явно какой-то пунктик насчет PHP. Нет, я говорил хотя бы о тех же C# и Java.
>пс: а коментарий ниже неасилил ?А к нему мой ответ тоже относится.
>>Нет, я говорил хотя бы о тех же C# и Java.аа вот оно что ))) а там дебаггер не используется ???
>>А к нему мой ответ тоже относится.
а более весомого ответа не нашлось ??? ну и как же на современных языках отследить утечку ???
сорри забыл )) на современных языках надо забыть про понятие памяти там есть gc
>аа вот оно что ))) а там дебаггер не используется ???Ты чего докопался? Я же не говорил, что дебаггеры вообще не нужны.
>а более весомого ответа не нашлось ??? ну и как же на
>современных языках отследить утечку ???
>сорри забыл )) на современных языках надо забыть про понятие памяти там
>есть gcГоворишь так, будто это что-то плохое.
>>Говоришь так, будто это что-то плохое.1) по отношению к gc - ничего плохого в gc нету есть кривые его реализации которые себя до сих пор не оправдали
и вот думает народ что лучше управлять памятью в ручную2) утечка - вот это точно ночной кошмар программиста
>>Ты чего докопался? Я же не говорил, что дебаггеры вообще не нужны.
сори конечно же что всех тут достал, но меня бесит то что человек называющий себя программистом - привязывает себя к какому либо языку, который по сути является просто упрощённым вариантом одного единого языка - языка команд процессора, и кричит что нах не нужен асм, нах не нужен С, нах не нужен С#. И не надо думать что если я напишу быстро на С# пограмму получу за это много денег и через несколько лет буду мажором ))) - мажорами становятся только такие как дядя Билл ))))
>...меня бесит то что человек называющий себя программистом - привязывает себя к какому либо языку,Я как раз за выбор языков адекватно задаче. Однако считаю, что большую часть десктопного софта (и тем более серверного) можно и нужно писать на высокоуровневых языках со сборщиком мусора. А для функциональных ЯП, к которым сейчас проявляется повышенный интерес (неслучайно имхо), это вообще врожденная особенность.
>И не надо думать что если я напишу быстро на С# пограмму получу за это
>много денег и через несколько лет буду мажором ))) - мажорами
>становятся только такие как дядя Билл ))))Жизненные цели конечно у всех свои, но я не вижу ничего плохого в том, чтобы быстро написать на C# программу и получить за это много денег.
>Вы хоть представляете как работает дебаггер ???Да, я не только представляю но еще и пользуюсь им. Такой я вот нехороший.
>или можетет предсказать как будет действовать компилятор с использованием всякой
>оптимизации??Как бы при отладке - оптимизация отключается. Как раз чтобы не разгребать фортели оптимизера а заниматься отловом проблемы. Сюрприз? :-)
>может ваши дебаг логи это покажут ??
Дебаг логи могут показать в каком месте облажалась общая логика программы. При том через дебагер это понять зачастую намного геморройнее. Более того - логи применимы даже для сложных, многопоточных программ критичных к непрерывному выполнению. Дебаггер как бы достаточно сильно вклинивается в логику программы и может попросту своим наличием убрать условия вылезания проблемы. Кстати даже логи в принципе могут влиять - мне известны случаи когда особо-паскудные баги не желали проявляться когда активен вербозный логгинг. Какиенить race conditions например удивительно капризны к временной последовательности :) чуть что не так - и все как бы нормально. А чуть условия поменялись - бац - вылазит какой-то странный сюрприз!
>пс: нех засорять программу ненужным кодом
Да, зато когда какойнить IM или P2P клиент (или какой вам там по вкусу сетевой софт) работает криво - я бы посмотрел как вы отдебажите дебагером протокольную логику и закидоны в ней, учтя что это совместная игра минимум 2 или более узлов сети в реальном времени. И вклинивание в нее с какиминить там брякпойнтами - сильно порушит логику и изменит правила игры до неузнаваемости. Как бы ремотные узлы видя что вы тупанули на энное время - могут кардинально изменить свою логику поведения по отношению к вам.
>всёравно программа будет выполняться так как компилятор захочетБред. Если программа делает не то что надо программисту - ему надо йаду выпить.
>и тут чтобы решить всякие появившиеся траблы можно только с помощью дебаггера
Хрен там, некоторые типы багов через дебагер ловить проблематично. А порой и невозможно. Скажем в случае энтерпрайзов - кастомер тупо никогда вам не даст достаточных прав а его системах оперирующих с чувствительными данными.
>пс: учите асм чтобы уметь пользоваться дебаггером
Так я знаю штук пять асмов. Асм х86 знаю погано, на минимальном уровне, т.к. гадость этот ваш х86, строго говоря. В мире полно явно более симпотных архитектур. Ну хоть тот же ARM например - на асме он сильно менее мерзопакостен чем х86 :)
>Так я знаю штук пять асмов. Асм х86 знаю погано, на минимальном
>уровне, т.к. гадость этот ваш х86, строго говоря. В мире полно
>явно более симпотных архитектур. Ну хоть тот же ARM например -
>на асме он сильно менее мерзопакостен чем х86 :)Как насчёт IBM POWER5-6?
>[оверквотинг удален]
>>грамотным логгингом в 100500 раз проще чем только ффтыкая в дебаггере.
>>Поубивал бы тех кому впадлу писать вербозные логи предпринимаемой активности.
>
>Ты сегодня на удивление правильные мысли выражаешь. Согласен на 80%. Сам сейчас
>пишу на JS, где практически невозможно в силу environment ставить точки
>останова и ходить по программе. Успел освоить и привыкнуть к отладке
>по логам. В некоторых случаях (несколько потоков исполнения) бывает нагляднее обычного
>дебаггера; ловил довольно "вредные" вещи. Но опять же слышал про "многопоточных
>отладчик" в новой VS и "обратное выполнение" в последнем GDB и
>иногда подозреваю, что это тоже очень мощные вещи.УПД:
наличие утечек вы тоже будете фиксировать в дебаг логе ??
пс: эксцепшены не есть отладка
>наличие утечек вы тоже будете фиксировать в дебаг логе ??Зачем? Для этого Valgrind, со товарищи, есть.
"There are Valgrind tools that can automatically detect many memory management and threading bugs, and profile your programs in detail."
Т.е. Valgrind, как бы профилировщик, а не дебагер в полном смысле этого слова.
У Гугля, что-то подобное было...
))))посоветуйте коментом выше
если человеку грубо говоря западло использовать дебаггер то про валгринд он ваще не слышал ))пс: он бы в первую очередь закоментил бы
>наличие утечек вы тоже будете фиксировать в дебаг логе ??Если перехватить функции выделения памяти и логгить их вызовы из "собственного, отладочного malloc" и прочая - почему бы и нет? Получите трейс вызовов функций выделения памяти - будет над чем подумать, не так ли? :) Кастомные аллокаторы памяти на сях под те или иные нужды - вообще явление не столь редкое.
вы ещё дамп памяти снимайтепс: так пишите сразу свой gc
>>Хватает отладочного вывода.
>
>!!! програмерам на заметку, кстати. Вербозные логи на каждый пук порой лучше
>любого отладчика! Когда оно реализовано нормально - это по сути трейс
>исполнения программы в реальном времени, где видно что, куда и нафига
>происходило и что и где пошло не так как хотелось бы.Вот чем отличается embedded-разработка от энтерпрайза, тах это наличием (вернее — отсутствием, при грамотном подходе) простыней таких вот "логов". А если не умеешь масштабироваться, то тебе придётся в них ковырятся — и ещё не известно, сколько времени у тебя уйдёт на разбор полётов и на само, собственно, программирование приложения уровня энтерпрайз.
>По многолетнему опыту отлова багов - локализовать проблему в программе с
>грамотным логгингом в 100500 раз проще чем только ффтыкая в дебаггере.Угу. Только в небольших приложениях, с участками отладки не более 1000 строк кода. Вот там, действительно, логи рулят. Что ниже этого порога и не многопоточно — легче дебагом. Что выше — пиши модульные и функциональные тесты.
>Поубивал бы тех кому впадлу писать вербозные логи предпринимаемой активности.
Не нужно быть столь циничным к другим отраслям разработки ПО. Приложения пишутся не только для смартфонов.
На закуску: http://samolisov.blogspot.com/2010/05/eclipse-36.html
>>!!! програмерам на заметку, кстати. Вербозные логи на каждый пук порой лучше
>>любого отладчика!
>Вот чем отличается embedded-разработка от энтерпрайза, тах это наличием (вернее —
>отсутствием, при грамотном подходе) простыней таких вот "логов".Я видел и дебаговые printf-ы в компорт в эмбеддед и неслабые портянки логфайлов в энтерпрайзном добре с выкрученными на максимум уровнями дебаглоггинга, которые только и позволяли програмерам понять что случилось (или простыня на диск или срач в БД). И что характерно - вербозный логгинг позволяет локализовать проблему быстро и точно, если сделано не через задницу (а если все-таки через задницу - так програмерам приходится его еще и дописывать по мере возникновени багов у кастомеров, мля). При том - сие катит для совершенно разных типов программ. И кстати лучше сразу нормально написать мощную и настраиваемую подсистему логгинга (выбор левела срачности и т.п. для разных целей+желательно фильтрация источников) чем потом мудохаться с костылями которые придется клеить на сопли сбоку под конкретную граблю вон того юзера. В итоге в сумме на костылестроение уйдет в сто раз больше сил и времени чем 1 раз нормально сделать.
>А если не умеешь масштабироваться, то тебе придётся в них ковырятся
Не понял какая взаимосвязь между логами и масштабированием. Масштабируемые системы тоже сбоят и как ни странно, вменяемый логгинг там может что называется, спасти день, позволив локализовать проблему и проследить общую последовательность событий которая вызывает проблему. При том - если бага вылазит раз в месяц - вы ее только по таким вот логам и сможете поймать, потому как лично караулить в дебагере месяц - не вариант.
>— и ещё не известно, сколько времени у тебя уйдёт на разбор полётов и
>на само, собственно, программирование приложения уровня энтерпрайз.Вот честно, я видел кучу энтерпрайзных проектов. При том те кто не поломался написать логинг - сильно упростили жизнь прежде всего себе. Потому что во первых случаях, иногда юзер по вербозному логингу и так может вдуплить что у него не так с конфигой, а во вторых, вы не сможете лично окарауливать вон тот редкий но мерзкий баг вылезающий раз в месяц и собссно все что вам сможет предоставить кастомер это как раз такие вот логи. Это максимум что как правило может дать энтерпрайзный кастомер. Большая часть таких кастомеров не даст вам копаться в их системах с дебагерами, что-либо менять там и прочая. Поэтому как правило при работе с энтерпрайзными кастомерами и их проблемами - вот такие вот портянки логов это чуть ли не единственное на что програмеры вообще могут надеяться. Сюрприз? :)
>Угу. Только в небольших приложениях, с участками отладки не более 1000 строк кода.
Напротив - грамотный и кондово сделанный логгинг, особенно с фильтровкой интересных событий от только некоторых подсистем (для уменьшения объема разгребаемых логов - очень круто если подсистема логгинга позволяет отстрелить заведомо ненужные подсистемы из вывода в логи) например может некисло помочь в отлове редких но мерзких багов, словив общую картину событий вызывающую проблему. После этого уже может стать понятно как оно воспоризводится и это можно на раз поймать уже у себя под микроскопом, изучить во всех позах и с помпой удавить. А если оно только у юзера и раз в месяц - да хрен вы это как-то еще удавите, по большому счету. Ну не будете же вы месяц у юзера дебажить лично, или где?!
>Что выше — пиши модульные и функциональные тесты.
Тесты - это замечательно, НО они не панацея. Баги после них все-равно высираются, особенно в энтерпрайзных поделиях как раз. Поэтому переоценивать их - не стоит. Это лишь один из аспектов, не более. Остальное придется все-равно ловить более-менее вербозным логгингом, как показывает практика. Вон на майкрософт посмотрите. Автоматизированными тестами облеплено все. Тем не менее, если уж даже сетап не доезжает до финиша или система виснет в первые полчаса колупания оной - видимо не всесильны тесты, а? :)
>Не нужно быть столь циничным к другим отраслям разработки ПО. Приложения пишутся
>не только для смартфонов.Как ни странно - у меня есть опыт тестирования достаточно разных сущностей. Включая немелкие энтерпрайзные системы, да (думаете за что я их так не люблю? Да как раз за то что там вечно багов как грязи, а те кто их писал - довольно деревянные, блин! :D).
>На закуску: http://samolisov.blogspot.com/2010/05/eclipse-36.html
Это к чему вообще? Лично я не сильно жалую монструозные IDE, по той же причине что и монструозную энтерпрайзятину.
>>На закуску: http://samolisov.blogspot.com/2010/05/eclipse-36.html
>
>Это к чему вообще? Лично я не сильно жалую монструозные IDE, по той же причине что и монструозную энтерпрайзятину.Это к тому, что Eclipse — самое сложное хорошо масштабируемое приложение, когда-либо написанное и выпущенное в свет. Оно сложнее даже самых накрученных энтерпрайз-поделий (на Eclipse RCP строятся многие из них). ;) Тем не менее, такая мощная среда подвергается отладке и тестированию в обозримые сроки благодаря _модульной_ архитектуре, придерживающейся спецификаций OSGi (реализация — Equinox).
Использование модульности и модульных тестов позволяет локализовать проблему в отдельном модуле. Грамотно расставленные ассерты (часть системы детального тестирования) улучшают защиту кода. Ассерты и тесты не попадают в конечный продукт по понятным причинам, да и отладочная информация вычищается перед приёмочными испытаниями. Или вы хотите, чтобы они там были вместе, чтобы пользователь любовался внезапно появившейся простынёй из закорючек? :)
>Это к тому, что Eclipse — самое сложное хорошо масштабируемое приложение,Вы уж простите, конечно, но с моей точки зрения - это всего лишь монструозный переросток с встроенными жопоподтиралками. Тормозной, ресурсожоркий и довольно глючный. Такая вот разница в классификациях, да. Готов поспорить что за сутки юзежа наверняка найду в нем минимум десять багов.
>когда-либо написанное и выпущенное в свет.
Подобного барахла - навалом. А масштабируемое... пардон, а оно без проблем распараллелится на 10 000 узлов по всему шарику? Увеличив скорость всех операций в 10 000 раз? Ну или какого буя оно самое масштабируемое? Что там масштабируется то, кроме невменяемой ресурсожоркости и монструозности? Нельзя ли пояснить? oO
>Оно сложнее даже самых накрученных энтерпрайз-поделий
Не факт, имхо. У энтерпрайзников иногда такое термоядерное говно попадается что я просто фигею что оно вообще как-то работать ухитряется.
>(на Eclipse RCP строятся многие из них).
Если честно - ни одного не видел. Хотя и что-то слышал о таких.
> в обозримые сроки благодаря _модульной_ архитектуре,
Модульность - это хорошо и правильно. Но...
>Использование модульности и модульных тестов позволяет локализовать проблему
>в отдельном модуле.... но ваш фэйл в том что вы с какого-то рожна возомнили что можно сделать юнит-тесты на все случаи жизни, предусматривающие все и вся. Практика показала что нихрена подобного, юнит тесты ловят только сильно некоторые типы багов и не более того. Ну да, какое-то количество багов они может и словят. А какое-то - непременно останется. Учтя размер кода этой хрени - багов там наверняка водятся зиллионы. Чем монструознее и сложнее код, тем больше там багов. Майкрософт вон тоже с тестами упирается. Но я бы заметил что им не больно то это помогает, по моим наблюдениям.
Как по мне - KISS принцип по-моему наиболее надежный вариант. Проще всего не создавать себе проблем чем пытаться их решить пуская пар. Посему хороший софт - это софт который сделан настолько просто как это только возможно для данного набора фич.
>Грамотно расставленные ассерты (часть системы детального тестирования)
>улучшают защиту кода. Ассерты и тесты не попадают в конечный продукт
>по понятным причинам,Да, поэтому мощные по последствиям баги высирающиеся раз в месяц и только в реальных условиях - отхватывают именно кастомеры. Которые этим адски недовольны, и что хуже, вычислить и обезвредить такое - не очень то простая задача. И, собственно, обычно кастомер как максимум готов предоставить логи и не более того. Кульно, правда? Ну не может кастомер на месяц отдать на растерзание свою боевую систему чтобы вы там покопались и вычислили бяку. Ему работать надо. Такая вот фигня, yeah?
> да и отладочная информация вычищается перед приёмочными испытаниями.
Приемочные испытания - это круто, но вот знаете ли, вы никогда не сможете смоделировать все возможные конфиги кастомеров и все их особенности и отличия. В результате обычно у кастомеров все-равно что-то ломается, сколько вы не пыжьтесь. Особенно если не дай боже у вас огроменный код (а в энтерпрайзном крапе так по жизни, пардон). Чем больше кода - тем больше с ним гемоороя. Вот это - железобетонный тренд. По моим наблюдениям - простой код даже оттестированный вручную едва ли пару раз - может оказаться куда лучшего качества чем мегамонстр облепленый автотестами от и до.
> Или вы хотите, чтобы они там были вместе, чтобы пользователь любовался внезапно
> появившейся простынёй из закорючек? :)Зачем простыню показывать по дефолту? Совсем опухли? Просто должна быть опция врубить вербозный лог. В файлик или там куда еще. Доступным юзеру методом. Далее юзер или сам вдуплит (в энтерпрайзных вещах с проблемами зачастую борятся вполне вменяемые админы которые понимают что такое "404" или "access denied" или что там еще и вполне могут починить какой-то грабль своей конфиги неэстетично обработанный гуйной частью программы и сами, подыграв проге немного). Или если не осилили - лог идет на изучение програмерам которые понимают по нему что не так и чинят. А какие еще варианты то есть? Только не надо идиотских допущений что в энтерпрайзном крапе не бывает проблем - с их монструозностью и рапидной техникой разработки это, извините, фантастика :)
Я>Это к тому, что Eclipse — самое сложное хорошо масштабируемое приложение,>Вы уж простите, конечно, но с моей точки зрения - это всего лишь монструозный переросток с встроенными жопоподтиралками.
На C++ стройную и лёгкую среду подобного функционала всё ещё пишут, но нам не показывают почему-то. Может это миф, и С++ — весьма монструозен и немасштабируем до таких вещей? Нет — на C++ написана 99% кода OpenOffice. Значит могут, если захотят. Но вот по уровню модульности OpenOffice далеко позади известных операционных сред — прямо-таки раздробленный монолит из нескольких частей (Writer, Calc, Draw и т.д.). Есть ещё IBM Lotus Symphony... но это некстати (Eclipse RCP, чо). :))
>Тормозной, ресурсожоркий и довольно глючный.
Какую версию смотрели? eclipse.ini правили на предмет захвата JVM оптимального количества памяти?
>Готов поспорить что за сутки юзежа наверняка найду в нем минимум десять багов.
Баги обычно локализуются в бандлах (модулях), на общую устойчивость среды это не влияет.
>Я>Это к тому, что Eclipse — самое сложное хорошо масштабируемое приложение,Что значит - масштабируемое? А так знаете, апач вон например масштабируемый. Если ему дать сферическую машину в вакууме - с бесконечным числом процессоров и бесконечным количеством оперативы - он с его форками будет работать там идеально, юзая все ресурсы по делу и прекрасно смасштабируется. А вот на реальных машинах почему-то машины состояний типа нжинксы почему-то ведут себя куда лучше. Наверное потому что по процессору на юзера - явно перебор.
>>переросток с встроенными жопоподтиралками.
>На C++ стройную и лёгкую среду подобного функционала всё ещё пишут,Да вот знаете, глядя на майкрософт и их продукты понимаешь что все хорошо в меру. И функционал - тоже! Начиная с некоторой точки получается см. выше что. И сколько его не дебажь, не профайли и прочая - а будет монструозное, тормозное и глючное УГ.
>монструозен и немасштабируем до таких вещей?
Как про такое говорится - дело было не в бобине... ;)
>Нет — на C++ написана 99% кода OpenOffice. Значит могут, если захотят.
Но, заметьте, он тоже "монструозное, тормозное и глючное УГ". Просто потому что ни на сях++, ни на яве, ни на [тут ваш любимый язык] вы не сможете идеально отладить до безглючности такое монстрило за обозримое время.
>Но вот по уровню модульности OpenOffice далеко позади известных операционных сред —
>прямо-таки раздробленный монолитДля тормозов намекаю: монолитность или модульность от языка как бы не сильно зависит. Скорее зависит от тех кто ришения о дизайне принимал. Вот и спросите у саней - какого хрена они все это нагородили. Сани круто выглядят снаружи, но если посмотреть в кишки - они городят как умели (типично для корпорасов, кстати).
>Lotus Symphony... но это некстати (Eclipse RCP, чо). :))
Спасибо что напомнили, Кэп! Проблема только в том что этот лотус отлично попадает под описание "монструозное, тормозное и глючное УГ". Лучше любого опенофиса. Поэтому очень даже кстати. Как видите и на яве можно сделать УГ. Круто, а? :)
>Какую версию смотрели? eclipse.ini правили на предмет захвата JVM оптимального
>количества памяти?Ну вы сами на свою жопу упомянули лотус, а? Вот я его видел. Так уж получилось. Он - натуральное монструозное и тормозное УГ. Глючное, да - или вываливается нафиг или икает эксепшнами при удобном случае, только шаг в сторону - и готово. И тормозит ощутимо. Даже на довольно мощных машинах. Эталоном качественного софта я бы это не назвал. Еще есть кульные ява-сетаперы от айбиэм. Это вообше пи...ц! Потому что в некоторых версиях продуктов IBM оно вообще неработоспособно было oO.
>>Готов поспорить что за сутки юзежа наверняка найду в нем минимум десять багов.
>Баги обычно локализуются в бандлах (модулях), на общую устойчивость среды это не
>влияет.Баги влияют на общую устойчивость пользователя, мля. Работать в тормозном глюкалове - удовольствие сильно ниже среднего, мягко говоря.
>>Какую версию смотрели? eclipse.ini правили на предмет захвата JVM оптимального
>>количества памяти?
>
>Ну вы сами на свою жопу упомянули лотус, а? Вот я его
>видел. Так уж получилось. Он - натуральное монструозное и тормозное УГ.
>Глючное, да - или вываливается нафиг или икает эксепшнами при удобном
>случае, только шаг в сторону - и готово. И тормозит ощутимо.
>Даже на довольно мощных машинах. Эталоном качественного софта я бы это
>не назвал. Еще есть кульные ява-сетаперы от айбиэм. Это вообше пи...ц!Вы действительно видели Symphony?
Оно действительно запускалось в той среде/окружении, для которой рекомендовалось (объём оперативки, версия операционной системы и т.д.)? А то я, скажем, пробовал запускать Eclipse, собранную для Linux скачанную с официального сайта в блобах, на FreeBSD — не запускалось, хоть линуксулатор был включен. Настолько эта среда пропитана линуксизмами внутри нативных либ, что без пересборки из сорцов (привет GCC!) её не удастся даже запустить.
>Ты хоть раз отлаживал что-нибудь на С++?Да, отлаживал. Хоть того же aMule с редкими крешами или странностями поведения при нестандартных выходках сильно некоторых редких ремотных пиров (нормальная такая бага, а?)
Ну и что, нравится оно или нет? Может стоит поставить под сомнение фактор, который вы все тут считаете незыблемым(С++ и С) а подумать каждый раз когда это вызывается кривостью языка. Например такая невинная вещь, как забыть написать return в конце функции(на что gcc не выдаст ошибки а только варнинг) может привести к куче головной боли.
>Ну и что, нравится оно или нет? Может стоит поставить под сомнение
>фактор, который вы все тут считаете незыблемым(С++ и С) а подумать
>каждый раз когда это вызывается кривостью языка. Например такая невинная вещь,
>как забыть написать return в конце функции(на что gcc не выдаст
>ошибки а только варнинг) может привести к куче головной боли.Это как раз не самая большая проблема крестов. Как сказал один из авторов FreePascal в ответ на просьбу внести сахар в синтаксис, "Мы программисты, мы не забываем". Предупреждения компилера можно и почитать, это слишком очевидная ошибка. Больше Неудобств же причиняют старые наследованные формализмы и негибкие места языка, а также обилие вещей, про которые нужно всегда помнить и держат в голове. Потому и считается, что на то, чтобы стать опытным кодером на C++ нужно потратить годы.
Может показаться, что в этом комментарии я противоречу сам себе, но это не так :)
Просто существует адекватная граница допустимого.
>Ну и что, нравится оно или нет?Да нормально вроде все. Ну, помедитировал в gdb, он вполне доходчиво выдал место где случается креш а логи показали что примерно в этот момент происходило.
>как забыть написать return в конце функции(на что gcc не выдаст
>ошибки а только варнинг) может привести к куче головной боли.Раздолбайство при программировании вообще почему-то приводит к головной боли. Так, всего лишь наблюдение :).А варнинги в gcc легко делаются error-ами и культурные програмеры не гнушаются -Werror воткнуть и проверить что оно вот так вот компилится. Хотя-бы в окончательной версии.
>>Ну, помедитировал в gdb, он вполне доходчиво выдал место где случается креш а логи показали что примерно в этот момент происходило.достаточно компилить программу с отладочной инфой для gdb и писать свою отладку не придётся
иначе юзайте трейсеры и увидите где что происходило
>достаточно компилить программу с отладочной инфой для gdb и писать свою отладку
>не придётсяЛоги это не то чтобы отладка, это такое неизвазивное логгирование хода выполнения в удобном виде. Если програмер правильно понимает ключевые места и выдает в лог достаточно инфо - все очень упрощается. Особенно отладка общей логики поведения программы например.
Хотите прикольный, модный и современный пример? Попробуйте допустим логику публикации записи в DHT сеть дебагером отладить до состояния логической корректности, когда ваша прога начинает играть в ту же игру что и еще миллион пиров правильно. При том если вы стормозите на брякпойнте - остальными нодами будет посчитано что вы умерли и отвалились. Реальное время - не ждет. И на вид может выглядеть что прога работает. Не крашится. Но какие гарантии что она работает правильно? Правильно - а НИКАКИХ! Узнать о том что публикация удачна вы можете в общем случае только когда на вас долбанутся в поиске опубликованного. Вбахать дебагеру правильные точки останова не только сложно, но и чревато, ибо после неуспешной долбежки пока вы там на брякпойнте клевали - вас посчитают трупиком и забьют на вас. С удовольствием посмотрел бы как вы бы отлаживали общую корректность логики вот чего-то такого одним дебагером и через сколько вы бы позеленели нафиг :)
>>Если програмер правильно понимает ключевые места и выдает в лог достаточно инфо - все очень упрощается.знаете коментарии в коде тоже многое упрощают
>>При том если вы стормозите на брякпойнте - остальными нодами будет посчитано что вы умерли и отвалились. Реальное время - не ждет. И на вид может выглядеть что прога работает. Не крашится. Но какие гарантии что она работает правильно? Правильно - а НИКАКИХ!
в тестовом режиме это вполне нормально
если до места брейкпоинта всё идет нормально (соответсвенно логически) то значить никакиз проблем нет.>>Вбахать дебагеру правильные точки останова не только сложно, но и чревато, ибо после неуспешной долбежки пока вы там на брякпойнте клевали - вас посчитают трупиком и забьют на вас.
для начала прочтите
http://mitya.pp.ru/gdb/gdb_6.html#SEC28и какой смысл ставить к примеру точку останова там где происходит подключение ????
>>вас посчитают трупиком и забьют на вас.
)))) для этого существуют эмуляционные тесты
как по вашему отлаживают программы андронного коллайдера ????
в реалтайме на рабочей системе ????>>С удовольствием посмотрел бы как вы бы отлаживали общую корректность логики вот чего-то такого одним дебагером и через сколько вы бы позеленели нафиг :)
вас точно к проэктированию андронного коллайдера даже близко не допустили бы
пс: как повашему происходит отладка ядра линукса ???? када там миллион строк и нужна протестить отдельный функционал что вы тогда делать будете ???? запускать всё с нуля и потом копаться в гигабайтовом логе ????
>знаете коментарии в коде тоже многое упрощаютДа, но в конечном итоге - вероятность того что юзер пришлет вербозный лог в 100500 раз выше чем то что вы сможете убедить его взять в лапы дебагер и что он осилит найти проблемное место и прислать инфо вам. Более того - часть проблем в общем то проблемы на стороне юзера (особенно в реалистичных сложных конфигах) и по вербозным логам - юзер (особенно если это админ) вполне сможет понять в чем проблема его конфигурации, не имея програмерам мозг лишний раз.
>Но какие гарантии что она работает правильно? Правильно - а НИКАКИХ!
>в тестовом режиме это вполне нормально если до места брейкпоинта всё
>идет нормально (соответсвенно логически) то значить никакиз проблем нет.Сразу видно - сложные клиент-серверные или P2P приложения вы видимо не отлаживали вообще или делали это настолько ужасно и без понимания общей логики процесса, что я бы побоялся юзать ваши программы. Для тех кто в танке - намекаю: многие программы оперируют в реальном времени, взаимодействуя с другими системами. И притормаживание их брякпойнтом, пардон, может изменить всю картину. Вплоть до того что баг может совсем перестать вылезать, например, или вообще последовательность событий изменится. Логи с другой стороны всем похрену: они не вламываются в общую логику хода выполнения (хотя мне известны даже случаи когда включение логгинга срывало вылезание бага, чуть времянки изменились - и какойнить подленький и гнусный race condition вылезать уже перестал, но никуда ессно не пропал и будет при случае доканывать юзерье, которое придет по вашу душу, разумеется).
>для начала прочтите http://mitya.pp.ru/gdb/gdb_6.html#SEC28
Что сказать то хотели?
>и какой смысл ставить к примеру точку останова там где происходит подключение ????
Сникерс съешьте. А то тормозите. В упомянутом примере (DHT) - процедура подключения достаточно условна. Публикуется присутсвие себя любимого, а потом В РЕАЛЬНОМ ВРМЕНИ обрабатываются запросы от заинтересованных нодов. Публикация периодически повторяется. Если вы за считанные секунды не ответили на пинги, которые приходят когда угодно (от вас это не зависит никак), протокольная логика у остальных - резонно подумает что вы труп или перегружены траффиком и на вас надо попросту забить. В итоге воткнуть брякпойнт вообще проблематично: общая картина сильно поменяется. И свою тестовую конфигу собрать - проблема: поднимать миллион узлов крайне геморно а на десятке узлов поведение будет уже не то (обычно такое отлаживают итеративно по мере вычисления проблем и узких мест). Да и клиент-сервер... знаете, большая часть серверов написанных вменяемо - проверяет живость клиента, пингуя его. Приконектились? Попали в брякпойнт? Не ответили за эн секунд? Значит бобик сдох, пщел вон с сервера! Те кто эту логику не применяет - имеют висящие ЧАСАМИ мертвые конекции и отхватывают много интересных но неприятных сюрпризов, пардон.
- идет реалтаймная "игра" между кучей систем по определенным правилам игры. Правила игры
>)))) для этого существуют эмуляционные тесты
С удовольствием посмотрю как вы сэмулируете хотя-бы миллион нодов в DHT сети. А то десяток нодов - неинтересно. Даже если ваш алгоритм живет при десяти нодах - как бы не факт что он не подохнет при более реалистичном миллионе или десяти миллионах. Тем более что эмулировать реальных клиентов с их глюками и багами а также фруктов атакующих структуру - вы умрете нафиг. Обычно такие штуки отлаживают на реальной работающей сети.
>в реалтайме на рабочей системе ????
Коллайдер - один. И ученым так и быть под него выделят время на какомнить roadrunner. А вам его выделят?И баблосов то хватит на эмуляцию сетки с миллионом нодов? Ну как бы дерзайте, да :)
>вас точно к проэктированию андронного коллайдера даже близко не допустили бы
Коллайдеры - товар штучный. Под коллайдер и доступ к суперкомпьютерам дадут, да еще и не за ваш счет. А вот для написания просто проги - никто не даст вам такие ресурсы, как бы.
>запускать всё с нуля и потом копаться в гигабайтовом логе ????
Как происходит, как происходит...
Про EXT4 скажу. Создается томик с оным и насилуется во всех позах. Анализируется успешность операций. Читаются логи системы. Да, часть ляпов была поймана по именно логам, прикиньте? Кстати говоря, всякие там оопсы - тоже вид вербозных логов если что.
>> В любом случае сложившая ситуация в индустрии ПО не отменяет факта, что С++ как язык >>программирования УГ.На протяжении многих лет не перестаю поражаться, как люди выдают свою врожденную криворукость и лень за некие мифические недостатки языка. Если оно для вас сложно осилить, читайте Страуструпа, или Элджера, или пишите на пэхэпэ, но зачем показывать свою некомпетентность?...
То ты кроме двух крайностей - C++ и php ничего не знаешь? Тяжелый случай. И что рекомендовать Страуструпа - это просто Reference языка. Александреску к примеру описывает техники, которые позволяют делать очень хитрые вещи и выжать максимум из плюсов. Но тем не менее александреску сейчас ушел на D. А это один из экспертов по С++. Делайте выводы сами.
тонкий пЭЙАр языка D?развели тролизм
тему почикать до внятных комментарий по сути
а тем кому нравиться другие языки отличные от C++, идите на сайт языка D и там пиарте его дальшетоже мне умники нашлись
Балбес ты, народ же начал заявлять о безальтернативности и спрашивать о других языках. Изначально я только сказал что С++ УГ. Это по теме.
УГ это ваш D
а александреску это еще не показатель
вон торвальдс виндовс 7 рекламирует и что? это показатель того что линукс УГ?
>а александреску это еще не показательНу, Александреску, пожалуй, показатель... Умный дядька, я полтора года пытался разобраться в его книге ( ИМХО, писать он, всеж, не умеет! ), но теперь из его наработок, кое-что на практике использую. Удобно очень. Особенно обобщенные функторы понравились, как наш ответ Чамб^W C#, с его (чего греха таить) весьма удобными делегатами. Использование обобщенных функторов не менее удобно и настолько же просто.
Т.ч. не стоит катить бочку на Александреску.
вы александреску о ява раскажите, а то он со своими шаблонами крышей поехал
поэтому и убежал на D
мучался дядка мучался
с таким успехом как он ваял шаблоны, он мог просто уйти на какой то скриптовый язык
>вы александреску о ява раскажите, а то он со своими шаблонами крышей
>поехал
>поэтому и убежал на D
>мучался дядка мучался
>с таким успехом как он ваял шаблоны, он мог просто уйти на
>какой то скриптовый языкПо факту, промышленная разработка именно к работе с шаблонами сводится.
>По факту, промышленная разработка именно к работе с шаблонами сводится.сильно надуманые факты
шаблоны конечно вещь полезная
но не надо ею увлекаться как это зделал александерску
результат - он убежал на D
Логика на гране фантастики. Не надо увлекаться как "зделал" Александреску только потому чтобы не уйти с С++. Шаблоны отличная техника позволяющая генерировать код на стадии компиляции при этом не повторяя себя и не теряя в производительности. Метапрограммирование рулит.
результат вашего метапрограммирование - STL, как пример унылого Г
>
>По факту, промышленная разработка именно к работе с шаблонами сводится.Под "шаблонами" в вашей промышленности понимаются паттерны или та херь с типизацией, на которую в институтах студенты оргазмируют, в сотый раз прочтя за первый месяц информатики что "ведь с++ - это улучшенный с"?
То, что безмозглые переводчики называют Паттернами.
Ну вот, а теперь логический шаг после этого попробовать D. Похожая парадигма, но это будет как глоток свежего воздуха. И сразу увидишь что многие вещи которые невозможны в С++ или делались через Ж, станут получатся легко и свободно.
у меня наверное какой то не такой С++
потому что у меня на нём всё что мне нужно - получаеться, причем свободноруководствуюсь правилом, если гора не идёт к магомеду, то нафиг ту гору - тогда и в С++ легко дышеться
Я на работе пишу на С++ и у меня тоже все получается. Мысли шире. Если можешь.
я сужу по языку на основе уже выходных данных, как бы exe,elf файлах в дизасме
если мне сформированый код не нравиться, значит язык я не используюC++ уже хорошенько вылизали в этом плане и мне asm сформированый код нравиться
в D - не нравиться, может как язык, D и не плох
но еще не вылизанв этом плане мне также не нравится и Делфи
>я сужу по языку на основе уже выходных данных, как бы exe,elf
>файлах в дизасме если мне сформированый код не нравиться, значит язык я не используюГлупейший критерий суждения лучшести/худшести языка.
>C++ уже хорошенько вылизали в этом плане и мне asm сформированый код
>нравиться в D - не нравиться, может как язык, D и не плохС++ — тормозное убожество. Компилятор очень долго склеивает простыни исходников (инкрементная компиляция опасна) и долго их компилит — разница во времени по сравнению с компиляцией javac (который написан на Java) такого же объёма исходного кода на Java — десятки раз!
>но еще не вылизан в этом плане мне также не нравится и Делфи
Компилятор среды Delphi 3.0 в 1997 году был однопроходным и отрабатывал, по опубликованным в прессе тестам, со скоростью ~300 тысяч строк исходнодного кода в минуту. Вот почему в нашей стране была так популярна эта среда, а не похожий на неё как две капли воды, но сверхтормозной и ресурсожручий Borland C++ Builder.
зен - иди на яву и там ори
о твоей яве уже сто раз по разу рассказали и особенно User2**
что когда на ней можно будет писать драйвера для Операционок, тогда и будешь ее втюривать
а пока что твоя ява стоит в сторонке и посмактывает
и
твоя ява компилит код для процессоров а не для виртуальной машины? а? - нет
итд
>зен - иди на яву и там ори
>о твоей яве уже сто раз по разу рассказали и особенно User2**Он нихрена не смыслит в Яве.
>что когда на ней можно будет писать драйвера для Операционок, тогда и
>будешь ее втюриватьВ Sun уже написали в 2007 году драйвер на Java, который работал совместно с микроядерной JVM.
>а пока что твоя ява стоит в сторонке и посмактывает
4.2
Java на серверах Google генерирует тебе странички (see GWT).>и твоя ява компилит код для процессоров а не для виртуальной машины? а?
JIT компилит код для реального процессора, учитывая особенности архитектуры, размер кэша.
>- нет итд
4.2
его ответ тебе был насчет ява и ембедед
ему как и мне и многим другим положить на явусан? один какойто драйвер?
а под твою любимую фряху уже можно на яве писать драйвера?
а под виндовс уже тоже можно на яве писать драйвера?
тотожену и что что она генерирует страничке в гугле?
ты спрашивал у умельцев гугла почему они и многие другие выбирают ява для www а не с++?ну раз твой джит такой умны
Вы на D все же поглядите, занятная штука. Тем более, что почти ничего из доступного в плюсах не отобрано (есть указатели, можно не использовать gc, есть стековые объекты и т.д.) - а вот новых фишек много, и интересных."Почти" - потому что довольно прилично ограничена перегрузка операторов. В частности, присваивание для классов не перегрузишь.
> ... (есть указатели, можно не использовать gc, есть стековые объекты и т.д.) ...Вот это уже интереснее. Время будет можно и глянуть, интереса ради.
> В частности, присваивание для классов не перегрузишь.
А в двух слова, чем _это_ вызвано не скажите? Я понимаю, за что ругали указатели или, например, множественное наследование, а чем был вызван такой шаг? Мешало работе gc? Хотя, это на врятли...
Потому что в D *правильное* разделение между классами и структурами. Классы - полностью объекты по ссылке, как в C# или Java. Поэтому при присваивании происходит присваивание ссылки(то же самое что и указатель). Структуры же имеют такую же семантику как и в С++, то есть объекты по значению, для них соответственно operator= работает и имеет смысл. Но для структур не работает наследование(зато есть другие плюшки как alias this из D2), так как мы хотим избежать проблем с полиморфизмом для объектов по значению. В результате приходим к такой же схеме какую избрали в Qt. Есть классы, которыми пользоваться можно только по указателю - QObject и иерархия наследников, но у них запрещены конструктор копирования и operator=, и есть классы по значению, которые чаще всего не имеют наследников и передаются по значению, и имеют implicit sharing. Это умный дизайн, и грамотные люди давно советуют при программировании на С++ разделять полиморфные классы от тех, которые используются по значению. В D этот дизайн по умолчанию.
>То ты кроме двух крайностей - C++ и php ничего не знаешь?
>Тяжелый случай. И что рекомендовать Страуструпа - это просто Reference языка.
>Александреску к примеру описывает техники, которые позволяют делать очень хитрые вещи
>и выжать максимум из плюсов. Но тем не менее александреску сейчас
>ушел на D. А это один из экспертов по С++. Делайте
>выводы сами.создатель языка это ещё не означает супер пупер проггер
Создатель языка как раз и является "супер пупер проггером", так как он мыслит шире, знает разные парадигмы, видит узкие места в существующих ЯП и в неудовлетворенности ими создает новый. Если бы все были как комментирующие в этом посте, то мир так бы и остановился в развитии и ПО писалось бы только на С/C++.Ну и александреску никогда создателем языка не был.
)))) супер пупер эт означить самый умный ???
а будет Страуструп знать что я буду писать через 10 лет ????
Насчет мифических недостатков, ты хочешь чтобы я начал перечислять?
Надоело спорить. Местное население упертое и консервативное до невозможности и считает программирование на С/C++ неким джедайство, непонимая что при правильной стратегии использования программ с тем же самым сборщиком мусора можно добиться большей производительности чем с ручным управлением памяти. Пока все остальные пробуют разные интересные вещи типа VM, и других языков программирования здешние будут сидеть на православных сях до конца дней своих. Скучно.
Вот много раз слышал это утверждение. Ну хоть раз приведите пример из жизни, как нечто было переписано с полноценного нативного языка на какую-либо vm-реализацию (или обзавелось gc) и улучшило результаты по производительности.
Приведу конкретный пример из своей практики, не про целое приложение. Была задача, загрузить текстовый файл простейшего вида:
3.3 5.7 2.7
12.7 5.8 36.7
...Три числа в строке. Поскольку использую Qt, естественно применяю кьютишные средства. QTextStream в цикле каждую итерацию отдает мне строку из файла в виде QString.
QString line = stream.getLine(); // или как-то так
QStringList strings = lexWhitespace(line); // парсит строку и возвращает строки с содержимым, к примеру для первой строки "3.3" "5.7" "2.7"
QVector<float> vals;
foreach(QString string; strings)
vals << string.toFloat();Вот типичный С++ код. Однако он оооочень неэффективный(парился по поводу оптимизаций так как файлы были очень большие). Функция lexWhitespace() возвращает QStringList с тремя элементам QString. Строка для каждого из них была выделена на куче. 3 лишних аллокации!!!
Если же использовать сборщик мусора, то можно их избежать так как строки были бы всего лишь *настоящими* подстроками оригинальной строки line. Например в D строка представляет собой структуру содержащую указатель и длину. Таким образом программа со сборщиком мусора работала бы намного быстрее.
Я пытался оптимизировать с использованием QStringRef - но они не содержат и десятой части всех полезных функций, которые есть в QString, в том числе требовавшаяся мне toFloat(). Естественно можно вызвать QString QStringRef::toString() - но это выльется в ту же самую аллокацию, которую я хочу избежать.
Вывод - надо думать мозгами, а не полагаться на "догмы", как "ручное управление памятью всегда быстрее".
а кто вам сказал что в QT все прооптимизировано?QT создали для рисования хрюшечек, а те кто занимается оптимизацией по памяти коду и прочему, пишут свои Lite библиотеки и молча используют
или вы хотите скзать что перейдя на D, вы переписали свою версию QT где все стало профит?
по теме
STL был есть и будет, и лицензия у него лояльнаяа libstd++ лиш одна разновидность применима для GCC
зачем было еще одну изобретать когда проще STL утановить
STL - это спецификация. Куда вы ее установите? libc++, libstdc++, STLport - примеры реализаций STL.
>STL - это спецификация. Куда вы ее установите? libc++, libstdc++, STLport -
>примеры реализаций STL.STL он и в африке STL
go to http://www.sgi.com/tech/stl/а то что вы перечислили, взбучки отдельных проектов
Только этот STL не удовлетворяет стандартам C++, потому что был написан до них. А так да, практически никаких проблем.
>Только этот STL не удовлетворяет стандартам C++, потому что был написан до
>них. А так да, практически никаких проблем.ОМГ!)))
а каким стандартам он тогда удолетворяет?
> go to http://www.sgi.com/tech/stl/Всего лишь пример еще одной реализации STL.
Далеко не самой лучшей, кстати.
ждём в дебиане и убунте.
Да не надо ждать, скомпилировать из исходников llvm совсем не сложно, думаю тоже самое относится и к clang/libstd++
подскажите есть ли сейчас язык+компилятор+оптимизатор-линкер такого вида:
1) язык с возможностью указать в какой части программы какие оптимизации (какого рода/типа - алгоритмов, расположения данных, параллелизация и пр) необходимы, допустимы, недопустимы
2) компилятор переводящий программу в некий "байткод"-формат с оптимизацией алгоритмической части (например если в функции указана оптимизация по скорости и указано плевать на память то расчёт необходимой всей функции памяти и выделение её в самом начале) (с сохранением остальных указаний оптимизатору) (хочется единый "байткод"-формат для разных языков программирования)
3) сам оптимизатор+линкер (независимый от компилятора) - делающий из "байткода" исполняемый код с учётом возможностей оптимизации под конкретную платформу (например что в 64 бита влезет 2 32битовых инта за 1 проход цикла) (и указаний программиста в самой программе)
>подскажите есть ли сейчас язык+компилятор+оптимизатор-линкер такого вида:
>1) язык с возможностью указать в какой части программы какие оптимизации (какого
>рода/типа - алгоритмов, расположения данных, параллелизация и пр) необходимы, допустимы, недопустимыJava.
>2) компилятор переводящий программу в некий "байткод"-формат с оптимизацией алгоритмической части (например
>если в функции указана оптимизация по скорости и указано плевать на
>память то расчёт необходимой всей функции памяти и выделение её в
>самом начале) (с сохранением остальных указаний оптимизатору) (хочется единый "байткод"-формат для
>разных языков программирования)javac.
>3) сам оптимизатор+линкер (независимый от компилятора) - делающий из "байткода" исполняемый код
>с учётом возможностей оптимизации под конкретную платформу (например что в 64
>бита влезет 2 32битовых инта за 1 проход цикла) (и указаний
>программиста в самой программе)Java HotSpot.
>>подскажите есть ли сейчас язык+компилятор+оптимизатор-линкер такого вида:
>>1) язык с возможностью указать в какой части программы какие оптимизации (какого
>>рода/типа - алгоритмов, расположения данных, параллелизация и пр) необходимы, допустимы, недопустимы
>
>Java.как для Java выглядит 1 пункт в коде ?
>>>подскажите есть ли сейчас язык+компилятор+оптимизатор-линкер такого вида:
>>>1) язык с возможностью указать в какой части программы какие оптимизации (какого
>>>рода/типа - алгоритмов, расположения данных, параллелизация и пр) необходимы, допустимы, недопустимы
>>
>>Java.
>
>как для Java выглядит 1 пункт в коде ?Читайте: http://java.sun.com/docs/books/jls/second_edition/html/expre...