Здравствуйте, Cyberax, Вы писали:
C>Я слабо представляю библиотеку для работы с многопоточностью без примитивов синхронизации. Ну кроме Erlang'а, разве что.
Я не про библиотеку а про язык, что бы атомарные операции были частью языка. И потом язык программирования не обязан быть только алгоритмическим.
C>Причём тут процессы? Ты вообще понимаешь, что выход из потока и завершение программы с помощью управляющего сигнала — это вообще разные действия?
Простая задача у тебя сотня потоков и тебе надо остановить половину, причем немедленно. и так что бы все созданные объекты умерли своей смертью. ваши действия? а если многопоточность есть в языке эта ситуация должна быть расписана.
_>>Что непонятного, генерация исключения в потоку самый простой и очевидный способ его завершения для C++ c его объектами, разве не так? C>Не так. Это неправильный подход.
Нет это именно так. Только вызов исключения, других путей для C++ пока просто нет.
C>Т.е. "thread_local SomeObject var;"
+1 учту. особенно в ситуации что многопоточности в стандарте не будет.
C>>>http://en.wikipedia.org/wiki/C%2B%2B0x#Thread-local_storage ? _>>И еще докле мы будем в качестве конструктора и деструктора писать имя класса???? почему нельзя зарезервировать имена типа ctor и dtor??? C>А зачем?
Сам подумай. Тебе надо поменять название класса. Тебе приходиться менять имена во многих местах. Просто нелогично и не удобно. И потом наличие пред деструктора и после конструктора особенно как виртуальных функций было бы замечательным явлением, но это мечты.
C>>>Как ты это решишь "компилятором"? Деление на ноль — это аппаратная ошибка, компилятор о ней ничего не знает. В Линуксе она вызывает соответствующий сигнал. _>>Ха. так что мешает компилятору генерить код который позволяет преобразовать сигнал в исключение??? C>Из-за того, что это невозможно сделать корректно в общем случае.
Лошь и провакация. Можно.
_>>ведь из обработчика сигнала мы спокойно можем передать управление в любую точку программы, в том числе и на вызов исключения. (единственное что gcc генерит очень забавный код который не позволяет генерить исключения где угодно). Если интересно могу подробно в деталях рассказать как сделать, если интересно. C>Я прекрасно знаю как работает SEH, table-driven exceptions в GCC и почему асинхронные исключения в MSVC — плохая вещь.
Да вы все сговорились. Вы похожи на тех кто делал dos extender-ы для 32bit protected mode. нет чтоб обработку прерывание передавать в пользовательский код они его обрабатывали сразу по приходу в отдельном стеке, чем связали руки не только себе.
MSVC плохая вешь, а table-driven exception просто замечательная. да вы сума сошли. выпиши в столбик недостатки и преимущества и ты удивишься.
Если после обработки подобных исключений в M$ всё работает, а в Linux выскакивает патрульное приложение и сообщает о скоропостижной смерти дочернего процесса и предлагает вам капнуть разработчикам или просто перезапустить процесс. Я вас непонимаю. Нормальная обработка исключений возможно в сколь угодно убогой оси.
C>Ничего он не должен... Обращение по нулевому указателю и деление на ноль — это ОШИБКИ. Точно такая же, как обращение к удаленному объекту.
Как вас переубедить. Что любое событие можно преобразовать в последовательность действий? В том числе и ошибки можно обрабатывать с помощью исключений.
C>Их можно сделать штатным поведением, но это потребует слишком больших жертв в скорости и простоте C++.
Ничего подобного. Никаких жертв, всё довольно просто и естественно. Да и потом кто бы говорил о простоте с таким стандартом.
... C>Мда. Даже комментировать не буду — смешно.
тогда прокоментируй почему в стандарте есть char16_t char32_t, но нет int16, int32, int64 ???? или хотя бы std::float32_t ?
C>>>Да, можно и без пространств имён обойтись — если делать префиксы к каждому имени. Ну как в SVN API, например: svn_get_status(..), svn_list_files(). Ничего не ... _>>а поумолчанию не включать namespace? _>>Да чусвствую щас приведёте кучу примеров почему нельзя, но все они связаны именно с тем что объектники так генеряться. C>Нет. Есть такое хорошее правило — не делать опасные действия по умолчанию или неявно. Твой пример очень грубо этот принцип нарушает.
да точно давайте на всё натянем колючую проволку и везде поставим капканы и растяжки и рассуём всё по наймспейсам что бы программист себя чуствовал как на минном поле на территории врага.
C>>>В любом другом языке так же. Нужно изучить кучу всякого ненужного, чтобы написать любую нормальную программу. _>>Я не спорю, что нужно долго учится, но метапрограмирование на templata-ах это не то чему надо учиться. C>Почему? Полезная вещь. Например, у меня библиотека контейнеров написана на них. Она работает быстрее стандартных string/vector/list. C>Да, в Стандарт её включить нельзя из-за того, что я её затачивал только под свои задачи.
Очень удевлён столько ненужного уже есть в C++ и сколько обещают в C++0x
C>>>Я не пробовал. Но компиляторы на базе Комо видел самолично. А еще есть LLVM-C, там на выходе вообще почти что ассемблер, записаный на С. Его вообще кто угодно скомпилирует. _>>Ёмоё. так останется только компилятор комо, и все его баги будут включены в стандарт, ибо без них все имеющиеся библиотеки и программы работать не будут. C>Почему?
Монополия никчему хорошему не приводит.
C>Пробовал как-то для экспериментов. См.: ftp://ftp.axis.se/pub/users/hp/pgccfd/pgccfd-0.5.pdf
раз всё так просто помоги людям: http://propeller.wikispaces.com/Programming+in+C C>Или просто посмотри простые md-файлы в GCC.
Скорее всего всё равно придётся писать на чистом C с ассемблерными вставками, как и раньше.
C>>>Потому как с double'ом ты требуешь наличия сопроцессора или его эмуляции. Например, на MIPS'е где я использую boost::thread сопроцессора нет, а эмуляцию мне ставить не хочется. Функции getSleepPrecision() нет потому, что её нет в обычных threading API — в Windows и POSIX Threads гарантируется только, что sleep() будет работать не меньше указанного времени. _>>Эмуляции испугался, а буст за собой таскаеш C>Те части Boost'а, которые я использую, имеют размер в килобайты.
Эмуляция double 2.5-4кб но это тебя безусловно пугает сильнее чем operator"Suffix". А вот double мы досих пор опасаемся. Пользуясь бустом бояться чисел с плавающей точкой. Просто фобия какая-то, аж смешно double и float был даже в C где нет апаратной поддержки применяется эмуляция и это всё в стандарте есть.
C>Ага, чтобы пользователи double'а получили много неприятных сюрпризов. точно реализацию писали индусы и ты не опускаешся до таких сложных и непредсказуемых типов, а complex и quaternion придумали вообще еретики. Не понимающие как всё это тормозит
C>Вот видишь, сколько твоё решение добавляет сложности, вместо простого указания наносекунд?
нет не вижу.
!!повторюсь. Я просто наблюдаю как язык C++ движется в могилу. после 2009 года язык будет называться, хотя скорее всего не язык, а "Стандарт" C++1x, после 2019 C++2x и так далее
Но главное отключить фантазию и ни вкоем случае не пытаться предстаавить язык C++0x.NET
Здравствуйте, kov_serg, Вы писали:
C>>Я слабо представляю библиотеку для работы с многопоточностью без примитивов синхронизации. Ну кроме Erlang'а, разве что. _>Я не про библиотеку а про язык, что бы атомарные операции были частью языка. И потом язык программирования не обязан быть только алгоритмическим.
Когда мне говорят слова "алгоритмический язык [программирования]" — хочется в говорящего бросить тяжёлый предмет.
C>>Причём тут процессы? Ты вообще понимаешь, что выход из потока и завершение программы с помощью управляющего сигнала — это вообще разные действия? _>Простая задача у тебя сотня потоков и тебе надо остановить половину, причем немедленно. и так что бы все созданные объекты умерли своей смертью. ваши действия? а если многопоточность есть в языке эта ситуация должна быть расписана.
Да никак этого не сделать корректно простыми способами. Н_И_К_А_К.
Банально:
void someFunction()
{
char *c=(char*) heap_alloc(1123);
//А вот тут прилетел пушной зверёк в виде исключения.
...
heap_free(c);
}
Получим утечку памяти. Причем этот код может быть внутри сторонней библиотеки.
Или еще хуже:
void someFunc()
{
EnterCriticalSection(cs);
//Упс...
LeaveCriticalSection(cs);
}
//А потом в других потоках будем стоять и ждать бесконечности...
С асинхронными исключениями ровно та же проблема, кстати.
_>>>Что непонятного, генерация исключения в потоку самый простой и очевидный способ его завершения для C++ c его объектами, разве не так? C>>Не так. Это неправильный подход. _>Нет это именно так. Только вызов исключения, других путей для C++ пока просто нет.
А нет общего правильного способа для С++.
C>>А зачем? _>Сам подумай. Тебе надо поменять название класса. Тебе приходиться менять имена во многих местах. Просто нелогично и не удобно. И потом наличие пред деструктора и после конструктора особенно как виртуальных функций было бы замечательным явлением, но это мечты.
Моя IDE умеет делать search&replace. В любом случае, придется менять название класса в реализациях методов.
_>>>Ха. так что мешает компилятору генерить код который позволяет преобразовать сигнал в исключение??? C>>Из-за того, что это невозможно сделать корректно в общем случае. _>Лошь и провакация. Можно.
Покажи код.
C>>Я прекрасно знаю как работает SEH, table-driven exceptions в GCC и почему асинхронные исключения в MSVC — плохая вещь. _>Да вы все сговорились. Вы похожи на тех кто делал dos extender-ы для 32bit protected mode. нет чтоб обработку прерывание передавать в пользовательский код они его обрабатывали сразу по приходу в отдельном стеке, чем связали руки не только себе.
У меня сразу появилось уважение к создателям dos extender'ов. Так как они знают, что асинхронные события надо обрабатывать в отдельном контексте (банально, в пользовательском коде в момент исключения может быть разрушен указатель на стек).
_>MSVC плохая вешь, а table-driven exception просто замечательная. да вы сума сошли. выпиши в столбик недостатки и преимущества и ты удивишься.
Эээ... Может хватит с собой разговаривать?
_>Если после обработки подобных исключений в M$ всё работает, а в Linux выскакивает патрульное приложение и сообщает о скоропостижной смерти дочернего процесса и предлагает вам капнуть разработчикам или просто перезапустить процесс. Я вас непонимаю. Нормальная обработка исключений возможно в сколь угодно убогой оси.
MSVCшные асинхронные исключения маскируют ошибки. Они не могут работать на 100% корректно. Просто в большей части случаев программе везет, и не происходит повреждений.
C>>Ничего он не должен... Обращение по нулевому указателю и деление на ноль — это ОШИБКИ. Точно такая же, как обращение к удаленному объекту. _>Как вас переубедить. Что любое событие можно преобразовать в последовательность действий? В том числе и ошибки можно обрабатывать с помощью исключений.
Ошибки программиста — нет. На них надо валиться как можно раньше и засылать bugreport.
C>>Их можно сделать штатным поведением, но это потребует слишком больших жертв в скорости и простоте C++. _>Ничего подобного. Никаких жертв, всё довольно просто и естественно. Да и потом кто бы говорил о простоте с таким стандартом.
Покажи код...
C>>Мда. Даже комментировать не буду — смешно. _>тогда прокоментируй почему в стандарте есть char16_t char32_t, но нет int16, int32, int64 ???? или хотя бы std::float32_t ?
std::float32_t не будет никогда — это бред. Аппаратура не умеет работать с плавающими числами произвольной точности.
int16/32/64 — есть. В виде short int, int, long long int.
C>>Нет. Есть такое хорошее правило — не делать опасные действия по умолчанию или неявно. Твой пример очень грубо этот принцип нарушает. _>да точно давайте на всё натянем колючую проволку и везде поставим капканы и растяжки и рассуём всё по наймспейсам что бы программист себя чуствовал как на минном поле на территории врага.
Да, было бы неплохо, чтобы при любой ошибке я сразу бы получал в лоб при компиляции.
А для тех, кому не нравятся namespace'ы — рекомендую написать сложное приложение на JavaScript. Сколько бывает удовольствия...
C>>Почему? Полезная вещь. Например, у меня библиотека контейнеров написана на них. Она работает быстрее стандартных string/vector/list. C>>Да, в Стандарт её включить нельзя из-за того, что я её затачивал только под свои задачи. _>Очень удевлён столько ненужного уже есть в C++ и сколько обещают в C++0x
Это ты к чему?
_>>>Ёмоё. так останется только компилятор комо, и все его баги будут включены в стандарт, ибо без них все имеющиеся библиотеки и программы работать не будут. C>>Почему? _>Монополия никчему хорошему не приводит.
Я имею в виду — почему останется один Комо?
C>>Пробовал как-то для экспериментов. См.: ftp://ftp.axis.se/pub/users/hp/pgccfd/pgccfd-0.5.pdf _>раз всё так просто помоги людям: http://propeller.wikispaces.com/Programming+in+C
Делать мне больше нечего, чем писать порт GCC для бесполезных контроллеров. Могу посоветовать взять LLVM и посмотреть в ней CBackend...
C>>Те части Boost'а, которые я использую, имеют размер в килобайты. _>Эмуляция double 2.5-4кб но это тебя безусловно пугает сильнее чем operator"Suffix". А вот double мы досих пор опасаемся. Пользуясь бустом бояться чисел с плавающей точкой. Просто фобия какая-то, аж смешно double и float был даже в C где нет апаратной поддержки применяется эмуляция и это всё в стандарте есть.
Мне просто абсолютно не нужны лишние сущности на ровном месте. double/float, кстати, в С не был — он был в реализациях С, причем далеко не во всех.
Да, и корректная эмуляция плавающей точки занимает вовсе не 2кб. Эмулятор в linux-2.6.24/arch/mips/math-emu в скомпилированом виде занимает 73Кб. Только не надо говорить, что можно взять урезаный эмулятор.
C>>Ага, чтобы пользователи double'а получили много неприятных сюрпризов. _> точно реализацию писали индусы и ты не опускаешся до таких сложных и непредсказуемых типов, а complex и quaternion придумали вообще еретики. Не понимающие как всё это тормозит
Нет. Есть такое понятие — контракт. Обычно программисты привыкли, что в double лежит IEEE-подобная плавучка. А тут окажется, что из-за того, что ты хочешь писать sleep(123d) — компилятор вдруг в определенных случаях начинает использовать фиксированую точку.
И как ты после этого можешь говорить, что программистам нужно много знать, чтобы писать программы?
C>Я прекрасно знаю как работает SEH, table-driven exceptions в GCC и почему асинхронные исключения в MSVC — плохая вещь.
А почему? Потому что SEH-и лазят в ядро?
Здравствуйте, Left2, Вы писали:
C>>Я прекрасно знаю как работает SEH, table-driven exceptions в GCC и почему асинхронные исключения в MSVC — плохая вещь. L>А почему? Потому что SEH-и лазят в ядро?
Сами вы асинхронные. Деление на ноль и обращение к защиенной области памяти это СИНХРОННЫЕ события. И они не происходят из за событий из вне это вам не таймер и не NMI. SEH в ядро не лазит, более того все мета их возникновения в свойм коде компилятор может зарание виписать. Задача ядра обеспечить SEH, а не SEH-у лазить в ядро.
SEH должен быть реализован так чтоб ядра видно не было, но быть он должен.
Схема должна быть такой. Произошло исключение процессор перешел по idt в L0 выяснил чьё и сэмулировал в пользовательском стеке потока вызвавшего косяк вызов обработчика сигнала и потом передала управление потоку, а уже обработчик сигнала в обычном L3 вызывал исключение и то что ему кажется правильным. Где я не прав?
Где SEH в таком случае лазит в ядро???
Здравствуйте, Cyberax, Вы писали:
C>Когда мне говорят слова "алгоритмический язык [программирования]" — хочется в говорящего бросить тяжёлый предмет.
Очень прискорбно. Разве он не такой? А когда вы слышите декларативный язык вы готовы биться головой ап стену?
C>>>Причём тут процессы? Ты вообще понимаешь, что выход из потока и завершение программы с помощью управляющего сигнала — это вообще разные действия? _>>Простая задача у тебя сотня потоков и тебе надо остановить половину, причем немедленно. и так что бы все созданные объекты умерли своей смертью. ваши действия? а если многопоточность есть в языке эта ситуация должна быть расписана. C>Да никак этого не сделать корректно простыми способами. Н_И_К_А_К.
Ха. это сейчас никак, почему это не предусмотреть, что бы программисты вместо Н_И_К_А_К говорили, элементарно, и дописывали одну две строчки?
C>Банально: C>
C>void someFunction()
C>{
C> char *c=(char*) heap_alloc(1123);
C> //А вот тут прилетел пушной зверёк в виде исключения.
C> ...
C> heap_free(c);
C>}
C>
C>Получим утечку памяти. Причем этот код может быть внутри сторонней библиотеки.
Элементарно, неужели вам это не очевидно. Это решается именно стандартом и средствами компилятора.
void someFunction() {
char *c=(char*)heap_alloc(1123); try {
//А вот тут прилетел пушной зверёк в виде исключения. и нет проблемм
...
} finally {
heap_free(c);
}
}
или
void someFunction() {
ptr<char> c=new char[1123];
//А вот тут прилетел пушной зверёк в виде исключения. и нет проблемм
...
}
C>Или еще хуже: C>
C>void someFunc()
C>{
C> EnterCriticalSection(cs);
C> //Упс...
C> LeaveCriticalSection(cs);
C>}
C>//А потом в других потоках будем стоять и ждать бесконечности...
C>
Ваши представления о генерации кода. Очень странные. Особенно тут. Просто не пиши так.
Почему нельзя встроить в язык конструкцию вида:
lock(cs) {
//action
}
Теболее она есть во всех велосипедах примерно в таком виде:
И вобще и в текущем C++ можно выделять память и делать throw не освобождая, какие проблемы то. Почему вы про это молчите?
C>С асинхронными исключениями ровно та же проблема, кстати.
Когда я говорил про асинхроныые исключения. !!!ТОЛЬКО СИНХРОННЫЕ!!! Поделил на ноль исключение, нарушил правила защиты исключение. Вызвал функцию ожидания или другую функцию которая может работать длительное время будь готов к исключению типа завершение потока. Чему это противоречит?
_>>>>Что непонятного, генерация исключения в потоку самый простой и очевидный способ его завершения для C++ c его объектами, разве не так? C>>>Не так. Это неправильный подход. _>>Нет это именно так. Только вызов исключения, других путей для C++ пока просто нет. C>А нет общего правильного способа для С++.
? неужели. Так уж совсем нет, или никто не ищет?
C>>>А зачем? _>>Сам подумай. Тебе надо поменять название класса. Тебе приходиться менять имена во многих местах. Просто нелогично и не удобно. И потом наличие пред деструктора и после конструктора особенно как виртуальных функций было бы замечательным явлением, но это мечты. C>Моя IDE умеет делать search&replace. В любом случае, придется менять название класса в реализациях методов.
Ха ха ха. А еще твоя IDE умеет подсказывать код, и много еще чего. Причем тут IDE. Я про язык, а не про IDE. Кстати любовь к namespace-ам отчастья подпитывается именно эти самыми IDE c intelisence. Желание того чтоб он подсказывал то что хочется. В топку всё остальное лишбы было удобно и красиво в этом IDE.
_>>>>Ха. так что мешает компилятору генерить код который позволяет преобразовать сигнал в исключение??? C>>>Из-за того, что это невозможно сделать корректно в общем случае. _>>Лошь и провакация. Можно. C>Покажи код.
Посмотри HP c++ для Tru64
C>>>Я прекрасно знаю как работает SEH, table-driven exceptions в GCC и почему асинхронные исключения в MSVC — плохая вещь. _>>Да вы все сговорились. Вы похожи на тех кто делал dos extender-ы для 32bit protected mode. нет чтоб обработку прерывание передавать в пользовательский код они его обрабатывали сразу по приходу в отдельном стеке, чем связали руки не только себе. C>У меня сразу появилось уважение к создателям dos extender'ов. Так как они знают, что асинхронные события надо обрабатывать в отдельном контексте (банально, в пользовательском коде в момент исключения может быть разрушен указатель на стек).
Именно из за таких идиотов мы движемся не туда. 4 кольша в процессорах i386 и систему защиты сделали не для того чтобы усложнять жизнь, а для улучшения стабильности работы.
Правильным решением должно было. Обрабатывать прерывание в отдельном стеке, но не вызывать пользовательский код с привелегиями ядра для обработки исключения. (За это вы их тоже уважаете?) Надо было просто в пользовательском стеке на 3-ем уромне сделать эмуляцию возникновения прерывания как в обычном real86 и небыло бы никаких проблем.
И еще достали уже. Какое нафиг оно асинхронное. Асинхронное это прерывание по внешнему событию. А все отказы они синхронные!
C>MSVCшные асинхронные исключения маскируют ошибки. Они не могут работать на 100% корректно. Просто в большей части случаев программе везет, и не происходит повреждений.
Они СИНХРОННЫЕ!
C>Ошибки программиста — нет. На них надо валиться как можно раньше и засылать bugreport.
мдя. вот бы так ядро системы работало!
C>>>Их можно сделать штатным поведением, но это потребует слишком больших жертв в скорости и простоте C++. _>>Ничего подобного. Никаких жертв, всё довольно просто и естественно. Да и потом кто бы говорил о простоте с таким стандартом. C>Покажи код...
Какой именно код тебе показать?
C>std::float32_t не будет никогда — это бред. Аппаратура не умеет работать с плавающими числами произвольной точности. C>int16/32/64 — есть. В виде short int, int, long long int.
Это не бред. два типа с плавающей точкой float и double есть уже давно.
А short,int и long всегда были привязаны к разрядности регистра и разрядности адреса процессора, для которого компилируется код.
sizeof(int)=8 pic16
sizeof(int)=16 x86
sizeof(int)=32 i386+ pm
sizeof(int)=64 x64
Каждый раз надо объявлять типы фиксированной разрядности, почему их не добавить в стандарт?
C>>>Нет. Есть такое хорошее правило — не делать опасные действия по умолчанию или неявно. Твой пример очень грубо этот принцип нарушает. _>>да точно давайте на всё натянем колючую проволку и везде поставим капканы и растяжки и рассуём всё по наймспейсам что бы программист себя чуствовал как на минном поле на территории врага. C>Да, было бы неплохо, чтобы при любой ошибке я сразу бы получал в лоб при компиляции.
Вы мазахист! Раскидайте по дому детских граблей и завяжите глаза...
C>А для тех, кому не нравятся namespace'ы — рекомендую написать сложное приложение на JavaScript. Сколько бывает удовольствия...
javascript -- это не язык. это именно script и в нем слишком много ограничений, он для мелких поделок и DHTML.
_>>Очень удевлён столько ненужного уже есть в C++ и сколько обещают в C++0x C>Это ты к чему?
К тому, что много излишеств совершенно ненужных или реализованных совершенно противоестественным способом как в случае с шаблонами.
_>>Монополия никчему хорошему не приводит. C>Я имею в виду — почему останется один Комо?
Потому что остальные вымрут.
C>Делать мне больше нечего, чем писать порт GCC для бесполезных контроллеров. Могу посоветовать взять LLVM и посмотреть в ней CBackend...
Гы. а говорил халява. А между прочим 8ядерный ширпотребный микроконтроллер для робототехники.
C>Мне просто абсолютно не нужны лишние сущности на ровном месте. double/float, кстати, в С не был — он был в реализациях С, причем далеко не во всех.
double/float это не лишние сущности. Неужели если ты оцениваешь время необходимое для окончания работы работы функции ты всё делаешь в целочисленной арифметике, или когда ты балансируеш трафик ты тоже пользуешь только int64? И потом операция sleep её просять притормозить выполнение, куда ты спешиш?
Откуда такая фобия?
C>Да, и корректная эмуляция плавающей точки занимает вовсе не 2кб. Эмулятор в linux-2.6.24/arch/mips/math-emu в скомпилированом виде занимает 73Кб. Только не надо говорить, что можно взять урезаный эмулятор.
Мдя. Ну нафига же мне эмулятор, всех команд сопроцессора. Арктангенс синус и логарифмы, если мне надо только перевод в целое, сложение и умножение? Ваши 73кб это от того что там много лишнего и ненужного, которое именно компилятор с линковщиком должны отбрасывать.
C>Нет. Есть такое понятие — контракт. Обычно программисты привыкли, что в double лежит IEEE-подобная плавучка. А тут окажется, что из-за того, что ты хочешь писать sleep(123d) — компилятор вдруг в определенных случаях начинает использовать фиксированую точку.
Есть такое понятие -- привычка. Вот вы так привыкли и не хотите смотреть на вещи иначе. Все эти окончания LL, D, UUL и т.п. это по большому счету бред.
надо было сразу пользоваться конструкторами классов типа
sleep(double(123.4));
sleep(fixed(123.53));
sleep(long(123));
sleep(int64(123));
а не
sleep(1);
sleep(1l);
sleep(1ll);
Просто у вас инертность большая и вы так привыкли. Но это безобразие.
Все правильно, ты не получишь видимость чего-то, пока явно не запросишь необходимую тебе видимость. По умолчанию давать тебе абсолютно все, до чего можешь дотянуться — имхо не стоит, иначе моментально утонешь в сотнях вспомогательных функций/классов/typedef-ов и прочих радостях. Да и интеллисенс пожалей . Что надо — то и запрашивай. На проектах уровня HelloWorld — может это и напряжно. Я же предпочитаю писать не
Здравствуйте, kov_serg, Вы писали:
C>>>>http://en.wikipedia.org/wiki/C%2B%2B0x#Thread-local_storage ? _>>>И еще докле мы будем в качестве конструктора и деструктора писать имя класса???? почему нельзя зарезервировать имена типа ctor и dtor??? C>>А зачем? _>Сам подумай. Тебе надо поменять название класса. Тебе приходиться менять имена во многих местах. Просто нелогично и не удобно. И потом наличие пред деструктора и после конструктора особенно как виртуальных функций было бы замечательным явлением, но это мечты.
Еще предлагаю ввести base0, base1, base2... А лучше сразу base(0), base(1)...
Это для списка инициализации в случае множественного наследования, если кто не понял. Да и просто к базовым обращаться. Остается еще одна проблема — а если поменяют местами базовые в списке? Ну т.е. было public A, public B, а сделали public B, public A. Блин, тут есть над чем серьезно подумать!
Здравствуйте, VoidEx, Вы писали:
VE>Еще предлагаю ввести base0, base1, base2... А лучше сразу base(0), base(1)... VE>Это для списка инициализации в случае множественного наследования, если кто не понял. Да и просто к базовым обращаться. Остается еще одна проблема — а если поменяют местами базовые в списке? Ну т.е. было public A, public B, а сделали public B, public A. Блин, тут есть над чем серьезно подумать!
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, VoidEx, Вы писали:
VE>>Еще предлагаю ввести base0, base1, base2... А лучше сразу base(0), base(1)... VE>>Это для списка инициализации в случае множественного наследования, если кто не понял. Да и просто к базовым обращаться. Остается еще одна проблема — а если поменяют местами базовые в списке? Ну т.е. было public A, public B, а сделали public B, public A. Блин, тут есть над чем серьезно подумать!
J>Да что там думать — по алфавиту нада!
При переименовании родительского класса тогда придётся учитывать: поменялся ли алфавитный порядок родительских классов или нет. Такие прикольные баги могут появиться
Здравствуйте, kov_serg, Вы писали:
C>>Когда мне говорят слова "алгоритмический язык [программирования]" — хочется в говорящего бросить тяжёлый предмет. _>Очень прискорбно. Разве он не такой? А когда вы слышите декларативный язык вы готовы биться головой ап стену?
Язык программирования может быть декларативным, функциональным, логическим, императивным. Единственное чем он не может быть — не алгоритмическим.
C>>Да никак этого не сделать корректно простыми способами. Н_И_К_А_К. _>Ха. это сейчас никак, почему это не предусмотреть, что бы программисты вместо Н_И_К_А_К говорили, элементарно, и дописывали одну две строчки?
Ну допиши...
_>
_>void someFunction() {
_> char *c=(char*)heap_alloc(1123); try {
_> //А вот тут прилетел пушной зверёк в виде исключения. и нет проблемм
_> ...
_> } finally {
_> heap_free(c);
_> }
_>}
_>или
_>void someFunction() {
_> ptr<char> c=new char[1123];
_> //А вот тут прилетел пушной зверёк в виде исключения. и нет проблемм
_> ...
_>}
_>
И каким образом компилятор догадается, что ему нужно достроить try..finally? Hint: эта задача неразрешима в принципе
Ну и я уж не говорю про то, что это всё может быть во внешней бинарной библиотеке, написаной на Objective C.
C>>
C>>void someFunc()
C>>{
C>> EnterCriticalSection(cs);
C>> //Упс...
C>> LeaveCriticalSection(cs);
C>>}
C>>//А потом в других потоках будем стоять и ждать бесконечности...
C>>
_>Ваши представления о генерации кода. Очень странные. Особенно тут. Просто не пиши так.
Какая генерация кода? Ты о чём вообще?
Этот код может быть в библиотеке на чистом С. Или он может быть специально написан с использованием ручных вызовов функции.
А ты же предлагаешь весь код переписать. Так что твоё предложение идёт в топку, пока ты не покажешь как сделать правильное кидание исключений без единого изменения кода.
C>>С асинхронными исключениями ровно та же проблема, кстати. _>Когда я говорил про асинхроныые исключения. !!!ТОЛЬКО СИНХРОННЫЕ!!! Поделил на ноль исключение, нарушил правила защиты исключение. Вызвал функцию ожидания или другую функцию которая может работать длительное время будь готов к исключению типа завершение потока. Чему это противоречит?
Всему. См. выше.
C>>А нет общего правильного способа для С++. _>? неужели. Так уж совсем нет, или никто не ищет?
Нет, не будет, и нет смысла искать.
C>>Моя IDE умеет делать search&replace. В любом случае, придется менять название класса в реализациях методов. _>Ха ха ха. А еще твоя IDE умеет подсказывать код, и много еще чего. Причем тут IDE. Я про язык, а не про IDE. Кстати любовь к namespace-ам отчастья подпитывается именно эти самыми IDE c intelisence. Желание того чтоб он подсказывал то что хочется. В топку всё остальное лишбы было удобно и красиво в этом IDE.
Это же ты что-то начал мямлить про ctor/dtor. Тольк зачем это нужно? Для облегчения cut&paste?
C>>Покажи код. _>Посмотри HP c++ для Tru64
Файлы, строки?
C>>У меня сразу появилось уважение к создателям dos extender'ов. Так как они знают, что асинхронные события надо обрабатывать в отдельном контексте (банально, в пользовательском коде в момент исключения может быть разрушен указатель на стек). _>Именно из за таких идиотов мы движемся не туда.
Тут вообще-то на личности не переходят...
_>4 кольша в процессорах i386 и систему защиты сделали не для того чтобы усложнять жизнь, а для улучшения стабильности работы.
Угу, поэтому эти кольца пошли лесом во всех основных операционках. Осталось только нулевое и третее кольца.
_>Правильным решением должно было. Обрабатывать прерывание в отдельном стеке, но не вызывать пользовательский код с привелегиями ядра для обработки исключения. (За это вы их тоже уважаете?) Надо было просто в пользовательском стеке на 3-ем уромне сделать эмуляцию возникновения прерывания как в обычном real86 и небыло бы никаких проблем.
Угу. И на каждое прерывание щёлкать контекстами (а это МЕДЛЕННО). Ой как этому драйверы обрадуются...
_>И еще достали уже. Какое нафиг оно асинхронное. Асинхронное это прерывание по внешнему событию. А все отказы они синхронные!
"Асинхронное" означет "без контроля со стороные прикладного кода". Т.е. для прикладного кода оно может случится в любой момент.
C>>MSVCшные асинхронные исключения маскируют ошибки. Они не могут работать на 100% корректно. Просто в большей части случаев программе везет, и не происходит повреждений. _>Они СИНХРОННЫЕ! http://msdn2.microsoft.com/en-us/library/1deeycx5.aspx — grep по слову "async"...
C>>Ошибки программиста — нет. На них надо валиться как можно раньше и засылать bugreport. _>мдя. вот бы так ядро системы работало!
Оно так и работает...
_>>>Ничего подобного. Никаких жертв, всё довольно просто и естественно. Да и потом кто бы говорил о простоте с таким стандартом. C>>Покажи код... _>Какой именно код тебе показать?
"Абсолютно правильной(tm)" обработки исключений.
C>>std::float32_t не будет никогда — это бред. Аппаратура не умеет работать с плавающими числами произвольной точности. C>>int16/32/64 — есть. В виде short int, int, long long int. _>Это не бред. два типа с плавающей точкой float и double есть уже давно.
Ну да. А где же у нас float64 и double128?
_>Каждый раз надо объявлять типы фиксированной разрядности, почему их не добавить в стандарт? http://en.wikipedia.org/wiki/C%2B%2B0x#Type_long_long_int
C>>Да, было бы неплохо, чтобы при любой ошибке я сразу бы получал в лоб при компиляции. _>Вы мазахист! Раскидайте по дому детских граблей и завяжите глаза...
Есть мааааленькая разница. Ошибки компиляции указывают мне на ошибки в моём коде. Чем больше компилятор их найдет — тем лучше.
Расставление граблей — это как раз то, что вы любите делать.
C>>А для тех, кому не нравятся namespace'ы — рекомендую написать сложное приложение на JavaScript. Сколько бывает удовольствия... _>javascript -- это не язык. это именно script и в нем слишком много ограничений, он для мелких поделок и DHTML.
Кхм... Google Mail?
C>>Я имею в виду — почему останется один Комо? _>Потому что остальные вымрут.
С чего бы?
C>>Делать мне больше нечего, чем писать порт GCC для бесполезных контроллеров. Могу посоветовать взять LLVM и посмотреть в ней CBackend... _>Гы. а говорил халява. А между прочим 8ядерный ширпотребный микроконтроллер для робототехники.
Оно не сложно, где-то на неделю работы. Недели лишнего времени у меня нет.
_>double/float это не лишние сущности. Неужели если ты оцениваешь время необходимое для окончания работы работы функции ты всё делаешь в целочисленной арифметике, или когда ты балансируеш трафик ты тоже пользуешь только int64? И потом операция sleep её просять притормозить выполнение, куда ты спешиш?
double/float — именно ЛИШНИЕ сущности в твоём примере. Они НИЧЕГО не дают по сравнению с указанием наносекунд. В смысле АБСОЛЮТНО ничего.Зато требуют подключение всего механизма работы с плавающей точкой.
Причём тут баллансировка траффика — мне вообще непонятно.
_>Мдя. Ну нафига же мне эмулятор, всех команд сопроцессора. Арктангенс синус и логарифмы, если мне надо только перевод в целое, сложение и умножение? Ваши 73кб это от того что там много лишнего и ненужного, которое именно компилятор с линковщиком должны отбрасывать.
Я же просил — не говорить про урезаный эмулятор... Это очередные сложности на пустом месте.
_>Есть такое понятие -- привычка. Вот вы так привыкли и не хотите смотреть на вещи иначе. Все эти окончания LL, D, UUL и т.п. это по большому счету бред.
Вот вашу привычку и лучше ломать. Нефиг ваши измышления выдавать за истину в последней инстанции.
_>Просто у вас инертность большая и вы так привыкли. Но это безобразие.
Нет, просто вы не писали реальных больших систем. Это сразу видно.
_>>void someFunction() {
_>> char *c=(char*)heap_alloc(1123); try {
_>> //А вот тут прилетел пушной зверёк в виде исключения. и нет проблемм
_>> ...
_>> } finally {
_>> heap_free(c);
_>> }
_>>}
_>>или
_>>void someFunction() {
_>> ptr<char> c=new char[1123];
_>> //А вот тут прилетел пушной зверёк в виде исключения. и нет проблемм
_>> ...
_>>}
_>>
C>И каким образом компилятор догадается, что ему нужно достроить try..finally?
Вообще-то C++ компилятор это уже делает. При вызове исключения он последовательно вызывает деструкторы созданных объектов. C>Hint: эта задача неразрешима в принципе
слово "это" — очень не хорошее слово. в данном контексте оно потеряло значимость.
C>Ну и я уж не говорю про то, что это всё может быть во внешней бинарной библиотеке, написаной на Objective C.
Любая проблемма тоже может быть решена, хотя не обязательно точно и полно:
Например при вызове внешней библиотеке, в потоке можно менять поведение обработчика исключений,
принципе можно следить за ресурсами выделяемыми этой сторонней библиотекой.
Более того эту библиотеку можно запускать, как бы изолировано, что бы имелась возможность
освободить всё что зависло в памяти, вплоть до запуска в отдельном процессе.
C>>>
C>>>void someFunc()
C>>>{
C>>> EnterCriticalSection(cs);
C>>> //Упс...if (something) return; // -- упс
C>>> //Упс...
C>>> LeaveCriticalSection(cs);
C>>>}
C>>>//А потом в других потоках будем стоять и ждать бесконечности...
C>>>
_>>Ваши представления о генерации кода. Очень странные. Особенно тут. Просто не пиши так. C>Какая генерация кода? Ты о чём вообще?
О том что в таком коде изначально заложена возможнось пролететь. В идеале для такиз случаев нужна конструкция в языке вида:
C>Этот код может быть в библиотеке на чистом С. Или он может быть специально написан с использованием ручных вызовов функции.
{
unsafe { // меняем способ реагирования на исключения, и метод слежения за ресурсами
lib.betta(params);
}
}
C>А ты же предлагаешь весь код переписать. Так что твоё предложение идёт в топку, пока ты не покажешь как сделать правильное кидание исключений без единого изменения кода.
Нет конешно. Я предлагаю поменять подход к написанию новых программ. А баги в уже имеющихся никакой способ обработки не спасёт. Просто их надо бережно использовать.
C>>>А нет общего правильного способа для С++. _>>? неужели. Так уж совсем нет, или никто не ищет? C>Нет, не будет, и нет смысла искать.
Да мы все умрём. Но сложить лапки и не рапаться это не наш метод. Если вы не видите смысла искать и уже доказали невозможность, то вечная вам память.
C>>>Моя IDE умеет делать search&replace. В любом случае, придется менять название класса в реализациях методов. _>>Ха ха ха. А еще твоя IDE умеет подсказывать код, и много еще чего. Причем тут IDE. Я про язык, а не про IDE. Кстати любовь к namespace-ам отчастья подпитывается именно эти самыми IDE c intelisence. Желание того чтоб он подсказывал то что хочется. В топку всё остальное лишбы было удобно и красиво в этом IDE. C>Это же ты что-то начал мямлить про ctor/dtor. Тольк зачем это нужно? Для облегчения cut&paste?
Нет. Просто большая избыточность. Вообще-то хочется повысить читабельнось и нагляднось, а не просто облехчать работу в какомно там IDE.
// .h
class SampleClassWithHumanReadableName : public BaseClass {
public:
SampleClassWithHumanReadableName();
~SampleClassWithHumanReadableName();
};
// .cpp
SampleClassWithHumanReadableName::SampleClassWithHumanReadableName() {}
SampleClassWithHumanReadableName::~SampleClassWithHumanReadableName() {}
vs
// .hh
class SampleClassWithHumanReadableName : public BaseClass {
public:
ctor();
dtor();
};
// .cc
namespace SampleClassWithHumanReadableName {
ctor() {}
dtor() {}
}
[code]
Коряво конешно. Но идея такая, зачем много раз дублировать одно и тоже особенно если это класс большой вложенности a::b::c::d
C>>>Покажи код.
_>>Посмотри HP c++ для Tru64
C>Файлы, строки?
/usr/ccs/lib/cmplrs/cc/libexc.a - exception handling library
/usr/include/excpt.h
/usr/include/pdsc.h
/usr/include/signal.h
Тут:
http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51_HTML/ARH9MBTE/VNTPRCSS.HTM#exc-sig-hand-coexistence
http://www.camk.edu.pl/doc/ccc/Programmers_Guide/XCPTCHPX.HTM
функция exc_raise_signal_exception
Выглядит примерно так:
[code]
#include <excpt.h>
#include <stdio.h>
#include <signal.h>
struct sigaction foo={ (void(*)(int))exc_raise_signal_exception,0,0 };
double x,y=0;
void main() {
sigaction(SIGFPE,&foo,0);
sigaction(SIGSEGV,&foo,0);
try {
x=x/y;
printf("exception not raised\n");
} catch(...) {
printf("exception raised correctly\n");
}
}
C>>>У меня сразу появилось уважение к создателям dos extender'ов. Так как они знают, что асинхронные события надо обрабатывать в отдельном контексте (банально, в пользовательском коде в момент исключения может быть разрушен указатель на стек). _>>Именно из за таких идиотов мы движемся не туда. C>Тут вообще-то на личности не переходят...
Я и не перехожу. Просто обработака прерываний в dos-extender-ах убила возможность многопоточность в них на корню.
_>>4 кольша в процессорах i386 и систему защиты сделали не для того чтобы усложнять жизнь, а для улучшения стабильности работы. C>Угу, поэтому эти кольца пошли лесом во всех основных операционках. Осталось только нулевое и третее кольца.
Да есть такая фигня. Хотя так крависво было задумано только ядро на 0 уровне, на 1-ом система, на 2-ом драйвера и только на 3-ем всякий прикладной и глючный софт.
_>>Правильным решением должно было. Обрабатывать прерывание в отдельном стеке, но не вызывать пользовательский код с привелегиями ядра для обработки исключения. (За это вы их тоже уважаете?) Надо было просто в пользовательском стеке на 3-ем уромне сделать эмуляцию возникновения прерывания как в обычном real86 и небыло бы никаких проблем. C>Угу. И на каждое прерывание щёлкать контекстами (а это МЕДЛЕННО). Ой как этому драйверы обрадуются...
Ха. именно так и происходит, но контекстами щелкает проц. Меделено не медленно, но так бы было правильно и позволило развиваться. А так похоронили заживо.
_>>И еще достали уже. Какое нафиг оно асинхронное. Асинхронное это прерывание по внешнему событию. А все отказы они синхронные! C>"Асинхронное" означет "без контроля со стороные прикладного кода". Т.е. для прикладного кода оно может случится в любой момент.
Очень удивил. Деление на ноль происходит только когда ты вызываеш операцию деления! Так же и с обращением к защищенной памяти.
Конешно есть т другие события прерывание по отладке например
C>>>MSVCшные асинхронные исключения маскируют ошибки. Они не могут работать на 100% корректно. Просто в большей части случаев программе везет, и не происходит повреждений. _>>Они СИНХРОННЫЕ! C>http://msdn2.microsoft.com/en-us/library/1deeycx5.aspx — grep по слову "async"...
Это опечатка, напиши им пусть исправят Они называют общий вид исключений поэтому так и написали. Асинхронный значит от внешнего источника, а синхронны это сама программа. Например out of bouds, access violation, divide by zero, overflow -- это всё синхнонные события. Выполнил условие получил исключение.
if (cond) throw;
Somewhat related with the concept of checked exceptions is exception synchronity. Synchronous exceptions happen at a specific program statement whereas asynchronous exceptions can raise practically anywhere.[9][10] It follows that asynchronous exception handling can't be required by the compiler. They are also difficult to program with. Examples of naturally asynchronous events include pressing Ctrl-C to interrupt a program, and receiving a signal such as "stop" or "suspend" from another thread of execution.
Programming languages typically deal with this by limiting asynchronity, for example Java has lost thread stopping and resuming.[11] Instead, there can be semi-asynchronous exceptions that only raise in suitable locations of the program or synchronously.
http://en.wikipedia.org/wiki/Exception_handling
C>>>Ошибки программиста — нет. На них надо валиться как можно раньше и засылать bugreport. _>>мдя. вот бы так ядро системы работало! C>Оно так и работает...
Что то я не помню чтобы ядро сисемы писали на С++. Видел только на C.
_>>>>Ничего подобного. Никаких жертв, всё довольно просто и естественно. Да и потом кто бы говорил о простоте с таким стандартом. C>>>Покажи код... _>>Какой именно код тебе показать? C>"Абсолютно правильной(tm)" обработки исключений.
Вообще "Абсолютно правильной(tm)" уже торговая марка есть?
Незнаю как насчет абсолютно правильного, но как вполне приемлиа схема така для каждого отдельного потока в приложении это обработка исключений не должна отличаться от ситуации если бы это поток работал один в реальном режиме. т.е. он ничего не должен знать что происходило в ядре системы. Примером может служить window-ый SEH вполне добротно сделано. Единственное что переполнение стека надо обрабатывать отдельно. А асинхронные события по схеме как работают прерывания. Только разница в том что они эмулируются системой, т.е. ядро вписывает в стек адресс возврата и флаги и передаёт управление обработчику пользователя.
C>>>std::float32_t не будет никогда — это бред. Аппаратура не умеет работать с плавающими числами произвольной точности.
Я не говорю об произвольной точность, но float32 и float64 -- это стандарт для большинства процессоров имеющих FPU. Есть конечно суперскалярные у которых вектора из float32. C>>>int16/32/64 — есть. В виде short int, int, long long int. _>>Это не бред. два типа с плавающей точкой float и double есть уже давно. C>Ну да. А где же у нас float64 и double128?
а нафига тебе double128? я говорю об стандартных типах, которые можно встерить в файлах данных.
typedef float float32;
typedef double float64;
//typedef long double float80; // хотя такого уже больше нет хотя в x86 регистры сопроцессора именно такие
Имеется ввиду что иногда нужны типы данных не максимально быстро работающие на данном процессоре, а именно фиксированных параметров.
_>>Каждый раз надо объявлять типы фиксированной разрядности, почему их не добавить в стандарт? C>http://en.wikipedia.org/wiki/C%2B%2B0x#Type_long_long_int
Я же тебе говорю что на 64бит системах твой long long int будет не 64бит а в два раза больше. (Более того на практике в разных компиляторах имеются разногласия на это счет).
Все подключат хедаы с #if sizeof(int)=4 ... , #if GCC long long... #if VC __int64...
C>>>Да, было бы неплохо, чтобы при любой ошибке я сразу бы получал в лоб при компиляции. _>>Вы мазахист! Раскидайте по дому детских граблей и завяжите глаза... C>Есть мааааленькая разница. Ошибки компиляции указывают мне на ошибки в моём коде. Чем больше компилятор их найдет — тем лучше.
Да есть разница, компилятор вам ничего не скажет -- это ошибки runtime! (входных данных). Лучше бы он мог говорить контекст ошибки с возможностью отката назад, хотя это больше к отладной информации, которую тоже генерит компилятор с линковщиком.
C>>>А для тех, кому не нравятся namespace'ы — рекомендую написать сложное приложение на JavaScript. Сколько бывает удовольствия... _>>javascript -- это не язык. это именно script и в нем слишком много ограничений, он для мелких поделок и DHTML. C>Кхм... Google Mail?
да и на бейсике можно программы писать. и что? дело в другом: одна и таже программа написаная на разных языках требует разный уровень затрат, и её будут иметь свои "профессиональные" проблеммы, которые определяются именно языком и тем способом которым программист опходит недостатки этого языка.
_>>Мдя. Ну нафига же мне эмулятор, всех команд сопроцессора. Арктангенс синус и логарифмы, если мне надо только перевод в целое, сложение и умножение? Ваши 73кб это от того что там много лишнего и ненужного, которое именно компилятор с линковщиком должны отбрасывать. C>Я же просил — не говорить про урезаный эмулятор... Это очередные сложности на пустом месте.
Не понимаю, у вас все программы не используют float и double?
_>>Есть такое понятие -- привычка. Вот вы так привыкли и не хотите смотреть на вещи иначе. Все эти окончания LL, D, UUL и т.п. это по большому счету бред. C>Вот вашу привычку и лучше ломать. Нефиг ваши измышления выдавать за истину в последней инстанции.
Я такого никогда не говорил.
_>>Просто у вас инертность большая и вы так привыкли. Но это безобразие. C>Нет, просто вы не писали реальных больших систем. Это сразу видно.
Да конешно, у вас есть фиксированный набор правил норм и шаблонов и вы их строго придерживаетесь как робот -- иначе труба. И это тоже сразу видно. Да в промышленном программировании свободы нет. Просто землекопы -- что дали тем и копаем. Просто тупо копаем, за остальное не платят. А свободного времени и не будет, так и умрём землекопами.
ps: Чаще смотрите в ночное небо, там звёзды, и они прекрасны...
Здравствуйте, kov_serg, Вы писали:
C>>И каким образом компилятор догадается, что ему нужно достроить try..finally? _>Вообще-то C++ компилятор это уже делает. При вызове исключения он последовательно вызывает деструкторы созданных объектов.
Ещё раз меееедленно: есть cleanup-действия которые, НЕ производятся деструкторами.
C>>Ну и я уж не говорю про то, что это всё может быть во внешней бинарной библиотеке, написаной на Objective C. _>Любая проблемма тоже может быть решена, хотя не обязательно точно и полно: _>Например при вызове внешней библиотеке, в потоке можно менять поведение обработчика исключений,
Угу. Как? У тебя есть dll/lib. Что ты там менять будешь?
А если эта библиотека делает callback в твой код?
_>принципе можно следить за ресурсами выделяемыми этой сторонней библиотекой.
Как?
_>Более того эту библиотеку можно запускать, как бы изолировано, что бы имелась возможность
Как?
_>освободить всё что зависло в памяти, вплоть до запуска в отдельном процессе.
Угу, спасибо. С такими предложениями — в лес.
C>>>>
А нету "if(something) return". Код портировали с чистого С и оставили всё как было.
_>О том что в таком коде изначально заложена возможнось пролететь. В идеале для такиз случаев нужна конструкция в языке вида:
Да я не спорю. В идеальном мире вообще всё было бы хорошо. Тот код, который я написал — СУЩЕСТВУЕТ КАК ОБЪЕКТИВНАЯ РЕАЛЬНОСТЬ.
Далее, есть совершенно валидный код, который свалится с асинхронными исключениями:
class list
{
list *next, *prev;
void add_before(list *elem)
{
prev->next=elem;
//Тут вылетает птичка.
elem->next=this;
elem->prev=prev;
prev=elem;
}
~list()
{
//Chain deletionif (next) delete next;
}
}
Совершенно валидный exception-safe код с асинхронными исключениями, в результате, будет вызывать утечки памяти.
И это простой случай. В реальном коде будут примеры, намного более сложные.
C>>А ты же предлагаешь весь код переписать. Так что твоё предложение идёт в топку, пока ты не покажешь как сделать правильное кидание исключений без единого изменения кода. _>Нет конешно. Я предлагаю поменять подход к написанию новых программ.
Идёшь в лес.
_>Да мы все умрём. Но сложить лапки и не рапаться это не наш метод. Если вы не видите смысла искать и уже доказали невозможность, то вечная вам память.
Сначала рекомендую изучить предмет.
_>[code] _>// .h _>class SampleClassWithHumanReadableName : public BaseClass { _>public: _> SampleClassWithHumanReadableName(); _> ~SampleClassWithHumanReadableName(); _>}; _>// .cpp _>SampleClassWithHumanReadableName::SampleClassWithHumanReadableName() {} _>SampleClassWithHumanReadableName::~SampleClassWithHumanReadableName() {}
_>vs
_>// .hh _>class SampleClassWithHumanReadableName : public BaseClass { _>public: _> ctor(); _> dtor(); _>}; _>// .cc _>namespace SampleClassWithHumanReadableName { _> ctor() {} _> dtor() {} _>} _>[code] _>Коряво конешно. Но идея такая, зачем много раз дублировать одно и тоже особенно если это класс большой вложенности a::b::c::d
Читаемость лучше в первом случае. Так как в исходнике строк хотя бы на 500 придётся очень долго искать чего же мы сейчас реализуем.
_>Тут: _>http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51_HTML/ARH9MBTE/VNTPRCSS.HTM#exc-sig-hand-coexistence _>http://www.camk.edu.pl/doc/ccc/Programmers_Guide/XCPTCHPX.HTM _>функция exc_raise_signal_exception
Угу, аналог SEHа. Почему он не работает — см. пример выше.
_>>>4 кольша в процессорах i386 и систему защиты сделали не для того чтобы усложнять жизнь, а для улучшения стабильности работы. C>>Угу, поэтому эти кольца пошли лесом во всех основных операционках. Осталось только нулевое и третее кольца. _>Да есть такая фигня. Хотя так крависво было задумано только ядро на 0 уровне, на 1-ом система, на 2-ом драйвера и только на 3-ем всякий прикладной и глючный софт.
Всё красиво на бумаге, да забыли про овраги...
Даже для NT с её IRQL оказались колечки не нужны.
C>>Угу. И на каждое прерывание щёлкать контекстами (а это МЕДЛЕННО). Ой как этому драйверы обрадуются... _>Ха. именно так и происходит, но контекстами щелкает проц. Меделено не медленно, но так бы было правильно и позволило развиваться. А так похоронили заживо.
И что, что процессор меняет контексты. Это всё равно медленно, и с каждым годом становится всё медленнее.
Есть такая замечательная микроядерная OS QNX. Там ядро занимает что-то около 30 килобайт рукописного ассемблера, а все драйверы работают в отдельных процессах. В 90-е годы в QNXе были отдельные серверы IO, графики, сети. Где-то в 2003-м году их объединили — так как тормозило всё слишком из-за избыточных переключений контекстов.
_>>>И еще достали уже. Какое нафиг оно асинхронное. Асинхронное это прерывание по внешнему событию. А все отказы они синхронные! C>>"Асинхронное" означет "без контроля со стороные прикладного кода". Т.е. для прикладного кода оно может случится в любой момент. _>Очень удивил. Деление на ноль происходит только когда ты вызываеш операцию деления! Так же и с обращением к защищенной памяти.
Защищенная память обрабатывается системой, для прикладного приложения оно вообще незаметно (если не стараться). Ошибка деления на ноль для прикладного приложения тоже происходит "незаметно" — в момент, когда оно его не ожидает.
_>Конешно есть т другие события прерывание по отладке например
Точно так же.
_>>>Они СИНХРОННЫЕ! C>>http://msdn2.microsoft.com/en-us/library/1deeycx5.aspx — grep по слову "async"... _>Это опечатка, напиши им пусть исправят Они называют общий вид исключений поэтому так и написали. Асинхронный значит от внешнего источника, а синхронны это сама программа. Например out of bouds, access violation, divide by zero, overflow -- это всё синхнонные события. Выполнил условие получил исключение.
Нет. Это именно асинхронные исключения — они возбуждаются внешним по отношению к приложению кодом. Точно так же, как и ctrl-c.
C>>Оно так и работает... _>Что то я не помню чтобы ядро сисемы писали на С++. Видел только на C.
Посмотри на BeOS или L4 microkernel.
C>>"Абсолютно правильной(tm)" обработки исключений. _>Вообще "Абсолютно правильной(tm)" уже торговая марка есть?
Угу. От "The One True Way Corporation".
C>>Ну да. А где же у нас float64 и double128? _>а нафига тебе double128? я говорю об стандартных типах, которые можно встерить в файлах данных.
Ну почему же? Ты же хотел произвольные типы?
_>Имеется ввиду что иногда нужны типы данных не максимально быстро работающие на данном процессоре, а именно фиксированных параметров.
Это не имеет особого смысла в стандарте С++. Могу напомнить про PDP11 и прочие OS/390 с 36-битным int'ом.
C>>>>А для тех, кому не нравятся namespace'ы — рекомендую написать сложное приложение на JavaScript. Сколько бывает удовольствия... _>>>javascript -- это не язык. это именно script и в нем слишком много ограничений, он для мелких поделок и DHTML. C>>Кхм... Google Mail? _>да и на бейсике можно программы писать. и что? дело в другом: одна и таже программа написаная на разных языках требует разный уровень затрат, и её будут иметь свои "профессиональные" проблеммы, которые определяются именно языком и тем способом которым программист опходит недостатки этого языка.
JavaScript — это как раз замечательный пример работы без namespace'ов. Так как оно кусается даже в небольших приложениях
C>>Я же просил — не говорить про урезаный эмулятор... Это очередные сложности на пустом месте. _>Не понимаю, у вас все программы не используют float и double?
Да. Нафиг мне рассчёты на встроеной системе?
_>>>Просто у вас инертность большая и вы так привыкли. Но это безобразие. C>>Нет, просто вы не писали реальных больших систем. Это сразу видно. _>Да конешно, у вас есть фиксированный набор правил норм и шаблонов и вы их строго придерживаетесь как робот -- иначе труба. И это тоже сразу видно. Да в промышленном программировании свободы нет. Просто землекопы -- что дали тем и копаем. Просто тупо копаем, за остальное не платят. А свободного времени и не будет, так и умрём землекопами.
У меня в программировании один принцип — не добавлять сущности без необходимости.
C>>>>>А для тех, кому не нравятся namespace'ы — рекомендую написать сложное приложение на JavaScript. Сколько бывает удовольствия... _>>>>javascript -- это не язык. это именно script и в нем слишком много ограничений, он для мелких поделок и DHTML. C>>>Кхм... Google Mail? _>>да и на бейсике можно программы писать. и что? дело в другом: одна и таже программа написаная на разных языках требует разный уровень затрат, и её будут иметь свои "профессиональные" проблеммы, которые определяются именно языком и тем способом которым программист опходит недостатки этого языка. C>JavaScript — это как раз замечательный пример работы без namespace'ов. Так как оно кусается даже в небольших приложениях
Зря вы JavaScript ругаете. Namespace-ы (вместе с модулями) на нём делаются малой кровью и в рамках уже существующего синтаксиса. Т.е. хочешь писать большое модульное приложение — пиши в определённом стиле. Не хочешь — ССЗБ. Но ведь и в языке с неймспейсами их использование носит характер рекомендации, а не требования.
kov_serg wrote:
> _>>Мдя. Ну нафига же мне эмулятор, всех команд сопроцессора. Арктангенс > синус и логарифмы, если мне надо только перевод в целое, сложение и > умножение? Ваши 73кб это от того что там много лишнего и ненужного, > которое именно компилятор с линковщиком должны отбрасывать. C>Я же просил > — не говорить про урезаный эмулятор... Это очередные сложности на пустом > месте. Не понимаю, у вас все программы не используют float и double?
Я вот недавно напоролся (впервые за полтора года) на работу с float'ами.
Если б ты знал с каким удовольствием я бы заменил его на тип с
фиксированной точкой, но не могу, т.к. он в таком виде уже лет 10-15 в
проекте существует и шкурка выделки не стоит.
Типы с плавающей точкой на пустом месте создают море тонких моментов
(граблей), и если нет жёсткой необходимости их использовать, то лучше
обойтись вычислениями с фиксированной точкой.
Короче, это я к тому, что пихать float везде очень неразумно.
Posted via RSDN NNTP Server 2.1 beta
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, dr.Chaos, Вы писали:
DC>Типы с плавающей точкой на пустом месте создают море тонких моментов DC>(граблей), и если нет жёсткой необходимости их использовать, то лучше DC>обойтись вычислениями с фиксированной точкой.
Я не понимаю, откуда такая фобия? Почему вы боитесь одних алгоритмов, при этом используете другие менее отлаженные и оптимизированные без зазрения совести.
DC>Короче, это я к тому, что пихать float везде очень неразумно.
Хочу вас успокоить с типами с фиксированной точкой проблем гораздо больше, и главная это переполнение.
А вторая -- этого типа нет в стандарте, и всегда приходится пользовать велосипед.
Почему нельзя тип fixed (16.16) добавить в стандарт на ряду с float и double? Интересно что мешает?
kov_serg wrote:
> Здравствуйте, dr.Chaos, Вы писали: > > DC>Типы с плавающей точкой на пустом месте создают море тонких моментов > DC>(граблей), и если нет жёсткой необходимости их использовать, то лучше > DC>обойтись вычислениями с фиксированной точкой. > Я не понимаю, откуда такая фобия? Почему вы боитесь одних алгоритмов, при > этом используете другие менее отлаженные и оптимизированные без зазрения > совести.
:/ Мда-а-а. А откуда ты узнал какие алгоритмы я использую? Мелофон? Или со
спутника узрел? При чём тут алгоритмы? Значения с плавающей точкой
значительно более капризны при вычислениях, хотя бы потому, что вычисления
с ними не точные, за счёт представления. Я не вижу смысла использовать их
бездумно.
> DC>Короче, это я к тому, что пихать float везде очень неразумно. > Хочу вас успокоить с типами с фиксированной точкой проблем гораздо больше, > и главная это переполнение.
Да ну? А с чем ещё?
> А вторая -- этого типа нет в стандарте, и всегда приходится пользовать
велосипед. Почему нельзя тип fixed (16.16) добавить в стандарт на ряду с
float и double? Интересно что мешает?
Да и float с double поддерживаются на довольно низком уровне. А
универсального решения всё равно не напишешь, т.к. области могут быть очень
разными.
Posted via RSDN NNTP Server 2.1 beta
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, dr.Chaos, Вы писали:
>> Здравствуйте, dr.Chaos, Вы писали: >> >> DC>Типы с плавающей точкой на пустом месте создают море тонких моментов >> DC>(граблей), и если нет жёсткой необходимости их использовать, то лучше >> DC>обойтись вычислениями с фиксированной точкой. >> Я не понимаю, откуда такая фобия? Почему вы боитесь одних алгоритмов, при >> этом используете другие менее отлаженные и оптимизированные без зазрения >> совести. DC>:/ Мда-а-а. А откуда ты узнал какие алгоритмы я использую? Мелофон? Или со DC>спутника узрел? При чём тут алгоритмы? Значения с плавающей точкой DC>значительно более капризны при вычислениях, хотя бы потому, что вычисления DC>с ними не точные, за счёт представления. Я не вижу смысла использовать их DC>бездумно.
Очень просто если не используете float и double, для вычислений то вы используете что то другое :P
И миелофон не понадобился. И потом вам нужна процессорная мощь и распределенные вычисления, но не нежны типы данных с плавающей точкой?
Очень, очень странно. Для чего же вы используете вычислительную технику? Для вывода спец эффектов в висте?
>> DC>Короче, это я к тому, что пихать float везде очень неразумно. >> Хочу вас успокоить с типами с фиксированной точкой проблем гораздо больше, и главная это переполнение. DC>Да ну? А с чем ещё?
Много еще overflow, underflow, математические функции и т.п. но в ряде узкоспециализированных задачах он просто незаменимый.
И встроенная эффективная поддержка в компилятор была бы очень полезна. Тем более что это не сложно.
>> А вторая -- этого типа нет в стандарте, и всегда приходится пользовать DC>велосипед. Почему нельзя тип fixed (16.16) добавить в стандарт на ряду с DC>float и double? Интересно что мешает? DC>Да и float с double поддерживаются на довольно низком уровне. А DC>универсального решения всё равно не напишешь, т.к. области могут быть очень DC>разными.
А кто говорит об общем решении. Но эти типы очень широко и успешно применяются. А fixed тоже очень простой тип его очень легко поддерживать.
Специально как промежуточного звена между int и float для тех кому религия запрещает пользоваться типами float и double.
Так почему такого типа в стандарте нет? зато std::size_t есть. Я негодую!
но это тебя безусловно пугает сильнее чем operator"Suffix". А вот double мы досих пор опасаемся. Пользуясь бустом бояться чисел с плавающей точкой. Просто фобия какая-то, аж смешно 
double и float был даже в C где нет апаратной поддержки применяется эмуляция и это всё в стандарте есть.
. Что надо — то и запрашивай. На проектах уровня HelloWorld — может это и напряжно. Я же предпочитаю писать не
хотя в x86 регистры сопроцессора именно такие
