VC++ против VB - померяемся х...?
Хотя бы по тому, что VB6 умер 
Потом сравнение не самое честное.
Потом сравнение не самое честное.
М.б. умер. Это не значит, что он был "плохой".
Я к чему веду?
Как ты считаешь, что важнее, умение программировать или умение искать инфу в MSDN? Еще точнее, что важнее, умение придумать алгоритм или умение его записать на языке?
Я к чему веду?
Как ты считаешь, что важнее, умение программировать или умение искать инфу в MSDN? Еще точнее, что важнее, умение придумать алгоритм или умение его записать на языке?
Есть у меня примерчик на VBA... Загружает P4 на 100% и метров 200 памяти отжирает...
Я согласен, что насильно пичкать MFC -- это жестоко. А С++, нормально, это ж один из самых популярных языков.
Sub test
While 1 > 0
For i = 1 To 65535
Cells(i, 1).Value = i
Next i
Wend
End Sub
Вот, кстати, и он
While 1 > 0
For i = 1 To 65535
Cells(i, 1).Value = i
Next i
Wend
End Sub
Вот, кстати, и он
С этим утверждением согласен. Могу даже привести пример:
C++ Builder:
конечно, не настолько прозрачно, как в бейсике, но и не настолько ужасно, как на визуальных сях.
C++ Builder:
Edit1->Text = AnsiString("1");
конечно, не настолько прозрачно, как в бейсике, но и не настолько ужасно, как на визуальных сях.
На ДоНЕТ надо переходить. И писать на C#.
И чем паскаль не устраивает ?
Язык уже около 30-ти лет очень хорошо подходит для обучения программированию.
Язык уже около 30-ти лет очень хорошо подходит для обучения программированию.
Слишком уж он корявый. Учить программировать можно и на BASIC, ЛОГО, Алголе, Фортране, Кенгурёнке Ру и т. д. Только нафиг надо учить программированию на Паскале, а затем переучивать для нормального языка?
Я убеждён: надо сразу учить на C++/C#/Java. С какого лучше начать, не знаю.
Я убеждён: надо сразу учить на C++/C#/Java. С какого лучше начать, не знаю.
Слишком уж он корявый."Корявый" ? Это ещё почему (можно аргументы) ? А по-моему "корявый" - С++
Учить программировать можно и на BASIC, ЛОГО, Алголе, Фортране, Кенгурёнке Ру и т. д. Только нафиг надо учить программированию на Паскале, а затем переучивать для нормального языка?Паскалеподобные (Оберон-2, компонентный паскаль, ну или даже Delphi) - очень простые и безопасные языки (по сравнению с C++). На них проще всего учиться программировать.
Я убеждён: надо сразу учить на C++/C#/Java. С какого лучше начать, не знаю.
Паскаль также во всех отношениях лучше, чем basic, algol и fortran.
Я считаю, что лучше сначала научиться программировать на паскале, а потом выучить ещё и C#/Java/C++, чем сразу писать на них, потому что так быстрее и "безболезненнее" научиться программировать. После паскаля и усвоенных в нём основных принципов программирования можно легко при необходимости перейти на другой язык. Нужно будет только выучить новый синтаксис, у C# - он самый простой из C-подобных. ещё
Для некоторых задач будет хорошо подходить компонентный паскаль и система программирования Blackbox. Например, все задания / курсовые / практикумы (на физфаке) намного проще делать на нём, чем на Visual Studio / MFC.
// "Корявый" ? Это ещё почему (можно аргументы) ? А по-моему "корявый" - С++
Вряд ли на Паскале можно сделать что-то полезное, не прибегая ко всяким {$I, {$O и т. д. Просто это изначально слишком бедный язык (по сегодняшним меркам). Особо коряво выглядят попытки перенять черты C++. Например, что это вообще за конструкторы-деструкторы, которые надо вызывать вручную?
// Паскалеподобные (Оберон-2, компонентный паскаль, ну или даже Delphi) - очень простые и безопасные языки (по сравнению с C++). На них проще всего учиться программировать.
Паскаль во всех отношениях лучше, чем basic, алгол и фортран.
Алгол и Фортран особо не знаю, но давай не будем столь категорично говорить про "все отношения". Например, в Паскале есть обработка исключительных ситуаций?
А в каком-нибудь Бейсике есть (ON ERROR GO TO ...).
ОК, я не знаю, какой язык для старта подходит большинству (я бы рекомендовал C++). Кто-то осваивает линукс с KDE, кто-то с Linux from scratch...
// Нужно будет только выучить новый синтаксис, у C# - он самый простой из C-подобных.
По моим данным, этим может похвастаться скорее язык Java.
Вряд ли на Паскале можно сделать что-то полезное, не прибегая ко всяким {$I, {$O и т. д. Просто это изначально слишком бедный язык (по сегодняшним меркам). Особо коряво выглядят попытки перенять черты C++. Например, что это вообще за конструкторы-деструкторы, которые надо вызывать вручную?
// Паскалеподобные (Оберон-2, компонентный паскаль, ну или даже Delphi) - очень простые и безопасные языки (по сравнению с C++). На них проще всего учиться программировать.
Паскаль во всех отношениях лучше, чем basic, алгол и фортран.
Алгол и Фортран особо не знаю, но давай не будем столь категорично говорить про "все отношения". Например, в Паскале есть обработка исключительных ситуаций?
А в каком-нибудь Бейсике есть (ON ERROR GO TO ...). ОК, я не знаю, какой язык для старта подходит большинству (я бы рекомендовал C++). Кто-то осваивает линукс с KDE, кто-то с Linux from scratch...
// Нужно будет только выучить новый синтаксис, у C# - он самый простой из C-подобных.
По моим данным, этим может похвастаться скорее язык Java.
Я убеждён: надо сразу учить на C++/C#/Java. С какого лучше начать, не знаю.Кодеры, которые первым языком изучали джаву лично у меня вызывают неприязнь. Эти люди не умеютдумать, они умеют только кодить.
Считаю, что первым языком оптимальней всего изучать паскаль, как самый безопасный, простой и позволяющий изучить основные конструкции императивных языков программирования.
Еще считаю, что очень правильная последовательность языков на ВМК
Паскаль->ASM->C->C++, а дальше зависит от кафедры.
Наверно, ты прав. Но, с другой стороны, может просто язык Паскаль наши преподы уже научились по-человечески объяснять, а Java - ещё нет. Ведь начинают учить язык не с ООП или распределённых или параллельных вычислений, а со всяких if, for, while, массивов и т. д., которые везде примерно одинаковые.
Отдалённая аналогия. Эсперанто и упрощённый английский куда проще для изучения, чем просто английский. Однако...
Отдалённая аналогия. Эсперанто и упрощённый английский куда проще для изучения, чем просто английский. Однако...
Паскаль наши преподы уже научились по-человечески объяснять, а Java - ещё нет.По этой логике им было бы проще всего преподавать на алголе и на том языке, на котором они писали проги для БЭСМ-6. Думаю, ты недооцениваешь наших преподов, большая их часть может в голове компилировать приличные куски кода на паскале, асме или Сях.
Отдалённая аналогия. Эсперанто и упрощённый английский куда проще для изучения, чем просто английский. Однако..ИМХО, некорректная аналогия. Приниципиальная разница в понятиях "учиться программировать" и "учиться кодить на определенном языке". Программировать учатся по трудам Кнута и Вирта, а кодить по книжкам типа "Язык джава для чайников и дегенератов".
Когда человек, первым языком изучал джаву, у него на любую задачу реакция одна: "эту задачу надо решать на джаве". Очень тяжело переубедить, что определенные задачи может быть оптимально решать на С++, Перле или даже Лиспе.
Вряд ли на Паскале можно сделать что-то полезное, не прибегая ко всяким {$I, {$O и т. д.Для своих задач он в своё время хорошо подходил.
Обрати внимание на компонентный паскаль - "современный" паскаль.
Просто это изначально слишком бедный язык (по сегодняшним меркам)."Бедный" ? Скорее, ничего лишнего
Особо коряво выглядят попытки перенять черты C++. Например, что это вообще за конструкторы-деструкторы, которые надо вызывать вручную?Это уже Borland со своим Object Pascal / Delphi. Сейчас там используются объекты-экземпляры типа "class", где есть конструкторы / деструкторы, и всё это хорошо сочетается с синтаксисом Delphi.
В виртовском паскале ~1970-го года не было ООП.
Элементы ООП появились в языках Oberon, Oberon-2 и Active Oberon (где кстати есть конструкторы). В компонентном паскале (КОП, компонентно-ориентированное программирование) нет конструкторов/дектрукторов, потому что там они не нужны. Виртовские языки не перенимали ничего с C / C++
Например, в Паскале есть обработка исключительных ситуаций? А в каком-нибудь Бейсике есть (ON ERROR GO TO ...).Обработка исключений есть в Delphi.
В оберонах / компонентном паскале нет, потому что не нужна.
ОК, я не знаю, какой язык для старта подходит большинству (я бы рекомендовал C++). Кто-то осваивает линукс с KDE, кто-то с Linux from scratch...Blackbox / Component Pascal (но не Turbo Pascal / Delphi, и уж тем более не C / C++)
А если речь о "UNIX"-системах - то я бы выбрал FreeBSD / DragonFlyBSD
Начинать надо с простого
c# рулит!
Возвращаясь к теме. Да, кодить маленькие задачки со стандартным контентом удобнее и быстрее на VB. Пример ты привёл крайне неудачный. Потому что именно в этом случае на C++ я бы написал m_editNParticles.SetWindowText("1" что не так уж ужасно выглядит.
Но если рассматривать всё это с другой стороны, то попробуй найти решение любой нестандартной задачи на VB. Попробуй найти хоть один реально продаваемый коммерческий продукт на VB. Таких очень и очень мало. Потому что VB просто не приспособлен для создания проектов с исходниками от 500kb и выше. На VB такие проекты выраждаются очень быстро в кучу непонятной мути, с которой просто невозможно работать.
Но если рассматривать всё это с другой стороны, то попробуй найти решение любой нестандартной задачи на VB. Попробуй найти хоть один реально продаваемый коммерческий продукт на VB. Таких очень и очень мало. Потому что VB просто не приспособлен для создания проектов с исходниками от 500kb и выше. На VB такие проекты выраждаются очень быстро в кучу непонятной мути, с которой просто невозможно работать.
Вот только не надо гнать на VB. Хороший язык. А то, что с ним в последние годы делают, вообще красота. Например, VB 2005 очень неплохо смотрится относительно того же C#. Плюс в VS 2005 среда под VB получше будет (хотя последнее, наверно, решается с помощью всяких примочек).
или даже Лиспеили даже Прологе
Вот только не надо гнать на VB.Я не гнал, а привёл факты.
Хороший язык.Я не писал, что он плохой, а сказал, что он хорош только для определённого круга задач. И если небольшое офисное приложение на VB будет выглядеть красивее, и сделать его будет проще и быстрее, то большой коммерческий проект на VB поднять практически нереально. Ни я, ни мои знакомые такого не встречали.
А ещё у него чудовищный синтаксис.
Учить программированию ИМХО действительно стоит начинать с паскаля, а дальше асм, с, c#/java (на C++ забить, ибо говно). Всё-таки паскаль процедурно-ориентированный, достаточно простой, и у него достаточно удобная Стандартная Библиотека.
Я вчера пытался на плюсах считать из файла строку интов. То есть там было много строк интов, а мне нужно было их все считать, причём у конца строки было Сакральное Значение. После получаса безуспешного изучения fscanf я написал свою функцию ReadInt, которая работала через fgetc. Это говно.
Учить программированию ИМХО действительно стоит начинать с паскаля, а дальше асм, с, c#/java (на C++ забить, ибо говно). Всё-таки паскаль процедурно-ориентированный, достаточно простой, и у него достаточно удобная Стандартная Библиотека.
Я вчера пытался на плюсах считать из файла строку интов. То есть там было много строк интов, а мне нужно было их все считать, причём у конца строки было Сакральное Значение. После получаса безуспешного изучения fscanf я написал свою функцию ReadInt, которая работала через fgetc. Это говно.
VB, разумеется, неприспособлен к созданию проектов на 500 КБ VB-кода, вся его концепция построена на быстром связывании в основном ActiveX-компонентов, написанных в основном на VC++, друг с другом и формой настройкой их свойств и небольшим количеством кода, максимально понятного и простого для изменения - логики, а данные и методы работы с ними спрятаны в компонентах. Проектов на VB, суммарный объем кода компонентов и программы которых больше 500 КБ, полно.
На чем же еще можно было писать большие коммерческие проекты до появления дотНет. ИМХО как раз такие проекты глупо писать полностью на С++ (MFC, ATL). VB6 для интерфейса и для работы с СОМ, да и для написания СОМ очень подходит. По идее, такие проекты часто используют СОМ+. Еще прогеры, которые такие вещи эффективно могут делать на С++, стоят гораздо дороже чем VB прогеры, и не факт, что они стоят таких сверх затрат.
Проектов на VB, суммарный объем кода компонентов и программы которых больше 500 КБ, полно.Я с этим не спорю. Но только в таких проектах кода на C++ будет больше, чем на VB.
Я изначально тема называлась C++ vs VB.VB6 для интерфейса и для работы с СОМ, да и для написания СОМ очень подходит. По идее, такие проекты часто используют СОМ+. Еще прогеры, которые такие вещи эффективно могут делать на С++, стоят гораздо дороже чем VB прогеры, и не факт, что они стоят таких сверх затрат.COM не так уж и страшен на C++ до тех пор, пока он не выходит за рамки C++. Если же ты хочешь полностью автоматизированную программу, то не факт что на VB тебе будет легко это сделать. А большие коммерческие проекты как раз большей частью пишутся на C++/Java, по крайней мере за пять лет работы ни я, ни мои знакомые не видели в глаза проекты на VB, что говорит о редкости этих проектов. Ещё раз, в большом проекте часто приходится решать нестандартные задачи, решение которых на VB всегда вырождается в гемор.
всегда было подозрение, что пишут люди на си просто потому, что относительно легко портировать на юникс, скажем. написал ты на си под винду, малость подкрутил - и юниксовая версия у тебя в кармане. с паскалем так не выйдет.
работал и с си, и с паскалем, и ассембер отлично знаю, и даже в vbasicе есть порядочный опыт. лучший из этих языков - паскаль. оберон как-то не приглянулся.
а если смотреть .net - так там нет разницы, на каком языке писать, тк там они все абсолютно идентичны, просто синтаксисом различаются.
работал и с си, и с паскалем, и ассембер отлично знаю, и даже в vbasicе есть порядочный опыт. лучший из этих языков - паскаль. оберон как-то не приглянулся.
а если смотреть .net - так там нет разницы, на каком языке писать, тк там они все абсолютно идентичны, просто синтаксисом различаются.
всегда было подозрение, что пишут люди на си просто потому, что относительно легко портировать на юникс, скажем. написал ты на си под винду, малость подкрутил - и юниксовая версия у тебя в кармане.ИМХО, подозрение у тебя неверное.
работал и с си, и с паскалем, и ассембер отлично знаю, и даже в vbasicе есть порядочный опыт. лучший из этих языков - паскаль. оберон как-то не приглянулся.
угу, умеем писать на 10 языках в стили pascal
ОНИ ЖЕ ВСЕ ОДИНАКОВЫЕ
угу, умеем писать на 10 языках в стили pascal
ОНИ ЖЕ ВСЕ ОДИНАКОВЫЕ
У это я к тому, что можно эффективно народ использовать. На С++ можно доверить опытному прогеру, который понимает что он пишет. А на VB начинающему писать прикладной и интерфейсный код. Оплата тоже соответствующая. Думаю, хватает народу, кому доверять на С++ писать не стоит, а на VB соответствующие задачи вполне.
Ну и расскажи ,что там такого замечательного в Паскале? Не нравится, когда нужно переменные объявлять не там, где они используются.
Думаю, хватает народу, кому доверять на С++ писать не стоит, а на VB соответствующие задачи вполне.Я всегда думал, что критерий такой: либо не доверяем писать ни на чём, либо доверяем на всём.
Ну и расскажи ,что там такого замечательного в Паскале? Не нравится, когда нужно переменные объявлять не там, где они используются.Ностальгия: с чего начали, то глубоко запало в ранимую детскую душу
У это я к тому, что можно эффективно народ использовать. На С++ можно доверить опытному прогеру, который понимает что он пишет. А на VB начинающему писать прикладной и интерфейсный код. Оплата тоже соответствующая. Думаю, хватает народу, кому доверять на С++ писать не стоит, а на VB соответствующие задачи вполнеПриходишь в контору, там уже пишут на определенных языках. Кто будет поддерживать твой код на VB, если ты уйдешь?
кодеров на vb раз, два, и обчелся. А C++ и Delphi нынче в институтах учат
vb.net для asp.net, да, наверное есть группы, которые так пишут.
Начинающие пытаются исправлять чужие ошибки и изменяют front-endы
Да я не про контору. Я про людей. Есть очень много народу, которые после универа еще зеленые, чтобы нормально писать на С++. Я может про ВМК не прав, но кажется, что любой выпускник ВМК, который сам довольно много не програл вообще на С++ в частности, будет очень слабым С++ прогером. С другой стороны, после нескольких курсов про VB и друзей, он бы вполне эффективно справлялся с определенными задачами на VB. Вот и получается, что вполне разумно взять в проект на просую рутину человека, который будет выдавать приемлемое решение на VB, чем человека, который будет рожать кривой код на С++, что потом приложение будет трещать по швам из-за нарушений доступа и проблем с управление памятью (причем этот код невозможно будет привести в надлежащий вид). Хотя конечно есть еще вариант взять крутого С++ прогера, который будет окошки ваять и так далее, и платить ему как двум VB прогерам, которые возможно тоже самое сделали в несколько раз быстрее.
будет очень слабым С++ прогером. С другой стороны, после нескольких курсов про VB и друзей, он бы вполне эффективно справлялся с определенными задачами на VBНу не будет такого, это нонсенс. VB - это не qbasic.
Я бы хотел обратить внимание людей, что любой язык с автоматическим освобождением памяти (шарп, жава, ВБ) по любому делает язык без такой фишки по скорости производства отдебаженного кода, причём в десятки раз.
Доверить часть проекта писать на плюсах неопытному программисту - лучше сразу застрелиться. Один нолик прописанный в нужное место, и всё, прогу легче написать с нуля.
А вот на ВБ, жаве или шарпе - запросто. Что-нить ненапряжное, типа УИ.
Далее, за счёт изначально приятного синтаксиса и немаленького количества дополнительного сахара код на шарпе попросту в разы быстрее пишется по сравнению с плюсами и дельфями. И с пойнтерами возиться не надо, это тоже способствует.
Да! Я вспомнил основной недостаток паскалевского синтаксиса (ИМХО): из него самого совершенно неочевидны правила расстановки отступов. Более того, известная неортогональность так и не позволила мне сгенерировать идеальную систему (эдак лет за пять в общей сложности). При этом после первых пяти сотен строк на чистом С (не в вижуальной студии, замечу) автоматически находится вполне логичная система.
Вообще, более лаконичного и ортогонального синтаксиса чем в чистом С (из процедурных, конечно) я не видел. В плюсах его изрядно испоганили, да.
Доверить часть проекта писать на плюсах неопытному программисту - лучше сразу застрелиться. Один нолик прописанный в нужное место, и всё, прогу легче написать с нуля.
А вот на ВБ, жаве или шарпе - запросто. Что-нить ненапряжное, типа УИ.
Далее, за счёт изначально приятного синтаксиса и немаленького количества дополнительного сахара код на шарпе попросту в разы быстрее пишется по сравнению с плюсами и дельфями. И с пойнтерами возиться не надо, это тоже способствует.
Да! Я вспомнил основной недостаток паскалевского синтаксиса (ИМХО): из него самого совершенно неочевидны правила расстановки отступов. Более того, известная неортогональность так и не позволила мне сгенерировать идеальную систему (эдак лет за пять в общей сложности). При этом после первых пяти сотен строк на чистом С (не в вижуальной студии, замечу) автоматически находится вполне логичная система.
Вообще, более лаконичного и ортогонального синтаксиса чем в чистом С (из процедурных, конечно) я не видел. В плюсах его изрядно испоганили, да.
Да! Я вспомнил основной недостаток паскалевского синтаксиса (ИМХО): из него самого совершенно неочевидны правила расстановки отступов. Более того, известная неортогональность так и не позволила мне сгенерировать идеальную систему (эдак лет за пять в общей сложности).В обероне / компонентном паскале это исправили.
Вообще, более лаконичного и ортогонального синтаксиса чем в чистом С (из процедурных, конечно) я не видел.Угу
А вот это последнее, вот это ты к чему сказал?
Вообще, более лаконичного и ортогонального синтаксиса чем в чистом С ...особенно если использовать макросы
А это ты к чему сказал?
Батенька! Ви миня пытаетесь обмануть!
У Вас в примере с VB заранее определена переменная Edit1, а в примере с VC - нет. Так что пример с VC сокращается до Edit1.SetWindowText("1") - о чем выше писали.
По поводу остального треда:
http://rsdn.ru/article/mag/200406/editorial.xml
У Вас в примере с VB заранее определена переменная Edit1, а в примере с VC - нет. Так что пример с VC сокращается до Edit1.SetWindowText("1") - о чем выше писали.
По поводу остального треда:
rsdn:№6-2004
На нашем сайте особой популярностью пользуются длинные и, как правило, безрезультатные дискуссии типа "Что-то vs. что-то", например, "Функциональные языки vs. что-то еще". Все такие споры можно свести к следующему: апологеты языка/подхода А явно или неявно утверждают, что A лучше, чем В. При этом утверждается, что в А есть возможность Х, отсутствующая в В. После нескольких итераций спора оказывается, что Х реализуема и в В, но для этого необходимо некоторое усилие, возможно, однократное – например, создание некоторого шаблона (template) (это естественно, так как практически на любом современном языке можно реализовать машину Тьюринга, способную решить любые вычислительные задачи). Иногда этот шаблон может полностью реализовать Х, а иногда требует некоторых дополнительных действий при каждом применении. Последнее дает козыри апологетам А, и в дальнейшем спор крутится вокруг этого. Таким образом, спор зачастую вырождается в обсуждение возможности реализации Х средствами В и удобства этой реализации.
Главное, что упускают апологеты А – это то, что они неправильно строят свои рассуждения. Отсутствие Х в В – это не техническая проблема, а концептуальная. Х для В по сути является паттерном. Для не знающего о возможности Х этой возможности в В просто не существует. С другой стороны, незнание паттерна Х не мешает применять этот паттерн в А, куда он изначально встроен. Это происходит потому, что в А человек оперирует Х на уровне базового понятия. Важно понять, что Х в данном случае – высокоуровневая сущность, реализация которой не имеет значения для пользователя.
http://rsdn.ru/article/mag/200406/editorial.xml
Пожалуй, стоит в FAQ занести.
есть одно большое НО:
поддержка паттерна на уровне языка - резко уменьшает кол-во ошибок и время разработки.
Взять те же паттерны: garbage collector или ООП-наследование.
Понятно, что их можно реализовать и в C, и в Asm-е: но на этих языках не будет проверяться корректность использования этих паттернов, что в случае опечаток или ошибок - приведет к выявлению ошибок уже на этапе реальной работы, к резкому увеличению времени отладки и т.д.
поддержка паттерна на уровне языка - резко уменьшает кол-во ошибок и время разработки.
Взять те же паттерны: garbage collector или ООП-наследование.
Понятно, что их можно реализовать и в C, и в Asm-е: но на этих языках не будет проверяться корректность использования этих паттернов, что в случае опечаток или ошибок - приведет к выявлению ошибок уже на этапе реальной работы, к резкому увеличению времени отладки и т.д.
Пожалуй, не стоит.
Один нолик прописанный в нужное место, и всё, прогу легче написать с нуля.И каким же образом существует проекты, которым уже больше десятка лет?
> И каким же образом существует проекты, которым уже больше десятка лет?
Встречный вопрос:
Каким образом дцать лет назад с места на место таскали камни(руду, вещи, материалы)?
Можно ли сказать, что дцать лет назад происходило с большим кол-вом геморра?
зы
С использованием такой-то матери, можно заставить работать что угодно, особенно если не надо на поток ставить.
Встречный вопрос:
Каким образом дцать лет назад с места на место таскали камни(руду, вещи, материалы)?
Можно ли сказать, что дцать лет назад происходило с большим кол-вом геморра?
зы
С использованием такой-то матери, можно заставить работать что угодно, особенно если не надо на поток ставить.
И каким же образом существует проекты, которым уже больше десятка лет?Я думаю, что не VB-шные программисты способны найти "нолик, из-за которого ничего не пашет" максимум за несколько часов работы. Всё-таки самый хороший аргумент за весь тред - это утечка памяти. Но современные средства разработки умеют их отлавливать, вплоть до строки в которой вызывается new. Так, десяток хороших memory leak'ов в последний раз я пофиксил за пол часа. Труднее дело обстоит с COM.
Согласен - memory leak-и ищутся довольно легко, т.к. на это дело можно хоть какую-то диагностику прикрутить.
Но страшнее, когда иногда(в редких случаях) происходит использование невалидных поинтеров (например, на уже удаленные объекты).
Такие ошибки разрущающе действуют на программу, и сложны в обнаружении.
Но страшнее, когда иногда(в редких случаях) происходит использование невалидных поинтеров (например, на уже удаленные объекты).
Такие ошибки разрущающе действуют на программу, и сложны в обнаружении.
Для борьбы с этим (использование невалидных поинтеров) уже столько всего придумано. Те же smart pointer'ы и прочее, и прочее. Всё же, алгоритмические ошибки встречаются чаще, я бы сказал в 90-95% случаев. А нормально спроектированная программа на С++ содержит очень мало new/delete.
написал ты на си под винду, малость подкрутил - и юниксовая версия у тебя в кармане. с паскалем так не выйдет.Ещё как выйдет. имеется опыт с Kylix/Delphi и FreePascal
> Для борьбы с этим (использование невалидных поинтеров) уже столько всего придумано.
Только - это лишь отчасти помогает на реальных программах.
Взять те же игрушки - почти все грохаются сразу в кору, при малейших шаг влево, шаг вправо.
Или более простой пример: кодеки для плейеров - тоже постоянно норовят вылетить при малейших проблемах.
А теперь представь, что тебе надо обеспечить работу ядра программы - 24x7, как ты - это будешь делать?
Особенно, если большая часть кода пишется не тобой, а непонятно кем?
> Всё же, алгоритмические ошибки встречаются чаще, я бы сказал в 90-95% случаев
Алгоритмические ошибки проще в отладке, т.к. там можно сравнить, что хотелось, с тем, что получили.
И строить на этих различиях - какие-то предположения.
Когда программа падает в core-у, потому что десять минуть назад какой-то левый плагин затер важные данные - никакие предположения уже не помогают.
> А нормально спроектированная программа на С++ содержит очень мало new/delete.
Какой процент программ от установленных у тебя на компьютере был нормально спроектирован?
Только - это лишь отчасти помогает на реальных программах.
Взять те же игрушки - почти все грохаются сразу в кору, при малейших шаг влево, шаг вправо.
Или более простой пример: кодеки для плейеров - тоже постоянно норовят вылетить при малейших проблемах.
А теперь представь, что тебе надо обеспечить работу ядра программы - 24x7, как ты - это будешь делать?
Особенно, если большая часть кода пишется не тобой, а непонятно кем?
> Всё же, алгоритмические ошибки встречаются чаще, я бы сказал в 90-95% случаев
Алгоритмические ошибки проще в отладке, т.к. там можно сравнить, что хотелось, с тем, что получили.
И строить на этих различиях - какие-то предположения.
Когда программа падает в core-у, потому что десять минуть назад какой-то левый плагин затер важные данные - никакие предположения уже не помогают.
> А нормально спроектированная программа на С++ содержит очень мало new/delete.
Какой процент программ от установленных у тебя на компьютере был нормально спроектирован?
Взять те же игрушки - почти все грохаются сразу в кору, при малейших шаг влево, шаг вправо.Уже год общения в этом разделе пытаюсь донести мысль - не надо обвинять язык в том, что кто-то на нём неаккуратно программирует.
Или более простой пример: кодеки для плейеров - тоже постоянно норовят вылетить при малейших проблемах.
P.S. Я не сведущ в современных играх, но помню что Doom и Quake всех версий не вылетает. Хотя написаны на це. Фильмы смотрю с помощью mplayer, не вылетает.
А теперь представь, что тебе надо обеспечить работу ядра программы - 24x7, как ты - это будешь делать?Но ведь это делают, причем весьма успешно.
Особенно, если большая часть кода пишется не тобой, а непонятно кем?
Давай начнем перечислять программы, которые работают 24x7. Я буду перечислять программы написанные на C (возможно C++ а ты на языках, где автоматический memory management. Программы, работающие в единственном экземпляре перечислять нельзя. Интересует только широко известный софт, можно как open, так и closed source. Посмотрим, кто перечислит больше.
> не надо обвинять язык в том
согласен
но также полностью уверен, что для каждого языка можно высчитать коэффициент качество/цена.
И этот показатель не в пользу низкоуровневых языков.
> но помню что Doom и Quake всех версий не вылетает. Хотя написаны на це. написаны на це. Фильмы смотрю с помощью mplayer, не вылетает.
Стресс-тестирование пробовал устраивать?
DirectX отобрать, память урезать, битые файлы подсунуть и т.д.
Насколько при этом было корректное поведение и адекватные сообщения?
> Давай начнем перечислять программы, которые работают 24x7. Я буду перечислять программы написанные на C (возможно C++ а ты на языках, где автоматический memory management.
Согласен, но при условии, что также есть и инфа по кол-ву человеколет, потраченных на разработку.
согласен
но также полностью уверен, что для каждого языка можно высчитать коэффициент качество/цена.
И этот показатель не в пользу низкоуровневых языков.
> но помню что Doom и Quake всех версий не вылетает. Хотя написаны на це. написаны на це. Фильмы смотрю с помощью mplayer, не вылетает.
Стресс-тестирование пробовал устраивать?
DirectX отобрать, память урезать, битые файлы подсунуть и т.д.
Насколько при этом было корректное поведение и адекватные сообщения?
> Давай начнем перечислять программы, которые работают 24x7. Я буду перечислять программы написанные на C (возможно C++ а ты на языках, где автоматический memory management.
Согласен, но при условии, что также есть и инфа по кол-ву человеколет, потраченных на разработку.
Вам не пофигу?
Ну захотелось человеку блеснуть тем что он только что нашел (ну не совсем удачно так просто можно порадоваться за него...
Всё равно любая программа это набор алгоритмов, а каким языком вы её завернете не имеет значения ( размер проги до 500 Кб :Р )
а свыше...
Линус и Windows на VB написаны, удобнее же было бы ?
Ну захотелось человеку блеснуть тем что он только что нашел (ну не совсем удачно так просто можно порадоваться за него...
Всё равно любая программа это набор алгоритмов, а каким языком вы её завернете не имеет значения ( размер проги до 500 Кб :Р )
а свыше...
Линус и Windows на VB написаны, удобнее же было бы
?теперь представь, что тебе надо обеспечить работу ядра программы - 24x7, как ты - это будешь делать?Ни wmplayer, ни игрушки таковыми не являются.
Чтобы программа летела из-за записи данных по невалидному указателю - это надо ПОСТАРАТЬСЯ. Я такого за все три своих реально крупных проекта ни разу не видел. А остальное... С таким же успехом программы на добрых языках могут вылетать из-за деления на 0, выброса критического исключения из-за каких-то проблем с алгоритмом, и т.д. И мне почему-то кажется, что в 95% случаев так оно и происходит.
Делать 24х7 под разными ОС надо по-разному. В *x сохранять коре, в винде тоже свои методы есть.
> С таким же успехом программы на добрых языках могут вылетать из-за деления на 0, выброса критического исключения из-за каких-то проблем с алгоритмом, и т.д.
В добрых языках - такие вылеты не являются фатальными - их можно перехватить, после них программа может работать дальше и т.д.
т.е. на добрых языках - можно написать и оттестировать ядро программы, которые не будет зависить от ошибок в других модулях/плагинах (менее важных, и менее надежных).
> Чтобы программа летела из-за записи данных по невалидному указателю - это надо ПОСТАРАТЬСЯ
Достаточно:
1. непронициализировать данные
2. не проверить код возврата (не проверить валидность используемых данных)
3. Ошибиться с определением сроков жизни данных
4. неправильно выставить размеры массивы
Если ты считаешь, что таких ошибок мало, то почему так много червей/exploit-ов - которые используют, например, переполнение буфера?
Открой bugtrack и посмотри - 80% дырок - это некоррректная работа с указателями.
В добрых языках - такие вылеты не являются фатальными - их можно перехватить, после них программа может работать дальше и т.д.
т.е. на добрых языках - можно написать и оттестировать ядро программы, которые не будет зависить от ошибок в других модулях/плагинах (менее важных, и менее надежных).
> Чтобы программа летела из-за записи данных по невалидному указателю - это надо ПОСТАРАТЬСЯ
Достаточно:
1. непронициализировать данные
2. не проверить код возврата (не проверить валидность используемых данных)
3. Ошибиться с определением сроков жизни данных
4. неправильно выставить размеры массивы
Если ты считаешь, что таких ошибок мало, то почему так много червей/exploit-ов - которые используют, например, переполнение буфера?
Открой bugtrack и посмотри - 80% дырок - это некоррректная работа с указателями.
В добрых языках - такие вылеты не являются фатальными - их можно перехватить, после них программа может работать дальше и т.д.Вот-вот, их не можно, а нужно прехватить, иначе никуда твоя программа не поедет. И я не понимаю, почему на С++ нельзя написать ядро программы, которое не будет зависеть от ошибок в модулях!?
Достаточно:Ещё раз, я не говорю о том, что не знаю, как это в теории можно сделать. Но, например пункт 1 в 99,999% случаев полетит при использовании неинициализированного указателя, и ничью память никто не перезапишет. По пункту два, обычно при ошибке все нормальные функции, даже в плохо спроектированной программе, возвращают NULL. А вместо статических массивов все более-менее нормальные программисты дааааааааавно используют vector, CArray, etc.
1. непронициализировать данные
2. не проверить код возврата (не проверить валидность используемых данных)
3. Ошибиться с определением сроков жизни данных
4. неправильно выставить размеры массивы
Если ты считаешь, что таких ошибок мало, то почему так много червей/exploit-ов - которые используют, например, переполнение буфера?Тут много о чём можно думать, но программист, который позволяет такое, наверняка оставил бы дыру пиши он хоть на Java, хоть на basic.
> И я не понимаю, почему на С++ нельзя написать ядро программы, которое не будет зависеть от ошибок в модулях!?
Потому что чужой модуль - может легко затереть и данные ядра в том числе.
> Но, например пункт 1 в 99,999% случаев полетит при использовании неинициализированного указателя, и ничью память никто не перезапишет.
Откуда ты такую оценку взял?
C++, по-умолчанию, новые данные не обнуляет - соответственно, если забыть проинициализировать данные, то там будет какой-то мусор, который может ссылаться в том числе и на важные данные.
> По пункту два, обычно при ошибке все нормальные функции, даже в плохо спроектированной программе, возвращают NULL.
В случае, вот такого кода:
> А вместо статических массивов все более-менее нормальные программисты дааааааааавно используют vector, CArray, etc.
На stl-ных итераторах ты никогда ошибки не ловил?
например, такие:
Потому что чужой модуль - может легко затереть и данные ядра в том числе.
> Но, например пункт 1 в 99,999% случаев полетит при использовании неинициализированного указателя, и ничью память никто не перезапишет.
Откуда ты такую оценку взял?
C++, по-умолчанию, новые данные не обнуляет - соответственно, если забыть проинициализировать данные, то там будет какой-то мусор, который может ссылаться в том числе и на важные данные.
> По пункту два, обычно при ошибке все нормальные функции, даже в плохо спроектированной программе, возвращают NULL.
В случае, вот такого кода:
или такого
MyData * data = GetData;
data->a = bla-bla;
Обращение идет не по нулевому указателю, а по null +/- километр, соответственно, такие некорректные обращения не всегда ловятся.
MyData * data = GetData;
data->VirtualFunction;
> А вместо статических массивов все более-менее нормальные программисты дааааааааавно используют vector, CArray, etc.
На stl-ных итераторах ты никогда ошибки не ловил?
например, такие:
и все это в большой разветвленной программе.
for(Items::iterator it = items.begin; it != items.end; ++it)
{
ProcessItem(*it);
}
void ProcessItem(Item & item)
{
if (item.IsBad)
items.Remove(item);
}
> Тут много о чём можно думать, но программист, который позволяет такое, наверняка оставил бы дыру пиши он хоть на Java, хоть на basic.
Но резко и резко меньше, просто потому, что сама платформа более стабильна и надежна, по-умолчанию
Но резко и резко меньше, просто потому, что сама платформа более стабильна и надежна, по-умолчанию
Можем поспорить - ты пишешь надежное ядро на C++, я на .Net-е.
Далее меняемся, и для каждого из ядер пишем плагины, которые пытаются завалить ядро.
и смотрим, что получилось.
т.к. плагины менее важные - то ядро может их какими-либо способами ограничивать, для обеспечения своей надежности.
Далее меняемся, и для каждого из ядер пишем плагины, которые пытаются завалить ядро.
и смотрим, что получилось.
т.к. плагины менее важные - то ядро может их какими-либо способами ограничивать, для обеспечения своей надежности.
Я так понимаю что плагины для .Net приложения можно писать на чем угодно?
> Я так понимаю что плагины для .Net приложения можно писать на чем угодно?
Да, но см. пункт:
Да, но см. пункт:
т.к. плагины менее важные - то ядро может их какими-либо способами ограничивать, для обеспечения своей надежности
Я тебе на С++ напишу такой плагин, что ядро ничего не сможет сделать. Разве что плагины не будут запускаться как отдельные процессы и не сообщаться с ядром по IPC.
такой плагин просто не запуститься, т.к. в таких случаях - ядро обычно требует, чтобы плагины имели safe-код.
А с фига? Тогда у меня будет ядро на С++ и тоже будет ограничение чтобы плагины имели safe код. Тогда плагины и моему ядру ни фига не смогут сделать Нужно играть в равных условиях.
Нужно играть в равных условиях.на C++ - это будет чисто административное ограничение.
на .Net-е - это будет техническое ограничение.
и на C++ - придется верить на слово, что плагин написан безопасно.
> Тогда плагины и моему ядру ни фига не смогут сделать
Как ты будешь проверять, что плагины для C++-ядра имеют безопасный код?
> Нужно играть в равных условиях.
Дык, условия равные - ядро же оно не дурное, и тоже жить хочет.
и, вообще, зачем тебе в плагинах unsafe-код?
на .Net-е - это будет техническое ограничение.
и на C++ - придется верить на слово, что плагин написан безопасно.
> Тогда плагины и моему ядру ни фига не смогут сделать
Как ты будешь проверять, что плагины для C++-ядра имеют безопасный код?
> Нужно играть в равных условиях.
Дык, условия равные - ядро же оно не дурное, и тоже жить хочет.
и, вообще, зачем тебе в плагинах unsafe-код?
Потому что чужой модуль - может легко затереть и данные ядра в том числе.См. выше, может и не затереть, смотря как написано ядро. Например, когда падают плагины wmplayer'а, сам wmplayer не падает.
C++, по-умолчанию, новые данные не обнуляет - соответственно, если забыть проинициализировать данные, то там будет какой-то мусор, который может ссылаться в том числе и на важные данные.Попробуй просчитать вероятность этого. И ещё по-умолчанию С++ и мемори лики ловить не должен. Многие современные компиляторы помогают избежать таких проблем, не нарушая при этом стандарт.
MyData * data = GetData;В этом случае оно упадёт на ->, ещё до вызова оператора присваивания.
data->a = bla-bla;
На stl-ных итераторах ты никогда ошибки не ловил?Ага, я тебе такие ошибки и на Java могу сделать, от темы-то не уходи.
Ты хочешь сказать что в WinAPI(я подразумеваю что так или иначе .Net - часть винапи) нет функций на проверку плагина на безопасность?
> В этом случае оно упадёт на ->, ещё до вызова оператора присваивания.
В честь чего это?
я, надеюсь, ты в курсе, в какой асм - это конструкция транслируется
> Попробуй просчитать вероятность этого
Если прога, например, отжирает гиг памяти. то 1/4.
> Ага, я тебе такие ошибки и на Java могу сделать, от темы-то не уходи.
И?
на Java - будет нормальный exception
на C++ - такой цикл убивает программу, особенно, если в цикле элементы как-то менялись.
В честь чего это?
я, надеюсь, ты в курсе, в какой асм - это конструкция транслируется
> Попробуй просчитать вероятность этого
Если прога, например, отжирает гиг памяти. то 1/4.
> Ага, я тебе такие ошибки и на Java могу сделать, от темы-то не уходи.
И?
на Java - будет нормальный exception
на C++ - такой цикл убивает программу, особенно, если в цикле элементы как-то менялись.
> Ты хочешь сказать что в WinAPI(я подразумеваю что так или иначе .Net - часть винапи) нет функций на проверку плагина на безопасность?
в .Net-е есть, но опять же если плагин написан на хорошем языке, а не на C++.
ps
.Net - это совсем не WinApi. Достаточно вспомнить Mono.
в .Net-е есть, но опять же если плагин написан на хорошем языке, а не на C++.
ps
.Net - это совсем не WinApi. Достаточно вспомнить Mono.
> См. выше, может и не затереть, смотря как написано ядро. Например, когда падают плагины wmplayer'а, сам wmplayer не падает.
Скорее, потому что - он маленький, и поэтому ему просто везет.
Скорее, потому что - он маленький, и поэтому ему просто везет.
ЧТо говорить про стабильность C++, если вот такой код:
по стандарту должен убивать программу.
MyClass c;
throw 1;
class MyClass
{
~MyClass {throw 1;}
}
Поэтому все нормальные люди и пишут ~Blabla throw
> Поэтому все нормальные люди и пишут ~Blabla throw
Чем это поможет?
в случае, такого кода:
или такого:
Чем это поможет?
в случае, такого кода:
MyClass c;
throw 1;
class MyClass
{
~MyClass
{
int * pa = NULL;
*pa = 1;
}
}
или такого:
MyClass c;
throw 1;
class MyClass
{
~MyClass
{
int zero = GetZero;
int b = 10 / zero ;
}
}
Против этого помогут только прямые руки. Хотя я согласен что отсутствие сборки мусора порой очень сильно мешает. Деструкторы - это вообще головная боль. Лучше там не делать ничего кроме как освобождать выделенные ресурсы. Ну и писать так чтобы освобождение ресурсов всегда было возможно без каких-либо исключений.
я, надеюсь, ты в курсе, в какой асм - это конструкция транслируетсяНа разных компиляторах, видимо, по-разному. Но даже если следовать твоему принципу (добавить и разыменовать? то для продолжения работы программы этот класс должен иметь поистине огромные размеры на любой из популярных платформ.
Если прога, например, отжирает гиг памяти. то 1/4Не факт, что 1/4, но даже если и так. Пишем в конструкторе p_pBlabla = NULL; и всё. Это тоже вообще-то любой нормальный программист на С++ делает на автопилоте.
на Java - будет нормальный exceptionАга, но продолжать работу программы в этом случае будет нельзя, ибо как ты разберёшься, что произошло с этим циклом, почему он упал, и не нарушена ли структура данных? То есть в случае с Java тебе тоже придётся переписывать программу, пока она не будет нормально работать.
или хотя бы такого (причем этот код уже хрен перепишешь, чтобы он не падал)
MyClass c;
throw 1;
class MyClass
{
~MyClass
{
std::vector<BYTE> data(1000000); //и здесь по каким-либо причинам не хватило памяти.
}
}
Именно поэтому мне в последнее время все чаще и чаще приходят в голову разные мысли по поводу транзакционного языка - возможность делать так чтобы набор операций либо выполнялся целиком, либо не выполнялся вообще. Интересно, это вообще возможно?
Я тебе объяснил что деструктор не должен делать ничего кроме освобождения ресурсов.
Ну вот, вся дискуссия съехала к тому, кто программирует с головой, а кто тупит. Я ваще представить не могу, ЗАЧЕМ кому-то может понадобиться писать такой код. А новички они и на Java будут использовать список, например, для сортированной вставки. И будет эта стабильная программа выполнять вставку из 1000 элементов в течении пяти минут...
> Это тоже вообще-то любой нормальный программист на С++ делает на автопилоте.
А если этот нормальный программист - ошибся. Что дальше?
Как эту ошибку предлагаешь искать? И через сколько ее, вообще, найдут?
> То есть в случае с Java тебе тоже придётся переписывать программу, пока она не будет нормально работать.
Но главное, что даже в этом случае, и пользователь и сервер могут продолжать нормально работать.
Возьмем тот же client-server и следующий цикл работы:
1. Пользователь жмет кнопку
2. Клиент связывается с сервером, и что-то меняет
3. Клиент получается обновленные данные с сервера
Далее допустим во время 2 или 3 - ложиться сеть.
В нормальных языках - мы получим нормальное исключение, которое можно поймать - или либо сказать об этом пользователю, либо повторить операцию.
В C++ мы можем получить все что угодно.
А если этот нормальный программист - ошибся. Что дальше?
Как эту ошибку предлагаешь искать? И через сколько ее, вообще, найдут?
> То есть в случае с Java тебе тоже придётся переписывать программу, пока она не будет нормально работать.
Но главное, что даже в этом случае, и пользователь и сервер могут продолжать нормально работать.
Возьмем тот же client-server и следующий цикл работы:
1. Пользователь жмет кнопку
2. Клиент связывается с сервером, и что-то меняет
3. Клиент получается обновленные данные с сервера
Далее допустим во время 2 или 3 - ложиться сеть.
В нормальных языках - мы получим нормальное исключение, которое можно поймать - или либо сказать об этом пользователю, либо повторить операцию.
В C++ мы можем получить все что угодно.
дык, стабильность и длительное время работы - это очень различные понятия.
Второе простить можно, первое - прощать нельзя.
Второе простить можно, первое - прощать нельзя.
> Ну вот, вся дискуссия съехала к тому, кто программирует с головой, а кто тупит.
Ты можешь поставить 1000000$ (или хотя бы 100$ что пишешь всегда грамотный код?
Который будет корректно работать даже в непредусмотренных тобой случаях?
Ты можешь поставить 1000000$ (или хотя бы 100$ что пишешь всегда грамотный код?
Который будет корректно работать даже в непредусмотренных тобой случаях?
> Открой bugtrack и посмотри - 80% дырок - это некоррректная работа с указателями.
Похоже ты открывал bugtrack последний раз 5 лет назад. Теперь там 80% дырок в программах на всяких высокоуровневых скриптовых языках для веб - в php и прочих. Как видишь автоматическое управление памятью не спасает от алгоритмических ошибок.
Похоже ты открывал bugtrack последний раз 5 лет назад. Теперь там 80% дырок в программах на всяких высокоуровневых скриптовых языках для веб - в php и прочих. Как видишь автоматическое управление памятью не спасает от алгоритмических ошибок.
Стресс-тестирование пробовал устраивать?Например, я знаю, как тестируют игры на крупных shareware* порталах типа realarcade.com, reflexive.net. Там бета-тестеры, которые тестируют именно с точки зрения, что понравится пользователю, что совместимо с компьютерами большинства пользователей и т.д.
Подсовывать битые файлы и урезать память (когда есть system requirements, где сказана нижняя граница в том числе и по памяти) никто не будет. А вот если у тебя будут завышены требования по скорости, по системным ресурсам и т.д., то никто нафиг не возьмет твою игру.
Тестируют же на совместимость с заявленными требованиями (при этом смотрят, чтобы эти заявленные требования не были высокими).
А например, если забыть проверить, что на какой-то там встроенной карточке от Intel немного другой формат текстур и твоя игра это не уследит - это уж минус.
Вывод - не все ошибки одинаково значимы. Исправлять некоторые (я бы даже не назвал это ошибками) - паранойя, лучше время потратить на более серьезные вопросы.
DirectX отобрать, память урезать, битые файлы подсунуть и т.д.Не буду комментировать, но хотелось бы узнать, где это ты такое тестирование видел?
Хотелось бы ссылки на те игры, которые ты (или твои знакомые, которых ты имеешь ввиду говорят такое) сделал(и) с таким вот подходом.
Насколько при этом было корректное поведение и адекватные сообщения?С точки зрения тех, кто тестирует (а они основываются на мнении большинства пользователей, покупающих эту игру) - абсолютно пофигу, будет ли сообщение осмысленным, или какое-нибудь стандартное access violation. Потому что с точки зрения покупателя - это одинаково фигово. Если ты "подменишь ресурс", то человеку все равно, грохнется ли игра по "access violoation" или по "Level 666 could not be found".
Ну а по поводу плагинов, портящих ядро программы.
кодеки у меня не грохались (не знаю, я мало смотрю фильмов может повезло просто.
Но опять же - если один раз на 1000 из-за какой-то хитрой подмены (какой-то там dll или ресурса) грохнется - это будет пофигу, если в остальных случаях функциональность достаточна.
Некоторые примеры - 3D Max при работе с (ты бы назвал это плагином, хотя в терминах макс это не совсем плагин) VideoPost грохается 8 из 10 раз (я знаю, что это плохо, но, возможно, в такой системе сложно было отследить но все в нем работают - почему? Да потому что в те оставшиеся 2 раза все делается в разы лучше, чем у конкурирующих программ.
Adobe Illustrator (не текущая версия) тоже подглючивал на многих функциях, но при этом он позволял делать многое из того, что нельзя было др. програми сделать.
Так что, имхо, разумный подход - не тратить время на паранойю (а что будет, если кто-то из винды потрет какую-нибудь gdi32.dll, glut.dll или же ресурс игры).
Тем более речь идет об обычных пользовательских программах, которые вряд ли будут 24/7 работать. Те же части (например, серверная часть в сетевых играх) , которые могут в таком режиме работать, будут и тестироваться тщательнее (правда, писаться все равно на C|C++, просто человека, у которого мало опыта, не допустят до таких вещей).
непонимаю, почему на С++ нельзя написать ядро программы, которое не будет зависеть от ошибок в модулях!?В больших популярных системах SDK для написания плагинов продуманы/протестированы годами. К тому же Photoshop или 3D Max плагин затереть данные основной программы не сможет (если разработчики пользуются тем, что указано в документации к SDK).
Потому что чужой модуль - может легко затереть и данные ядра в том числе.
Так что если средства (SDK) для этих самых плагинов хорошие, и используют их аккуратно, то и проблем не возникнет.
Битые файлы - это про плейер.
Битые файлы на входе плейера - это стандартная ситуация.
Битые файлы в дистрибутиве игры - это уже редкость, хотя, конечно, даже в этом случае - хочется иметь адекватные сообщения об ошибках.
> Не буду комментировать, но хотелось бы узнать, где это ты такое тестирование видел?
При чем здесь тестирование?
Это то, что может случиться при реальном использование.
И я как пользователь хочу иметь адекватную программу, которая даже в этих случаях ведет себя корректно.
> Если ты "подменишь ресурс", то человеку все равно, грохнется ли игра по "access violoation" или по "Level 666 could not be found".
Мне, как пользователю, не все равно - т.к. второе сообщение - мне лучше позволяет понять, почему программа упала, и что надо, в следующий раз, сделать, чтобы она не падала.
> Исправлять некоторые (я бы даже не назвал это ошибками) - паранойа, лучше время потратить на более серьезные вопросы.
Исправлять - да, паранойя.
А вот писать так и использовать такие инструменты - которые позволяют эти ошибки избежать - это уже конструктивный подход.
> VideoPost грохается 8 из 10 раз
Вот видишь - все знают, что падает - но никто не знает (даже разработчики) почему.
В случае Access Violation-а даже bug report-нормальный хрен получишь.
а ведь корректный exception + stack trace - способен здорово облегчить понимание ошибки.
Битые файлы на входе плейера - это стандартная ситуация.
Битые файлы в дистрибутиве игры - это уже редкость, хотя, конечно, даже в этом случае - хочется иметь адекватные сообщения об ошибках.
> Не буду комментировать, но хотелось бы узнать, где это ты такое тестирование видел?
При чем здесь тестирование?
Это то, что может случиться при реальном использование.
И я как пользователь хочу иметь адекватную программу, которая даже в этих случаях ведет себя корректно.
> Если ты "подменишь ресурс", то человеку все равно, грохнется ли игра по "access violoation" или по "Level 666 could not be found".
Мне, как пользователю, не все равно - т.к. второе сообщение - мне лучше позволяет понять, почему программа упала, и что надо, в следующий раз, сделать, чтобы она не падала.
> Исправлять некоторые (я бы даже не назвал это ошибками) - паранойа, лучше время потратить на более серьезные вопросы.
Исправлять - да, паранойя.
А вот писать так и использовать такие инструменты - которые позволяют эти ошибки избежать - это уже конструктивный подход.
> VideoPost грохается 8 из 10 раз
Вот видишь - все знают, что падает - но никто не знает (даже разработчики) почему.
В случае Access Violation-а даже bug report-нормальный хрен получишь.
а ведь корректный exception + stack trace - способен здорово облегчить понимание ошибки.
> Теперь там 80% дырок в программах на всяких высокоуровневых скриптовых языках для веб
php - с точки зрения языка - высокоуровневый, с точки зрения системы - такой же низкоуровневый, как и остальные cgi-системы.
php - с точки зрения языка - высокоуровневый, с точки зрения системы - такой же низкоуровневый, как и остальные cgi-системы.
> php - с точки зрения языка - высокоуровневый, с точки зрения системы - такой же низкоуровневый, как и остальные cgi-системы.
Речь о том, что 80% ошибок уже давно не про память и указатели. О том, что 80% ошибок уже давно при использовании автоматического управления памятью.
Речь о том, что 80% ошибок уже давно не про память и указатели. О том, что 80% ошибок уже давно при использовании автоматического управления памятью.
> Как видишь автоматическое управление памятью не спасает от алгоритмических ошибок.
Согласен.
Но если в C++ проге - есть ошибки алгоритмические + низкоуровневые, причем низкоуровневые фиг быстро отловишь, даже если знаешь, что она есть,
то в высокоуровневых языках - есть только алгоритмические.
Согласен.
Но если в C++ проге - есть ошибки алгоритмические + низкоуровневые, причем низкоуровневые фиг быстро отловишь, даже если знаешь, что она есть,
то в высокоуровневых языках - есть только алгоритмические.
> О том, что 80% ошибок уже давно при использовании автоматического управления памятью.
В веб-е - да.
На десктопе пока до сих пор память и указатели.
В веб-е - да.
На десктопе пока до сих пор память и указатели.
Самое главное - я совсем не понимаю - как вы видите глобальное развитие программирование.
На мой взгляд, четко видно - что с увеличением производительности, а также с развитем программирования - высокоуровневые системы программирования все сильнее и сильнее заменяют низкоуровневые, т.к. высокоуровневые системы меньше требует человекоресурсов при гораздо большем "выхлопе".
Вы с этим согласны?
На мой взгляд, четко видно - что с увеличением производительности, а также с развитем программирования - высокоуровневые системы программирования все сильнее и сильнее заменяют низкоуровневые, т.к. высокоуровневые системы меньше требует человекоресурсов при гораздо большем "выхлопе".
Вы с этим согласны?
Да. Покажите того дурака, который сегодня будет писать веб приложение на С++.
> по поводу транзакционного языка - возможность делать так чтобы набор операций либо выполнялся целиком, либо не выполнялся вообще. Интересно, это вообще возможно?
Возможно, но язык должен быть достаточно высокоуровневым, чтобы правильно выполнять сохранение контрольных точек и выполнять корректно откаты до этих точек.
Возможно, но язык должен быть достаточно высокоуровневым, чтобы правильно выполнять сохранение контрольных точек и выполнять корректно откаты до этих точек.
Да, на верхнем уровне - такие системы/технологии уже есть.
У microsoft-а - это MTS.
У microsoft-а - это MTS.
Но если в C++ проге - есть ошибки алгоритмические + низкоуровневые, причем низкоуровневые фиг быстро отловишь, даже если знаешь, что она есть,Мой опыт показывает, что ошибки с памятью находятся быстрее и проще, чем хитрые алгоритмические. Более того, есть готовые инструменты для их поиска, потому как эти ошибки типичны.
то в высокоуровневых языках - есть только алгоритмические.
На мой взгляд, четко видно - что с увеличением производительности, а также с развитем программирования - высокоуровневые системы программирования все сильнее и сильнее заменяют низкоуровневые, т.к. высокоуровневые системы меньше требует человекоресурсов при гораздо большем "выхлопе".Я снова повторю мысль, которую повторяю год в этом разделе. Многие программисты упускают из виду другие области программирования, кроме тех, в которые сами вовлечены. Насколько я понял, ты вовлечен в более менее бухгалтерские задачи. Тебе нужно достоточно быстро создать сервер приложений, на котором будут висеть не более десяти клиентов. Основные фокусы задачи: удобный интерфейс и скорость разработки. Тут конечно рулят высокоуровневые языки.
Вы с этим согласны?
А есть такие области, где важна производительность.
При чем здесь тестирование?Просто там как раз бета-тестеры с сайта-продавца (которые и повлияют на решение, брать на продажу или нет, понравится ли это пользователям, или нет и т.д. и тестируют они именно с точки зрения удобства для конечного пользователя. А ты предлагал какое-то "стресс-тестирование" - убрать то, убрать се, и квейк грохнется ;(
Это то, что может случиться при реальном использование.
И я как пользователь хочу иметь адекватную программу, которая даже в этих случаях ведет себя корректно.Ок. Только я до сих пор не понимаю, насколько среда разработки здесь поможет. Вот у меня есть примеры на компе - samples к Microsoft directx sdk (раз уж про игрушки заговорили). Один и тот же пример есть как на C#, так и на обычном C++ . И там, и там, если я подсуну битый файл, выдается Could nof find required media. И там и там - это результат обычной проверки.
Только в C# public class MediaNotFoundException : SampleException...
написали классы для исключений (но это же тоже написали! не сама же среда сделает проверку). А вот в C++ почему-то даже и без exception обошлись, HRESULT проверяют.
Таким образом, если разрабочик посчитал нужным (или у него время нашлось, или его заставили) обработать какую-то ошибку или ситуацию, это будет сделано на любом языке. И опять же - скажут ему - никаких тебе exception, обрабатывай HRESULT, и будет так.
А вот то, что fps в этих самых аналогичных примерах различается в 2, а то и 3 раза, меня уже настораживает.
> Если ты "подменишь ресурс", то человеку все равно, грохнется ли игра по "access violoation" или по "Level 666 could not be found".Скорее всего, ты в меньшинстве. Большинство покупателей и так и так не догадается, что сделать, и будет вопрошать в саппорт/на форумы/или еще куда.
Мне, как пользователю, не все равно - т.к. второе сообщение - мне лучше позволяет понять, почему программа упала, и что надо, в следующий раз, сделать, чтобы она не падала.
от видишь - все знают, что падает - но никто не знает (даже разработчики) почему.Иногда, думаю, разработчики все-таки знают, почему. Просто чтобы исправить, придется переписать много, а на это не пойдут из-за затрат. Все-таки сейчас большинство ошибок - скорее следствие того, что люди не знали, как алгоритмически что-то сделать, нагородили с заплатками, а потом, даже когда появилось время и разобрались - исправлять накладно будет.
Надежность/оттестированность/осмысленные сообщения и пр. - это следствие в первую очередь того, кто пишет и тех требований, которые перед ним ставятся. И уж потом - следствие среды.
Если ты не понимаешь, чем исключения лучше HRESULT, то я тебе сочувствую. Видимо ты мало писал на СОМ, когда от ифов в глазах рябит, не говоря уже о том, что дают исключения при отладке.
> Насколько я понял, ты вовлечен в более менее бухгалтерские задачи
Я имею отношение к следующим отраслям:
Web,
Desktop,
АСУТП,
"бухгалтерские".
В целом, во всех этих отраслях сейчас идет отход от C++-а.
Даже в Асутп идет тенденция оставить C++/C только на уровне железа (на уровне контроллеров).
Я имею отношение к следующим отраслям:
Web,
Desktop,
АСУТП,
"бухгалтерские".
В целом, во всех этих отраслях сейчас идет отход от C++-а.
Даже в Асутп идет тенденция оставить C++/C только на уровне железа (на уровне контроллеров).
Если ты не понимаешь, чем исключения лучше HRESULT, то я тебе сочувствую. Видимо ты мало писал на СОМ, когда от ифов в глазах рябит, не говоря уже о том, что дают исключения при отладке.Так, один поддался на провокацию - увидел в посте, то что хотел. Я специально так расписал, чтобы показать, что ошибки обработать по-разному можно, что зависит от требований и пр. И если разработчик не знает, что из битого (недокачанного) avi-шника можно проигрывать что-то там (и не обработает этот случай соответствующим образом) - то неважно, какая среда и какой механизм.
А ты, видимо, мало писал для сред, где exceptionов нет (да-да, бывают такие вот С++ под некоторые платформы, как ни странно это тебе кажется) или где их реализация сильно тормозит по сравнению с ифами и скорость работы важнее.
А ты, видимо, мало писал для сред, где exceptionов нетНадеюсь и не придется.
тормозит по сравнению с ифамиА вот про производительность не надо. Непосредственно сами исключения на производительность влияют только положительно. В ифах ты все время проверяешь условия, причем в каждом месте, где может случится ошибка. А для реализации исключений достаточно запихивать в стек при вызове метода указатель на таблицу обработчиков. И только если произойдет исключительная ситуация, нужно будет пробежаться по стеку и обработчикам.
> Надеюсь и не придется.
Таким образом, ты, скорее всего, не знаком с задачами, которые приходится решать в таких случаях и не понимаешь, почему там нет поддержки исключений (кроме setjmp/longjmp). Тем не менее, это не помешало тебе делать _общие_ утверждения вроде:
> Непосредственно сами исключения на производительность влияют только положительно.
Это не всегда так. _Могут_ влиять положительно и не более того. А поскольку исключения _всегда_ увеличивают размер программы (даже по сравнению с явными проверками тем самым увеличивая нагрузку на кэш, они _могут_ сильно снизить общую производительность, даже если в каком-то блоке её увеличат.
Также стоит учесть, что в разных архитектурах (ты ведь только для x86 пишешь, так?) стоимость исключений сильно разнится (это предполагая их "идеальные" реализации, что, очевидно, не всегда имеет место).
Таким образом, ты, скорее всего, не знаком с задачами, которые приходится решать в таких случаях и не понимаешь, почему там нет поддержки исключений (кроме setjmp/longjmp). Тем не менее, это не помешало тебе делать _общие_ утверждения вроде:
> Непосредственно сами исключения на производительность влияют только положительно.
Это не всегда так. _Могут_ влиять положительно и не более того. А поскольку исключения _всегда_ увеличивают размер программы (даже по сравнению с явными проверками тем самым увеличивая нагрузку на кэш, они _могут_ сильно снизить общую производительность, даже если в каком-то блоке её увеличат.
Также стоит учесть, что в разных архитектурах (ты ведь только для x86 пишешь, так?) стоимость исключений сильно разнится (это предполагая их "идеальные" реализации, что, очевидно, не всегда имеет место).
Исключения, по крайней мере в гнутой реализации, требуют выделения определенной структуры на стеке при каждом входе в функцию. При сверхглубокой рекурсии это сказывается не только на производительности, но и на работоспособности программ.
один указатель -- это много?
Там больше. Но даже один указатель - уже много. При ограниченном стеке и очень легкой функции.
Блядь, какого хера в ДоДиезе такие тормозные исключения?
Склоняюсь к "ХРЕЗАЛТУ".
Склоняюсь к "ХРЕЗАЛТУ".
Очень легкая функция скорее всего может быть объявлена как throw .
А вот интересно, что будет быстрее:
или
try
{
for
{
do_step;
}
}
catch( blablabla )
{
}
или
for
{
if ( !do_step )
{
break;
}
}
В каком случае тормозные? Пока не произошла исключительная ситуация оверхед нулевой, вроде, там даже этот указатель в стеке ссылается на информацию о методе, которая используется в том числе и GC. А случаться исключительные ситуации должны редко, на то они и исключительные ситуации. Плюс в редких случаях всегда можно обойтись и без них, если возникают проблемы с производительностью (например, Parse и TryParse).
Еще можно расширить твой пример, когда в do_step еще несколько уровней подшагов, в каждом нужно будет делать проверку на ошибку. Получиться больше проверок на одну итерацию цикла
В додиезе только первый вылет исключения мило тормозит. Подозреваю, что в этот момент подключаются библиотечки и докомпиливается код. Дальше они весьма быстры. Int.TryParse, кстати, ловит исключение =)
Во втором фреймворке они должны быть ещё быстрее.
С целью оптимизировать что-то там можешь кинуть исключение на старте проги =) Int.TryParse("Хуй" например.
Во втором фреймворке они должны быть ещё быстрее.
С целью оптимизировать что-то там можешь кинуть исключение на старте проги =) Int.TryParse("Хуй" например.
> Да, на верхнем уровне - такие системы/технологии уже есть.
> У microsoft-а - это MTS.
Есть чё почитать хорошее?
Там возможны различные состояния объектов в конкурентных транзакциях? Или это не ОО-шняга?
> У microsoft-а - это MTS.
Есть чё почитать хорошее?
Там возможны различные состояния объектов в конкурентных транзакциях? Или это не ОО-шняга?
Уже нашёл.
Опять не то (с)
Опять не то (с)
> На мой взгляд, четко видно - что с увеличением производительности, а также
> с развитем программирования - высокоуровневые системы
> программирования все сильнее и сильнее заменяют низкоуровневые, т.к.
> высокоуровневые системы меньше требует человекоресурсов при гораздо
> большем "выхлопе".
> Вы с этим согласны?
Частично.
То есть да, системы становятся всё более высокоуровневыми в смысле того, что всё больше толщина обёрток "над железом". Но не всегда это происходит для оптимизации использования "человекоресурсов".
Как правило, по моим наблюдениям, обёртки используются просто потому, что они есть, и есть некоторая культура обращения с ними, а культура обращения с низким уровням менее распространена, а в некоторых аспектах - и утеряна.
Культура развивается по своим законам, а оптимизация - постольку поскольку.
> с развитем программирования - высокоуровневые системы
> программирования все сильнее и сильнее заменяют низкоуровневые, т.к.
> высокоуровневые системы меньше требует человекоресурсов при гораздо
> большем "выхлопе".
> Вы с этим согласны?
Частично.
То есть да, системы становятся всё более высокоуровневыми в смысле того, что всё больше толщина обёрток "над железом". Но не всегда это происходит для оптимизации использования "человекоресурсов".
Как правило, по моим наблюдениям, обёртки используются просто потому, что они есть, и есть некоторая культура обращения с ними, а культура обращения с низким уровням менее распространена, а в некоторых аспектах - и утеряна.
Культура развивается по своим законам, а оптимизация - постольку поскольку.
Оставить комментарий
Elina74
MS VC++MS VB
Пардон, я дико извиняюсь, но зачем писать на этом? Более того, зачем заставлять людей на втором курсе писать проги на VC++?