Здравствуйте, ·, Вы писали:
_>>·>В java никакого UB нет. Ровно как и в dynamic_cast. Аналога static_cast в java нет. _>>Т.е. код типа "double x=3.14; int y=(int)x;" в Java невозможен? Или ты считаешь, что компилятор вставляет тут код рантайм проверки типа переменной х (это же и есть суть dynamic_cast)? ) ·>И где есть UB? И причём тут вообще double? Ещё раз — мы обсуждаем class cast. Напомню обсуждаемый тезис — object header нужен для безопасного class cast.
А причём тут вообще UB? Я вот вообще не понял зачем ты притащил его в данную дискуссию, т.к. к обсуждаемой теме наличие/отсутствие UB никакого отношения не имеет.
Далее, что касается double->int, то я уже говорил, что это реакция на твоё утверждение, что "static_cast (ну естественно речь про аналог) в Java нет". Или ты быть может хочешь сузить своё утверждение до только преобразования классов? )
_>>Ничего не понял, что ещё за моя терминология? ) Я сказал простую вещь, что static_cast отрабатывает на этапе компиляции, а dynamic_cast на этапе исполнения программы. Причём тут нечто твоё странное dynamic_cast<int>(string), которое не отрабатывает вообще нигде? ))) ·>А что отрабатывает и на каком этапе в java при приведении классов?
_>>Derived d = Derived.class.cast(base) это аналог cast operator Derived d = (Derived)base (синтаксически эквивалентен c-cast) через API рефлексии. Точно так же как Method.invoke(obj, "func", x) это аналог obj.func(x).
_>>И кто тут врун? ))) ·> Слова "аналог" и "одно и то же" хоть и являются аналогами, но не одно и то же.
Ага, ага, особенно если почитать дискуссию по данной ветке ниже, то это будет очень хорошо видно. ))) Ну да ладно, меня что-то утомили эти глупые препирательства. Давай вернёмся к моему изначальному утверждению (оно вот кстати даже видно в цитате по ссылке выше), на которое ты почему-то неадекватно отреагировал. И так, ты согласен, что Class.cast из Java является аналогом dynamic_cast из C++ и они оба являются примером работы рефлексии?
_>>·>Не правильно. Перечитай. _>>Перечитал. Вообще не могу увидеть каким образом твоя фраза "Когда рефлексия реализована без rtti" отвечает на мой вопрос "в каком же случае rtti не будет частью рефлексии?". У тебя что-то не то с логикой? ))) ·>Ок. Повторю. В C++ обещают compile time reflection, которая будет reflection без rtti, но это не отменит существующий на данный момент rtti в C++ — и эти обе фичи можно будет независимо использовать.
Оно собственно уже так работает, только убого (нет перечисления элементов класса). Только вот я не понял почему в этом случае существующая в языке rtti перестанет быть частью рефлексии? Напоминаю, что это ты пытаешься ответить на вопрос "в каком же случае rtti не будет частью рефлексии?".
_>>Так был же уже пример... Ну давай повторю его: _>>
Тезис в том, что в данном случае интроспекция отрабатывает в статике — нет никакого определения типа в рантайме (да и как оно могло бы сработать без дополнительного поля у объекта?), компилятор определяет тип на этапе компиляции и размещает нужные данные (имя типа в данном случае) сам. кстати, довольно забавно, что происходит это с помощью оператора формально относящегося к подсистеме rtti,
·>Т.е. ты прикапываешься к конкретной фразе, полностью забыв тему обсуждения. Напомню мой тезис: object header нужен для точного gc.
Если бы твой тезис звучал бы как "object header используется в Java в том числе и для точного gc", то он был бы абсолютно верен. Однако у тебя немного другой акцент стоит, типа "object header строго необходим реализации для точного gc", что очевидно не верно, т.к. я тебе уже продемонстрировал один пример работы точного gc без такого дополнительного поля.
_>>- точный сборщик мусора (стандартен для динамических языков, Java, C#, Go; есть реализации для D (естественно без дополнительных полей у объектов) и C++). ·>Я пока не видел этих реализаций. Или файлик "Презентация.pdf" ты смело называешь реализацией?
Там вообще то в конце статьи есть github ссылка на реализацию. ))) Да и в самой статье полно тестов производительности обсуждаемого GC — они очевидно же на чём-то измерялись, не так ли? ))) Странно ты вообще читаешь статьи...
_>>На мой взгляд для статических языков является верным решением второй вариант, а для динамических четвёртый. Но если уж зачем то захотелось делать четвёртый вариант для статического языка, то в нём будет совершенно не обязательно вводить дополнительное поле во все объекты. ·>Теоретически может и не обязательно, а на практике пока получается именно так.
Скорее тут действует принцип, что если уж у нас и так есть такое поле (динамические языки в принципе не могут существовать без него, а в Java/C# без этого поля не будет работать рефлексия), то глупо придумывать какие-то ещё варианты.
_>>·>Нет. Ты врёшь опять. Вот что ты утверждал: "переключение с консервативного на точный для обсуждаемого нами примера добавился бы ровно 1 бит (!) лишних данных". _>>·>Но как выяснилось, что бит не один, а гораздо больше. И не точный gc, а всё ещё консервативный, но уже "almost precise". И не выиграл, а проиграл. _>>И где же это выяснилось, что для того примера требовалось больше одного бита? ·>Судя по твоей же презентации требуется не бит, а info bitmap, которая несколько больше 1го бита.
В общем случае info bitmap конечно же будет не обязательно в 1 бит, но для нашего конкретного класса (обсуждаемого здесь примера) это будет ровно 1 бит.
_>>И в чём же конкретно указанный GC не точный? ·>22 слайд в твоей презенташке. И почитай 23й заодно — на другие недостатки такого gc.
Слайд то я видел. Но ты можешь своими словами описать в чём там не точность и какие из этого следуют ужасные последствия? )))
_>>Если не предоставишь обоснование этих двух своих утверждений, то как раз ты станешь вруном. Ой, хотя я же забыл, что это уже и так выяснилось несколькими абзацами выше... ·>Предоставил.
Неа. )
Re[36]: Где срачь про то, как C# порвал C++ (и все остальные
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
S>>>> Еще раз я привел тебе файл настроек, что по умолчанию все типы. Ты вообще, читаешь? S>>>>
S>>>> Но для более эффективного использования компиляции (инлайнинга, хранение переменных в регистрах итд), ты можешь указать только нужные классы. S>>>>Сам компилтор не может. Вернее он выберет все подходящие, но реально могут использоваться только часть из всех возможных _>>>И? ) С чем конкретно в моем сообщение ты пытался поспорить?) Я вот не вижу никаких расхождений между твоими слова и моими... S>> Выделил. Руками ничего не нужно, но если ооочень хочется, то можно указать нужные классы.
_>Ну т.е. указанная тобой строчка (причём это ещё и не оптимальный вариант) — это не руками что ли?
Конечно. Это созданный файл по умолчанию, который можно править. А вот вопрос по оптимальность.
Есть 100 классов со свойством "PropertyName". Как компилятор узнает, что используется всего 2 класса с этим свойством?
и солнце б утром не вставало, когда бы не было меня
Re[54]: Где срачь про то, как C# порвал C++ (и все остальные
Здравствуйте, alex_public, Вы писали:
_>>>·>В java никакого UB нет. Ровно как и в dynamic_cast. Аналога static_cast в java нет. _>>>Т.е. код типа "double x=3.14; int y=(int)x;" в Java невозможен? Или ты считаешь, что компилятор вставляет тут код рантайм проверки типа переменной х (это же и есть суть dynamic_cast)? ) _>·>И где есть UB? И причём тут вообще double? Ещё раз — мы обсуждаем class cast. Напомню обсуждаемый тезис — object header нужен для безопасного class cast. _>А причём тут вообще UB? Я вот вообще не понял зачем ты притащил его в данную дискуссию, т.к. к обсуждаемой теме наличие/отсутствие UB никакого отношения не имеет. Выделил для тебя другое слово в моём тезисе.
_>Далее, что касается double->int, то я уже говорил, что это реакция на твоё утверждение, что "static_cast (ну естественно речь про аналог) в Java нет". Или ты быть может хочешь сузить своё утверждение до только преобразования классов? )
В том то и дело, что "реакция", а не обдуманное возражение. Мы вообще-то обсуждали object header, а ты тут вдруг double притащил. Прям срезал.
_>>>Ничего не понял, что ещё за моя терминология? ) Я сказал простую вещь, что static_cast отрабатывает на этапе компиляции, а dynamic_cast на этапе исполнения программы. Причём тут нечто твоё странное dynamic_cast<int>(string), которое не отрабатывает вообще нигде? ))) _>·>А что отрабатывает и на каком этапе в java при приведении классов? _>В java для классов у нас очевидно работает аналог dynamic_cast из C++.
Верно, что я и говорил. И аналога static_cast для классов в java нет. И именно благодаря object header.
_>>>·>Не ври. Я это не доказывал. _>>>http://rsdn.org/forum/flame.comp/6994999.1
_>>>Derived d = Derived.class.cast(base) это аналог cast operator Derived d = (Derived)base (синтаксически эквивалентен c-cast) через API рефлексии. Точно так же как Method.invoke(obj, "func", x) это аналог obj.func(x).
_>>>И кто тут врун? ))) _>·> Слова "аналог" и "одно и то же" хоть и являются аналогами, но не одно и то же. _>Ага, ага, особенно если почитать дискуссию по данной ветке ниже, то это будет очень хорошо видно. )))
Так давай почитай, только внимательно, не пропуская слова.
_>Ну да ладно, меня что-то утомили эти глупые препирательства. Давай вернёмся к моему изначальному утверждению (оно вот кстати даже видно в цитате по ссылке выше), на которое ты почему-то неадекватно отреагировал. И так, ты согласен, что Class.cast из Java является аналогом dynamic_cast из C++ и они оба являются примером работы рефлексии?
Класс Class и его методы — да, это пример рефлексии. dynamic_cast — (и cast оператор в java) это не релфексия. Иначе, расскажи подробно как с помощью dynamic_cast ты сможешь "to examine, introspect, and modify its own structure and behavior at runtime".
_>>>Перечитал. Вообще не могу увидеть каким образом твоя фраза "Когда рефлексия реализована без rtti" отвечает на мой вопрос "в каком же случае rtti не будет частью рефлексии?". У тебя что-то не то с логикой? ))) _>·>Ок. Повторю. В C++ обещают compile time reflection, которая будет reflection без rtti, но это не отменит существующий на данный момент rtti в C++ — и эти обе фичи можно будет независимо использовать. _>Оно собственно уже так работает, только убого (нет перечисления элементов класса). Только вот я не понял почему в этом случае существующая в языке rtti перестанет быть частью рефлексии? Напоминаю, что это ты пытаешься ответить на вопрос "в каком же случае rtti не будет частью рефлексии?".
Ну так rtti и не чать рефлексии, поэтому перестать не может. Каким образом run-time type information может быть частью compile-time reflection?
_>>>Так был же уже пример... Ну давай повторю его: _>>>
_>·>ну и? А дальше что? Тезис-то у тебя какой? _>Тезис в том, что в данном случае интроспекция отрабатывает в статике — нет никакого определения типа в рантайме (да и как оно могло бы сработать без дополнительного поля у объекта?), компилятор определяет тип на этапе компиляции и размещает нужные данные (имя типа в данном случае) сам.
Вот с этого и надо было начинать, нечего было кругами ходить. Ты просто запутался. Есть две категории. Первая — статический тип и динамический тип. Вторая — compile-time информация о типах и run-time информация о типах. Так вот rtti выдаёт инфу, доступную во время работы о типе выражения как статический, так и динамический.
_>кстати, довольно забавно, что происходит это с помощью оператора формально относящегося к подсистеме rtti,
Забавно только тебе, ибо не согласуется с твоей логикой, основанной на твоём личном восприятии общепринятых терминов.
_>·>Т.е. ты прикапываешься к конкретной фразе, полностью забыв тему обсуждения. Напомню мой тезис: object header нужен для точного gc. _>Если бы твой тезис звучал бы как "object header используется в Java в том числе и для точного gc", то он был бы абсолютно верен. Однако у тебя немного другой акцент стоит, типа "object header строго необходим реализации для точного gc", что очевидно не верно, т.к. я тебе уже продемонстрировал один пример работы точного gc без такого дополнительного поля.
По факту пока получается именно так. Систем с точным gc без object header или аналога нет. Но допускаю, что теоретически это возможно.
_>>>- точный сборщик мусора (стандартен для динамических языков, Java, C#, Go; есть реализации для D (естественно без дополнительных полей у объектов) и C++). _>·>Я пока не видел этих реализаций. Или файлик "Презентация.pdf" ты смело называешь реализацией? _>Там вообще то в конце статьи есть github ссылка на реализацию. ))) Да и в самой статье полно тестов производительности обсуждаемого GC — они очевидно же на чём-то измерялись, не так ли? ))) Странно ты вообще читаешь статьи...
Забавно, что 25-страничную презентацию ты называешь статьёй... Тесты там довольно однобокие. Ничего об эффективности такого решения не говорит. А ты сам по ссылке-то этой на github ходил? Дохлое же оно, поигрались и бросили. ЧТД.
_>·>Теоретически может и не обязательно, а на практике пока получается именно так. _>Скорее тут действует принцип, что если уж у нас и так есть такое поле (динамические языки в принципе не могут существовать без него, а в Java/C# без этого поля не будет работать рефлексия), то глупо придумывать какие-то ещё варианты.
Ты заявил, что "существенно менее эффективным становится ВЕСЬ код" — поэтому как раз совсем не глупо сделать Правильное Решение™ без этого всего ужасного оверхеда и порвать в клочья все эти ваши тормозные Java/C#.
_>>>И где же это выяснилось, что для того примера требовалось больше одного бита? _>·>Судя по твоей же презентации требуется не бит, а info bitmap, которая несколько больше 1го бита. _>В общем случае info bitmap конечно же будет не обязательно в 1 бит, но для нашего конкретного класса (обсуждаемого здесь примера) это будет ровно 1 бит.
Ну это мягко говоря приукрашивание. То что 1 бит мы расскажем, а что ещё по одному биту на каждое слово — это мелочи... Мне вот совсем не очевидно, что в типичной программе размер этого битмапа будет меньше, чем object header всех объектов в сумме. И в итоге получится, что не в лоторею, а в карты, и не выиграл, а проиграл.
_>>>И в чём же конкретно указанный GC не точный? _>·>22 слайд в твоей презенташке. И почитай 23й заодно — на другие недостатки такого gc. _>Слайд то я видел. Но ты можешь своими словами описать в чём там не точность и какие из этого следуют ужасные последствия? )))
Что у тебя ВНЕЗАПНО в проде вылезет OOM из-за того что юзер (или хакер) ввел какое-то неудачное значение.
_>>>Если не предоставишь обоснование этих двух своих утверждений, то как раз ты станешь вруном. Ой, хотя я же забыл, что это уже и так выяснилось несколькими абзацами выше... _>·>Предоставил. _>Неа. )
Ага.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[3]: Где срачь про то, как C# порвал C++ (и все остальные языки)?
Здравствуйте, gandjustas, Вы писали:
G>Кроссплатформенность в .NET уже давно есть, C# гораздо более кроссплатформенный язык, чем C++
Позвольте не согласиться. Хотя, если смотреть в разрезе что у всех докладчиков на c++ митапе исключительно студия под форточкой, доля правды есть. Маленькая.
Re[37]: Где срачь про то, как C# порвал C++ (и все остальные
Здравствуйте, Serginio1, Вы писали:
_>>Ну т.е. указанная тобой строчка (причём это ещё и не оптимальный вариант) — это не руками что ли? S> Конечно. Это созданный файл по умолчанию, который можно править. А вот вопрос по оптимальность. S>Есть 100 классов со свойством "PropertyName". Как компилятор узнает, что используется всего 2 класса с этим свойством?
Вообще то если мы говорим о языке со статической типизацией и в данном месте не используется динамический полиморфизм или рефлексия, то компилятор на 100% знает какой класс используется.
Re[55]: Где срачь про то, как C# порвал C++ (и все остальные
Здравствуйте, ·, Вы писали:
_>>А причём тут вообще UB? Я вот вообще не понял зачем ты притащил его в данную дискуссию, т.к. к обсуждаемой теме наличие/отсутствие UB никакого отношения не имеет. ·> Выделил для тебя другое слово в моём тезисе.
Мне казалось вполне очевидным, что наличие или отсутствие рантайм-проверки (которая как раз и даёт безопасность) следует из времени отработки каста (про которое я и говорил). И это не зависит от особенностей языка (непоняты причём тут твои отсылки к UB).
_>>Далее, что касается double->int, то я уже говорил, что это реакция на твоё утверждение, что "static_cast (ну естественно речь про аналог) в Java нет". Или ты быть может хочешь сузить своё утверждение до только преобразования классов? ) ·>В том то и дело, что "реакция", а не обдуманное возражение. Мы вообще-то обсуждали object header, а ты тут вдруг double притащил. Прям срезал.
Ну т.е. ты уже согласен с тем, что в java (не ограничиваясь классами) имеется static_cast? )
_>>·> Слова "аналог" и "одно и то же" хоть и являются аналогами, но не одно и то же. _>>Ага, ага, особенно если почитать дискуссию по данной ветке ниже, то это будет очень хорошо видно. ))) ·>Так давай почитай, только внимательно, не пропуская слова.
Зачем пропускать, когда ты там сам всё сказал?
_>Это конечно замечательно, что ты смог найти в документации в чём именно заключена разница между этими двумя операциями.
Ищи подтверждения своим заблуждениям сам, не требуй от меня этого.
или
Так в чём разница-то? В неявном upcast о котором ты забыл не знал?
Забавно, как ты на протяжение одной темки пытаешься доказывать противоположные точки зрения. )))
_>>Ну да ладно, меня что-то утомили эти глупые препирательства. Давай вернёмся к моему изначальному утверждению (оно вот кстати даже видно в цитате по ссылке выше), на которое ты почему-то неадекватно отреагировал. И так, ты согласен, что Class.cast из Java является аналогом dynamic_cast из C++ и они оба являются примером работы рефлексии? ·>Класс Class и его методы — да, это пример рефлексии. dynamic_cast — (и cast оператор в java) это не релфексия. Иначе, расскажи подробно как с помощью dynamic_cast ты сможешь "to examine, introspect, and modify its own structure and behavior at runtime".
Как раз "examine" там и происходит, на предмет соответствия переданной ссылки нужному типу. Причём именно что в рантайме (это ключевое отличие от static_cast).
_>>Оно собственно уже так работает, только убого (нет перечисления элементов класса). Только вот я не понял почему в этом случае существующая в языке rtti перестанет быть частью рефлексии? Напоминаю, что это ты пытаешься ответить на вопрос "в каком же случае rtti не будет частью рефлексии?". ·>Ну так rtti и не чать рефлексии, поэтому перестать не может. Каким образом run-time type information может быть частью compile-time reflection?
Что-то ты похоже совсем запутался. Наличие в языке рефлексии времени компиляции не означает автоматического убирания RTTI из языка — оно остаётся и используется при явной работе с динамическим полиморфизмом (если мы говорим про C++). Т.е. тут будут оба вида рефлексии (правда только в рамках интроспекции).
_>>Тезис в том, что в данном случае интроспекция отрабатывает в статике — нет никакого определения типа в рантайме (да и как оно могло бы сработать без дополнительного поля у объекта?), компилятор определяет тип на этапе компиляции и размещает нужные данные (имя типа в данном случае) сам. ·>Вот с этого и надо было начинать, нечего было кругами ходить. Ты просто запутался. Есть две категории. Первая — статический тип и динамический тип. Вторая — compile-time информация о типах и run-time информация о типах. Так вот rtti выдаёт инфу, доступную во время работы о типе выражения как статический, так и динамический.
Вот, ты наконец то начал понимать.
_>>Если бы твой тезис звучал бы как "object header используется в Java в том числе и для точного gc", то он был бы абсолютно верен. Однако у тебя немного другой акцент стоит, типа "object header строго необходим реализации для точного gc", что очевидно не верно, т.к. я тебе уже продемонстрировал один пример работы точного gc без такого дополнительного поля. ·>По факту пока получается именно так. Систем с точным gc без object header или аналога нет. Но допускаю, что теоретически это возможно.
Ну да, люди смотрят на тесты производительности таких вещей, но их при этом нет.
_>>·>Теоретически может и не обязательно, а на практике пока получается именно так. _>>Скорее тут действует принцип, что если уж у нас и так есть такое поле (динамические языки в принципе не могут существовать без него, а в Java/C# без этого поля не будет работать рефлексия), то глупо придумывать какие-то ещё варианты. ·>Ты заявил, что "существенно менее эффективным становится ВЕСЬ код" — поэтому как раз совсем не глупо сделать Правильное Решение™ без этого всего ужасного оверхеда и порвать в клочья все эти ваши тормозные Java/C#.
Что-то не пойму про какой язык ты говоришь. C++ и так рвёт в клочья, но в нём нет GC. Если ты имел ввиду переделать Java/C#, то не забывай, что при этом придётся ещё много чего переделать в языке (основанного на текущей реализации рефлексии). Хотя я не исключаю, что когда-нибудь .net native (как отдельное ответвление) возможно продвинется в этом направление.
_>>>>И где же это выяснилось, что для того примера требовалось больше одного бита? _>>·>Судя по твоей же презентации требуется не бит, а info bitmap, которая несколько больше 1го бита. _>>В общем случае info bitmap конечно же будет не обязательно в 1 бит, но для нашего конкретного класса (обсуждаемого здесь примера) это будет ровно 1 бит. ·>Ну это мягко говоря приукрашивание. То что 1 бит мы расскажем, а что ещё по одному биту на каждое слово — это мелочи... Мне вот совсем не очевидно, что в типичной программе размер этого битмапа будет меньше, чем object header всех объектов в сумме. И в итоге получится, что не в лоторею, а в карты, и не выиграл, а проиграл.
А причём тут некий "типичный случай", если в моей фразе было чётко указано, что речь идёт про конкретный пример? Вот цитата:
·>Нет. Ты врёшь опять. Вот что ты утверждал: "переключение с консервативного на точный для обсуждаемого нами примера добавился бы ровно 1 бит (!) лишних данных".
·>Но как выяснилось, что бит не один, а гораздо больше.
И ты тут утверждаешь, что выяснилось, что в своей фразе где-то наврал. Так кто тут реально врун то?
_>>Слайд то я видел. Но ты можешь своими словами описать в чём там не точность и какие из этого следуют ужасные последствия? ))) ·>Что у тебя ВНЕЗАПНО в проде вылезет OOM из-за того что юзер (или хакер) ввел какое-то неудачное значение.
Хы, с чего бы это? )))
Re[3]: Где срачь про то, как C# порвал C++ (и все остальные языки)?
G>Кроссплатформенность в .NET уже давно есть, C# гораздо более кроссплатформенный язык, чем C++
По факту либо нихера не работает, либо работает криво (C# on Android).
Re[3]: Где срачь про то, как C# порвал C++ (и все остальные языки)?
A>Игровой движок Unity зародился в 2005 году на Mac OS и сейчас работает на всём что движется.
И надо сказать, что делает он это очень херово.
A>Поэтому каждый раз, когда слышу, что C# не кроссплатформенный, у меня в голове срабатывает зуммер.
У меня тоже. Потому что его кросплатформенность притянута за уши и прибита гвоздями, причем кривыми.
Re[4]: Где срачь про то, как C# порвал C++ (и все остальные языки)?
Здравствуйте, eskimo82, Вы писали:
A>>Игровой движок Unity зародился в 2005 году на Mac OS и сейчас работает на всём что движется. E>И надо сказать, что делает он это очень херово.
A>>Поэтому каждый раз, когда слышу, что C# не кроссплатформенный, у меня в голове срабатывает зуммер. E>У меня тоже. Потому что его кросплатформенность притянута за уши и прибита гвоздями, причем кривыми.
Что значит херово. Либо работает, либо не работает. Игры есть, они работают и их просто дохера.
Re[36]: Где срачь про то, как C# порвал C++ (и все остальные
Здравствуйте, alex_public, Вы писали:
_>>>Тут вопрос даже не в самом факте отжирания памяти (хотя C# и Java этим весьма славятся), а тем фактом, что вот данное отжирание совершенно попусту. I>>И откуда этот факт следует ?
_>Этот факт следует из существования языков с тем же уровнем интроспекции, что и у Java/C#, но при этом без всяких накладных расходов.
Откуда следует, что издержки исключительно из-за интроспекции ?
>>>И кстати это не только моё мнение — обрати внимание на реализацию .net native... I>>На что именно там обращать внимание ?
_>На то, как там реализована рефлексия.
Здравствуйте, alex_public, Вы писали:
_>>>А причём тут вообще UB? Я вот вообще не понял зачем ты притащил его в данную дискуссию, т.к. к обсуждаемой теме наличие/отсутствие UB никакого отношения не имеет. _>·> Выделил для тебя другое слово в моём тезисе. _>Мне казалось вполне очевидным, что наличие или отсутствие рантайм-проверки
Вот тут
ты заявлял, что и без рантайм-проверки "будет вполне себе компилировать и гарантированно выводить "g". Т.е. никаких UB." — однако, по стандарту тут таки UB. Только после этого тебе вдруг стало казаться очевидным?
_>(которая как раз и даёт безопасность) следует из времени отработки каста (про которое я и говорил). И это не зависит от особенностей языка (непоняты причём тут твои отсылки к UB).
Не следует, конечно. Безопасный downcast в compile time можно например соорудить с помощью CRTP. Но даже если ты это не знал и согласен с моим тезисом, то непонятно с чем ты тогда спорил.
_>>>Далее, что касается double->int, то я уже говорил, что это реакция на твоё утверждение, что "static_cast (ну естественно речь про аналог) в Java нет". Или ты быть может хочешь сузить своё утверждение до только преобразования классов? ) _>·>В том то и дело, что "реакция", а не обдуманное возражение. Мы вообще-то обсуждали object header, а ты тут вдруг double притащил. Прям срезал. _>Ну т.е. ты уже согласен с тем, что в java (не ограничиваясь классами) имеется static_cast? )
Это если тебе сову не жалко. С таким же успехом можно заявить о reinterpret_cast и c-cast и даже const_cast натягивается, если очень постараться.
_>>>·> Слова "аналог" и "одно и то же" хоть и являются аналогами, но не одно и то же. _>>>Ага, ага, особенно если почитать дискуссию по данной ветке ниже, то это будет очень хорошо видно. ))) _>·>Так давай почитай, только внимательно, не пропуская слова. _>Зачем пропускать, когда ты там сам всё сказал? _>
_>Это конечно замечательно, что ты смог найти в документации в чём именно заключена разница между этими двумя операциями.
_>Ищи подтверждения своим заблуждениям сам, не требуй от меня этого.
А правда ты хотел, чтобы я искал для тебя доказательства твоим высказываниям?
_>или _>
Так в чём разница-то? В неявном upcast о котором ты забыл не знал?
_>Забавно, как ты на протяжение одной темки пытаешься доказывать противоположные точки зрения. )))
Это ты из контекста выдрал. Это высказывание о разнице, почему одно компилируется, а другое нет:
X x_ref3=(X)y;// не компилируется
X x_ref4=X.class.cast(y);//нормально компилируется (о чудо!), но бросает исключение в процессе работы
Эффект у этих кастов (cast operator и Class.cast()) одинаковый, но рефлексия используется только во втором.
_>>>Ну да ладно, меня что-то утомили эти глупые препирательства. Давай вернёмся к моему изначальному утверждению (оно вот кстати даже видно в цитате по ссылке выше), на которое ты почему-то неадекватно отреагировал. И так, ты согласен, что Class.cast из Java является аналогом dynamic_cast из C++ и они оба являются примером работы рефлексии? _>·>Класс Class и его методы — да, это пример рефлексии. dynamic_cast — (и cast оператор в java) это не релфексия. Иначе, расскажи подробно как с помощью dynamic_cast ты сможешь "to examine, introspect, and modify its own structure and behavior at runtime". _>Как раз "examine" там и происходит, на предмет соответствия переданной ссылки нужному типу. Причём именно что в рантайме (это ключевое отличие от static_cast).
Оппа. А в virtual call тоже происходит "examine" типа ссылки и вызов соответствующего кода. Virtual call тоже рефлексия? Да что уж тут... division by zero тоже проверяет на тип "ненулевых целых чисел" — тоже рефлексия! У тебя получается везде сплошная рефлексия.
И ещё, поинтересуйся на досуге чем отличается слова "and" от "or" и найди одно из этих слов в определении рефлексии выше.
_>>>Оно собственно уже так работает, только убого (нет перечисления элементов класса). Только вот я не понял почему в этом случае существующая в языке rtti перестанет быть частью рефлексии? Напоминаю, что это ты пытаешься ответить на вопрос "в каком же случае rtti не будет частью рефлексии?". _>·>Ну так rtti и не чать рефлексии, поэтому перестать не может. Каким образом run-time type information может быть частью compile-time reflection? _>Что-то ты похоже совсем запутался. Наличие в языке рефлексии времени компиляции не означает автоматического убирания RTTI из языка — оно остаётся и используется при явной работе с динамическим полиморфизмом (если мы говорим про C++). Т.е. тут будут оба вида рефлексии (правда только в рамках интроспекции).
А... ну т.е. рефлексия, но как бы некая другая рефлексия. Такая особенная рефлексия, которая свойствами рефлексии не обладает, но рефлексией называется. Что-ж как тут не запутаться...
_>>>Тезис в том, что в данном случае интроспекция отрабатывает в статике — нет никакого определения типа в рантайме (да и как оно могло бы сработать без дополнительного поля у объекта?), компилятор определяет тип на этапе компиляции и размещает нужные данные (имя типа в данном случае) сам. _>·>Вот с этого и надо было начинать, нечего было кругами ходить. Ты просто запутался. Есть две категории. Первая — статический тип и динамический тип. Вторая — compile-time информация о типах и run-time информация о типах. Так вот rtti выдаёт инфу, доступную во время работы о типе выражения как статический, так и динамический. _>Вот, ты наконец то начал понимать.
Давно уж. А ты похоже так и не начал.
_>>>Если бы твой тезис звучал бы как "object header используется в Java в том числе и для точного gc", то он был бы абсолютно верен. Однако у тебя немного другой акцент стоит, типа "object header строго необходим реализации для точного gc", что очевидно не верно, т.к. я тебе уже продемонстрировал один пример работы точного gc без такого дополнительного поля. _>·>По факту пока получается именно так. Систем с точным gc без object header или аналога нет. Но допускаю, что теоретически это возможно. _>Ну да, люди смотрят на тесты производительности таких вещей, но их при этом нет.
Ну да, люди смотрят на тесты singularity, ведь у нас полно операционок на managed языках!
А ещё люди смотрят на преимущества освоения Марса. И как там погодка, опять ветренно?
_>>>Скорее тут действует принцип, что если уж у нас и так есть такое поле (динамические языки в принципе не могут существовать без него, а в Java/C# без этого поля не будет работать рефлексия), то глупо придумывать какие-то ещё варианты. _>·>Ты заявил, что "существенно менее эффективным становится ВЕСЬ код" — поэтому как раз совсем не глупо сделать Правильное Решение™ без этого всего ужасного оверхеда и порвать в клочья все эти ваши тормозные Java/C#. _>Что-то не пойму про какой язык ты говоришь. C++ и так рвёт в клочья, но в нём нет GC. Если ты имел ввиду переделать Java/C#, то не забывай, что при этом придётся ещё много чего переделать в языке (основанного на текущей реализации рефлексии). Хотя я не исключаю, что когда-нибудь .net native (как отдельное ответвление) возможно продвинется в этом направление.
И какой там GC?
_>>>·>Судя по твоей же презентации требуется не бит, а info bitmap, которая несколько больше 1го бита. _>>>В общем случае info bitmap конечно же будет не обязательно в 1 бит, но для нашего конкретного класса (обсуждаемого здесь примера) это будет ровно 1 бит. _>·>Ну это мягко говоря приукрашивание. То что 1 бит мы расскажем, а что ещё по одному биту на каждое слово — это мелочи... Мне вот совсем не очевидно, что в типичной программе размер этого битмапа будет меньше, чем object header всех объектов в сумме. И в итоге получится, что не в лоторею, а в карты, и не выиграл, а проиграл. _>А причём тут некий "типичный случай", если в моей фразе было чётко указано, что речь идёт про конкретный пример? Вот цитата: _>
_>·>Нет. Ты врёшь опять. Вот что ты утверждал: "переключение с консервативного на точный для обсуждаемого нами примера добавился бы ровно 1 бит (!) лишних данных".
_>·>Но как выяснилось, что бит не один, а гораздо больше.
_>И ты тут утверждаешь, что выяснилось, что в своей фразе где-то наврал. Так кто тут реально врун то?
Судя по той презентации чтобы переключить gc с консервативного на точный (а точнее почти-точный) потребуется не 1 бит, а 1 битмап, какой бы пример ты ни взял.
_>>>Слайд то я видел. Но ты можешь своими словами описать в чём там не точность и какие из этого следуют ужасные последствия? ))) _>·>Что у тебя ВНЕЗАПНО в проде вылезет OOM из-за того что юзер (или хакер) ввел какое-то неудачное значение. _>Хы, с чего бы это? )))
Потому что консервативный.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>Ну т.е. указанная тобой строчка (причём это ещё и не оптимальный вариант) — это не руками что ли? S>> Конечно. Это созданный файл по умолчанию, который можно править. А вот вопрос по оптимальность. S>>Есть 100 классов со свойством "PropertyName". Как компилятор узнает, что используется всего 2 класса с этим свойством?
_>Вообще то если мы говорим о языке со статической типизацией и в данном месте не используется динамический полиморфизм или рефлексия, то компилятор на 100% знает какой класс используется.
Вообще то мы говорим о рефлексии. А она вызывается, когда нет возможности использовать полиморфизм. Нам известно лишь название свойства или метода и его сигнатура.
Мало того, что компилятор не знает, я не знаю, чей метод вызовется, ведь это может быть и IDispatch и DinamicObject, ExpandoObject.
А может это свойство или метод реального объекта. Просто DLR упрощает жизнь, там где невозможно применить Интерфейсы, наследование или это влечет за собой кучу изменений
И очень смешно смотреть на С++ код при работе с IDispatch. Ведь до DLR C# тоже был в этом плане динозавром. И как завидовал VB.Net
и солнце б утром не вставало, когда бы не было меня
Re: Где срачь про то, как C# порвал C++ (и все остальные языки)?
Здравствуйте, Ватакуси, Вы писали:
G>>Есть вообще хоть один язык, который превосходит C# не по отдельным фичам, а по совокупности?
G>>ЗЫ. Про кроссплатформенность не надо, C# гораздо более кроссплатформенный, чем многие другие языки.
В>Питон даже тот же. В>Ибо любую программу на нём написать в разы быстрее и проще, чем на C#
мммммм?
Что-то сомнения возникли. Что там в питоне с платформенными вызовами, и как дела со скоростью математики обстоят?
Всё сказанное выше — личное мнение, если не указано обратное.
Re[3]: Где срачь про то, как C# порвал C++ (и все остальные языки)?
Слова "аналог" и "одно и то же" хоть и являются аналогами, но не одно и то же.
