Здравствуйте, merk, Вы писали:

M>каким образом по-вашему стороннее приложение может завершить другое, через нехватку памяти? через захват общей памяти системы? тогда его, стороннее, обязана завершить ос. чтобы не баловалось.

OS вообще-то разные бывают...

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, merk, Вы писали:

M>>каким образом по-вашему стороннее приложение может завершить другое, через нехватку памяти? через захват общей памяти системы? тогда его, стороннее, обязана завершить ос. чтобы не баловалось.

E>OS вообще-то разные бывают...
Егор, ваши знания поистине безграничны.

Здравствуйте, merk, Вы писали:

E>>OS вообще-то разные бывают...
M>Егор, ваши знания поистине безграничны.
Это смотря с чьими сравнивать...

Но в целом ты меня поразил глубиной своих познаний...

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, merk, Вы писали:

E>>>OS вообще-то разные бывают...
M>>Егор, ваши знания поистине безграничны.
E>Это смотря с чьими сравнивать...

E>Но в целом ты меня поразил глубиной своих познаний...

егор, вы приблизительно помните название топика?

Здравствуйте, merk, Вы писали:

M>егор, вы приблизительно помните название топика?
Что-то про анотомию плохих тонцоров?
Но в целом вроде как ты, конкретно, развивал тему про вредоносность программистов использующих исключения для чего-то кроме авоста...
Или я тебя как-то не так понял?

Здравствуйте, IROV.., Вы писали:

IRO>Здравствуйте, remark, Вы писали:

R>>Что Вам мешает в С++?
IRO>Отсутствие приватных методов и членнов которые бы не были видны в .hpp фаилах. Например.

IRO>Foo.hpp
IRO>

IRO>class Foo
IRO>{
IRO>public:
IRO>  void print();
IRO>};
IRO>

IRO>Foo.cpp
IRO>

IRO>private int Foo::m_params;

IRO>private void Foo::print_impl( int _p )
IRO>{
IRO> ...
IRO>}

IRO>void Foo::print()
IRO>{
  this->>print_impl( this->m_params );
IRO>}
IRO>

R>>
IRO>

тут проблема в том, что компайлер по декларации класса вычисляет его размер. а если будет браться экземпляр класса, например как поле нового класса, то физразмер поля нужен обязатно. но если только поинтер, то физразмер необязатно.
проблема может быть решена только разбиением представления класса на видимые поля и сцылу(указатель) на невидимые поля в обьекте класса.соответсвенно при доступе к невидимым нужна дополнительная косвенность. сами невидимые будут располагаться где-то вне обьекта данного класса, состоящего из видимых полей.
поскольку в С++ невидимость может быть нарушена например френдами, то для компиляции френдов скрытые поля все равно нужно как-то открыть, а их из хидеров не видно... или отказаться от френдов вообще.
короче даже если страструп и думал бы над этим, все это запутало и без того не особо распутанный его концепт.

Здравствуйте, merk, Вы писали:

M>короче даже если страструп и думал бы над этим, все это запутало и без того не особо распутанный его концепт.

Вообще-то можно было бы просто использовать недовычесленные выражения, вроде "размер того-то + рамер того-то +..."
А при линковке всё досчитывать и генерить код окончательно.

свою редакцию стандарта пишешь?

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, merk, Вы писали:

M>>короче даже если страструп и думал бы над этим, все это запутало и без того не особо распутанный его концепт.

E>Вообще-то можно было бы просто использовать недовычесленные выражения, вроде "размер того-то + рамер того-то +..."
E>А при линковке всё досчитывать и генерить код окончательно.

а если обьект получается из dll? компилятор вообще его размера не знает, что-ли? ну там в поля ему залезть?
рекомендация — положить видимые первыми, не проходит если у вас есть наследник от такого класса. в наследнике между видимыми предка и видимыми наследника будут невидимые предка.

еще. поскольку в С++ нет модулей, то к одному хидеру может идти несколько реализаций, или реализация может быть растащена на много файлов. скрытые поля по сути недекларированы в хидере и могут быть получаиццо обьявлены где-то. в неограниченном количестве, в неограниченном количестве файлов. скрытые поля являются суммой всех найденных обьявлений? или могут быть обьявлены только в одном файле? но в С++ такого выделенного файла нет. значит сумма.

Здравствуйте, merk, Вы писали:

M>а если обьект получается из dll? компилятор вообще его размера не знает, что-ли? ну там в поля ему залезть?
M>рекомендация — положить видимые первыми, не проходит если у вас есть наследник от такого класса. в наследнике между видимыми предка и видимыми наследника будут невидимые предка.
Ну и что? Ну экспортировался бы из dll ещё и какой-то описатель приватной части объектов? Ты же просто символы из DLL экспортируешь? Почему лэйаут объектов нельзя?

M>еще. поскольку в С++ нет модулей, то к одному хидеру может идти несколько реализаций, или реализация может быть растащена на много файлов. скрытые поля по сути недекларированы в хидере и могут быть получаиццо обьявлены где-то. в неограниченном количестве, в неограниченном количестве файлов. скрытые поля являются суммой всех найденных обьявлений? или могут быть обьявлены только в одном файле? но в С++ такого выделенного файла нет. значит сумма.

Ну будет нарушение ODR. Как будто что-то новое в этом есть

В целом, при желании, можно прямо сейчас доработать С++ напильником до того, чтобы приватную часть класса не показывать. Типа пишешь какой-то хедер, в котором только публичный интерфейс + ещё один файл особого вида, где есть полное описание. Из этого файла это описание экспортируется в другие единицы трансляции и всё. Каких-то непреодолимых особо пролем нет. Просто это не особо кому-то надо

Здравствуйте, merk, Вы писали:

M>я бы вам посоветовал все таки спасаться. поскольку без памяти программы обычно не работают. выташите все модули памяти из компа и перезагрузитесь.

Отличный пример Я услышу звуковые сигналы "нет памяти". Если бы разработчики BIOS следовали "спасительному правилу", был бы бесконечный цикл попыток загрузки

M>каким образом по-вашему стороннее приложение может завершить другое, через нехватку памяти? через захват общей памяти системы?

Например, да. Главное, что если какие-то способы неизвестны, это не значит, что их нет. Не в тему, но для развития фантазии можно погуглить, как Joanna Rutkowska загружала код в ядро Vista.

M>тогда его, стороннее, обязана завершить ос. чтобы не баловалось.

На каком основании? Запрос памяти приложением — лагальное действие.

Здравствуйте, Erop, Вы писали:

E>Ну и что? Ну экспортировался бы из dll ещё и какой-то описатель приватной части объектов? Ты же просто символы из DLL экспортируешь? Почему лэйаут объектов нельзя?

то есть dll ный загрузчик будет еще и с размерами в программе разбираццо?
смело шагает маладешь к виртуальным машинам!

E>Ну будет нарушение ODR. Как будто что-то новое в этом есть
никакого нарушения одр. разные поля в разных файлах. реально декларацию класса придется собирать по кускам из произвольного множества файлов.

E>В целом, при желании, можно прямо сейчас доработать С++ напильником до того, чтобы приватную часть класса не показывать. Типа пишешь какой-то хедер, в котором только публичный интерфейс + ещё один файл особого вида, где есть полное описание. Из этого файла это описание экспортируется в другие единицы трансляции и всё. Каких-то непреодолимых особо пролем нет. Просто это не особо кому-то надо
это как раз особо и надо. в частности для простецкой реализации приблуды типа фасад. да и вообще удобного сокрытия. вот только делать это нужно ручками, рисуя поинтер либо на раелизующий класс, либо скрытые поля, например. попытка разместить эт она стеке будет ужасающей по производительности, за счет размещения части обьекта на куче.
клиент желает истинного сокрытия своих полей от потребителя класса. а если есть какой-то "файл специального вида", то он доступен потребителю. в данном случае — "другие единицы трансляции" это именно файлы потребителя.
также будет невозможно писать реализации отдельных методов класса прямо в хидере, поскольку в нем приватных полей нет.
напильник у меня есть, могу подарить. но чем больше рассуждений тута, тем ближе мы становимся к интеллектуальным загрузчикам и всяким там джитам.

Здравствуйте, gear nuke, Вы писали:

GN>Здравствуйте, merk, Вы писали:

M>>я бы вам посоветовал все таки спасаться. поскольку без памяти программы обычно не работают. выташите все модули памяти из компа и перезагрузитесь.

GN>Отличный пример Я услышу звуковые сигналы "нет памяти". Если бы разработчики BIOS следовали "спасительному правилу", был бы бесконечный цикл попыток загрузки
биосу тут вообще память не нужна. он из пзу работает. у него не нехватка памяти, а необнаружение нечта. и поскольку он совершенно функционален и без вашей памяти, он вам и пищит.

GN>Например, да. Главное, что если какие-то способы неизвестны, это не значит, что их нет. Не в тему, но для развития фантазии можно погуглить, как Joanna Rutkowska загружала код в ядро Vista.
опять ерунда. приложение от которого требуется особая устойчивость вообще не будет работать в одной среде с вашими левыми программами. это первое. второе то, что вы никакого более разумного общего способа не предложили. на самом деле есть способы сохранения некоей работоспособности, но они очень частные и в общем случае ничего не гарантируют. таким образом не могут рассматриваться как рекомендации.
тогда вы о чем вообще?
да какая разница как эта дама грузила код в ядро виста? причем тут приложение испытываюющее нехватку памяти?
приложение летит на марс на бортовом компьютере..причем тут и виста и рутковска?

M>>тогда его, стороннее, обязана завершить ос. чтобы не баловалось.
GN>На каком основании? Запрос памяти приложением — лагальное действие.
запрос памяти — легальное, но с сохранением неких инвариантов, если вы требуете устойчивую среду. если приложение просит памяти выше некоего соглашения с ним и мешает другим, что не требуют памяти выше соглашения с ними, то виновато первое приложение и система его считает разрушителем инвариантов с вытекающими.

Здравствуйте, merk, Вы писали:

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

M>>А все просто , наверху я могу изменить параметры и попытаться снова или отказаться от операции, все зависит от программы.
M>если у вас недостаток памяти, все ваши трепыхания ни к чему не приведут. см. совет выше.
Как минимум в результате раскрутки стека при выбросе исключения будут уничтожены локальные объекты и это может привести к освобождения памяти(или других ресурсов). Поможет это или нет — другой вопрос.
...
M>>напрмиер в псевдокоде.

M>>void readHeaderFromFile(filename)
M>>{
M>>   file f(filename);
M>>     if(f.error())
M>>     {
M>>        throw ("open file error");
M>>     }
     
M>>     readHeader(f);
M>>}

M>и что? в 100 местах программы вы вызываете эту функцию.
M>и в ста местах программы вы будете ее писать в конструкции
M>try{
M> readHeaderFromFile(filename)
M>} catch ....

M>не утомительно?
M>... любая функция может и часто должна иметь предусловия.
Согласен

M>в вашем случае просто валидность имени файла. не пустое имя, не нуль(если указатель), правильно сформированное. это — ну например.
M>вы ж без проверки, тут же конструируете обьект, обламываетесь например в конструкторе, и всю кучу возможных ошибок, то есть —
M>невалидность имени, факт существования файла, существование файловой системы вообще, заблокированность файла кем-то другим, заблокированность файловой системы и прочие ошибки ввода вывода... завернули в исключение "ошибка открытия файла", и кинули наружу.
M>и уже готовы меня убедить, что сможете восстановиться от ошибки.
M>КАК? вы же в реальности не знаете что произошло.

Здесь все смешано в кучу. Не всегда все можно вынести в предусловия: даже если у нас будет функция ПолучитьОбъемДоступнойПамяти — толку от нее нет, поскольку между временем ее вызова и запросом на выделение памяти другой поток/процесс может съесть весь доступный объем. Так же и с открытием файла: нет смысла выносить в предусловие факт его существования. Успешность вызова таких функций определяется "по факту": вызов либо успешен, либо нет.

Предусловия, имхо, лучше делать "типизированными" например, если для имени файла существует валидный паттерн(и его правильность не зависит от окружения), то в первом приближении

void readHeaderFromFile(const std::string& name) 
//можно заменить на:
void readHeaderFromFile(const filename& name)

(существование объекта filename должно гарантировать првавильность имени, которое он содержит)

Дальше: readHeaderFromFile исходя из названия должна читать header, а она еще и открывает файл, а это нарушает принцип разделения обязанностей, поэтому функциональность логичнее разделить на две части, приблизительно так:

void readHeaderFromStream(const InputStream& strm) // "типизированное" предусловие - открытый файл.
+
std::auto_ptr<InputStream> create_file_stream(const filename& name/* или const std::string&, или вообще без аргументов - имя спрашиваем у пользователя*/);

M>если вы будете проверять предусловия(когда-нить в жизни), вы будете тоже генерить исключения???
Поскольку не сказано чьи предусловия проверяются(и где это происходит), то возможны два случая:

1) проверка собственных предусловий внутри функций: — только assert и никаких исключений.

2) исключение — это нормальная ситуация, если(и только если)
* это происходит _перед_ вызовом функции чьи предусловия проверяются, и
* невозможность вызова функции(чьи предусловия проверяются) является исключительной ситуацией для вызывающего


M>тогда вызов каждой функции будете делать в блоке try{} что-ли??? не утомительный ли стиль?
Только там где исключение нужно обработать.

M>короче. вот тут наткнулся на какое-то руководство... ну совершенно согласен с автором. особенно обратите внимание на конец страницы — 11.5. Исключения и вопросы проектирования
M>http://valera.asf.ru/cpp/book/c11.shtml
Видимо после таких статей и возникает желание оборачивать каждый вызов в try/catch.

Здравствуйте, gear nuke, Вы писали:

G_K>>LOL я то глупый думал, что макросы да шаблоны как раз предназначены для уменьшения писанины

GN>Верно, клиентский код сокращается, но из этого совсем не следует. что библиотечный будет автоматически сгенерирован компилятором

Не понял вашу мысль Я вам указал на то, что переплевывание в метапрограммировании при большем количестве писанины выглядит несколько ... смешно
Как впрочем и кроссплатформенные ассемблеры.
Последняя Ваша фраза просто не дошла до сознания. Видимо слишком глубока

Здравствуйте, remark, Вы писали:

R>Регулярно можно слышать критику в адрес С++, что дескать язык морально устаревший, что время разработки на С++ неприлично большое, что в С++ постоянно приходится сражаться с ветряными мельницами. Посему хочется провести следующий опрос среди коллег С++ программистов.

R>Что Вам мешает в С++?

Если говорить о чем то, что именно мешает, а не о фичах, которые хотелось бы.

1. Это RTTI (Run Time Type Information). В таком языке как C++ лучще бы смотрелся CTTI (Compile Time Type Information). Т.е. нужно больше информации о типе в compile time, что это за тип, какие у него функции/свойства, как называется, номер (UUID какой нибудь) и т.п. А какой то специфичный RTTI я и сам из этого сделаю.

Здравствуйте, Аноним, Вы писали:

I>>Ну и в догонку, что мешает. Бинарная несовместимость — библиотеку построенную одним компилятором не прикрутишь в другому
А>Как вы себе представляете прикручивание библиотеки скомпиленной под IA64 в проект для arm'а какого нить?

Ну не нужно же передергивать!

merk пишет:
> E>Ну будет нарушение ODR. Как будто что-то новое в этом есть
> никакого нарушения одр. разные поля в разных файлах. реально декларацию
> класса придется собирать по кускам из произвольного множества файлов.

Зачем произвольного? Ограничить одним — получится всем знакомое ODR.

> E>В целом, при желании, можно прямо сейчас доработать С++ напильником до
> того, чтобы приватную часть класса не показывать. Типа пишешь какой-то
> хедер, в котором только публичный интерфейс + ещё один файл особого
> вида, где есть полное описание. Из этого файла это описание
> экспортируется в другие единицы трансляции и всё. Каких-то непреодолимых
> особо пролем нет. Просто это не особо кому-то надо
> это как раз особо и надо. в частности для простецкой реализации приблуды
> типа фасад. да и вообще удобного сокрытия. вот только делать это нужно
> ручками, рисуя поинтер либо на раелизующий класс, либо скрытые поля,
> например. попытка разместить эт она стеке будет ужасающей по
> производительности, за счет размещения части обьекта на куче.

Не надо ничего в куче размещать, функцию alloca никто пока не отменял.

> клиент желает истинного сокрытия своих полей от потребителя класса. а
> если есть какой-то "файл специального вида", то он доступен потребителю.
> в данном случае — "другие единицы трансляции" это именно файлы потребителя.

С++ должен защищать от дурака, а не от террориста Так что с этим
вполне нормально.

> также будет невозможно писать реализации отдельных методов класса прямо
> в хидере, поскольку в нем приватных полей нет.

Для приватных-скрытых можно ввести отдельную декларацию, типа

private extern:

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

Тут главное чтобы до сборки мусора дело не дошло

Здравствуйте, merk, Вы писали:

M>то есть dll ный загрузчик будет еще и с размерами в программе разбираццо?
Зачем? Это может быть просто частью интерфейса DLL. Если интерфейс устаревает, то надо пересобрать клиента. Это всего лишь вопрос того, насколько широко ты готов продвинуться по пути сокрытия подробностей реализации класса от его клиентов.

M>смело шагает маладешь к виртуальным машинам!
Это ты про Вирта что ли?

Здравствуйте, Sergey, Вы писали:

S>Не надо ничего в куче размещать, функцию alloca никто пока не отменял.
не настолько знаю С++ чтобы автоматически распознать, где обьявляется переменная данного класса.
если она обьявляется глобально — скрытую часть нужно помещать в кучу.
если локально — можно на стеке
если делается по new — опять в куче.

>> клиент желает истинного сокрытия своих полей от потребителя класса. а
>> если есть какой-то "файл специального вида", то он доступен потребителю.
>> в данном случае — "другие единицы трансляции" это именно файлы потребителя.

S>С++ должен защищать от дурака, а не от террориста Так что с этим
S>вполне нормально.

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

>> также будет невозможно писать реализации отдельных методов класса прямо
>> в хидере, поскольку в нем приватных полей нет.

S>Для приватных-скрытых можно ввести отдельную декларацию, типа
S>

private extern:

private extern — что? нужно сделать так чтобы там не было никаких имен.
опять же из соображений общности, аналогичный ход можно сделать и в отношении приватных виртуальных методов.
то есть убрать их из интерфейса. тогда компилятор извне не сможет понять индексы публичных виртметодов в виртуальной таблице.

в принципе, если б делать язык с нуля, нужно ввести модули и генерацию "хидера" из текста модуля. то есть интерфейс составляется автоматически компилятором и не пишется руками вообще.
тогда сокрытие, по простому выражалось бы так
в сгенерированном интерфейсе модуля стояло бы, ну например
class A
{
hidden[60]; //60 hidden bytes
int a; //public
int b; //public
virtual f(int fx)[20] //это обьявление публичной вирт функции и обьявление ее смещения в вирт таблице
virtual ff()[32] //еще публ.вирт функция со смещением
}

по такому описанию компилятор извне работал бы спокойно и размер типа известен и смещения виртметодов.