форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[ Отслеживать ]

"OpenNews: Интервью с Бьерном Страуструпом, с вопросами о буд..."

Сообщение от opennews (ok) on 23-Авг-08, 01:09

"Interview Update With Bjarne Stroustrup On C++ (http://www.devx.com/SpecialReports/Article/38813/0/page/1)"    - интервью с Бьерном Страуструпом, с вопросами о будущем стандарте C++ (C++0x), принятие которого ожидается в 2009 году. URL: http://www.devx.com/SpecialReports/Article/38813/0/page/1 Новость: http://www.opennet.dev/opennews/art.shtml?num=17517

Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

6. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."

Сообщение от Светочка on 23-Авг-08, 01:56

Мое предложение по C++: усилить типобезопасность языка (вплоть до того, чтобы убрать неявное преобразование unsigned int -> signed int), при этом ввести директиву наподобие typesafety <strong, weak, very strong>, для совместимости со старым кодом при отсутствии такой директивы будет предполагаться, что используются старые правила преобразования типов. Однако может возникнуть проблема, если такая директива появиться в заголовочном файле, который будет подключен к старому коду, т. к. компилятор может компилировать в режиме с усиленной типобезопасностью, после получения директивы из заголовка, старый код. Также можно отказаться от использования заголовочных файлов (сделать так, как в java).

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	7. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от Александр Чуранов on 23-Авг-08, 02:59
	1) "Усилить типобезопасность языка" Куда уж дальше усилять-то? Сначала язык изучите, причём на уровне boost::mpl, а потом смело вносите предложения. Дело в том, что при использовании современного C++ проблема "неявное преобразование unsigned int -> signed int" НИКОГДА не возникает. Светочка, Вы даже не представляете, насколько это незначительная проблема. Поэтому-то ей никто всерьёз и не занимается. Для того, чтобы Вы могли понять это прямо сейчас, могу привести один из возможных способов решения проблемы неявного преобразования. Создаётся класс template <   typename Underlying,   typename OverflowUnderflowStrategy,   typename CStyleCastStrategy> class safer_int; И стратегии для него: // OverflowUnderflowStrategy class DoNothing; class Throw; class Abort; // CStyleCastStrategy class AllowCast; class DisallowCast; Теперь safer_int является кодогенератором, который может дать как полностью защищённые от неявных преобразований (а также переполнения и недополнения) типы, так и полностью незащищённые (как встроенный int), а также другие. Далее, в программе выбираем нужное поведение: typedef safer_int <long, Throw, DisallowCast>::type my_int; и используем выбранный тип в коде: my_int sqrt(my_int x); Теперь достаточно поместить typedef в заголовочный файл и можно за секунду весь проект перевести с быстрых целочисленных типов на безопасные. Или наоборот. В общем, одного человекодня вполне хватит. 2) "Также можно отказаться от использования заголовочных файлов" Да, и наложить новые ограничения на трансляторы, заставляя производителей либо реализовывать дорогие решения, либо строить всех в ряд, как в Java. Дело в том, что заголовочные файлы по сути нужны лишь для одной цели - уменьшить проблемы с нарушением ODR. И если их грамотно использовать, то такие вопросы, как у Вас даже возникать не будут. Это тоже малозначительная проблема. 3) Вообще советую всем сначала прочесть любую книгу уровня "Modern C++ Design" Андрея Александреску, а также все книги, что понадобятся, чтобы это понять. А потом можно и дискуссии разводить. Только вопросы будут совсем другими... Ссылки: http://en.wikipedia.org/wiki/Header_file http://www.boost.org/ http://en.wikipedia.org/wiki/Modern_C%2B%2B_Design
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	17. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от Света on 23-Авг-08, 17:06
	>[оверквотинг удален] > >Для того, чтобы Вы могли понять это прямо сейчас, могу привести один >из возможных способов решения проблемы неявного преобразования. Создаётся класс > >template < >  typename Underlying, >  typename OverflowUnderflowStrategy, >  typename CStyleCastStrategy> >class safer_int; >... Только много строк кода получается. Так что встроенная поддержка усиленной типобезопасности не помешает.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	18. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от Александр Чуранов on 23-Авг-08, 18:01
	>Только много строк кода получается. Так что встроенная поддержка усиленной типобезопасности не помешает. 1) Это сломает совместимость с С на уровне исходников. А это боле чем важно, поскольку многие проекты используют и С и С++. 2) Критерий "много строк" - вот что является показателем серьёзности проекта. Для большого проекта это ничего не стоит: файлом больше - файлом меньше, а использовать можно потом десятилетиями. Вы же не обсуждаете, сколько строк кода в std::deque или std::locale. Кстати, если посмотреть исходник Mozilla Firefox - то там для решения аналогичных проблем используется куча самописных классов подобного рода. Только их решения не настолько универсальны. Вот стандартизовать такую библиотеку - это действительно полезно. Только к c++09 я уже не успел с предложением. Попробую предложить в следующий TR.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от Аноним (??) on 23-Авг-08, 03:37
	>Также можно отказаться от использования заголовочных файлов (сделать так, как в java) зачем C++ приводить к java? он C++ и как по мне для класса программирования задач которые пишуться на многих платформах исключая мобаил C++ самый лучший а вот ява уже для мобаил вообще для плохого программста любой язык плох потому как нет способностей освоить его и начинают изобретать что то новое создавая армию ненужных клоно-ботов
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от Александр Чуранов on 23-Авг-08, 03:49
	>исключая мобаил Точнее, включая. :-) C++ - отличный выбор для устройств с маломощными процессорами и небольшим количеством памяти. Да, я понимаю, что в свою Nokia я могу загружать только программы для JVM. И это сделано из соображений безопасности. Не удивлюсь, однако, если узнаю, что само ПО телефона и сама JVM написаны на C++.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от User294 (??) on 23-Авг-08, 04:21
	>C++ - отличный выбор для устройств с маломощными процессорами и небольшим количеством >памяти. Ну, вообще, там си порой в большем почете.Особенно на реально маломощных процессорах с мизерной памятью где вся система собрана в 1 кристалле.Для более мощных где RAM и флеша побольше - и C++ вполне по зубам. >Да, я понимаю, что в свою Nokia я могу загружать >только программы для JVM. И это сделано из соображений безопасности. Надо было покупать смартфон, а не тупую звонилку - симбиан на С++ в аккурат :D.Хотя сама система убогая - что-то типа "если бы MS-DOS переписали на сях++".Но программы именно нативные - шустрые, компактные, etc. > И это сделано из соображений безопасности. Ну вы просто не видели как хаксоры через эту "безопасную" машинный код выполняют на телефонах.На сименсах это например такой народный метод патчинга начального загрузчика (!!!) с целью сбить ограничения и позволить прошивать все что угодно.А вы говорите, безопасноть :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от Александр Чуранов on 23-Авг-08, 04:34
	>Для более мощных где RAM и флеша побольше - и C++ вполне по зубам. Здесь скорее не в мощности дело, а в привычках производителя. Приложения на С++ не более требовательны к ресурсам ЭВМ, а также потребляют не больше памяти и исполняются не медленнее программ на С. Если указанное выше не соблюдается, то либо программы не одинаковы, либо компилятор плох. К сожалению, gcc не лучший. Знаю организацию, где продукт с С++ на С перевели, а толком теперь объяснить не могут, зачем. Достоверно известны две вещи, что в этой организации не знают С++ толком и что gcc компилирует C++ код медленней чисто сишного. На вопрос "А почему hello-world на С++ компилируется в бинарник большего размера, чем аналогичная программа на С" Бъярн Страуструп ответил "а на моей платформе - в меньшего" :-) >Ну вы просто не видели как хаксоры Охотно верю, что взламывают. Думаю, что JVM выбирают в качестве "интерфейса" для телефонов, всё-таки чтобы доступ ограничить.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	22. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от User294 (ok) on 25-Авг-08, 09:26
	>Здесь скорее не в мощности дело, а в привычках производителя. Приложения на >С++ не более требовательны к ресурсам ЭВМ, а также потребляют не >больше памяти и исполняются не медленнее программ на С. Я охотно посмотрю как вы STL и прочая запихнете в чип с 16 кил флеша и 1 килом оперативы и как на все это памяти кода и данных хватит.И что там на полезные действия останется.Нет, я действительно очень хотел бы посмотреть как это будет выглядеть;).А на сях программят и такие чипы.И даже чипы с всего парой кил для кода, если изгальнуться, и то можно программить - выбросить лишний стартап, минималистичные библиотеки и усе, телемаркет.ЭВМ нынче бывают разные.В частности однокристальные а это бывает и восьмилапым тараканом с мизером памяти на борту.Си катит даже для програминга таких.А то тараканы бывают разномасштабные и скажем, 16 и более кило кода на асме колупать уже грустновато выходит.Не портабельно и башню програмеру срывает.В итоге C бывает разный.Например, AVR-GCC, и GCC для MSP430.Вполне себе хорошие и замечательные порты GCC под эти архитектуры.А вот C++ для них явно жирноват будет. >Если указанное выше не соблюдается, то либо программы не одинаковы, либо компилятор >плох. ...либо ресурсы ограничены так что жирный (в некоторых применениях) STL и прочая засунуть тупо некуда... :).Для более толстых систем - вы в общем случае правы а проекты крупнее некоторого размера на сях++ получаются даже лучше чем на сях с приемлимым распуханием кода и практически такой же скоростью.Тем не менее, даже на десктопе заметно что GTKшные программы писанные на сях все-таки обычно немного полегче и пошустрее с++ных программ на Qt.Допускаю что там дело не только в ++ но факт все-таки есть :) >gcc компилирует C++ код медленней чисто сишного. Медленнее, факт.При том заметно.Но это по моему вообще пофигу - юзеры поюзают бинарь а програмер может компилять только изменения и в современных реалиях - на чем-то многоядерном. >чем аналогичная программа на С" Бъярн Страуструп ответил "а на моей >платформе - в меньшего" :-) Я могу легко нарыть с дюжину платформ на которой просто запустить hello world на C++ будет трудновато или и вовсе невозможно :).При том тем не менее, колупать более 16 кило кода на асме желающих найдется ИМХО немного :P >Думаю, что JVM выбирают в качестве "интерфейса" для >телефонов, всё-таки чтобы доступ ограничить. Ну да.Правда толка с этого ноль.Хаксоры собственно класть хотели на ограничения.Итого в пролете сугубо юзеры как всегда.В смартфонах пошли на некий компромисс, там разделение: "GSM modem" и "процессор приложений", два разных процессора.В итоге на процессоре приложений можно выполнять по сути что угодно т.к. с сетью работает GSM модем со своим процессором (и вот оно как правило зубодробильно защищено от попыток туда сунуться, ибо обеспечивает симлоки и прочую "радость").
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	24. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от Александр Чуранов on 25-Авг-08, 20:30
	>[оверквотинг удален] >останется.Нет, я действительно очень хотел бы посмотреть как это будет выглядеть;).А >на сях программят и такие чипы.И даже чипы с всего парой >кил для кода, если изгальнуться, и то можно программить - выбросить >лишний стартап, минималистичные библиотеки и усе, телемаркет.ЭВМ нынче бывают разные.В частности >однокристальные а это бывает и восьмилапым тараканом с мизером памяти на >борту.Си катит даже для програминга таких.А то тараканы бывают разномасштабные и >скажем, 16 и более кило кода на асме колупать уже грустновато >выходит.Не портабельно и башню програмеру срывает.В итоге C бывает разный.Например, AVR-GCC, >и GCC для MSP430.Вполне себе хорошие и замечательные порты GCC под >эти архитектуры.А вот C++ для них явно жирноват будет. User294, давай адрес куда архив 3.6Кб положить. Там две тривиальные программы. Одна - на с, другая - на С++. Сам узнаешь, что куда запихать можно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	35. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от User294 (??) on 26-Авг-08, 18:04
	>User294, давай адрес куда архив 3.6Кб положить. Там две тривиальные программы. Одна >- на с, другая - на С++. Сам узнаешь, что куда >запихать можно. А си++ компилятор под 8-ногих и подобных тараканов уже спортировали?А то си почти под все (?) мыслимые семейства чипов есть, даже под экзотичных уродцев типа PIC16 с их крохотной памятью и 14-битными :\ словами.А вот си++ для многих из них или совсем нет или очень круто обкастрированный embedded вариант - чем прикажете тогда компилять?Впрочем, закиньте - user294@inbox.ru и учтите что из мелких я могу попробовать собрать пример только для AVR, MSP430 и ARM с помощью банального GCC.Если для ARM ++ явно бывают то для первых двух честно говоря не помню и как говорится, буду посмотреть (не жалуют ++ в данной области, и на то есть причины, озвученные мной).В таких чипах просто банальный printf то юзать порой проблема потому что оперативки он много жрет (когда ее всего 1Кб критерии для "много жрет" довольно специфичные).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	15. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от Аноним (??) on 23-Авг-08, 09:02
	>> И это сделано из соображений безопасности. > >Ну вы просто не видели как хаксоры через эту "безопасную" машинный код >выполняют на телефонах.На сименсах это например такой народный метод патчинга начального >загрузчика (!!!) с целью сбить ограничения и позволить прошивать все что >угодно.А вы говорите, безопасноть :) Если есть физический доступ к взламываемому объекту, то тут, конечно, безопасностью и не пахнет. Но вот можно ли взломать java-подсистему на телефонах удаленно, например, заставив пользователя установить определенное приложение? Фиг - как только оно попросит доступ к интернету, файловой системе, SMS и т.п - телефон спросит, разрешать доступ или нет. А иначе как с помощью виртуальной машины реализовать безопасное выполнение каких угодно программ на дешевых телефонах невозможно - аппаратного MMU там нет, и любая нативная программа имеет полный доступ ко всему.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	36. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от User294 (??) on 26-Авг-08, 19:03
	>реализовать безопасное выполнение каких угодно программ на дешевых телефонах невозможно >- аппаратного MMU там нет, Это неправда.Обычно там ARM926EJS или подобное ядро.С MMU и акселережкой Java.И даже у ARM без MMU есть более примитивный модуль защиты памяти позволяющий ее побить на несколько сегментов с разным доступом(не такой навернутый как MMU и число сегментов сильно ограниченное, но для изоляции JVM от прочих много и не надо).Другое дело что самопальные операционные системы юзаемые в телефонах писаны абы как и о секурити там если и думали то не всегда в первую очередь.Посему включаются и откровенно тупые ляпы.Укрепляют там традиционно только одно - то что занимается SIM Lock.Вот этот кусок обычно укреплен весьма конкретно и густо обвешан цифровыми подписями, чексуммами, вагоном проверок и прочая.А что там случится с юзером и его данными обычно никого не колышет.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	20. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от iZEN (ok) on 24-Авг-08, 10:52
	>> И это сделано из соображений безопасности. > >Ну вы просто не видели как хаксоры через эту "безопасную" машинный код >выполняют на телефонах.На сименсах это например такой народный метод патчинга начального >загрузчика (!!!) с целью сбить ограничения и позволить прошивать все что >угодно.А вы говорите, безопасноть :) Это исключение, связанное с ошибкой в KVM Siemens. И только. Насколько я знаю, другие мобильники через KVM не ломались ни разу. Выбор для системного программирования C/C++ обусловливается наличием библиотек разработки и инфраструктуры, то есть элементарной ленью начинать писать всё с нуля, например, на Modula-2 или Oberon, не говоря уж о Forth. В C++ слишком много разложено костылей над граблями, чтобы от них просто так отказаться.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	21. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от Александр Чуранов on 25-Авг-08, 07:16
	> слишком много разложено костылей над граблями Не знаю ни Modula-2, ни Oberon, ни Forth. Однако, очень хорошо знаю Java и имею знакомство с Ruby. Могу точно сказать, что у них целевое использование отличается от C++, поэтому и решения другие. Они либо эффективность приносят в ущерб чему-то, либо строят всех в один ряд, навязывая решения. В C++ вносят только проверенные-перепроверенные решения. Изучите работу комитета по стандартизации, если есть сомнения. В ruby есть instance methods, добавляемые пользователями, в java - checked exceptions. Через комитет подобное не прошло бы. > наличием библиотек разработки и инфраструктуры Ну, не знаю, как для Oberon, а для Java инфраструктура НАМНОГО более развита, чем для С++. Рассмотрите Eclipse, IDEA и Tapestry. В С++ даже код подсветить или подсказать никто правильно не может. Ни emacs, ни visual studio 2008. Дело в том, что кроме библиотек есть ещё и core language. А там различия огромны. В С++ есть то, на чём можно построить и boost::expressive и std::inner_product. Как правило, в других языках либо нельзя так сделать, либо тормозит. А С++ - единственный мне известный, сочетающий гибкость и скорость. А грядущие concepts и rvalue references только усиливают указанные качества языка. Об этом и новость, собственно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	26. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от User294 (??) on 25-Авг-08, 22:04
	>Это исключение, связанное с ошибкой в KVM Siemens. И только. Нет, не только.Почему-то как только я качаю себе жабу для браузера - в ней находят дыру вида "ой блин, удаленный хакер может вылезти за пределы песочницы и сделать все что душе угодно с правами текущего юзера".За***хался апдейтить в свое время.Теперь просто не юзаю ибо судя по багам такого плана разрешать аплетам запускаться из веба не сильно менее стремно чем позволить хакеру запускать просто бинарь в машинном коде под текущим юзером. >Насколько я знаю, другие мобильники через KVM не ломались ни разу. Потому что нахрен не нужно.Зато десктопная жаба ломалась немеряно раз. > Выбор для системного программирования C/C++ обусловливается ... тем что на сях можно накатать и такой код, который иначе пришлось бы нудно и долго колупать на гольном асме.Ну вот например, FreeLDR из ReactOS.Гольный бинарь - даже не PE EXE и не ELF.А тем не менее на сях писан.Да, с специфичным стартап-кодом.Да, с собственной рантайм-библиотекой.Но, черт побери, на обычных сях.А теперь покажите другой язык где вот так вот запросто бац и можно без ассемблера и спецутилсов и вообще каких-либо специальных фортелей штатными средствами компилера и линкера такое изобразить.Для системного программинга по-моему такое актуально.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	16. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от null (??) on 23-Авг-08, 14:34
	В телефонах на ARM926 процах, можно сказать, не JVM, а JRM. Там до 95% java кода выполняется нативно. Это тебе не порно-x86 :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	19. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от Александр Чуранов on 23-Авг-08, 18:02
	Интересно, побежал изучать ARM926.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

23. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."

Сообщение от yantux (??) on 25-Авг-08, 11:03

C++ один из самый ёкнутых языков программирования. Вместо того, чтобы производить полезный продукт программёры извращаются в плане оптимизаций, поиска ошибок, т.е. делаеют всё только не производить полезный продукт. Мне это напоминает дутых доцентов и профессоров.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	25. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от Александр Чуранов on 25-Авг-08, 20:33
	Yantux, ты мои посты не читал, что ли? Надо тебе точно в качестве капчи задачи по Software Engineering давать. Хочешь что-то сказать - говори предметно, чтобы мы могли сравнить и измерить. Вот, например, User294 про ресурсы сказал - я ему тест-приложения для анализа подготовил. Надо дискуссию содержательно вести. А, кстати, ты само интервью-то читал?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	27. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от Yantux on 26-Авг-08, 00:15
	Читал. Я не берусь за задачи Software Engineering, которые как правило требуют знать стандарт С++ и прочие хитрые прибамбасы, которые знает один программист из ста. Например ваш первый пример про типы я догадываюсь как работает, но по большому счёту совершенно не осознаю. Я берусь за реальные жизненние задачи в области embedded devices. Главный недостаток С и С++ - низкая скорость компиляции, pascal быстрее однозначно. java - замечательный язык для разработки надёжного ПО, т.е. с обработкой исключений. pascal, java - однозначно лучше С и С++.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	28. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от Александр Чуранов on 26-Авг-08, 04:15
	>Читал. Я не берусь за задачи Software Engineering... Представляю архитектора моста, говорящего "ну, я за задачи civil engineering не берусь вообще-то, а занимаюсь реальными проблемами". Архитекторам мостов НАДО браться за civil, а приложений - за software engineering. А то под нагрузккой разрушатся и те и другие. >Главный недостаток С и С++ - низкая скорость компиляции, pascal быстрее однозначно. В значительной степени недостаток не языка, а компилятора. Хотя вряд ли в pascal есть specialization matching и SFINAE. От того и быстрее. >java - замечательный язык для разработки надёжного ПО, т.е. с обработкой исключений. Да, неплохой. Только я так понимаю, что в других языках исключений нет, что ли? Или они в Java как-то лучше реализованы? А что такое "проглоченные исключения" в Java? А других проблем с исключениями, там, случаем нет? А что такое детерминированность поведения, она в понятие "надёжность" не входит, да? Кстати, про пример: можно сравнить что будет стоить программу на С++ перевести с встроенных целочисленных типов на защищённый из моего примера и что будет стоить в яве избежать переполнения и недополнения целых. Или это в "надёжность" совсем никак не входит? >pascal, java - однозначно лучше С и С++. Ну и хорошо. А вот для меня не всё так однозначно. У Java очень сильны позиции в web, а у С++ - в не-web. А pascal где применяется не в курсе. Все программы, которыми дома и на работе пользуюсь - на 90% С и С++ почему-то. Вот сейчас пишу этот текст в браузере и думаю: "а разработчики-то дурачки, надо браузер на паскале писать, или хотя бы на яве" :-)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	29. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от yantux (??) on 26-Авг-08, 10:35
	>Представляю архитектора моста, говорящего "ну, я за задачи civil engineering не берусь >вообще-то, а занимаюсь реальными проблемами". Архитекторам мостов НАДО браться за civil, >а приложений - за software engineering. А то под нагрузккой разрушатся >и те и другие. Ваш пример я не понял - не у меня такой квалификации и не вижу смысла вникать в такие тонкости. Такие задачи надо решать както проще. Ваш пример возможно поймёт один программёр изх 10-ти это не есть гуд. Программа должна полноценно поддерживаться. >В значительной степени недостаток не языка, а компилятора. Хотя вряд ли в >pascal есть specialization matching и SFINAE. От того и быстрее. Я не спец по компиляторам. Программисты (по специальности) говорят, что pascal однопроходной компилятор в отличии от С и С++. Этим и объясняется скорость компиляции. >Да, неплохой. Только я так понимаю, что в других языках исключений нет, >что ли? Или они в Java как-то лучше реализованы? А что >такое "проглоченные исключения" в Java? А других проблем с исключениями, там, >случаем нет? А что такое детерминированность поведения, она в понятие "надёжность" >не входит, да? Стек ошибок. >Кстати, про пример: можно сравнить что будет стоить программу на С++ перевести >с встроенных целочисленных типов на защищённый из моего примера и что >будет стоить в яве избежать переполнения и недополнения целых. Или это >в "надёжность" совсем никак не входит? Не знаю чем отличается целочисленный тип от защищённого. Я вижу разницу между int и float, char какие там ещё защищённые типы бывают не знаю и сомневаюсь что в них есть необходимость. >Ну и хорошо. А вот для меня не всё так однозначно. У >Java очень сильны позиции в web, а у С++ - в >не-web. А pascal где применяется не в курсе. Все программы, которыми >дома и на работе пользуюсь - на 90% С и С++ >почему-то. Вот сейчас пишу этот текст в браузере и думаю: "а >разработчики-то дурачки, надо браузер на паскале писать, или хотя бы на >яве" :-) С и С++ очень гибкие языки. Основная масса производителей
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	31. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от Александр Чуранов on 26-Авг-08, 14:41
	>Такие задачи надо решать както проще. typedef int my_int; // это сначала void f(my_int x); // и ещё 100 Мб кода в разных файлах --- через пару лет --- typedef safer_int <int, Throw, DisallowCast>::type my_int; void f(my_int x); // и ещё 100 Мб кода в разных файлах - не изменилось Вот, спустя два года одной строчкой проект переведён с обычных целых на защищённые. Это гибкость. Это поддерживаемость. И надёжность. Куда проще-то? >Ваш пример возможно поймёт один программёр изх 10-ти это >не есть гуд. К нам недавно в контору приходил человек на Team Lead'а собеседоваться. Не знает бинарный поиск. Да, это не есть гуд. Его не взяли, конечно. >pascal однопроходной компилятор в отличии от С и С++. Этим и объясняется скорость >компиляции. А в С++ - многопроходной? Я не уверен. В коде GCC такого пока не находил. Да, язык сложнее. Действительно, можно освоить лопату и использовать без проблем. И ломается она редко. А то, что экскаватором управлять надо учиться - это, конечно, минус. Только почему же используют их, эти экскаваторы? Они ведь и стоят дороже. Глупые люди себе проблем ищут. Товарищи, копайте лопатами! >Стек ошибок. Не понял, о чём конкретно это. Можно объяснить? >Я вижу разницу между int и float, char какие там ещё защищённые типы бывают не >знаю и сомневаюсь что в них есть необходимость. Ищите в Google по словам "integer vulnerabilities". А то может быть она есть, это необходимость?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	39. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от User294 (??) on 26-Авг-08, 20:18
	>Ищите в Google по словам "integer vulnerabilities". А то может быть она >есть, это необходимость? Еще какая есть.Некоторые упыри хронически не хотят валидацию входных данных делать и крайне безбашенно потом с полученными данными обращаются.Что на сях, что на жабе, что на пхп, что на чем там еще.В результате куда не ткни, незапланированные данные введенные юзером вызывают красивые спецэффекты.Integer overflow один из таковых.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	30. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от yantux (??) on 26-Авг-08, 10:39
	>Представляю архитектора моста, говорящего "ну, я за задачи civil engineering не берусь >вообще-то, а занимаюсь реальными проблемами". Архитекторам мостов НАДО браться за civil, >а приложений - за software engineering. А то под нагрузккой разрушатся >и те и другие. Ваш пример я не понял - не у меня такой квалификации и не вижу смысла вникать в такие тонкости. Такие задачи надо решать както проще. Ваш пример возможно поймёт один программёр изх 10-ти это не есть гуд. Программа должна полноценно поддерживаться. >В значительной степени недостаток не языка, а компилятора. Хотя вряд ли в >pascal есть specialization matching и SFINAE. От того и быстрее. Я не спец по компиляторам. Программисты (по специальности) говорят, что pascal однопроходной компилятор в отличии от С и С++. Этим и объясняется скорость компиляции. >Да, неплохой. Только я так понимаю, что в других языках исключений нет, >что ли? Или они в Java как-то лучше реализованы? А что >такое "проглоченные исключения" в Java? А других проблем с исключениями, там, >случаем нет? А что такое детерминированность поведения, она в понятие "надёжность" >не входит, да? Стек ошибок. >Кстати, про пример: можно сравнить что будет стоить программу на С++ перевести >с встроенных целочисленных типов на защищённый из моего примера и что >будет стоить в яве избежать переполнения и недополнения целых. Или это >в "надёжность" совсем никак не входит? Не знаю чем отличается целочисленный тип от защищённого. Я вижу разницу между int и float, char какие там ещё защищённые типы бывают не знаю и сомневаюсь что в них есть необходимость. >Ну и хорошо. А вот для меня не всё так однозначно. У >Java очень сильны позиции в web, а у С++ - в >не-web. А pascal где применяется не в курсе. Все программы, которыми >дома и на работе пользуюсь - на 90% С и С++ >почему-то. Вот сейчас пишу этот текст в браузере и думаю: "а >разработчики-то дурачки, надо браузер на паскале писать, или хотя бы на >яве" :-) С и С++ очень гибкие языки. Основная масса производителей ПО пожертвовала надёжностью ПО и скоростью разработки ПО ради гибкости. Т.е. вместо того, чтобы прорабатывать архитектуру, проект ПО, предпочитают свалить всё на программиста, а он сделает как получиться, благо гибкость С и С++ позволяет. От программистов же не требуют надёжность ПО. Сделал, работает и ладно. А потом мы удивляемся, чего это у нас всё как то не стабильно работает не важно какая windows или Линукс...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	32. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от Александр Чуранов on 26-Авг-08, 14:58
	>От программистов же не требуют надёжность ПО. Сделал, работает и ладно. Наверное, везде по-разному. У нас на надёжность почти все ресурсы и уходят. Код пишем 10% времени. И проверкой качества десятки человек занимаются.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	33. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от yantux (??) on 26-Авг-08, 17:15
	Значит вы делаете ПО не массового пользования. Делали бы на паскале и жабе всё былобы проще.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	34. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от Александр Чуранов on 26-Авг-08, 17:46
	>Значит вы делаете ПО не массового пользования. Делали бы на паскале и >жабе всё былобы проще. Вообще-то не очень массового. http://www.cisco.com/en/US/prod/collateral/contnetw/ps5719/p... А жаба вполне используется, так же, как и питон и шелл. И всё-таки есть на паскале ПО массового пользования или нет? Я что-то не найду в системе компилятор. Как же у меня массовые программы-то установились?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	40. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от User294 (??) on 26-Авг-08, 20:26
	>Значит вы делаете ПО не массового пользования. Угу, а потом в ПО массового использования находят замечательную дыру или логический баг позволяющий при штатном юзании и безобидной операции например юзера протрояниьт - в результате оравы пользователей нагибаются раком.Я понимаю когда вы программу пишете на уроке информатики и там до балды.А вот когда программа у миллиона юзеров это уже лакомое средство проникновения в систему.И по-моему ответственность за халтуру в таких программах должна быть на уровне ответственности архитектора если спроектированный им мост рухнул из-за ошибки в рассчетах.Если миллионам юзеров вдули виря или трояна или похитили данные и т.п. - ущерб не намного меньше как-то в результате, если програма и правда массовая.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	41. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от User294 (??) on 26-Авг-08, 20:31
	>Не знаю чем отличается целочисленный тип от защищённого. Зато когда хаксоры пришлют вашей программе не то что по вашей задумке должен ввести юзер а то что им было удобно чтобы сломать вашу программу - узнаете :).Результат бывает разный, но как правило - ничего хорошего.Отказ в обслуживании, повышение прав или выполнение удаленным хаксором своего кода - типичные такие грабельки от integer overflow.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	38. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от User294 (??) on 26-Авг-08, 20:06
	>Читал. Я не берусь за задачи Software Engineering, которые как правило требуют >знать стандарт С++ и прочие хитрые прибамбасы, которые знает один программист >из ста. А вы случайно не из тех чудаков на букву эм которые пишут на чем умеют биллинги и тому подобное практическое добро?С логическими ошибками над которыми юзерье потом угорает, прокидывая обладателя чудо-поделия на много денег и т.п..Потому что язык языком а если архитектура и реализация безбашенные - они на любом языке дрянь дрянью будут.И никакая жаба от этого не спасает.А чем более тупой програмер писал программу тем больше там логических ошибок как правило.Что?Вы не любите ловить ошибки?Дебажить?Следить за всем и вся?Зато хакеры в отличие от вас очень любят подавать на вход таким поделкам вместо того что задумал програмер откровенный левак.А потом появляются если и не переполнения буфера так SQL иньекции, XSS скриптинг, доступ к привилегированной информации и прочие веселости :).Кажется в tomcat недавно пофиксили крайне забавную багу с directory traversal (кстати да, серверов с этим "безопасным" добром позволяющих хапнуть файлов которые по идее мне не полагается видеть - выше крыши.Иногда там встречаются и всякие интересности :D).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	37. "Интервью с Бьерном Страуструпом, с вопросами о будущем станд..."
	Сообщение от User294 (??) on 26-Авг-08, 19:25
	>C++ один из самый ёкнутых языков программирования. Вместо того, чтобы производить полезный >продукт программёры извращаются в плане оптимизаций, поиска ошибок, т.е. делаеют всё >только не производить полезный продукт. Одна незадача - полезных продуктов писаных на C++ побольше чем всех остальных вместе взятых пожалуй.От компьютерных игр до десктопных сред.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]