Опубликован стандарт C++11 (бывший C++0x)

> Ясно же что имелось ввиду

Нет, имелось ввиду совершенно другое. А то, о чем ты говоришь - просто неосиляторство. Не смогли сделать ограниченную квантификацию, вот и все.

> ничего (0 байт в объектном файле)

Вот именно. Это и есть type erasure.

> в первом приближении type erasure это когда компилируется именно шаблон

Да.

, т.е. бинарный код, реализующий some_function<Class1> и some_function<Class2>, один и тот же

Нет. Вот в том же С# код один и тот же, но type erasure нет. type erasure - это такая реализация полиморфизма, при которой после компиляции не остается информации о полиморфных типах (аппликация типового аргумента производится в компайлтайме). То есть объекты с полиморфным типом в рантайме не существуют. В отличии от того же С#, где type erasure нету и по-этому полиморфная функция компилируется именно в полиморфную функцию. И уже только в рантайме производится подстановка. То же, о чем ты говоришь, никакого отношения к затиранию типов не имеет.

> (когда в скомпилированном коде нету информации о типовых аргументах, то есть полиморфная функция не может быть first-class объектом).

скорее наоборот — наличие информации о типовых аргументах мешает полиморфной функции быть 1 объектом, а не группой из многих-многих объектов

впрочем, шаблонами можно обернуть любой код, оперирующий void*, и так дешево и сердито получить type erasure (но компилятор тут уже не помощник)

>что за штука properties? аннотации как в жабе?

Пример похожий на борман с++: class SomeWindow {

public:

void setTitle(AnsiString newTitle);

AnsiString getTitle();

__property AnsiString Title=

{read=getTitle, write=setTitle, default=«»};

}

Теперь при SomeWindow.Title=«HELLO!» будет вызываться сеттер setTitle(), который, кроме всего прочего еще и перерисует окно с нужным заголовком и провалидирует значение, если нужно. Плюс у свойства может быть гетер но не будет сетера и наоборот. Плюшка, на самом деле удобная. Получается более интуитивно понятная семантика.

В C# выглядит так:

public class MyClass
{
    public string Property { get; private set; }
}

Там имелось ввиду именно это, даже если тот кто об этом говорил думал иначе.

Осиляторством не занимаюсь, у меня девушка есть.

> encyrtid

а еще в C# вот что есть (ковариация в C#4.0):

class Base {} class Derived : Base {} void Main() { Derived[] a1 = new Derived[10]; Base[] b1 = a1; // boom baby.

List<Derived> a2 = new List<Derived>(10); List<Base> b2 = a; // boom baby 2X :D }

Помню я давно пытался в C++ сделать подобное для своих шаблонных контейнеров, дело было довольно гиблое, вроде что то реализовал частично, не помню если честно, но дело было жуткое.

>> ничего (0 байт в объектном файле)

Вот именно. Это и есть type erasure.

вовсе нет; в яве результатом будет занимающий сколько-то байт байт-код, у которого везде, где были типы-параметры, будет стоять Object

в плюсах, чтобы добиться аналогичного, надо сделать нетривиальные движения руками

Не распарсил. В случае массивов ковариантность допустима, в случае генериков - нет.

> encyrtid

Вот ведь.. хотел понтануться не вышло. Видимо только IEnumerable<> работает... :D

>давно пытался в C++ сделать подобное
auto a1 = new list<derived*>(10);
list<base*>* a2 = reinterpret_cast<list<base*>*>(a1);
Оно? Только не надо про чистоту кода - какая задача такой и код.

> encyrtid

Но это правильно в любом случае, на примере функции добавления List.Add. Если я буду потом добавлять в список с Derived одиночные элементы Base - получится каша - список из разных типов. А просто массивы они статичны, не позволяют добавлять новые элементы, поэтому им всё дозволено :D

> son_of_a_gun

Проверил, вроде да, проверяет что Derived это предок Base, так что похоже это то что я пытался реализовать. :).

> Комитет C/C++ слишком консервативен, там у всех пубертатный период окончился.

Вчера собирал старый плюсовый код компилятором с включенной поддержкой нового стандарта. Обратная совместимость ушла лесом. А Вы говорите «пубертатный период окончился». Скорей всего он еще и не начался.

> Обратная совместимость ушла лесом.

пример можно?

> son_of_a_gun

А нет вру, это не то. И проверки что Base является родителем Derived тут нет. Я могу привести хоть к типу int* и компилятор проглотит. А я делал типобезопасную версию, такую что конвертация была возможна только если Base действительно родитель Derived.

> Но претензия была вполне очевидная - при модификации программ с тотальным Хиндли-Милнером ошибки могут вылезать в неожиданных (и далеких от точки модификации) местах, поэтому область применения вывода типов неплохо бы ограничивать, например, границами модуля.

Ну так это вроде очевидно и не является проблемой. Разве нет?

Более того, во всяких там хаскелях объявление сигнатур для интерфейса модуля является общепринятой и здравой практикой. А в Agda, если не изменяет память, так вообще сигнатуры всех определений верхнего уровня должны прописываться явно (правда там это из-за особенностей системы типов). И все чудесно.

> В строгой вы ничего не напишете. История с pascal-ем ничему не учит.

Что за история и чему она не учит?

> son_of_a_gun

И более того, была проверка что Base имеет виртуальный деструктор, перед конвертацией - и всё это в компайл тайме, с помощью __has_virtual_destructor и прочих наворотов языка. На случай если я захочу вызвать Clear с помощью второй ссылки. Короче там всё должно было быть безопасно и типобезопасно. А не просто насильно преобразовать один тип указателя в другой и наслаждаться рантайм багами.

Ладно пацаны, как бывший C++ сник я за вас рад, что вы наконец дождались нового стандарта. Но если честно когда я вспоминаю о C++ и о его не только новых, но и старых фичах у меня жутко начинает болеть голова. И кстати да, теперь C++ реально стал сложнее в обучении, это мне стало просто очевидно когда я просмотрел полный список фич нового стандарта. Мозги просто в трубочку закручиваются если честно :). В общем удачи, C++ сники всё равно нужны для грязной работы, я буду ждать в свою очередь C#5.0 будем надеется я там увижу обещанный скриптинг и C# наконец превратится в убийцу JavaScript, async если честно не очень сильно жду, и без него пока нормально живется.

>> Но претензия была вполне очевидная - при модификации программ с тотальным Хиндли-Милнером ошибки могут вылезать в неожиданных (и далеких от точки модификации) местах, поэтому область применения вывода типов неплохо бы ограничивать, например, границами модуля.

Ну так это вроде очевидно и не является проблемой. Разве нет?

Это очевидно тебе, но не угодайчегу. Насчет «не является проблемой» - ХЗ, у меня нет опыта. По тому, что я читал, таки является.

> > Скорее, предполагается, что NULL будет определяться не как (void*)0, а через nullptr.

А он и так не 0. Есть платформы, на которых C++ существует, но NULL там не равен 0.

В c++ по стандарту null есть 0.

В c++ по стандарту null есть 0.

Evaluates to 0, а не equals to 0.

на говне сметану не сделаешь...

>на говне сметану не сделаешь...

Да на нём и делается, вообще-то.

говно → почва → трава → корова → молоко → сливки → сметана

> говно → почва → трава → корова → молоко → сливки → сметана

→ человек → деньги → говно

Еще раз, type erasure - это когда такого объекта как «полиморфная ф-я» в рамках ЯП просто не существует. Так дело обстоит в плюсах, жабе, том же хаскеле. Если же затирания типов нет, то полиморфная функция выступает как полноправный объект - как, например, в C#.

> Там имелось ввиду именно это

Там имело ввиду именно то, что я сказал. Инфа 100%.

> Ну так это вроде очевидно и не является проблемой. Разве нет?

Конечно же нет. Является.

Не в курсе что он там делает у Вас, а у меня он - производит код 8)

а у меня конпеляет, и, по сообщениям отдельных товарищей, всю свою сознательную жизнь этим и занимался

а уж код для него я произвожу сам

gcc производит промежуточный lisp-о подобный платформонезависимый код.

какой-какой, лиспообразный? oh, shi~

наверное потому-что комитет плотно взаимодейсвтует с создателями компиляторов

да там половина чуваков в том комитете, из compiler teams

Вчера собирал старый плюсовый код компилятором с включенной поддержкой нового стандарта. Обратная совместимость ушла лесом.

ну-ка, ну-ка, на каком куске кода оно сломалось, не приведёте ли?

> Для справки: есть языки умеющие всё это и многое другое и их стандарт занимает 50 листов А4.

Спасибо за справку. Так вроде я о том же самом сказал.

В C# выглядит так:

public class MyClass
{
    public string Property { get; private set; }
}

Красиво, но мне на практике приходиться разбивать get и set, так как много проверок и различных действий висит на set, а порой и на get. И стараюсь делать по-старинке: процедура SetProperty(Value) и функция GetProperty().

Я так понимаю, что вы тоже про Хиндли-Миндлера только в содержании курса читали.

Почитай тога и эту книжку. Множество вопросов снимутся http://www.kodges.ru/9615-dizajjn-i-jevoljucija-jazyka-c.html

> Между «Point p(...); p.setX(...); p.setY(...)» и «Point p(...); p.moveTo(...);» есть огромная разница. А пропертиз помогают писать код, как в первом варианте, и совершенно бесполезны при использовании второго.

Чето я не понял, а где тут пропертиз? Что в первом, что во втором случае - простые вызовы методов класса. Разве что в первом это два вызова, а во втором агрегированный метод, который, возможно объявлен как инлайн и вызывает эти же два метода.

Проперти это когда Point p(...); p.x = ...; при том, что x - не паблик мембер.

Не?

Раскройте свою позицию.

>И проверки что Base является родителем Derived тут нет.
Внезапно. reinterpret_cast

> Ладно пацаны, как бывший C++ сник я за вас рад, что вы наконец дождались нового стандарта. Но если честно когда я вспоминаю о C++ и о его не только новых, но и старых фичах у меня жутко начинает болеть голова. И кстати да, теперь C++ реально стал сложнее в обучении, это мне стало просто очевидно когда я просмотрел полный список фич нового стандарта. Мозги просто в трубочку закручиваются если честно :). В общем удачи, C++ сники всё равно нужны для грязной работы, я буду ждать в свою очередь C#5.0 будем надеется я там увижу обещанный скриптинг и C# наконец превратится в убийцу JavaScript, async если честно не очень сильно жду, и без него пока нормально живется.

Во-первых мимо тазика. Меня C++ не особо волнует. :-) А шарп - тем более.

А во-вторых речь шла о какой-то там «истории с паскалем, которая ничему не учит». А я спрашивал, что это за история такая. Может там какие-то скандалы, интриги и расследования, а я все пропустил?

> > Ну так это вроде очевидно и не является проблемой. Разве нет?

Это очевидно тебе, но не угодайчегу. Насчет «не является проблемой» - ХЗ, у меня нет опыта. По тому, что я читал, таки является.

Угодайчег это вообще особый случай.

Я же интересуюсь, в чем проблема с Хиндли-Милнером, т.к. сам с проблемами не сталкивался. Может я просто не стремился нарушать стандарты и стрелять себе по ногам?

Правда софт у меня был небольшой. Так, несколько проектиков строк на 5-20K каждый. Связывалось все без проблем. И свой код со своим, и свой с чужим.

Внезапно: reinterpret_cast никаких гарантий не дает. Компилятор проглотит этот код, вне зависимости от того какой указатель ты подсунешь в reinterpret_cast.

А спроектировать приличную архитектуру, где не требуется всей этой свистопляски с бубенцами - никак?

>Внезапно: reinterpret_cast никаких гарантий не дает
Для вас может и внезапно, а я об этом и говорил.

>И проверки что Base является родителем Derived тут нет.

Внезапно. reinterpret_cast

А это что? Как reinterpret_cast поможет проверить наследование в compile-time?

Блин, мне очевидные вещи объяснять? НИКАК.

> только кривую, тормозную и до нельзя примитивную.

Ух ты какой годный вброс! Или я ошибся, и Вы всерьёз это утверждали? :)

> Правда софт у меня был небольшой. Так, несколько проектиков строк на 5-20K каждый.

Проблемы проявляются при обширной модификации, насколько я понял. Только размера недостаточно.

>> только кривую, тормозную и до нельзя примитивную.

Ух ты какой годный вброс!

Жалкий плагиат Гринспена.