F-22: «Хищники» опозорили Америку

Mishka> Basic превращался в BАСИЦ (транслитерация). Device ready — DЕВИЦЫ РЕАДЫ (что служило предметом многочисленных шуток).

Это еще не самое прикольное Вот ще из перлов:

ИЛЛЕЖАЛ ДВИЦЕ

ну и абсолютный лидер приколов ЕЬИТ

Mishka> Забавно, а какое решение предложите Вы, когда не хватит памяти в программе для управления железом? Были у нас тяжёлые споры на эту тему с Владом (Сергей знает). Кучу статей нарыли, обсуждали. Надо будет покапаться, да найти их и выложить.

Да не забавно это. Стандарт С++ , выпущенный аж в 1998 году четко оговаривает поведение данной формы new. И практически все используемые компиляторы стараются его поддерживать. И он , стандарт, утверждает, что при ошибке связанной с выделением памяти new должен генерить exception bad_alloc. Отсюда следует, что код в if никогда выполнен не будет. И при ошибке нужно просто ловить исключение.

try {
char* pchar = new char[size];
...
}
catch( exception& ex )
{
cout << ex.what() << endl;
}

А если уж очень хочется использовать if, то и это невозбраняется стандартом. Для этого есть специальная форма new

char* pchar = new(nothrow) char[size];
if( !pchar) {
cout << "Error" << endl;
return 1;
}

Меня удивляет здесь другое. Но ладно я, который помнит еще "доисторические" компиляторы, у которых new возвращал NULL. Но откуда эта "доисторическая" память у молодых программистов? Кстати свои первые опыты по программированию я начинал еще на ДВК-2 с RT11SJ на паскалевском компиляторе от самого Вирта
Кстати об ошибках. RSX11 генерилась из дистрибутива и ей можно было подсунуть свой текст ошибок. Ну и ребята изголялись как могли. И я раз наблюдал такую картину: рядом девушка за терминалом вдруг покраснела, вскочила и убежала в слезах. Я подошел к терминалу и прочел текст ошибки "Не суетись под клиентом, клиент потеет". Перед девушкой потом долго извинялись, даже перегенерили систему, но к терминалу она больше не подходила

Vyacheslav> Да не забавно это. Стандарт С++ , выпущенный аж в 1998 году

Какая жалость, что я последний серьёзный проект на С++ писал в 1997-м году

Vyacheslav> Да не забавно это. Стандарт С++ , выпущенный аж в 1998 году четко оговаривает поведение данной формы new.

Начнём с того, что есть новый — 2003 года.

Vyacheslav> И практически все используемые компиляторы стараются его поддерживать. И он , стандарт, утверждает, что при ошибке связанной с выделением памяти new должен генерить exception bad_alloc. Отсюда следует, что код в if никогда выполнен не будет. И при ошибке нужно просто ловить исключение.

Смотрите выдержки из стандарта 2003 года. Я не имею полных сведений о вашей программе, но но необязательно так. Во-первых, программист может определить displacement function со спецификацией throw() и тогда никакого эксепшина нет. Во-вторых, программист может переопределить оператор new-delete. И это всё в рамках стандарта. Стандарт 1998 года в

Vyacheslav> try {
Vyacheslav> char* pchar = new char[size];
Vyacheslav> ...
Vyacheslav> }
Vyacheslav> catch( exception& ex )
Vyacheslav> {
Vyacheslav> cout << ex.what() << endl;
Vyacheslav> }
Vyacheslav> А если уж очень хочется использовать if, то и это невозбраняется стандартом. Для этого есть специальная форма new
Vyacheslav> char* pchar = new(nothrow) char[size];
Vyacheslav> if( !pchar) {
Vyacheslav> cout << "Error" << endl;
Vyacheslav> return 1;
Vyacheslav> }
Vyacheslav> Меня удивляет здесь другое. Но ладно я, который помнит еще "доисторические" компиляторы, у которых new возвращал NULL. Но откуда эта "доисторическая" память у молодых программистов? Кстати свои первые опыты по программированию я начинал еще на ДВК-2 с RT11SJ на паскалевском компиляторе от самого Вирта

У многих компиляторов есть параметр, который это дело регулирует. И память не доисторическая (хотя тем, кто программировал на MS VC 6 — ещё долго будет икаться), это просто не знание и не принятие в усмотрение exceptions.

Vyacheslav> Кстати об ошибках. RSX11 генерилась из дистрибутива и ей можно было подсунуть свой текст ошибок. Ну и ребята изголялись как могли. И я раз наблюдал такую картину: рядом девушка за терминалом вдруг покраснела, вскочила и убежала в слезах. Я подошел к терминалу и прочел текст ошибки "Не суетись под клиентом, клиент потеет". Перед девушкой потом долго извинялись, даже перегенерили систему, но к терминалу она больше не подходила

Полностью звучит, вроде, так: Не суетись под клиентом — клиент потеет и соскальзыает.

Я когда-то в run-time library для Алгола 68 для PC написал строчку, которая выдавалась в ответ на Ctrl-C или Ctrl-Break — "Пользователь нажал на педаль!". За что получил от шефа немного по мозгам. Хотя сообщение оставили — лаба была за.

Mishka> Я когда-то в run-time library для Алгола 68 для PC написал строчку, которая выдавалась в ответ на Ctrl-C или Ctrl-Break — "Пользователь нажал на педаль!".

Мы как-то в FoxPro в универе заменили промпт на "Invalid command!". А потом позвали нашу преподавательницу по базам данных поглядеть, что мы не так делаем. Тоже было очень познавательно.

grOOmi> Почитал Авиафорум. Опух слегка. Вы чего народ, все программеры?
grOOmi> Нихрена не понял о чем тут вообще.

Много нас тут. И такие есть, которые писали софт к плавюще-летающим частям. Вот и спор примерно на эту тему — как обеспечение софта того же самолёта сделать надёжным. Впрочем, не только софта, но и пример инженерного уровня решения задач.

Serhio> Для общего развития мне двух лет изучения фортрана на ЕС-1036 хватило по самые уши

Ну вот видишь, считай повезло . А я только ассемблер 5Э26-го ЦВК подробно учил (остальное — неподробно). Поэтому мне интересно.

тут был дубль

Serhio> Для общего развития мне двух лет изучения фортрана на ЕС-1036 хватило по самые уши

нууу.. это не общее, это как раз очень частное к тому же не очень характерное Впрочем, я открещусь от стана программистов, бо уже десять (е-мое дейсвтиельно 10!) сам программок всерьез не пишу, все эти годы занимался общей архитектурой системы. И, слава богу, уже девять месяцев почти никак именно с разработкой софта уже не связан Пока больше и не хочется - наслаждаюсь "собиранием САПР из готовых кубиков"...

Mishka>. Во-первых, программист может определить displacement function со спецификацией throw() и тогда никакого эксепшина нет. Во-вторых, программист может переопределить оператор new-delete. И это всё в рамках стандарта. Стандарт 1998 года


Да ради бога. Конечно ему никто не запрещает переопределить. Только причем тут это. Я же когда спрашивал, не выдавал вводную о наличии переопределенного new. Мы же не об этом, а об этом :
Mishka> это просто не знание и не принятие в усмотрение exceptions.

Причем это "незнание" и "непринятие" иногда проявляют программисты, программы которых работают в весьма критичных областях. А почему же это не выплывает? Да потому что даже настольные компьютеры в настоящее время владеют весьма впечатляющими ресурсами, что реально схлопотать bad_alloc весьма проблематично. Это из серьезной ошибки превратилось в большинстве случаев в просто небрежность и таких небрежностей пруд пруди. Сейчас иногда не можно увидеть, что не удосуживаются на каждый new вызывать delete, или на new[] вызывают просто delete. Раньше при хилых ресурсах это бы непременно бы всплыло, а сейчас Win32 при завершеннии такого приложения сам освободит .
Прогресс.
Это кстати , напоминает мне ситуацию с конструктарами и конструкторской документацией.
Как сущесвует понятие для программиста "красивый код", так в приниципе существует понятие (по крайней мере для меня) : "красивый чертеж" , который определется размещением видов на формате, показом размеров, который более "читаем" и пр. Так в свое время я заметил, что у тех инжернеров, кто учился тогда, когда чертежи надо было обязательно чертить тушью чертежи выходили более "красивыс

Vyacheslav> Да ради бога. Конечно ему никто не запрещает переопределить. Только причем тут это. Я же когда спрашивал, не выдавал вводную о наличии переопределенного new. Мы же не об этом, а об этом :

Displacement — это немного другое. Плюс, я не берусь судить о фрагментах кода, когда по ним нельзя 100% сказать. Может в компиляторе кто прагму определил напрямую или параметром передал, может просто специальный параметр использовали. Может тот самый дисплейсмент сделали. В всех этих случаях фрагмент будет выполнятся нормально без всякого эксепшена.

Vyacheslav> Да потому что даже настольные компьютеры в настоящее время владеют весьма впечатляющими ресурсами, что реально схлопотать bad_alloc весьма проблематично.

Не знаю у кого как — у меня регулярно не хватает памяти. На прошлой работе и 32 гигов не хватало. А что делать?

Vyacheslav> Сейчас иногда не можно увидеть, что не удосуживаются на каждый new вызывать delete

Ну, это типичный memory leak — чем Java и хороша — там его нет в принципе.

Vyacheslav> , или на new[] вызывают просто delete.

А вот на это приличный компилятор с прилично rtl должны выругатся.

Vyacheslav> Раньше при хилых ресурсах это бы непременно бы всплыло, а сейчас Win32 при завершеннии такого приложения сам освободит .

Забавно рассуждаете — а когда так не было (не включая MS DOS)? ОС всегда рессурсы освобождала после завершения задачи. Чтобы получить рессурсы с диапазоном жизни (scope) больше, чем жизнь процесса — надо специально постараться. Тот же файл (директория — частный случай) — надо его создать, shared memory — то же самое, создатЬ, другой процесс — ещё один специализированный API.

Mishka> Забавно рассуждаете — а когда так не было (не включая MS DOS)? ОС всегда рессурсы освобождала после завершения задачи.

MS DOS не была исключением. Чтобы DOS не освободила выделенную программе память, нужно было выходить по прерыванию TSR. При обычном завершении - освобождала

Mishka> Я тебе один умный вещь скажу — я всегда выходил по нормальному и всегда оставлял память за собой.

Хм. Странно. То ли я уже совсем забыл элементарные вещи, то ли ты какими-то хитростями пользовался

Mishka>> Я тебе один умный вещь скажу — я всегда выходил по нормальному и всегда оставлял память за собой.
Balancer> Хм. Странно. То ли я уже совсем забыл элементарные вещи, то ли ты какими-то хитростями пользовался

Да какие хитрости, поскольку RTL для Алгола 68 на РС была моя часть, то я как бы знал как ОС размещает память. Защиты никакой, вот я и лазил по всей памяти. Подправить блок управления памятью ничего не стоило — он начинался со специальных буковок, а потом шёл размер. Через начало блока + размер ты должен был либо обнаружить последний блок, либо ещё один. Для свободной памяти специальная метка. При запросе на размещение памяти MS DOS искал первый подходящий блок (поэтому, при использовании HIGH MEM драйвера и LOADHIMEM ты мог указать в точности место, куда посадить программки — иначе в первое попавшееся место). Была ещё одна особенность у TSR окончания — MS DOS пыталась восстановить некоторые прерывания. Вот и пришлось написать маленькую процедурку, которая это всё заменяла. А потом ею и пользовался.

Mishka> Подправить блок управления памятью ничего не стоило

Так вот это - и есть "хитрость". Естественно, защиты у MS-DOS никакой не было. Но при работе штатными средствами, если ты ничего сам не менял в потрохах, память она потом отданную программе чистила.

А уж как мы с MCB (memory control block) ручками работали или цепочками прерываний - это уже отдельная песТня

В.М.> нууу.. это не общее, это как раз очень частное к тому же не очень характерное Впрочем, я открещусь от стана программистов, бо уже десять (е-мое дейсвтиельно 10!) сам программок всерьез не пишу, все эти годы занимался общей архитектурой системы. И, слава богу, уже девять месяцев почти никак именно с разработкой софта уже не связан Пока больше и не хочется - наслаждаюсь "собиранием САПР из готовых кубиков"...
Владимир, а может каааак бааааабахнем страниц так эндцать разговора о САПРе, ну в пику так сказать