We cannot make the language simpler to teach and learn by removing features
Уф-ф-ф. Ну хоть кто-то нормальным ещё остался в этой вакханалии.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Mika Soukhov, Вы писали:
MS>Здравствуйте, eao197, Вы писали:
S>>>C++ox будет похож на С#.
E>>В чем же?
MS>Видимо в том, что в С++ появятся параметризированные типы
Пока что C# упоминается как отрицательный пример:
The difficulty in the design of “concept” is to maintain the flexibility of templates so that we don’t require template arguments to fit into class hierarchies or require all operations to be accessed through virtual functions (as for Java and C# generics). In “generics”, an argument must be of a class derived from an interface (the C++ equivalent to “interface” is “abstract class”) specified in the definition of the generic. That means that all generic argument types must fit into a hierarchy. That imposes unnecessary constraints on designs requires unreasonable foresight on the part of developers. [...] That's rigid.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Дарней, Вы писали:
Д>мда. бедные разработчики компиляторов
Да бог с ними, с разработчиками компиляторов, их мало.
А вот C++ разработчикам может быть не весело. В каком-нибудь Visual Studio 2010 поддержка C++09 появится, и сразу же появится код, использующий эти особенности. А потом его придется портировать на какую-нибудь систему (AIX, HP-UX, Solaris, NonStop, Symbian, какой-нибудь встраиваемый Linux, OpenBSD и пр.), где компилятор будет на уровне нынешнего Visual C++ 7.1 или GNU C++ 4.0. Представляю себе эту веселуху.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Да бог с ними, с разработчиками компиляторов, их мало. E>А вот C++ разработчикам может быть не весело. В каком-нибудь Visual Studio 2010 поддержка C++09 появится, и сразу же появится код, использующий эти особенности. А потом его придется портировать на какую-нибудь систему (AIX, HP-UX, Solaris, NonStop, Symbian, какой-нибудь встраиваемый Linux, OpenBSD и пр.), где компилятор будет на уровне нынешнего Visual C++ 7.1 или GNU C++ 4.0. Представляю себе эту веселуху.
Ну ты так не переживай. Если проинтерполировать предыдущий опыт работы с MS VC, полноценная поддержка C++09 в нем появится этак к 2020 году, не раньше.
Здравствуйте, CrystaX, Вы писали:
CX>Ну ты так не переживай. Если проинтерполировать предыдущий опыт работы с MS VC, полноценная поддержка C++09 в нем появится этак к 2020 году, не раньше.
Да я не по поводу Visual-а переживаю. Меня больше волнует, что boost, использующий C++09, появится раньше, чем компиляторы, поддерживающие C++09
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
CX>>Ну ты так не переживай. Если проинтерполировать предыдущий опыт работы с MS VC, полноценная поддержка C++09 в нем появится этак к 2020 году, не раньше.
E> E>Да я не по поводу Visual-а переживаю. Меня больше волнует, что boost, использующий C++09, появится раньше, чем компиляторы, поддерживающие C++09
А это уж как пить дать. Ну дык не впервой. Прорвемся.
Здравствуйте, eao197, Вы писали:
E> E>Да я не по поводу Visual-а переживаю. Меня больше волнует, что boost, использующий C++09, появится раньше, чем компиляторы, поддерживающие C++09
Boost — это хорошо! Он является двигателем компиляторов, типа как test suite. И то не факт. Нехорошая специфика шаблонов заключается в том, что сам буст может прекрасно компилироваться, скажем VC7.1 (собственно там и компилировать-то особо нечего), а вот конкретный прикладной код, его использующий — давать ICE. То есть, глючность компиляторов обнаруживается на очень поздних стадиях. Но все равно, то что буст есть — это больше хорошо, чем плохо. Но в своих проектах я его использовать опасаюсь — очень уж это тяжелая зависимость.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Ты глянь, и дух птысы туда же... В смысле лезет развязать очередной флэйм C# vc. C++.
Причем делает это в лучших традициях тех самых флэймов, то есть не изучив того как обсуждаемый им вопрос на самом деле реализован в конкурирующем языке.
Цитирую:
Есть, конечно, обходы, но они усложняют код. Еще одна проблема состоит в том, что вы не можете использовать в generic-ах напрямую встроенные типы, поскольку встроенные типы, такие, как int, не являются классами и не имеют функций, требуемых интерфейсами, указываемых в generic-ах...
О как? Ну, что же проверим. Открываем определение первого попавшегося встроенного типа... И что мы видим?
public struct Int32 : IComparable, IFormattable, IConvertible, IComparable<int>, IEquatable<int>
...
Ба, оказывается встроенные типы реализуют кучу интерфейсов! Жаль, конечно, что в МС не додумались сделать интерфейсы типа IAddable, ISubtractable и т.п. Но вот как раз для реализации обобщенных алгоритмов они то обычно и не нужны. А интерфейсов IConvertible, IComparable<int>, IEquatable<int> более чем достаточно для большинства применений.
К тому же интерфейсы не единственное средство абстрагирвоания. Есть еще и, гы-гы, делегаты.
Идем дальше...
... – нужно создавать классы-обертки встроенных типов и обращаться к элементам косвенно через указатели.
О как? Классы и через указатели? А почему не структуры, по значению и с инлайнингом? Видимо Страуструп из тех, кто мало понимает в теории построения компиляторов... теоретик... ...
...Кроме того, типичные операции с generic-ами реализуются как вызов виртуальной функции...
О как? "Типичные"! А атипичные?
...Это может быть очень накладно (по сравнению с обычным использованием встроенной операции, например, + или <)...
Ай-яй-яй. Взрослый дядя, а как пацан основывает свои рассуждения на непроверенных слухах. А между тем в стандарте C# 2.0 имеется такой пунктик 25.7.3 Type parameters and boxing. В нем говорится о такой казалось бы совершенно посторонней вещи как отсутствии боксинга при вызовах методов интерфейсов (или унаследованных от object) у переменных и параметров типом которых является параметр типа. В стандарте это звучит так:
Similarly, boxing never implicitly occurs when accessing a member on a constrained type parameter.
И что спросите вы? А то, что вэлью-типы являются по определению запечатанными (sealed), а стало быть не могут иметь наследников. Так что если у незабоксеной переменной вэлью-типа производится вызов метода, то он принципиально производится напрямую. И что, спросят недогадливые? А то, что его принципиально можно инлайнить.
Не трудно произвести простенький эксперимент. Создать вот такой код:
using System;
using System.Diagnostics;
class Program
{
static void Main()
{
Console.WriteLine(Eq(2, 2));
}
static bool Eq<T>(T a, T b) where T: IEquatable<T>
{
Debugger.Break();
return a.Equals(b);
}
}
и выполнить его в релизе и не из под отладчика. Спустившись в колстэке на метод вниз можно уводить, что код Eq() выглядит так:
00000000 push esi
00000001 push eax
00000002 mov dword ptr [esp],ecx
00000005 mov esi,edx
00000007 call 787B2D48
0000000c cmp dword ptr [esp],esi
0000000f sete al
00000012 movzx eax,al
00000015 pop ecx
00000016 pop esi
00000017 ret
Откровенно говоря, за такой код надо поубивать тех, кто писал JIT-компилятор в МС. Но! Обратите внимание... Никаких виртуальных вызовов нет и в помине! Более того, единственный вызов (call 787B2D48) — это вызов метода Debugger.Break().
А за что убивать? Для этого нужно прокомментировать сгенерированный код:
00000000 push esi ; Сохраняют содержимое регистра esi (уроды :) )
00000001 push eax ; Сохраняют eax
00000002 mov dword ptr [esp],ecx ; Внимание!!! Загружают в стек значение ecx (он содержит значение второго параметра). Зачем?!
00000005 mov esi,edx ; edx содержит значение второго параметра. Зачем его копировать?
00000007 call 787B2D48 ; Вызов Debugger.Break()
0000000c cmp dword ptr [esp],esi ; Сравнивают значение скопированное в стек с esi. Короче сравнивают параметры.
0000000f sete al ; Эта и следующая команда помещают в eax 1 в случае успеха предыдущего
00000012 movzx eax,al ; сравнения. eax это и есть регистр в котором возвращается значение функции.
00000015 pop ecx ; Естественно теперь нужно восстановить значения регистров ecx
00000016 pop esi ; и esi (вот уроды :) )
00000017 ret
Возможно глупость этого кода спровоцирована вызовом Debugger.Break() и в реальном коде все будет намного лучше. Жаль, что джит допустил одну, непростительную, ошибку. Он не заинлайнил сам вызов Eq(), а при таких мизерных операциях как сравнение целых и он кое-что стоит.
Оданко совершенно ясно что товарищ мэтр явно не сечет в вопросе который затрагивает. И никаких идеологических проблем с оптимизацией кода нет, так как нет виртуального метода.
Более того, мы наблюдаем даже более забавную для управляемого мира вещь — инлайнинг метода из другой сборки. Забавно было бы поглядеть на оптимизации выполняемые С++-компилятором при вызове кода из другой DLL.
Думаю раз уж JIT научился делать такое, то в будущем он избавится и от промахов подобных описанному выше.
Ну, да вернемся к словам мэтра:
При таком способе реализации generic-и являются просто синтаксическим сахаром для абстрактных классов.
Уважаемый товарисчъ мэтр. Тешьте себя этой сказкой каждый вечер перед сном. Глядишь, когда в 20хх году, вы таки добьете свой эпохальный труд вас ждет много нового. Надеюсь к этому моменту детские болезни JIT-а пройдут, C# и Ява получат достойные реализации оптимизирующих компиляторов, и мы со смехом вспомним ваши слова сравнивая компиляторы C# 5.0 и Явы 1.68 с новейшим стандартом С++.
... << RSDN@Home 1.2.0 alpha rev. 631>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Идем дальше...
VD>
... – нужно создавать классы-обертки встроенных типов и обращаться к элементам косвенно через указатели.
VD>О как? Классы и через указатели? А почему не структуры, по значению и с инлайнингом? Видимо Страуструп из тех, кто мало понимает в теории построения компиляторов... теоретик... ...
По слухам, Страуструп как-то даже писал о возможности применения самомодифицирующегося кода для вызова виртуальных методов... может быть он имел ввиду JIT, но побоялся этого страшного слова?
[]
VD>А за что убивать? Для этого нужно прокомментировать сгенерированный код:
VD>
;; поскольку функция использует esi, сохраняют его как требуют конвенция fastcall
VD>00000000 push esi ; Сохраняют содержимое регистра esi (уроды :) )
;; выделяется память в стеке для локальной переменной.
VD>00000001 push eax ; Сохраняют eax;; в локальную переменную заносится ecx. почему не сделали просто push ecx выше :-?
VD>00000002 mov dword ptr [esp],ecx ; Внимание!!! Загружают в стек значение ecx (он содержит значение второго параметра). Зачем?!;; последующий call не будет изменять esi, но будет edx.
VD>00000005 mov esi,edx ; edx содержит значение второго параметра. Зачем его копировать?
VD>00000007 call 787B2D48 ; Вызов Debugger.Break()
;; единственная полезная операция
VD>0000000c cmp dword ptr [esp],esi ; Сравнивают значение скопированное в стек с esi. Короче сравнивают параметры.
VD>0000000f sete al ; Эта и следующая команда помещают в eax 1 в случае успеха предыдущего
VD>00000012 movzx eax,al ; сравнения. eax это и есть регистр в котором возвращается значение функции.
;; очищаем стек от аллоцированной локальной переменной.
VD>00000015 pop ecx ; Естественно теперь нужно восстановить значения регистров ecx
VD>00000016 pop esi ; и esi (вот уроды :) )
VD>00000017 ret
VD>Возможно глупость этого кода спровоцирована вызовом Debugger.Break() и в реальном коде все будет намного лучше.
Скорее всего, так и есть. Код больше похож на другие компиляторы, чем на MS
VD>Жаль, что джит допустил одну, непростительную, ошибку. Он не заинлайнил сам вызов Eq(), а при таких мизерных операциях как сравнение целых и он кое-что стоит.
Может именно вызов Debugger.Break() ему и помешал? Вероятно отладчик предполагает наличие параметров Eq() в определённых регистрах, а при оптимизации они могут быть где угодно, поэтому её пришлось отключить. Полностью.
VD>Более того, мы наблюдаем даже более забавную для управляемого мира вещь — инлайнинг метода из другой сборки. Забавно было бы поглядеть на оптимизации выполняемые С++-компилятором при вызове кода из другой DLL.
Конечно же это невозможно. Если экспортировать класс целиком, из dll будут вызываться даже "пустые" конструкторы и т.п. Однако можно в хидере экспортировать только "тяжёлые" методы, а остальное определить как inline, тогда всё будет намного лучше, если не считать необходимости "думать вручную". И в этом случае помимо только интерфейса, придётся поставлять с dll и часть реализации.
VD>Думаю раз уж JIT научился делать такое, то в будущем он избавится и от промахов подобных описанному выше.
Это скорее не заслуга самого JIT, а бонусы из-за методанных и прочих вещей управляемого кода.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, VladD2, Вы писали:
VD>Причем делает это в лучших традициях тех самых флэймов, то есть не изучив того как обсуждаемый им вопрос на самом деле реализован в конкурирующем языке.
Вообще-то, там не только C#, но и Java упомянута была.
VD>Цитирую: VD>
Есть, конечно, обходы, но они усложняют код. Еще одна проблема состоит в том, что вы не можете использовать в generic-ах напрямую встроенные типы, поскольку встроенные типы, такие, как int, не являются классами и не имеют функций, требуемых интерфейсами, указываемых в generic-ах...
VD>О как? Ну, что же проверим. Открываем определение первого попавшегося встроенного типа... И что мы видим? VD>
VD>Ба, оказывается встроенные типы реализуют кучу интерфейсов!
А теперь докажи то же самое для Java.
VD>Видимо Страуструп из тех, кто мало понимает в теории построения компиляторов... теоретик... ...
Видимо, VladD2 много понимает в теории построения компиляторов, практик, надо полагать. И можно ли узнать, какие компиляторы были тобой созданы и где они используются? Для оценки адекватности высказывания
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Да я не по поводу Visual-а переживаю. Меня больше волнует, что boost, использующий C++09, появится раньше, чем компиляторы, поддерживающие C++09
Равняться надо на Александреску — он абсолютно не комплексует что его код работает в основном на одном компиляторе
Здравствуйте, anton_t, Вы писали:
_>Получается как минимум для C# утверждение Страуструпа не верно. Зачем же его ещё и для Java опровергать?
Затем, что Страуструп не сравнивал C++ с C#. Речь шла о generic-ах вообще. И generic-и в C# только частный случай их воплощения. Не сильно распространенный пока, кстати.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
И можно ли узнать, какие компиляторы были тобой созданы и где они используются? Для оценки адекватности высказывания 
