Здравствуйте, Andrei F., Вы писали:
AF>http://herbsutter.spaces.live.com/blog/cns!2D4327CC297151BB!330.entry AF>Похоже, что сборки мусора и/или многопоточности в стандарте не будет, а сам стандарт будет выпущен в лучшем случае в 2009 году. Результат вполне закономерный, я не удивлен.
*мдя* как так, какого на%%% он тогда нужен. если в стандарте не будет много поточности. щас все системы идут по пути распараллеливания и переходя на плаформы не x86, а тут её нет да еще и только в 2009.
Сборщик мусора -- вы серьёзно, и без него жили. Но зато, наверняка, добавят новых гвоздей в крышку гроба языка C. Первые два гвозди + + к языку C уже были потом добавились указатели на члены класса, SFINAE, появился stl и boost. Все эти навороты только убивают язык. Такое ощущение что люди не отдают себе отчета и пытаются рекурсивно добавлять всякие рюшечки, навороты и изврещения. То что сделал Александреску ... просто слов нет, это операции на глазах через анальное отверстие, а теперь это делают стандартом. А товарищи из буста нагородили такого... да, это конешно всё замечательно, но это всё построено на заплатках и надстройках и ошибках в работе с шаблонами в разных компиляторах. И еще непонимаю эту манию писать длинные namespace-ы с деситикратной вложенностью как в яве. Зачем?.
Почему нельзя сделать сам язык более выразительным и простым, зачем городить такие огороды и тем более для чего это всё включать в стандарт? Чтоб тотом было тяжелее избавляться от этих раковых опухолей. Народ уже активно пользуется stl, boost-ом, и помоему это не совсем хорошо. Потому что всё это придётся поддерживать в последующих реинкарнациях компиляторах C++. В умелых руках stl, boost замечательный инструмент, который позволяет быстро решать ряд задачь, но:
1. во первых не забывайте для использования таких библиотек надо иметь очень хорошие познания в довольно неочевидных закоулках языка C++ а этим похвастаться никто не может, постоянно выясняется что есть ещё что то чего не знал.
(Я тут в форуме наблюдал сообщения типа помогите написать шаблон. Почему? Потому шаблоны в том виде что есть не являются тем средством которое позволяет писать код естественным образом. Это всего лиш жалкое подобие метаязыка. И написание шаблонов для некоторых задач превращается в искуство или вообще в задачу которая не имеет решения и приходится делать обходные пути. Шаблоны в том виде что есь -- зло. Для для узкого класса задач они незаменимы, но то что с ними делают в бусте... Я вообще не понимаю как люди досих пор пишут компиляторы C++ которые это компилируют.)
2. всё вот это придётся передавать следующим поколениям программистов, а они уже сейчас смотрят на это с недоверием. Вот вы к примеру знаете все тонкости этого ... языка и понимаете в деталях как это работает и поэтому аккуратно обходите грабли на которые остальные регулярно наступают. А способны ли вы расказать все тонкости и подводные камни другому человеку или (группе студентов) что бы они всё поняли так же и как вы в совершенстве овладели этими знаниями. Скорее всего нет.
3. все готорвые решения имеющиеся в boost и stl ведут как ни странно к деградации программистов. находятся люди которые не удалить в строке скобочки средствами stl. не смотря на то что на языку C эта проблемма решается двумя строчками кода. Люди даже не знают как устроены сбалансированные деревься. Бегают итератором по мапам и удаляют элементы и недоумевают почему глючит. Даже поиск максимума превращается в тяжелейшую неразрешимую проблемму без всех этих мягких и удобных средств stl в которых они не ориентируются. Все эти плюшевые подушечки и готовые решения превращают язык C++ в быдлокодерский язык. И ведут к привыканию к комфортным креслам. А расслабляться не стоит. Враг не дремлет.
4. С введением столь сложного стандарта, никому в голову не придёт писать свой компилятор C++0x и выживут только компиляторы основанные на старых C++ наследуя все косяки и грабли заложенные в них. Вообще-то это тоже очень печально. Т.к. есть огромное число процессоров и микроконтроллеров для которых язык типа C++ был бы не заменим, особенно в условиях много поточности. Но там толь asm и в лучшем случае C. т.к. это очень простые для написания компиляторы.
Более того всё совершенствования языка свёдётся и исправления всё новых и новых косяков которые будут появляться в геометрической прогрессии. Так что это тоже приведёт к торможению развития.
5. и еще все библиотеки как-то нацелены на совершенно общие задачи, и никак не нацелены на упрощение решения типовых задач и на повышения читабельности и выразительности кода. Почему в boost.threads не команды sleep(double seconds)? неужели столь ненужная функция. А эта любось к лямда вычислениям -- я досих пор не понимаю какого -- в каких практических задачах без этого нельзя обойтись?
Я вот лично не понимаю почему язык нельзя сделать много уровневым как слоёный пирог.
0 уровень разметка (аля html) что бы можно было вставлять в текст картинки и прикреплять файлы, делать интерактивной коментарии и примеры.
1 уровень. мета язык — язык который расширяет функциональность парсера, компилятора, кодогенератора и линковщика. (код который нужен до компиляции, вовремя и после)
2 уровень собственно алгоритмический язык программирования (будующий исполняемый код)
3 декларативный уровень в языке был бы очень к стати
3' уровень описания не алгоритмов, а процессов (как в vhdl)
можно и четвёртый уровень добавить управления кодом (проверка, проверка соблюдения правил, рекомендации и инвариантов).
+набор библиоткек для решения повседневных задач (обработка отказов и событий, строки, кодировки теста, математика, время, память, ввод/вывод, файловая система, многопоточность, сеть и взаимодействие cs p2p, гуи, контейнеры, контейнеры для данных на внешних носителях, и ряд других)
Поясню
2 описывает пошагово что надо сделать для решения задачи
3 описывает что есть и что надо получить, а 1-ый сам ищет алгоритм для решения задачи
3' описывает взаимосвязи и события в системе (и может быть использован для проверки правильности работы программы или для синтеза схем как в программируемой логике)
Что то я разошелся. Итого если так пойдёт то смерь языка C++ не загорами, язык C++0x может родиться вообще мёртвым языком.
Мне нужен простой в изучении, выразительный, понятный, легко раширяемы и мощный язык, генерящий эффективный код, который легко портировать на разные платформы с поддержкой распараллеливания (не просто много поточности но и связанных с этим типичных задач). Неужели я одинок в подобного рода желаниях? Неужели всех устраивает то что есть?
Може есть такие языки? а я не вкурсе
Здравствуйте, AndrewVK, Вы писали:
Вроде не где не ругался. Видимо термин злое%&чий вызвал такую реакцию. Но это не мат.
А так обещаю впредь сдерживаться и исключит подобные выражения из постов.
Но суть такая простой модификацией, новое поколения языка получить не удасться. А что что щас делают тупиковый путь развития.
Здравствуйте, VladD2, Вы писали:
VD>В обом случае обещаю, что после осваения хотя бы одного ФЯ твои взгляды на программирование серьезно расширятся.
VD>Единственная проблема — С++ перестанет казаться самым подходящим языком для большинства применений.
Здравствуйте, kov_serg, Вы писали:
_>*мдя* как так, какого на%%% он тогда нужен. если в стандарте не будет много поточности. щас все системы идут по пути распараллеливания и переходя на плаформы не x86, а тут её нет да еще и только в 2009.
Потоки в С++ замечательно работают уже мноооооооооооого лет. Сейчас просто стандартизуют семантику модели памяти.
С точки зрения прикладного программиста — ничего особо серьезного.
_>Сборщик мусора -- вы серьёзно, и без него жили. Но зато, наверняка, добавят новых гвоздей в крышку гроба языка C. Первые два гвозди + + к языку C уже были потом добавились указатели на члены класса, SFINAE, появился stl и boost.
Указатели на члены класса — полезная вещь. Хотя сделали их и не очень красиво.
_>Все эти навороты только убивают язык. Такое ощущение что люди не отдают себе отчета и пытаются рекурсивно добавлять всякие рюшечки, навороты и изврещения. То что сделал Александреску ... просто слов нет, это операции на глазах через анальное отверстие, а теперь это делают стандартом. А товарищи из буста нагородили такого... да, это конешно всё замечательно, но это всё построено на заплатках и надстройках и ошибках в работе с шаблонами в разных компиляторах. И еще непонимаю эту манию писать длинные namespace-ы с деситикратной вложенностью как в яве. Зачем?.
Затем же, зачем и в Java — убрать столкновения имён.
_>1. во первых не забывайте для использования таких библиотек надо иметь очень хорошие познания в довольно неочевидных закоулках языка C++ а этим похвастаться никто не может, постоянно выясняется что есть ещё что то чего не знал.
И что? Я спокойно использовал Boost ещё когда не особо понимал тонкости метапрограммирования. Точно так же, не каждый новый программист на какой-нибудь Java понимает все тонкости работы библиотек, что не мешает ему ими пользоваться.
_>3. все готорвые решения имеющиеся в boost и stl ведут как ни странно к деградации программистов. находятся люди которые не удалить в строке скобочки средствами stl. не смотря на то что на языку C эта проблемма решается двумя строчками кода. Люди даже не знают как устроены сбалансированные деревься. Бегают итератором по мапам и удаляют элементы и недоумевают почему глючит. Даже поиск максимума превращается в тяжелейшую неразрешимую проблемму без всех этих мягких и удобных средств stl в которых они не ориентируются. Все эти плюшевые подушечки и готовые решения превращают язык C++ в быдлокодерский язык. И ведут к привыканию к комфортным
креслам. А расслабляться не стоит. Враг не дремлет.
И что? Предлагается убрать все библитеки и писать всё целиком с нуля?
Неконструктивно.
Те же map/vector/list в С++, кстати, работают логическ ну точно так же, как и в куче других языков.
_>4. С введением столь сложного стандарта, никому в голову не придёт писать свой компилятор C++0x и выживут только компиляторы основанные на старых C++ наследуя все косяки и грабли заложенные в них. Вообще-то это тоже очень печально. Т.к. есть огромное число процессоров и микроконтроллеров для которых язык типа C++ был бы не заменим, особенно в условиях много поточности. Но там толь asm и в лучшем случае C. т.к. это очень простые для написания компиляторы.
Написание компилятора С++ для платформы, на которой есть компилятор С — задача достаточно простая (спросите у Комо-С++). Естественно, если не портировать всякие RTTI и исключения.
_>5. и еще все библиотеки как-то нацелены на совершенно общие задачи, и никак не нацелены на упрощение решения типовых задач и на повышения читабельности и выразительности кода. Почему в boost.threads не команды sleep(double seconds)? неужели столь ненужная функция. А эта любось к лямда вычислениям -- я досих пор не понимаю какого -- в каких практических задачах без этого нельзя обойтись?
Это ты про "static void boost::thread::sleep(const xtime& xt);"? У нее, кстати, наносекундное разрешение на поддерживаемых системах...
_>2 описывает пошагово что надо сделать для решения задачи _>3 описывает что есть и что надо получить, а 1-ый сам ищет алгоритм для решения задачи _>3' описывает взаимосвязи и события в системе (и может быть использован для проверки правильности работы программы или для синтеза схем как в программируемой логике)
Это всё только на бумаге выглядит хорошо. А на практике выливается в:
1) Ужас, разрушение и VisualBasic.
2) Непонятную смесь контролов.
3) Жуткое смешение слоёв.
Здравствуйте, Don Reba, Вы писали:
_>> И еще непонимаю эту манию писать длинные namespace-ы с деситикратной вложенностью как в яве. Зачем?. DR>Просто придирка: в Яве нет вложенных пространств имён.
Почему же? Есть.
Просто в Java нет _относительных_ пространств имён.
Я не говорю об отдельных недостатках. Я хочу сказать что движемся не туда.
а теперь по мелочи:
>Потоки в С++ замечательно работают уже мноооооооооооого лет. Сейчас просто стандартизуют семантику модели памяти.
в виде _begin_thred и pthread_* -- это просто каменный век. Всё остальное это не стандарт это сторонние библиотеки!
Я говорю о поддержке многопоточности в стандарте языка. Иначе все кому не лень пользуются кто чем. Почему? Видимо то что существует уже
мнооооого лет не устраивает. И вообще много поточность это не просто набор методов для запуска потоков, процессов и фиберов.
Это еще поддержка модели памяти с обектами которые следят за количеством ссылок на них. И синхронизация и обмен данными.
И прозрачно описанный способ завершения потока. Например выкидывание исключения из функций синхронизации или ожидания.
Много всего. Чего приходиться или искать или заниматься велосипедостроением.
>С точки зрения прикладного программиста — ничего особо серьезного.
Неужели. И как обычно решаются например обработка сигнала на завершение потока в C++, где поддерка TLS ?
Самое прикольное что если в Linux у вас поток поделил на ноль то это просто катострофа а если обратился по NULL то конец света.
О какой многопоточности может идти речь. А между прочим все эти проблеммы можно решить именно комптлятором и не валить на ось что там нет нормальной поддержки SEH.
>Указатели на члены класса — полезная вещь. Хотя сделали их и не очень красиво.
Некрасиво! да руки за такое отрывать надо
>Затем же, зачем и в Java — убрать столкновения имён.
Да ну, а мужики то не знают. А откуда они появились столкновения имён? Почему нельзя сделать стандарт без этого убожества. А namespace-ы пользовать только когда действительно два отдельных конкретных велосипеда конфликтуют
>>креслам. А расслабляться не стоит. Враг не дремлет. >И что? Предлагается убрать все библитеки и писать всё целиком с нуля?
Нет конешно. Просто констатирую факт. Но всё должно быть в языке естествено, а не так как щас. Приходится изучать кучу всего по большому счету совершенно ненужного. Что бы сделать элементарные вещи.
> Написание компилятора С++ для платформы, на которой есть компилятор С — задача достаточно простая (спросите у Комо-С++). Естественно, если не портировать всякие RTTI и исключения.
Не смешите мои тапочки! Попробуй как-нибуть, я на тебя посмотрю. Языки C для микроконтроллеров почти все не способны переварить то что генерит Комо-С++ (болле того он еще и не бесплатный и распостронять ты его не сможешь). И потом Комо стандарт поддерживает не идеально.
>Это ты про "static void boost::thread::sleep(const xtime& xt);"? У нее, кстати, наносекундное разрешение на поддерживаемых системах...
какая нафиг разница какое у неё разрешение. почему нет функции double getSleepPrecision();? почему просто нельзя сделать простую и понятную функцию void sleep(double dt)? и потом не заморачиваясь писать sleep(25e-6); ??? и нафига ей префикс boost::thread:: ?? это модно? или это придаёт чусво приобщения к вечности? код становиться короче и нагляднее если ей передавать не интервал, а конкретную дату?
>Это всё только на бумаге выглядит хорошо. А на практике выливается в: >1) Ужас, разрушение и VisualBasic. >2) Непонятную смесь контролов. >3) Жуткое смешение слоёв.
Я об этом и говорю, и чем дальше тем хуже и хуже. Мы уже имеем убогий язык C# и C++.NET VisualBasic уже давно не Basic (это же был язык для начинающих, а щас это основной язык быдлокодерства для аспшного веба). слово VisualBasic можно считать ругательством.
>Просто придирка: в Яве нет вложенных пространств имён.
Посмотри исходники openOffice
Здравствуйте, kov_serg, Вы писали:
>>Просто придирка: в Яве нет вложенных пространств имён. _>Посмотри исходники openOffice
Точки в названиях всего лишь условность. В Яве плоские упаковки. Вложенных пространств имён, как в С++, там нет. Собственно, в Яве действительно мало смысла так делать. В С++ вложенность позволяет ограничивать видимость имён слоями.
Здравствуйте, Don Reba, Вы писали:
DR>Точки в названиях всего лишь условность. В Яве плоские упаковки. Вложенных пространств имён, как в С++, там нет. Собственно, в Яве действительно мало смысла так делать. В С++ вложенность позволяет ограничивать видимость имён слоями.
Зачем? Зачем её делать слоями? Что бы мусор прятать под ковёр? Зачем так много лишних слоёв? Или наша цель что бы inteli-sence на правильно подсказывал? Но тогда нам надо знать куда ходить в какой складке спрятано то что нам надо. Да у виглядит убого a::b::c::d::e<a::b::c::e::f,a::b::c::e::g> z(a::b::c::d::z3);
Здравствуйте, kov_serg, Вы писали:
DR>>Точки в названиях всего лишь условность. В Яве плоские упаковки. Вложенных пространств имён, как в С++, там нет. Собственно, в Яве действительно мало смысла так делать. В С++ вложенность позволяет ограничивать видимость имён слоями. _>Зачем? Зачем её делать слоями? Что бы мусор прятать под ковёр? Зачем так много лишних слоёв? Или наша цель что бы inteli-sence на правильно подсказывал? Но тогда нам надо знать куда ходить в какой складке спрятано то что нам надо. Да у виглядит убого a::b::c::d::e<a::b::c::e::f,a::b::c::e::g> z(a::b::c::d::z3);
Тебе рассказать про using?
Namespace'ы нужны для предотвращения конфликта имён. Например, если не будет namespace'ов, то ты получишь конфликт, если подключишь thread из Boost'а и thread из Intel TBB.
Здравствуйте, kov_serg, Вы писали:
>>Потоки в С++ замечательно работают уже мноооооооооооого лет. Сейчас просто стандартизуют семантику модели памяти. _>в виде _begin_thred и pthread_* -- это просто каменный век. Всё остальное это не стандарт это сторонние библиотеки!
И что?
_>Это еще поддержка модели памяти с обектами которые следят за количеством ссылок на них.
Так, что значат слова "модель памяти" ты не знаешь.
А указатели с подсчётом ссылок есть уже давно — boost::shared_ptr, boost::intrusive_ptr. В следующем Стандарте они тоже будут.
_>И синхронизация и обмен данными.
Синхронизация, естественно, будет в Стандарте.
_>И прозрачно описанный способ завершения потока.
Выход из верхней функции потока.
_>Например выкидывание исключения из функций синхронизации или ожидания.
??
_>Много всего. Чего приходиться или искать или заниматься велосипедостроением.
В комитете по стандартизации глупые люди не сидят, они подумали об основных вещах.
>>С точки зрения прикладного программиста — ничего особо серьезного. _>Неужели. И как обычно решаются например обработка сигнала на завершение потока в C++, где поддерка TLS ? http://en.wikipedia.org/wiki/C%2B%2B0x#Thread-local_storage ?
_>Самое прикольное что если в Linux у вас поток поделил на ноль то это просто катострофа а если обратился по NULL то конец света. _>О какой многопоточности может идти речь. А между прочим все эти проблеммы можно решить именно комптлятором и не валить на ось что там нет нормальной поддержки SEH.
Как ты это решишь "компилятором"? Деление на ноль — это аппаратная ошибка, компилятор о ней ничего не знает. В Линуксе она вызывает соответствующий сигнал.
Если ты предлагаешь расставлять проверку на ноль перед каждым разыменованием к указателя — можешь идти лесом.
>>Указатели на члены класса — полезная вещь. Хотя сделали их и не очень красиво. _>Некрасиво! да руки за такое отрывать надо
Кстати, предложи как сделать их красиво.
>>Затем же, зачем и в Java — убрать столкновения имён. _>Да ну, а мужики то не знают. А откуда они появились столкновения имён? Почему нельзя сделать стандарт без этого убожества. А namespace-ы пользовать только когда действительно два отдельных конкретных велосипеда конфликтуют
Столкновения имён появились из-за того, что программисты не владеют телепатией. И два программиста вполне вполне могут решить использовать одно имя (даже внутри одного проекта).
Да, можно и без пространств имён обойтись — если делать префиксы к каждому имени. Ну как в SVN API, например: svn_get_status(..), svn_list_files(). Ничего не напоминает?
>>И что? Предлагается убрать все библитеки и писать всё целиком с нуля? _>Нет конешно. Просто констатирую факт. Но всё должно быть в языке естествено, а не так как щас. Приходится изучать кучу всего по большому счету совершенно ненужного. Что бы сделать элементарные вещи.
В любом другом языке так же. Нужно изучить кучу всякого ненужного, чтобы написать любую нормальную программу.
>> Написание компилятора С++ для платформы, на которой есть компилятор С — задача достаточно простая (спросите у Комо-С++). Естественно, если не портировать всякие RTTI и исключения. _>Не смешите мои тапочки! Попробуй как-нибуть, я на тебя посмотрю. Языки C для микроконтроллеров почти все не способны переварить то что генерит Комо-С++ (болле того он еще и не бесплатный и распостронять ты его не сможешь).
Я не пробовал. Но компиляторы на базе Комо видел самолично. А еще есть LLVM-C, там на выходе вообще почти что ассемблер, записаный на С. Его вообще кто угодно скомпилирует.
Да, и я забыл про GCC — портирование его на новую архитектуру делается написание (буквально) пары файлов.
_>И потом Комо стандарт поддерживает не идеально. Комо — это САМЫЙ СОВМЕСТИМЫЙ со Стандартом компилятор.
>>Это ты про "static void boost::thread::sleep(const xtime& xt);"? У нее, кстати, наносекундное разрешение на поддерживаемых системах... _>какая нафиг разница какое у неё разрешение. почему нет функции double getSleepPrecision();? почему просто нельзя сделать простую и понятную функцию void sleep(double dt)? и потом не заморачиваясь писать sleep(25e-6); ???
Потому как с double'ом ты требуешь наличия сопроцессора или его эмуляции. Например, на MIPS'е где я использую boost::thread сопроцессора нет, а эмуляцию мне ставить не хочется. Функции getSleepPrecision() нет потому, что её нет в обычных threading API — в Windows и POSIX Threads гарантируется только, что sleep() будет работать не меньше указанного времени.
Но если так хочется "sleep(double seconds)" — возьми и напиши. Какие проблемы?
_>и нафига ей префикс boost::thread:: ?? это модно? или это придаёт чусво приобщения к вечности?
Про namespace'ы ты не знаешь, мы уже это установили.
_>код становиться короче и нагляднее если ей передавать не интервал, а конкретную дату?
Какую "конкретную дату", ты о чём?
_>Я об этом и говорю, и чем дальше тем хуже и хуже. Мы уже имеем убогий язык C# и C++.NET VisualBasic уже давно не Basic (это же был язык для начинающих, а щас это основной язык быдлокодерства для аспшного веба). слово VisualBasic можно считать ругательством.
Чем дальше — тем хуже, это как раз в твоём случае будет с мнимым разделением между слоями.
Нужен С++ с возможностью делать разметку отдельно от логики? Берём HTMLayout и используем. Какие проблемы-то? Зачем своё понимание "слоёв" навязывать всем остальным?
Здравствуйте, AndrewVK, Вы писали:
C>>со Стандартом компилятор. AVK>О как, с большой буквы. Это по типу как Библия?
Сокращения имени собственного — названия "Стандарт ISO-IEC <номер-такой-то>".
Здравствуйте, Cyberax, Вы писали:
C>Namespace'ы нужны для предотвращения конфликта имён. Например, если не будет namespace'ов, то ты получишь конфликт, если подключишь thread из Boost'а и thread из Intel TBB.
Я же говорю про стандарт. Я хочу нормальный стандарт, чтобы многопоточность поддерживалась языком единообразно независимо от платформы. Что бы мне небыло необходимости подключать OpenMPI, IntelTBB, boost.thread, glib и т.п.
почему нельзя сделать что то вида:
include "velosiped1" into namespace v1;
include "velosiped2" into namespace v2;
include <threads>
void fn() {
sleep(1e-3);
v1::sleep(10);
v2::usleep(1000);
}
class A {
public virtual stdcall abstart:
int f1(int x,int y);
int f2(int z);
...
};
Здравствуйте, kov_serg, Вы писали:
C>>Namespace'ы нужны для предотвращения конфликта имён. Например, если не будет namespace'ов, то ты получишь конфликт, если подключишь thread из Boost'а и thread из Intel TBB. _>Я же говорю про стандарт. Я хочу нормальный стандарт, чтобы многопоточность поддерживалась языком единообразно независимо от платформы. Что бы мне небыло необходимости подключать OpenMPI, IntelTBB, boost.thread, glib и т.п.
Да какая разница! В Стандарт С++ всё запихать невозможно. И тогда придется писать: "mylib_point_2d" и "mylib_window" вместо нормального "point_2d" и "window". Так как шансы на конфликт имён с какой-нибудь бибилиотекой в будущем — почти 100%.
Да, и Стандарт никогда не заменит ВСЕ возможные варианты многопоточности. Это не нужно и невозможно.
_>Почему от подобная запись противоречит религии?
Потому как работать не будет. А тебе никто не мешает делать "using namespace blah" и писать без некрасивых "::".
Здравствуйте, Cyberax, Вы писали:
C>А указатели с подсчётом ссылок есть уже давно — boost::shared_ptr, boost::intrusive_ptr. В следующем Стандарте они тоже будут.
если оно будет в том же виде что и в boost то нафиг не надо.
_>>И синхронизация и обмен данными. C>Синхронизация, естественно, будет в Стандарте.
Слово естественно очень пугает.
_>>И прозрачно описанный способ завершения потока. C>Выход из верхней функции потока.
....обещал не ругаться матом... ты посмотри на все службы в виндовз и на демоны в линухе. как устроен процесс завершения службы. и после этого ты хочеш сказать что все делают по стандарту? нафигаже они посылают запрос и ждут некоторое время? почему службы умудряются не отвечать минутами? неужели тяжело это было зарание предусмотреть?
_>>Например выкидывание исключения из функций синхронизации или ожидания. C>??
Что непонятного, генерация исключения в потоку самый простой и очевидный способ его завершения для C++ c его объектами, разве не так?
_>>Много всего. Чего приходиться или искать или заниматься велосипедостроением. C>В комитете по стандартизации глупые люди не сидят, они подумали об основных вещах.
Конешно не глупые, но движимся мы не вту сторону. имхо.
>>>С точки зрения прикладного программиста — ничего особо серьезного. _>>Неужели. И как обычно решаются например обработка сигнала на завершение потока в C++, где поддерка TLS ?
Где модификатор на уровне auto, register, static, volatile, где модификатор типа threadvar ??? C>http://en.wikipedia.org/wiki/C%2B%2B0x#Thread-local_storage ?
И еще докле мы будем в качестве констуктора и деструктора писать имя класса???? почему нельзя заредервировать имена типа ctor и dtor???
_>>Самое прикольное что если в Linux у вас поток поделил на ноль то это просто катострофа а если обратился по NULL то конец света. _>>О какой многопоточности может идти речь. А между прочим все эти проблеммы можно решить именно комптлятором и не валить на ось что там нет нормальной поддержки SEH. C>Как ты это решишь "компилятором"? Деление на ноль — это аппаратная ошибка, компилятор о ней ничего не знает. В Линуксе она вызывает соответствующий сигнал.
Ха. так что мешает компилятору генерить код который позволяет преобразовать сигнал в исключение??? ведь из обработчика сигнала мы спокойно можем передать управление в любую точку программы, в том числе и на вызов исключения. (единственное что gcc генерит очень забавный код который не позволяет генерить исключения где угодно). Если интересно могу подробно в деталях рассказать как сделать, если интересно. C>Если ты предлагаешь расставлять проверку на ноль перед каждым разыменованием к указателя — можешь идти лесом.
Что я больной, если это всё аппаратно проверяется, а вот если нет то именно компилятор должен расставлять эти проверки.
>>>Указатели на члены класса — полезная вещь. Хотя сделали их и не очень красиво. _>>Некрасиво! да руки за такое отрывать надо C>Кстати, предложи как сделать их красиво.
Все велосипеды написанные на эту темы сводятся к написанию переходников, почему компилятор сам не может генерить подобное? может просто в стандарте этого нет.
>>>Затем же, зачем и в Java — убрать столкновения имён. _>>Да ну, а мужики то не знают. А откуда они появились столкновения имён? Почему нельзя сделать стандарт без этого убожества. А namespace-ы пользовать только когда действительно два отдельных конкретных велосипеда конфликтуют C>Столкновения имён появились из-за того, что программисты не владеют телепатией. И два программиста вполне вполне могут решить использовать одно имя (даже внутри одного проекта).
Отдельные проекты, да конешно. Но те кто делает стандарт, зачем им телепатия если есть интернет??? они что досих пор не смогли договориться?
C>Да, можно и без пространств имён обойтись — если делать префиксы к каждому имени. Ну как в SVN API, например: svn_get_status(..), svn_list_files(). Ничего не напоминает?
нет просто щас пространство имён есть как данность.
например надо писать
#include <string>
using namespace std
почему нельзя сделать наоборот
#include <string> into namespace std
???
а поумолчанию не включать namespace?
Да чусвствую щас приведёте кучу примеров почему нельзя, но все они связаны именно с тем что объектники так генеряться.
>>>И что? Предлагается убрать все библиотеки и писать всё целиком с нуля? _>>Нет конешно. Просто констатирую факт. Но всё должно быть в языке естествено, а не так как щас. Приходится изучать кучу всего по большому счету совершенно ненужного. Что бы сделать элементарные вещи. C>В любом другом языке так же. Нужно изучить кучу всякого ненужного, чтобы написать любую нормальную программу.
Я не спорю, что нужно долго учится, но метапрограмирование на templata-ах это не то чему надо учиться.
>>> Написание компилятора С++ для платформы, на которой есть компилятор С — задача достаточно простая ... C>Я не пробовал. Но компиляторы на базе Комо видел самолично. А еще есть LLVM-C, там на выходе вообще почти что ассемблер, записаный на С. Его вообще кто угодно скомпилирует.
Ёмоё. так останется только компилятор комо, и все его баги будут включены в стандарт, ибо без них все имеющиеся библиотеки и программы работать не будут.
C>Да, и я забыл про GCC — портирование его на новую архитектуру делается написание (буквально) пары файлов.
Гон, не всё так просто. Попроюуй как-нибуть.
_>>И потом Комо стандарт поддерживает не идеально. C> Комо — это САМЫЙ СОВМЕСТИМЫЙ со Стандартом компилятор.
Да, да конешно. И не поминай имя Комо C++ в суе.
>>>Это ты про "static void boost::thread::sleep(const xtime& xt);"? У нее, кстати, наносекундное разрешение на поддерживаемых системах... _>>какая нафиг разница какое у неё разрешение. почему нет функции double getSleepPrecision();? почему просто нельзя сделать простую и понятную функцию void sleep(double dt)? и потом не заморачиваясь писать sleep(25e-6); ??? C>Потому как с double'ом ты требуешь наличия сопроцессора или его эмуляции. Например, на MIPS'е где я использую boost::thread сопроцессора нет, а эмуляцию мне ставить не хочется. Функции getSleepPrecision() нет потому, что её нет в обычных threading API — в Windows и POSIX Threads гарантируется только, что sleep() будет работать не меньше указанного времени.
Эмуляции испугался, а буст за собой таскаеш Волков бояться в лес не ходить. И потом есть числа с фикированной точкой. Всё же упирается в компилятор, а не в MIPS. Реализация double может быть разной не обязательно IEEE-шной. Да что бы преобразовать double в интервал для ожидания надо всего несколько инструкций пара андов и несколько сдвигов и сложений. C>Но если так хочется "sleep(double seconds)" — возьми и напиши. Какие проблемы?
Так и сделаю. Но мне надо чтобы если я написал sleep(3.1536e7) он терпеливо ждал сигнала остановки потока и выкидывал исключение типа abort
Здравствуйте, Cyberax, Вы писали:
_>>Почему от подобная запись противоречит религии? C>Потому как работать не будет. А тебе никто не мешает делать "using namespace blah" и писать без некрасивых "::".
Да не мешает, я везде пишу using namespace.
Но ответь мне на простой вопрос почему в описании С++0x везде написано std::size_t ???
Неужели просто size_t это уже не достаточно готично?
ps: Когда то давно было задумано что sizeof(int)=sizeof(register) равен размеру регистра, а sizeof(long)=sizeof(void*) размеру указателя. но это не в тему...
Здравствуйте, kov_serg, Вы писали:
C>>А указатели с подсчётом ссылок есть уже давно — boost::shared_ptr, boost::intrusive_ptr. В следующем Стандарте они тоже будут. _>если оно будет в том же виде что и в boost то нафиг не надо.
Предложи лучший вариант...
C>>Синхронизация, естественно, будет в Стандарте. _>Слово естественно очень пугает.
Я слабо представляю библиотеку для работы с многопоточностью без примитивов синхронизации. Ну кроме Erlang'а, разве что.
_>....обещал не ругаться матом... ты посмотри на все службы в виндовз и на демоны в линухе. как устроен процесс завершения службы. и после этого ты хочеш сказать что все делают по стандарту? нафигаже они посылают запрос и ждут некоторое время? почему службы умудряются не отвечать минутами? неужели тяжело это было зарание предусмотреть?
Причём тут процессы? Ты вообще понимаешь, что выход из потока и завершение программы с помощью управляющего сигнала — это вообще разные действия?
C>>?? _>Что непонятного, генерация исключения в потоку самый простой и очевидный способ его завершения для C++ c его объектами, разве не так?
Не так. Это неправильный подход.
_>>>Неужели. И как обычно решаются например обработка сигнала на завершение потока в C++, где поддерка TLS ? _>Где модификатор на уровне auto, register, static, volatile, где модификатор типа threadvar ???
Слушай, ты вообще читаешь что тебе пишут?
A new thread-local storage duration (in addition to the existing static, dynamic and automatic) has been proposed for the next standard. Thread local storage will be indicated by the storage specifier thread_local.
Т.е. "thread_local SomeObject var;"
C>>http://en.wikipedia.org/wiki/C%2B%2B0x#Thread-local_storage ? _>И еще докле мы будем в качестве констуктора и деструктора писать имя класса???? почему нельзя заредервировать имена типа ctor и dtor???
А зачем?
C>>Как ты это решишь "компилятором"? Деление на ноль — это аппаратная ошибка, компилятор о ней ничего не знает. В Линуксе она вызывает соответствующий сигнал. _>Ха. так что мешает компилятору генерить код который позволяет преобразовать сигнал в исключение???
Из-за того, что это невозможно сделать корректно в общем случае.
_>ведь из обработчика сигнала мы спокойно можем передать управление в любую точку программы, в том числе и на вызов исключения. (единственное что gcc генерит очень забавный код который не позволяет генерить исключения где угодно). Если интересно могу подробно в деталях рассказать как сделать, если интересно.
Я прекрасно знаю как работает SEH, table-driven exceptions в GCC и почему асинхронные исключения в MSVC — плохая вещь.
C>>Если ты предлагаешь расставлять проверку на ноль перед каждым разыменованием к указателя — можешь идти лесом. _>Что я больной, если это всё аппаратно проверяется, а вот если нет то именно компилятор должен расставлять эти проверки.
Ничего он не должен... Обращение по нулевому указателю и деление на ноль — это ОШИБКИ. Точно такая же, как обращение к удаленному объекту.
Их можно сделать штатным поведением, но это потребует слишком больших жертв в скорости и простоте C++.
C>>Кстати, предложи как сделать их красиво. _>Все велосипеды написанные на эту темы сводятся к написанию переходников, почему компилятор сам не может генерить подобное? может просто в стандарте этого нет.
Переходники нужны для обхода слишком ограниченых указателей. Можно было бы сделать аналог делегатов в .NET, но это открывает банку с другими проблемами (с менеджментом памяти, в частности).
C>>Столкновения имён появились из-за того, что программисты не владеют телепатией. И два программиста вполне вполне могут решить использовать одно имя (даже внутри одного проекта). _>Отдельные проекты, да конешно. Но те кто делает стандарт, зачем им телепатия если есть интернет??? они что досих пор не смогли договориться?
Мда. Даже комментировать не буду — смешно.
C>>Да, можно и без пространств имён обойтись — если делать префиксы к каждому имени. Ну как в SVN API, например: svn_get_status(..), svn_list_files(). Ничего не ... _>а поумолчанию не включать namespace? _>Да чусвствую щас приведёте кучу примеров почему нельзя, но все они связаны именно с тем что объектники так генеряться.
Нет. Есть такое хорошее правило — не делать опасные действия по умолчанию или неявно. Твой пример очень грубо этот принцип нарушает.
C>>В любом другом языке так же. Нужно изучить кучу всякого ненужного, чтобы написать любую нормальную программу. _>Я не спорю, что нужно долго учится, но метапрограмирование на templata-ах это не то чему надо учиться.
Почему? Полезная вещь. Например, у меня библиотека контейнеров написана на них. Она работает быстрее стандартных string/vector/list.
Да, в Стандарт её включить нельзя из-за того, что я её затачивал только под свои задачи.
C>>Я не пробовал. Но компиляторы на базе Комо видел самолично. А еще есть LLVM-C, там на выходе вообще почти что ассемблер, записаный на С. Его вообще кто угодно скомпилирует. _>Ёмоё. так останется только компилятор комо, и все его баги будут включены в стандарт, ибо без них все имеющиеся библиотеки и программы работать не будут.
Почему?
C>>Да, и я забыл про GCC — портирование его на новую архитектуру делается написание (буквально) пары файлов. _>Гон, не всё так просто. Попроюуй как-нибуть.
Пробовал как-то для экспериментов. См.: ftp://ftp.axis.se/pub/users/hp/pgccfd/pgccfd-0.5.pdf
Или просто посмотри простые md-файлы в GCC.
C>>Потому как с double'ом ты требуешь наличия сопроцессора или его эмуляции. Например, на MIPS'е где я использую boost::thread сопроцессора нет, а эмуляцию мне ставить не хочется. Функции getSleepPrecision() нет потому, что её нет в обычных threading API — в Windows и POSIX Threads гарантируется только, что sleep() будет работать не меньше указанного времени. _>Эмуляции испугался, а буст за собой таскаеш
Те части Boost'а, которые я использую, имеют размер в килобайты.
_>И потом есть числа с фикированной точкой. Всё же упирается в компилятор, а не в MIPS. Реализация double может быть разной не обязательно IEEE-шной. Да что бы преобразовать double в интервал для ожидания надо всего несколько инструкций пара андов и несколько сдвигов и сложений.
Ага, чтобы пользователи double'а получили много неприятных сюрпризов.
Вот видишь, сколько твоё решение добавляет сложности, вместо простого указания наносекунд?
C>>Но если так хочется "sleep(double seconds)" — возьми и напиши. Какие проблемы? _>Так и сделаю. Но мне надо чтобы если я написал sleep(3.1536e7) он терпеливо ждал сигнала остановки потока и выкидывал исключение типа abort
Ээ...? Ну напиши нужную функцию. Какие проблемы-то?
это просто каменный век. Всё остальное это не стандарт это сторонние библиотеки!
а если обратился по NULL то конец света. 
да руки за такое отрывать надо 
VisualBasic уже давно не Basic (это же был язык для начинающих, а щас это основной язык быдлокодерства для аспшного веба). слово VisualBasic можно считать ругательством.