CC>>>Мне надо автоматический вызов конструкторов и деструкторов. Без макроёбства.
E>>Зачем тебе конструкторы, если ничего полезного в них ты сделать не сможеш по причиние невозможности вернуть ошибку ?
CC>Это почему ещё?
CC>Исключения работают, RTTI кстати тоже можно прикрутить, впрочем он очень редко нужен.
Как я понял из соседнего разговора — ты все смешал в кучу и не понимаеш, что SEH и плюсовые исключения — это совершенно разные вещи, хотя, конкретно в виндах у микрософтовского компилятора С++ исключения реализуются на базе SEH. Причем, чтобы это работало, внутри ядра должн быть закреплен фильтр SEH из userspace runtime который знает про формат сгенерированных твой любимой студией стековых фреймов. А надо сказать, этот формат для разных студий отличается. Ты хоть понимаеш каким диким говнокодом тебе придется осуществлять поддержку ++ ?

Что касается gcc то там С++ исключения реализованы по другому. Поэтому ты не сможеш просто-так собрать модуль ядра с поддержкой исключений. Более того, если ты вдруг собереш свой приплюсный виндово-ядровый код другим компилятором, или даже другой версией студии у тебя будет масса интересных сюрпризов. Ты вообще соображаеш какую говнояму ты таким образом выкапываеш для дальнейшей поддержки твоего кода ?

CC>>>Overloading нужна по параметрам: http://www.cplusplus.com/doc/tutorial/functions2/
E>>Ты можеш реализовать это с использованием gcc шного typeof и свитча внутри function-like макроса.
CC>Спасибо, макросы кушайте сами.
Ты даже не понял о чем я говорю.

CC>>>Вы когда нибудь отлаживали макросы? В вложенные макросы? Я — отлаживал, больше не хочу.
E>>Отлаживал и в огромных кол-вах. Надо просто уметь писать обобщенный код в макросах так, чтобы его было удобно отлаживать.
E>>Для этого надо писать не "в лоб", а немного подумать.
CC>Я в тот проект пришёл когда там линуксоиды со стажем все свои макросы уже написали. И занимались увлекательным делом — пытались с этим всем взлететь.
И, пока ты там не появился, весь в белом и на коне, ничего взлететь не могло. Ага, унылый сказочник.

E>>Думать можно начать с Степановского сишного прототипа STL.
CC>Ссылка была бы просто замечательна.
Спроси у гугла, ну или зайди на страницу Степанова — там есть ссылка.

CC>>>Вот только не надо мне рассказывать про макросы. Я их давным давно наелся.
E>>Ты просто не умееш с ними работать.
CC>
CC>Можно я буду так отвечать всем, кто кричит что С++ плохой?
А кто-то кричит что С++ плохой ? С++ — хороший, но внутри своей ниши, и не стоит пытаться тащить его во все без исключения места.

E>>>>2. Автоматический контроль за временем жизни переменных, RAII
E>>>>- Поскольку исключений нет, то и вернуть ошибку из конструктора невозможно.
CC>>>Исключения есть, лично писал kernel код с их использованием.
E>>Вот тут было интересно узнать подробности.
CC>Речь естественно про винду, в которой озаботились чтобы люди могли просто ловить исключения в ядре. Причём ловятся все, включая access violation.
Ты опять мешаеш всё в кучу, толи по глупости, толи из-за не понимания. Акксес виолайшен — это SEH исключение, оно из более низкого уровня абстракции. В языке С++ нет никаких access violation.

CC>Throw, сгенеренный компилятором, вызывает _CxxThrowException, которая всегда бросает стандартный виндовый SEH. Ядрёная реализация это делает через RtlRaiseException.
CC>Ловим __try / __except c EXCEPTION_EXECUTE_HANDLER. Бросаться стандартными классами исключений становится несколько сложнее.
CC>Из-за этой разницы стандартные юзермодные библиотеки без обработки напильником в кернеле использовать не получается.
Я знаком с этой кухней, поскольку лет 7-8 назад назад изучал возможность замены стандартного рантайма от студии на собственный.
_CxxThrowException — это функция из рантайма С++ предназначена для выполнения в user space mode.
RtlRaiseException — это опять же функция рантайма (но уже системного) и она предназначена для выполнения в user space mode.
При этом у С++ исключений есть специальный идентификатор, по которому его внутри фильтра можно отличить и разобрать фрейм сгенерированой студией. Но — формат этого фрейма а) немного разный для разных версий студии, б) недокументирован. А в твоем фильтре обработчике тебе надо разобрать этот формат, сделать unmagling типа RTTI и вызвать соответсвующие деструкторы.

CC>Можно прикрутить RTTI, можно сделать свои классы с блекджеком и всем что к нему прилагается.
Тебе это придется делать в любом случае — что бы понять что за исключение ты поймал и надо ли продолжать раскрутку стека.

Ты хоть понимаеш сколько малокоректного говнокда из полухаков это стоит ? Такое достойно только зеленого юнца воображающего себя кулхацкером. На самом деле — это даже не смех, а сплошные слезы глядя на этого горе-кулхакера.


E>>Особбенно совмещение неопределенных точек возврата с сишным кодом ядра.
CC>Не понял про что ты?
У сишного кода есть четко обозначеные точки возврата "наверх". Использование исключений дает неопределенныые точки возврата — раскрутка стека может произойти в любом месте. Сишный код такого эээ несколько не ожидает.

E>>Еще раз — ты просто не научился нормально работать с макросами.
CC>Судя по тому, как линуксоиды со стажем мудохаются со своими же макросами — с ними никто не умеет работать.
CC>Так что я не вижу смысла инвестировать свое время в напрасный труд.
Для начала тебе надо самому понять почему так, как ты описал выше, делать нельзя. К сожалению, ты неквалифицирован.

E>>>>Собственно очень хорошо видно, что оставшаяся огрызок от С++ никаких особых ++ по сравнению Си не дает, зато добавляет кучу всякого системного гемороя по поддержке ++ языка.
CC>>>Весь "системный геморрой" заключается в написании С++ stdlib для кернела с поддержкой SEH/Signal исключений. Очень сложно, да!
E>>То что ты сказал — на мой взгляд, сделать в линуксе невозможно. Но ты можеш поделить ссылкой на пример, если таковой конечно существует.
CC>Почему в винде это возможно (по факту) а в линухе вдруг нет?
Потому что в винде — это хак, в основе которого лежит использование того факта, что один единственый компилятор поддерживает механизм С++ исключений на основе системного механизма SEH.

E>>Даже для юзер спэйса, где нет кучи ограничений, написание поддержки С++ является проблемой. Через сколько там лет после первого релиза в андроиде появилася порт libstdc++ — можеш напомнить ?
CC>Спроси у авторов андроида почему у них руки из задницы.
Это у тебя руки из задницы.

E>>>>Вам такой С++ вообще нужен ?
CC>>>Мало того что нужен, мы его в винде давно уже используем.
E>>Не потому ли виндой сейчас уже невозможно пользоваться?
CC>Кому?
Нормальным разработчикам.

CC>>>Только линуксоиды упираются и цепляются за духовные скрепы С.
E>>Винда потихоньку помрет и туда ей дорога.
CC>Дада, она уже чёрти сколько лет вот вот помрёт. Осталось подождать ещё совсем немного.
А помрет она из-за таких вот горе-программистов.

CC>>>Мне надо автоматический вызов конструкторов и деструкторов. Без макроёбства.
E>>Зачем тебе конструкторы, если ничего полезного в них ты сделать не сможеш по причиние невозможности вернуть ошибку ?
CC>Это почему ещё?
CC>Исключения работают, RTTI кстати тоже можно прикрутить, впрочем он очень редко нужен.
Как я понял из соседнего разговора — ты все смешал в кучу и не понимаеш, что SEH и плюсовые исключения — это совершенно разные вещи, хотя, конкретно в виндах у микрософтовского компилятора С++ исключения реализуются на базе SEH. Причем, чтобы это работало, внутри ядра должн быть закреплен фильтр SEH из userspace runtime который знает про формат сгенерированных твой любимой студией стековых фреймов. А надо сказать, этот формат для разных студий отличается. Ты хоть понимаеш каким диким говнокодом тебе придется осуществлять поддержку ++ ?

Что касается gcc то там С++ исключения реализованы по другому. Поэтому ты не сможеш просто-так собрать модуль ядра с поддержкой исключений. Более того, если ты вдруг собереш свой приплюсный виндово-ядровый код другим компилятором, или даже другой версией студии у тебя будет масса интересных сюрпризов. Ты вообще соображаеш какую говнояму ты таким образом выкапываеш для дальнейшей поддержки твоего кода ?

CC>>>Overloading нужна по параметрам: http://www.cplusplus.com/doc/tutorial/functions2/
E>>Ты можеш реализовать это с использованием gcc шного typeof и свитча внутри function-like макроса.
CC>Спасибо, макросы кушайте сами.
Ты даже не понял о чем я говорю.

CC>>>Вы когда нибудь отлаживали макросы? В вложенные макросы? Я — отлаживал, больше не хочу.
E>>Отлаживал и в огромных кол-вах. Надо просто уметь писать обобщенный код в макросах так, чтобы его было удобно отлаживать.
E>>Для этого надо писать не "в лоб", а немного подумать.
CC>Я в тот проект пришёл когда там линуксоиды со стажем все свои макросы уже написали. И занимались увлекательным делом — пытались с этим всем взлететь.
И, пока ты там не появился, весь в белом и на коне, ничего взлететь не могло. Ага, унылый сказочник.

E>>Думать можно начать с Степановского сишного прототипа STL.
CC>Ссылка была бы просто замечательна.
Спроси у гугла, ну или зайди на страницу Степанова — там есть ссылка.

CC>>>Вот только не надо мне рассказывать про макросы. Я их давным давно наелся.
E>>Ты просто не умееш с ними работать.
CC>
CC>Можно я буду так отвечать всем, кто кричит что С++ плохой?
А кто-то кричит что С++ плохой ? С++ — хороший, но внутри своей ниши, и не стоит пытаться тащить его во все без исключения места.

E>>>>2. Автоматический контроль за временем жизни переменных, RAII
E>>>>- Поскольку исключений нет, то и вернуть ошибку из конструктора невозможно.
CC>>>Исключения есть, лично писал kernel код с их использованием.
E>>Вот тут было интересно узнать подробности.
CC>Речь естественно про винду, в которой озаботились чтобы люди могли просто ловить исключения в ядре. Причём ловятся все, включая access violation.
Ты опять мешаеш всё в кучу, толи по глупости, толи из-за не понимания. Аксес виолайшен — это SEH исключение, оно из более низкого уровня абстракции. В языке С++ нет никаких access violation.

CC>Throw, сгенеренный компилятором, вызывает _CxxThrowException, которая всегда бросает стандартный виндовый SEH. Ядрёная реализация это делает через RtlRaiseException.
CC>Ловим __try / __except c EXCEPTION_EXECUTE_HANDLER. Бросаться стандартными классами исключений становится несколько сложнее.
CC>Из-за этой разницы стандартные юзермодные библиотеки без обработки напильником в кернеле использовать не получается.
Я знаком с этой кухней, поскольку лет 7-8 назад назад изучал возможность замены стандартного рантайма от студии на собственный.
_CxxThrowException — это функция из рантайма С++ предназначена для выполнения в user space mode.
RtlRaiseException — это опять же функция рантайма (но уже системного) и она предназначена для выполнения в user space mode.
При этом у С++ исключений есть специальный идентификатор, по которому его внутри фильтра можно отличить и разобрать фрейм сгенерированой студией. Но — формат этого фрейма а) немного разный для разных версий студии, б) недокументирован. А в твоем фильтре обработчике тебе надо разобрать этот формат, сделать unmagling типа RTTI и вызвать соответсвующие деструкторы.

CC>Можно прикрутить RTTI, можно сделать свои классы с блекджеком и всем что к нему прилагается.
Тебе это придется делать в любом случае — что бы понять что за исключение ты поймал и надо ли продолжать раскрутку стека.

Ты хоть понимаеш сколько малокоректного говнокда из полухаков это стоит ? Такое достойно только зеленого юнца воображающего себя кулхацкером. На самом деле — это даже не смех, а сплошные слезы глядя на этого горе-кулхакера.


E>>Особбенно совмещение неопределенных точек возврата с сишным кодом ядра.
CC>Не понял про что ты?
У сишного кода есть четко обозначеные точки возврата "наверх". Использование исключений дает неопределенныые точки возврата — раскрутка стека может произойти в любом месте. Сишный код такого эээ несколько не ожидает.

E>>Еще раз — ты просто не научился нормально работать с макросами.
CC>Судя по тому, как линуксоиды со стажем мудохаются со своими же макросами — с ними никто не умеет работать.
CC>Так что я не вижу смысла инвестировать свое время в напрасный труд.
Для начала тебе надо самому понять почему так, как ты описал выше, делать нельзя. К сожалению, ты неквалифицирован.

E>>>>Собственно очень хорошо видно, что оставшаяся огрызок от С++ никаких особых ++ по сравнению Си не дает, зато добавляет кучу всякого системного гемороя по поддержке ++ языка.
CC>>>Весь "системный геморрой" заключается в написании С++ stdlib для кернела с поддержкой SEH/Signal исключений. Очень сложно, да!
E>>То что ты сказал — на мой взгляд, сделать в линуксе невозможно. Но ты можеш поделить ссылкой на пример, если таковой конечно существует.
CC>Почему в винде это возможно (по факту) а в линухе вдруг нет?
Потому что в винде — это хак, в основе которого лежит использование того факта, что один единственый компилятор поддерживает механизм С++ исключений на основе системного механизма SEH.

E>>Даже для юзер спэйса, где нет кучи ограничений, написание поддержки С++ является проблемой. Через сколько там лет после первого релиза в андроиде появилася порт libstdc++ — можеш напомнить ?
CC>Спроси у авторов андроида почему у них руки из задницы.
Это у тебя руки из задницы.

E>>>>Вам такой С++ вообще нужен ?
CC>>>Мало того что нужен, мы его в винде давно уже используем.
E>>Не потому ли виндой сейчас уже невозможно пользоваться?
CC>Кому?
Нормальным разработчикам.

CC>>>Только линуксоиды упираются и цепляются за духовные скрепы С.
E>>Винда потихоньку помрет и туда ей дорога.
CC>Дада, она уже чёрти сколько лет вот вот помрёт. Осталось подождать ещё совсем немного.
А помрет она из-за таких вот горе-программистов.