// сложение
void test_addition()
{
complex a(1,1);
complex b(1,1);
assert(a + b == complex(2,2));
}
C++ || C#
Если можно сравнивать, то какие у них достоинства и недостатки?
Цитата:
Originally posted by alibabaich
Если можно сравнивать...
Если можно сравнивать...
Нельзя сравнивать.
Цитата:
Originally posted by Green
Нельзя сравнивать.
Нельзя сравнивать.
Да. Я то же склоняюсь к этому. Просто его преподают как наследника и продолжателя С++.
Цитата:
Originally posted by alibabaich
Да. Я то же склоняюсь к этому. Просто его преподают как наследника и продолжателя С++.
Да. Я то же склоняюсь к этому. Просто его преподают как наследника и продолжателя С++.
Плюнь в лицо этим преподавателям.
Цитата:
Originally posted by Green
Плюнь в лицо этим преподавателям.
Плюнь в лицо этим преподавателям.
Всему Microsoft?:D
Цитата:
Originally posted by Green
Нельзя сравнивать.
Нельзя сравнивать.
Гмс... сравнивать можно все что угодно ( былы бы теория :) ). На данный момент ( по моему скромному мнению ) С++ наиболее соответсвующий язык для создания "реальных" приложений, то есть приложений которые реально будут использоваться в каком нибудь действительно важном роде человеческой деятельности ( типа систем навигации, медицинских приборов и т.п. ), где компьютеры применяются для того что бы повысить эффективость действий человека в каком нить роде деятельности не связанном изначально с компьютерами. В основном это благодаря тому что при использовании C++ можно максимально выжать из компьютера все его возможности, так как С++ это практически первая ступенька над ассемблером. Если же говорить о С# то лично мной он воспринимается как создание программ ради самих программ. Вообще такие языки как C# и Java появились в результате измышлений каким же должен быть идеальным язык программирования ( с академической точки зрения ), максимально оторванный от hardware. Но плата за академическую чистоту : эффективность.... ( продолжение следует ).
Цитата:
Originally posted by Mamontoboy
Гмс... сравнивать можно все что угодно ( былы бы теория :) ). На данный момент ( по моему скромному мнению ) С++ наиболее соответсвующий язык для создания "реальных" приложений, то есть приложений которые реально будут использоваться в каком нибудь действительно важном роде человеческой деятельности ( типа систем навигации, медицинских приборов и т.п. ), где компьютеры применяются для того что бы повысить эффективость действий человека в каком нить роде деятельности не связанном изначально с компьютерами.
Гмс... сравнивать можно все что угодно ( былы бы теория :) ). На данный момент ( по моему скромному мнению ) С++ наиболее соответсвующий язык для создания "реальных" приложений, то есть приложений которые реально будут использоваться в каком нибудь действительно важном роде человеческой деятельности ( типа систем навигации, медицинских приборов и т.п. ), где компьютеры применяются для того что бы повысить эффективость действий человека в каком нить роде деятельности не связанном изначально с компьютерами.
И канет в лету 1С(очень хочется, но маловероятно).
Цитата:
Originally posted by Mamontoboy
В основном это благодаря тому что при использовании C++ можно максимально выжать из компьютера все его возможности, так как С++ это практически первая ступенька над ассемблером.
В основном это благодаря тому что при использовании C++ можно максимально выжать из компьютера все его возможности, так как С++ это практически первая ступенька над ассемблером.
А еще можно писать в машинных кодах. Я так тетрис писал. Уже не помню для какого калькулятора(1987 год).
Цитата:
Originally posted by Mamontoboy
Если же говорить о С# то лично мной он воспринимается как создание программ ради самих программ. Вообще такие языки как C# и Java появились в результате измышлений каким же должен быть идеальным язык программирования ( с академической точки зрения ), максимально оторванный от hardware. Но плата за академическую чистоту : эффективность.... ( продолжение следует ).
Если же говорить о С# то лично мной он воспринимается как создание программ ради самих программ. Вообще такие языки как C# и Java появились в результате измышлений каким же должен быть идеальным язык программирования ( с академической точки зрения ), максимально оторванный от hardware. Но плата за академическую чистоту : эффективность.... ( продолжение следует ).
Так С++ то же поэтому же был создан(Ну не устраивл чем-то Страуструпа Си).
Наш ответ Чемберлену.....
Цитата:
Originally posted by alibabaich
И канет в лету 1С(очень хочется, но маловероятно).
И канет в лету 1С(очень хочется, но маловероятно).
Цитата:
Originally posted by alibabaich
А еще можно писать в машинных кодах. Я так тетрис писал. Уже не помню для какого калькулятора(1987 год).
А еще можно писать в машинных кодах. Я так тетрис писал. Уже не помню для какого калькулятора(1987 год).
Если нельзя но очень хочется то можно.
Цитата:
Originally posted by alibabaich
Так С++ то же поэтому же был создан(Ну не устраивл чем-то Страуструпа Си).
Так С++ то же поэтому же был создан(Ну не устраивл чем-то Страуструпа Си).
гмс... фактически этим ты называешь С++ языком максимально оторванным от hardware. Помоему нет языка высокого уровня так минимально оторванного от hardware как С++ ( и C как его подмножество ).
Цитата:
Originally posted by Mamontoboy
гмс... фактически этим ты называешь С++ языком максимально оторванным от hardware. Помоему нет языка высокого уровня так минимально оторванного от hardware как С++ ( и C как его подмножество ).
гмс... фактически этим ты называешь С++ языком максимально оторванным от hardware. Помоему нет языка высокого уровня так минимально оторванного от hardware как С++ ( и C как его подмножество ).
Язык С не является подмножеством языка С++, как и обратное.
Цитата:
Originally posted by Green
Язык С не является подмножеством языка С++, как и обратное.
Язык С не является подмножеством языка С++, как и обратное.
Безусловно С++ многим обязан языку С [8], который сохраняется как его подмножество. Бъярни Страуструп, второе издание книги Язык С++.
Цитата:
Originally posted by Mamontoboy
гмс... фактически этим ты называешь С++ языком максимально оторванным от hardware. Помоему нет языка высокого уровня так минимально оторванного от hardware как С++ ( и C как его подмножество ).
гмс... фактически этим ты называешь С++ языком максимально оторванным от hardware. Помоему нет языка высокого уровня так минимально оторванного от hardware как С++ ( и C как его подмножество ).
Не может быть языка высокого уровня привязанного к аппаратуре (кто-нибудь может представить себе машинный код высокого уровня?(ну не в этом веке точно...)). Языки низкого уровня это этап в разработке продукта пригодного к использованию (вряд ли кто-то будет ножом суп есть). Те кто заявляет что он будет писать только на С++, потому что он приближен к аппаратуре - это люди которые просто хотят показать свою крутизну (я например пишу на асме, я круче? - врят ли) или не знают ничего больше.
Программный код создается для человека, а не для машины (она его всё равно не поймет, даже если он написан на asm под конкретный проц). Ручной перевод текста программы в машинные коды - это 50-е годы прошлого века(на данный момент есть компиляторы и трансляторы (для тех кто забыл сегодня 2005 год, скоро 2006)). Оптимизация - это процесс выбора наилучшего алгоритма(оптимизацией кода должен заниматься компилятор). Я люблю и Си и С++(это мощьные и универсальные языки), но это не значит, что я не буду писать на других (если сочту их более удобными и приминимыми в конкретной ситуации). Если я не ошибаюсь то рождение программного продукта это, Проектирование - Разработка - Отладка - Сопровождение - Проектирование - ... . Если взять только первые три этапа то по времени и денежным затратам это где-то 40%-20%-40%. Так что мало писать на эффективном языке, надо еще писать корректно и по возможности без ошибок. В Си и С++ есть некоторые элементы которые добавляют гибкости, но провоцируют ошибки.
Цитата:
Originally posted by alibabaich
Не может быть языка высокого уровня привязанного к аппаратуре (кто-нибудь может представить себе машинный код высокого уровня?(ну не в этом веке точно...)). Языки низкого уровня это этап в разработке продукта пригодного к использованию (вряд ли кто-то будет ножом суп есть). Те кто заявляет что он будет писать только на С++, потому что он приближен к аппаратуре - это люди которые просто хотят показать свою крутизну (я например пишу на асме, я круче? - врят ли) или не знают ничего больше.
Программный код создается для человека, а не для машины (она его всё равно не поймет, даже если он написан на asm под конкретный проц). Ручной перевод текста программы в машинные коды - это 50-е годы прошлого века(на данный момент есть компиляторы и трансляторы (для тех кто забыл сегодня 2005 год, скоро 2006)). Оптимизация - это процесс выбора наилучшего алгоритма(оптимизацией кода должен заниматься компилятор). Я люблю и Си и С++(это мощьные и универсальные языки), но это не значит, что я не буду писать на других (если сочту их более удобными и приминимыми в конкретной ситуации). Если я не ошибаюсь то рождение программного продукта это, Проектирование - Разработка - Отладка - Сопровождение - Проектирование - ... . Если взять только первые три этапа то по времени и денежным затратам это где-то 40%-20%-40%. Так что мало писать на эффективном языке, надо еще писать корректно и по возможности без ошибок. В Си и С++ есть некоторые элементы которые добавляют гибкости, но провоцируют ошибки.
Не может быть языка высокого уровня привязанного к аппаратуре (кто-нибудь может представить себе машинный код высокого уровня?(ну не в этом веке точно...)). Языки низкого уровня это этап в разработке продукта пригодного к использованию (вряд ли кто-то будет ножом суп есть). Те кто заявляет что он будет писать только на С++, потому что он приближен к аппаратуре - это люди которые просто хотят показать свою крутизну (я например пишу на асме, я круче? - врят ли) или не знают ничего больше.
Программный код создается для человека, а не для машины (она его всё равно не поймет, даже если он написан на asm под конкретный проц). Ручной перевод текста программы в машинные коды - это 50-е годы прошлого века(на данный момент есть компиляторы и трансляторы (для тех кто забыл сегодня 2005 год, скоро 2006)). Оптимизация - это процесс выбора наилучшего алгоритма(оптимизацией кода должен заниматься компилятор). Я люблю и Си и С++(это мощьные и универсальные языки), но это не значит, что я не буду писать на других (если сочту их более удобными и приминимыми в конкретной ситуации). Если я не ошибаюсь то рождение программного продукта это, Проектирование - Разработка - Отладка - Сопровождение - Проектирование - ... . Если взять только первые три этапа то по времени и денежным затратам это где-то 40%-20%-40%. Так что мало писать на эффективном языке, надо еще писать корректно и по возможности без ошибок. В Си и С++ есть некоторые элементы которые добавляют гибкости, но провоцируют ошибки.
Завязываеться битва титанов :)
По моему господа вы не туда смотрите. С# и подобные платформы (Delfi, Жаба... на самом деле их миллион и появляються они каждый день) грешат навязыванием своего подхода програмисту. По опыту знаю при создании проекта на таком монстре 90%!!! времени уходит на преодоление ограничений языковой библиотеки. Про отладку я вообще молчу. Но если к большинству из них хотя бы можно найти исходники, то мелкомятые раскажут миру о том чтож они натворили в лучшем случае лет через пять (Если вообще раскажут). С другой стороны плюсы и си строго говоря вообще не языки и лищ набор формальных правил, этим и обьясняеться их невероятная гибкость и живучесть. А мораль сей басни такова: У виртуального удобства не такая уж маленькая цена.
Цитата:
Originally posted by DaemonDZK
Завязываеться битва титанов :)
По моему господа вы не туда смотрите. С# и подобные платформы (Delfi, Жаба... на самом деле их миллион и появляються они каждый день) грешат навязыванием своего подхода програмисту. По опыту знаю при создании проекта на таком монстре 90%!!! времени уходит на преодоление ограничений языковой библиотеки. Про отладку я вообще молчу. Но если к большинству из них хотя бы можно найти исходники, то мелкомятые раскажут миру о том чтож они натворили в лучшем случае лет через пять (Если вообще раскажут). С другой стороны плюсы и си строго говоря вообще не языки и лищ набор формальных правил, этим и обьясняеться их невероятная гибкость и живучесть. А мораль сей басни такова: У виртуального удобства не такая уж маленькая цена.
Завязываеться битва титанов :)
По моему господа вы не туда смотрите. С# и подобные платформы (Delfi, Жаба... на самом деле их миллион и появляються они каждый день) грешат навязыванием своего подхода програмисту. По опыту знаю при создании проекта на таком монстре 90%!!! времени уходит на преодоление ограничений языковой библиотеки. Про отладку я вообще молчу. Но если к большинству из них хотя бы можно найти исходники, то мелкомятые раскажут миру о том чтож они натворили в лучшем случае лет через пять (Если вообще раскажут). С другой стороны плюсы и си строго говоря вообще не языки и лищ набор формальных правил, этим и обьясняеться их невероятная гибкость и живучесть. А мораль сей басни такова: У виртуального удобства не такая уж маленькая цена.
Странно я на С# создал нетривиальный проект достаточно быстро и 90% времени на планирование состояний и переходов конечного автомата. Когда писал на "жабе" 90% времени уходило на изучении библиотек. Кстати они там достаточно не плохие. В 1С вообще изучал в основном бухгалтерию и наше противоричивое законодательство. На Delfi не писал - хотя код понимаю, но begin end и т.д. не моё. В pascal 90% уходило на отладку. В С++ и Си долго пытался понять как подключать файлы что бы скомпилировать проект. На асме писал в основном функции, поскольку их размер не большой, то говорить о этапах глупо. Бейсик первый язык воспоминания теплые и нежные как о папе уже давно не видел так что остались только эмоции. Пролог, если бы не архитектурные ошибки, то... Рефал - лучший из языков доказательства тождеств. Машинные коды, 90% поиск в таблицах...
Продолжать можно долго, но если подвести итог и учесть что планирование величина примерно постоянная, то пока что С# мне нравится.
Си и С++ это именно языки (набор правил - это скорее программа), живучесть им обеспечило их переносимость на другие платформы (а не как многие предпологают их эффективность или гибкость, асм более эффективен и гибок(но код его почти не переносим на другие платформы)).
Цитата:
Originally posted by Mamontoboy
Безусловно С++ многим обязан языку С [8], который сохраняется как его подмножество. Бъярни Страуструп, второе издание книги Язык С++.
Безусловно С++ многим обязан языку С [8], который сохраняется как его подмножество. Бъярни Страуструп, второе издание книги Язык С++.
Не помню такого высказывания. Может его нет в последующих изданиях? :)
В любом случае, на счет подмножества я в корне не согласен. Это два разных языка, хотя один вышел из другого, и синтаксис схож.
А цитату могу объяснить двумя причинами:
1) трудности перевода;
2) лукавство, либо заблуждение Страуструпа.
Цитата:
Originally posted by alibabaich
Не может быть языка высокого уровня привязанного к аппаратуре
Не может быть языка высокого уровня привязанного к аппаратуре
Это как посмотреть, как трактовать "привязанного".
Например, есть спец. диалекты языков для конкретного оборудования.
Но в общем случае, согласен, язык не должен зависеть от аппаратуры.
Цитата:
Originally posted by alibabaich
Языки низкого уровня это этап в разработке продукта пригодного к использованию (вряд ли кто-то будет ножом суп есть).
Языки низкого уровня это этап в разработке продукта пригодного к использованию (вряд ли кто-то будет ножом суп есть).
Кроме тех случаев, когда язык низкого уровня в большей степени соответствует достижению цели.
Цитата:
Originally posted by alibabaich
Оптимизация - это процесс выбора наилучшего алгоритма(оптимизацией кода должен заниматься компилятор).
Оптимизация - это процесс выбора наилучшего алгоритма(оптимизацией кода должен заниматься компилятор).
Здесь в корне не согласен.
Оптимизация - процесс выбора решения, наиболее соответствующего заданным критериям.
К сожалению, машина пока не может самостоятельно принимать решения, а алгоритмы выбора весьма общие. Поэтому оптимизация (а тем более алгоритма, а не его реализации) выполняется разработчиками.
При правильном подходе (IMHO) оптимизация выполняется после получения рабочей реализации алгоритма и выполнения профилирования, т.е. процесса выявления слабых мест, недостаточно отвечающие заданным критериям. Т.о. как видно, оптимизация стоит значительно позже компиляции, поэтому компилятор ну никак не может ей заниматься.
Если же ты говоришь об оптимизации во время компиляции, то это весьма специфичный вид оптимизации, и я бы не рассматривал его, как оптимизацию программного продукта вообще.
Цитата:
Originally posted by alibabaich
Если я не ошибаюсь то рождение программного продукта это, Проектирование - Разработка - Отладка - Сопровождение - Проектирование - ...
Если я не ошибаюсь то рождение программного продукта это, Проектирование - Разработка - Отладка - Сопровождение - Проектирование - ...
Если точнее:
Сбор требований - Анализ - Проектирование - Реализация - Тестирование - Внедрение - Сбор требований - ...
Сопровождение, как таковое, сейчас в большинстве своём отсутствует. Это связано с переходом многих разработчиков от водопадной к итерационной модели разработки, где сопровождение воспринимается как очередная итерация, т.е. опять сбор требований и т.д.
Цитата:
Originally posted by alibabaich
Если взять только первые три этапа то по времени и денежным затратам это где-то 40%-20%-40%.
Если взять только первые три этапа то по времени и денежным затратам это где-то 40%-20%-40%.
"Проектирование - Разработка - Отладка" ?
Что точнее звучит, как
"Проектирование - Реализация - Тестирование"
занимает соотв-но 15% - 20% - 45% времени.
Цитата:
Originally posted by alibabaich
Так что мало писать на эффективном языке, надо еще писать корректно и по возможности без ошибок.
В Си и С++ есть некоторые элементы которые добавляют гибкости, но провоцируют ошибки.
Так что мало писать на эффективном языке, надо еще писать корректно и по возможности без ошибок.
В Си и С++ есть некоторые элементы которые добавляют гибкости, но провоцируют ошибки.
Ты не мог бы привести определение "эффективности языка"?
От ошибок никто не застрахован. И не в языках тут дело. Язык программирования в обобщенном случае совсем не имеет значения. А тем более, если говорить об ошибках при написании программ. Здесь всё зависит от квалифицированности разработчиков, правил, методов и практик разработки.
Уменьшить колличество ошибок на этапе реализации позволяют юниттесты.
Цитата:
Originally posted by alibabaich
Странно я на С# создал нетривиальный проект достаточно быстро и 90% времени на планирование состояний и переходов конечного автомата.
Странно я на С# создал нетривиальный проект достаточно быстро и 90% времени на планирование состояний и переходов конечного автомата.
90% времени на планирование?!
А если на этапе реализации оказалось бы, что твоё планирование было ошибочно?
Нельзя столько времени уделять оторванному от реализации планированию.
Цитата:
Originally posted by alibabaich
В pascal 90% уходило на отладку.
В pascal 90% уходило на отладку.
А какое отношение язык программирования имеет к отладке?
Цитата:
Originally posted by alibabaich
В С++ и Си долго пытался понять как подключать файлы что бы скомпилировать проект.
В С++ и Си долго пытался понять как подключать файлы что бы скомпилировать проект.
О да! Здесь ясно просматриваются недостатки языка. :D
А какое отношение имеет язык программирования к проекту и способу подключения файлов к нему? :)
Цитата:
Originally posted by alibabaich
Си и С++ это именно языки (набор правил - это скорее программа), живучесть им обеспечило их переносимость на другие платформы (а не как многие предпологают их эффективность или гибкость, асм более эффективен и гибок(но код его почти не переносим на другие платформы)).
Си и С++ это именно языки (набор правил - это скорее программа), живучесть им обеспечило их переносимость на другие платформы (а не как многие предпологают их эффективность или гибкость, асм более эффективен и гибок(но код его почти не переносим на другие платформы)).
А какие ЯВУ не переносимы на др. платформы?
Здесь ты сам себе противоречишь (см. свой предыдущий пост).
Ассемблер более эффективен? Определение эффективности языка в студию!
Ну и заодно приведи доказательства категоричного утверждения о неверном предположении многих и о том, что действительно обеспечило живучесть С/С++.
Цитата:
Originally posted by alibabaich
Странно я на С# создал нетривиальный проект достаточно быстро и 90% времени на планирование состояний и переходов конечного автомата. Когда писал на "жабе" 90% времени уходило на изучении библиотек. Кстати они там достаточно не плохие. В 1С вообще изучал в основном бухгалтерию и наше противоричивое законодательство. На Delfi не писал - хотя код понимаю, но begin end и т.д. не моё. В pascal 90% уходило на отладку. В С++ и Си долго пытался понять как подключать файлы что бы скомпилировать проект. На асме писал в основном функции, поскольку их размер не большой, то говорить о этапах глупо. Бейсик первый язык воспоминания теплые и нежные как о папе уже давно не видел так что остались только эмоции. Пролог, если бы не архитектурные ошибки, то... Рефал - лучший из языков доказательства тождеств. Машинные коды, 90% поиск в таблицах...
Продолжать можно долго, но если подвести итог и учесть что планирование величина примерно постоянная, то пока что С# мне нравится.
Си и С++ это именно языки (набор правил - это скорее программа), живучесть им обеспечило их переносимость на другие платформы (а не как многие предпологают их эффективность или гибкость, асм более эффективен и гибок(но код его почти не переносим на другие платформы)).
Странно я на С# создал нетривиальный проект достаточно быстро и 90% времени на планирование состояний и переходов конечного автомата. Когда писал на "жабе" 90% времени уходило на изучении библиотек. Кстати они там достаточно не плохие. В 1С вообще изучал в основном бухгалтерию и наше противоричивое законодательство. На Delfi не писал - хотя код понимаю, но begin end и т.д. не моё. В pascal 90% уходило на отладку. В С++ и Си долго пытался понять как подключать файлы что бы скомпилировать проект. На асме писал в основном функции, поскольку их размер не большой, то говорить о этапах глупо. Бейсик первый язык воспоминания теплые и нежные как о папе уже давно не видел так что остались только эмоции. Пролог, если бы не архитектурные ошибки, то... Рефал - лучший из языков доказательства тождеств. Машинные коды, 90% поиск в таблицах...
Продолжать можно долго, но если подвести итог и учесть что планирование величина примерно постоянная, то пока что С# мне нравится.
Си и С++ это именно языки (набор правил - это скорее программа), живучесть им обеспечило их переносимость на другие платформы (а не как многие предпологают их эффективность или гибкость, асм более эффективен и гибок(но код его почти не переносим на другие платформы)).
Нетривиальный говоришь... Покажи похвастайся а то сходил к тебе на страничку, ничего не увидел.
Ну да ладно.
Опровергая чужое мнение подумай вот о чем. Переносимости си и плюсовых программ не сущесвует по определению. Всю переносимость возможную для них обеспечивают стандарны ANSI и POSIX. А чистый код ты никуда не перенесеш. Гибки эти языки потому что создать реализацию стандарта на любой платформе проблемм не составляет. Именно потому что они не содержат жестких элементов я и сказал что в строгом смысле они не являються языками.
Ну а эффективностьсю ты и так уже всеж напугал. :)
Цитата:
Originally posted by Green
90% времени на планирование?!
А если на этапе реализации оказалось бы, что твоё планирование было ошибочно?
Нельзя столько времени уделять оторванному от реализации планированию.
90% времени на планирование?!
А если на этапе реализации оказалось бы, что твоё планирование было ошибочно?
Нельзя столько времени уделять оторванному от реализации планированию.
При первом релизе после недели разработки (проект с нуля был написан дважды) ?
Цитата:
Originally posted by Green
А какое отношение язык программирования имеет к отладке?
А какое отношение язык программирования имеет к отладке?
Никакого. Если ты работаешь в команде и этим занимаешься не ты, а спец. отдел.
Цитата:
Originally posted by Green
О да! Здесь ясно просматриваются недостатки языка. :D
А какое отношение имеет язык программирования к проекту и способу подключения файлов к нему? :)
О да! Здесь ясно просматриваются недостатки языка. :D
А какое отношение имеет язык программирования к проекту и способу подключения файлов к нему? :)
Никакого. Если ты обходишься одним файлом. Кстати это не недостаток, а неудобство.
Цитата:
Originally posted by Green
А какие ЯВУ не переносимы на др. платформы?
Здесь ты сам себе противоречишь (см. свой предыдущий пост).
Ассемблер более эффективен? Определение эффективности языка в студию!
Ну и заодно приведи доказательства категоричного утверждения о неверном предположении многих и о том, что действительно обеспечило живучесть С/С++.
А какие ЯВУ не переносимы на др. платформы?
Здесь ты сам себе противоречишь (см. свой предыдущий пост).
Ассемблер более эффективен? Определение эффективности языка в студию!
Ну и заодно приведи доказательства категоричного утверждения о неверном предположении многих и о том, что действительно обеспечило живучесть С/С++.
Просто если я не ошибаюсь, то язык Си и ОСь UNIX это одни из первых удачных кроссплатформенных решений.
Цитата:
Originally posted by Green
А какие ЯВУ не переносимы на др. платформы?
Здесь ты сам себе противоречишь (см. свой предыдущий пост).
Ассемблер более эффективен? Определение эффективности языка в студию!
Ну и заодно приведи доказательства категоричного утверждения о неверном предположении многих и о том, что действительно обеспечило живучесть С/С++.
А какие ЯВУ не переносимы на др. платформы?
Здесь ты сам себе противоречишь (см. свой предыдущий пост).
Ассемблер более эффективен? Определение эффективности языка в студию!
Ну и заодно приведи доказательства категоричного утверждения о неверном предположении многих и о том, что действительно обеспечило живучесть С/С++.
Русский язык.:D Под эффективностью, в данном случае, я подразумевал скорость выполнения результирующего машинного кода.
Цитата:
Originally posted by DaemonDZK
Нетривиальный говоришь... Покажи похвастайся а то сходил к тебе на страничку, ничего не увидел.
Ну да ладно.
Опровергая чужое мнение подумай вот о чем. Переносимости си и плюсовых программ не сущесвует по определению. Всю переносимость возможную для них обеспечивают стандарны ANSI и POSIX. А чистый код ты никуда не перенесеш. Гибки эти языки потому что создать реализацию стандарта на любой платформе проблемм не составляет. Именно потому что они не содержат жестких элементов я и сказал что в строгом смысле они не являються языками.
Ну а эффективностьсю ты и так уже всеж напугал. :)
Нетривиальный говоришь... Покажи похвастайся а то сходил к тебе на страничку, ничего не увидел.
Ну да ладно.
Опровергая чужое мнение подумай вот о чем. Переносимости си и плюсовых программ не сущесвует по определению. Всю переносимость возможную для них обеспечивают стандарны ANSI и POSIX. А чистый код ты никуда не перенесеш. Гибки эти языки потому что создать реализацию стандарта на любой платформе проблемм не составляет. Именно потому что они не содержат жестких элементов я и сказал что в строгом смысле они не являються языками.
Ну а эффективностьсю ты и так уже всеж напугал. :)
Ну на awk.maill333.com можно не ходить я этот сайт забросил полгода назад, а на vas-kazmin.narod.ru его еще нет, так-как не готов под него сайт(выкладывать некуда). Машинный да. И что тогда язык?
Цитата:
Originally posted by Green
Не помню такого высказывания. Может его нет в последующих изданиях? :)
В любом случае, на счет подмножества я в корне не согласен. Это два разных языка, хотя один вышел из другого, и синтаксис схож.
А цитату могу объяснить двумя причинами:
1) трудности перевода;
2) лукавство, либо заблуждение Страуструпа.
Не помню такого высказывания. Может его нет в последующих изданиях? :)
В любом случае, на счет подмножества я в корне не согласен. Это два разных языка, хотя один вышел из другого, и синтаксис схож.
А цитату могу объяснить двумя причинами:
1) трудности перевода;
2) лукавство, либо заблуждение Страуструпа.
Clearly, C++ owes much to C [Kernighan,1978]. Except for closing a few serious loopholes in
the type system (see Appendix B), C is retained as a subset.
Третье издание Бъярни Страуструпа Язык С++.
Цитата:
Originally posted by Green
Кроме тех случаев, когда язык низкого уровня в большей степени соответствует достижению цели.
Кроме тех случаев, когда язык низкого уровня в большей степени соответствует достижению цели.
Согласен.
Цитата:
Originally posted by Green
Здесь в корне не согласен.
Оптимизация - процесс выбора решения, наиболее соответствующего заданным критериям.
К сожалению, машина пока не может самостоятельно принимать решения, а алгоритмы выбора весьма общие. Поэтому оптимизация (а тем более алгоритма, а не его реализации) выполняется разработчиками.
При правильном подходе (IMHO) оптимизация выполняется после получения рабочей реализации алгоритма и выполнения профилирования, т.е. процесса выявления слабых мест, недостаточно отвечающие заданным критериям. Т.о. как видно, оптимизация стоит значительно позже компиляции, поэтому компилятор ну никак не может ей заниматься.
Если же ты говоришь об оптимизации во время компиляции, то это весьма специфичный вид оптимизации, и я бы не рассматривал его, как оптимизацию программного продукта вообще.
Если точнее:
Сбор требований - Анализ - Проектирование - Реализация - Тестирование - Внедрение - Сбор требований - ...
Сопровождение, как таковое, сейчас в большинстве своём отсутствует. Это связано с переходом многих разработчиков от водопадной к итерационной модели разработки, где сопровождение воспринимается как очередная итерация, т.е. опять сбор требований и т.д.
"Проектирование - Разработка - Отладка" ?
Что точнее звучит, как
"Проектирование - Реализация - Тестирование"
занимает соотв-но 15% - 20% - 45% времени.
Здесь в корне не согласен.
Оптимизация - процесс выбора решения, наиболее соответствующего заданным критериям.
К сожалению, машина пока не может самостоятельно принимать решения, а алгоритмы выбора весьма общие. Поэтому оптимизация (а тем более алгоритма, а не его реализации) выполняется разработчиками.
При правильном подходе (IMHO) оптимизация выполняется после получения рабочей реализации алгоритма и выполнения профилирования, т.е. процесса выявления слабых мест, недостаточно отвечающие заданным критериям. Т.о. как видно, оптимизация стоит значительно позже компиляции, поэтому компилятор ну никак не может ей заниматься.
Если же ты говоришь об оптимизации во время компиляции, то это весьма специфичный вид оптимизации, и я бы не рассматривал его, как оптимизацию программного продукта вообще.
Если точнее:
Сбор требований - Анализ - Проектирование - Реализация - Тестирование - Внедрение - Сбор требований - ...
Сопровождение, как таковое, сейчас в большинстве своём отсутствует. Это связано с переходом многих разработчиков от водопадной к итерационной модели разработки, где сопровождение воспринимается как очередная итерация, т.е. опять сбор требований и т.д.
"Проектирование - Разработка - Отладка" ?
Что точнее звучит, как
"Проектирование - Реализация - Тестирование"
занимает соотв-но 15% - 20% - 45% времени.
Жаль что так мало думают над тем как сделать и так много как исправить...
Цитата:
Originally posted by Green
Ты не мог бы привести определение "эффективности языка"?
От ошибок никто не застрахован. И не в языках тут дело. Язык программирования в обобщенном случае совсем не имеет значения. А тем более, если говорить об ошибках при написании программ. Здесь всё зависит от квалифицированности разработчиков, правил, методов и практик разработки.
Уменьшить колличество ошибок на этапе реализации позволяют юниттесты.
Ты не мог бы привести определение "эффективности языка"?
От ошибок никто не застрахован. И не в языках тут дело. Язык программирования в обобщенном случае совсем не имеет значения. А тем более, если говорить об ошибках при написании программ. Здесь всё зависит от квалифицированности разработчиков, правил, методов и практик разработки.
Уменьшить колличество ошибок на этапе реализации позволяют юниттесты.
И при if(a=b) - ?
Цитата:
Originally posted by alibabaich
Ну на awk.maill333.com можно не ходить я этот сайт забросил полгода назад, а на vas-kazmin.narod.ru его еще нет, так-как не готов под него сайт(выкладывать некуда). Машинный да. И что тогда язык?
Ну на awk.maill333.com можно не ходить я этот сайт забросил полгода назад, а на vas-kazmin.narod.ru его еще нет, так-как не готов под него сайт(выкладывать некуда). Машинный да. И что тогда язык?
Basic, Pascal, Delfi, Java ... и т.д.
Язык подразумевает набор жестких элементов (операторов, функций, ключевых, слов). В си это не так актуально, а в плюсах я могу переопределить практически все.
Цитата:
Originally posted by DaemonDZK
Basic, Pascal, Delfi, Java ... и т.д.
Язык подразумевает набор жестких элементов (операторов, функций, ключевых, слов). В си это не так актуально, а в плюсах я могу переопределить практически все.
Basic, Pascal, Delfi, Java ... и т.д.
Язык подразумевает набор жестких элементов (операторов, функций, ключевых, слов). В си это не так актуально, а в плюсах я могу переопределить практически все.
Если семантика a+b будет <=> a/b , то объясните его смысл.
Цитата:
Originally posted by Mamontoboy
Clearly, C++ owes much to C [Kernighan,1978]. Except for closing a few serious loopholes in
the type system (see Appendix B), C is retained as a subset.
Третье издание Бъярни Страуструпа Язык С++.
Clearly, C++ owes much to C [Kernighan,1978]. Except for closing a few serious loopholes in
the type system (see Appendix B), C is retained as a subset.
Третье издание Бъярни Страуструпа Язык С++.
Тут просто надо определиться что есть множество, что подмножество(не всем известно определение).
Цитата:
Originally posted by alibabaich
Если семантика a+b будет <=> a/b , то объясните его смысл.
Если семантика a+b будет <=> a/b , то объясните его смысл.
Такого нелепого переопределения никто конечно делать не будет, но определить свой набор операторов для конкретного типа данных имеет смысл, например для упрощения исходных текстов.
Цитата:
Originally posted by DaemonDZK
Такого нелепого переопределения никто конечно делать не будет, но определить свой набор операторов для конкретного типа данных имеет смысл, например для упрощения исходных текстов.
Такого нелепого переопределения никто конечно делать не будет, но определить свой набор операторов для конкретного типа данных имеет смысл, например для упрощения исходных текстов.
Так зачем переопределять язык? { в begin и т.д.? Не проще использовать другой?
Цитата:
Originally posted by alibabaich
Так зачем переопределять язык? { в begin и т.д.? Не проще использовать другой?
Так зачем переопределять язык? { в begin и т.д.? Не проще использовать другой?
Язык никто переопределять не собираеться. Хотя и такие перлы ({ в begin) я наблюдал. Фактически програмируя в плюсах грамотно ты создаешь собственный его диалект под конкретную задачу.
Цитата:
Originally posted by DaemonDZK
Язык никто переопределять не собираеться. Хотя и такие перлы ({ в begin) я наблюдал. Фактически програмируя в плюсах грамотно ты создаешь собственный его диалект под конкретную задачу.
Язык никто переопределять не собираеться. Хотя и такие перлы ({ в begin) я наблюдал. Фактически програмируя в плюсах грамотно ты создаешь собственный его диалект под конкретную задачу.
Я бы сказал расширяешь...
P.S. Прошу прощенья если кого-то обидел своими высказываниями. Знаю что несколько раз садился здесь в лужу. Но когда начинаю спорить не могу остановиться.
Я создал топик не для того что бы кого-то учить или навязывать своё мнение, а что бы узнать больше самому. так что я очень благодарен всем принявшем в споре участникам. С наступающим всех праздником.
Для alibabaich:
Тестирование - это не исправление ошибок.
Много времени тестированию (примерно пополам на модульное и общее тестирование) уделяется как для выявления ошибок, так и для проверки полноты функциональности и соотв. требованиям.
Есть подход (TDD), при котором вся разработка завязана на постоянном тестировании, и тесты пишутся ещё до реализации самой функциональности. Т.о. закрепляются требования. Например, нам надо написать библиотеку работы с комплексными числами. Мы сразу определяем необходимые действия, которые потом будем реализовывать:
и т.д.
После чего начинаем реализовывать функциональность (в данном случае класс complex) так, чтобы все тесты сработали.
Естественно, что тесты должны охватывать несколько различных вариантов исхода, но если мы сразу охватили не всё, то ничего страшного, потом допишем тесты.
Для Mamontoboy:
Сложно точно определить, что имел в виду Страуструп. Возможно, он хотел сказать, что С++ настолько сильно вобрал в себя С.
Но моё мнение остается неизменным: язык С - это самостоятельный язык (в контексте кто чье подмножество), который имеет свой стандарт, причем последняя нотация утвержденна намного позднее появления языка С++ и кое где противоречит стандарту С++.
С Наступающим всех!
Тестирование - это не исправление ошибок.
Много времени тестированию (примерно пополам на модульное и общее тестирование) уделяется как для выявления ошибок, так и для проверки полноты функциональности и соотв. требованиям.
Есть подход (TDD), при котором вся разработка завязана на постоянном тестировании, и тесты пишутся ещё до реализации самой функциональности. Т.о. закрепляются требования. Например, нам надо написать библиотеку работы с комплексными числами. Мы сразу определяем необходимые действия, которые потом будем реализовывать:
Код:
и т.д.
После чего начинаем реализовывать функциональность (в данном случае класс complex) так, чтобы все тесты сработали.
Естественно, что тесты должны охватывать несколько различных вариантов исхода, но если мы сразу охватили не всё, то ничего страшного, потом допишем тесты.
Для Mamontoboy:
Сложно точно определить, что имел в виду Страуструп. Возможно, он хотел сказать, что С++ настолько сильно вобрал в себя С.
Но моё мнение остается неизменным: язык С - это самостоятельный язык (в контексте кто чье подмножество), который имеет свой стандарт, причем последняя нотация утвержденна намного позднее появления языка С++ и кое где противоречит стандарту С++.
С Наступающим всех!
Цитата:
Originally posted by Green
Для alibabaich:
Естественно, что тесты должны охватывать несколько различных вариантов исхода, но если мы сразу охватили не всё, то ничего страшного, потом допишем тесты.
Для alibabaich:
Естественно, что тесты должны охватывать несколько различных вариантов исхода, но если мы сразу охватили не всё, то ничего страшного, потом допишем тесты.
Не понял. Что не все? Не все выходные значения или входные (нереально это охватить) или не все граничные условия(а как тогда заведомо недопустимые входные значения и не граничные)?
Цитата:
Originally posted by alibabaich
Не понял. Что не все? Не все выходные значения или входные (нереально это охватить) или не все граничные условия(а как тогда заведомо недопустимые входные значения и не граничные)?
Не понял. Что не все? Не все выходные значения или входные (нереально это охватить) или не все граничные условия(а как тогда заведомо недопустимые входные значения и не граничные)?
Я всего лишь хотел сказать, что тесты могут дополнятся в процессе реализации.
Цитата:
Originally posted by DaemonDZK
Нетривиальный говоришь... Покажи похвастайся а то сходил к тебе на страничку, ничего не увидел.
Нетривиальный говоришь... Покажи похвастайся а то сходил к тебе на страничку, ничего не увидел.
http://vas-kazmin.narod.ru/Projects/Pocker.html - выложил... Алгоритм определения комбинаций придумывал сам, так что возможны ошибки. Пишите, исправлю.