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

Еще раз, type erasure - это когда в рантайме неизвестен тип параметров(генерика). В java это так - тип параметров генериков в рантайме - void*, все внешние методы виртуальны и никаких проблем. А С++ просто не может забыть тип, для корректной работы. Для каждого инстанцирования шаблона создается новая функция/класс работающая так, что от обычной её нельзя отличить. Т.е C++ знает с чем он работает и никакого type erasure здесь нет в принципе. Алсо шаблоны поддерживают специализацию, то есть генерацию различных функций/классов в зависимости от параметров шаблона - то что вам нужно?

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

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

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

> Необходимо сделать так сказать точку восстановления.

необходим новый язык поверх Ассемблера. В данный момент это язык C++, а нужен другой.

Даёшь апдейт стандарта Common Lisp!

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

Есть такие compile-time проверки. Boost.TypeTraits имеет нужные has_virtual_destructor и is_base_of.

Творческая интерпретация Гринспена.

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

Да.

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

Нет. Вот в том же С# код один и тот же, но type erasure нет.

я сказал «в первом приближении»; и кроме того, в моно бинарный код не один и тот же

type erasure - это такая реализация полиморфизма, при которой после компиляции не остается информации о полиморфных типах (аппликация типового аргумента производится в компайлтайме).

в первом приближении да

но где ты увидел *такое* в с++? код приведи! код!

То есть объекты с полиморфным типом в рантайме не существуют.

какие «объекты»? функции с полиморфным типом в яве существуют, хотя и совпадают с неполиморфными

то, что они тормозят из-за лишних рантаймовых проверок (т.е. не оптимизированны до конца) — это да, но очень странно было бы назвать это «полиморфные функции не first-class citizen»

type erasure - это такая реализация полиморфизма, при которой после компиляции не остается информации о полиморфных типах (аппликация типового аргумента производится в компайлтайме).

ну... я тебе могу такую аппликацию сделать, что *ВСЯ* инфа о типе пойдет в рантайм, где будет с успехом использоваться (хинт: одерски примерно это делает в скале)

по-моему, type erasure — это специальная комбинация слов, описывающая лень разрабов и сохранение совместимости из явы (и даже не jvm, а именно из явы), и к другим языкам мало применима

интересно, в хаскеле можно сделать че-то похожее на имплициты из скалы?

Алгоритм Хиндли-Милнера не заменяет мозг...

Не существует такой штуки, как алгоритм Хиндли-Милнера, десу.

> Для каждого инстанцирования шаблона создается новая функция/класс работающая так, что от обычной её нельзя отличить.

Вот именно. Это и есть type erasure, т.к. после компиляции остаются только инстансы. А в инстансах _нет_ информации о самом шаблоне и его параметрах. Она затирается при генерации инстансов. То есть вы не можете из инстанса получить его полиморфный оригинал.

Т.е C++ знает с чем он работает и никакого type erasure здесь нет в принципе.

Да ничего он не знает. Вот у вас был полиморфный тип forall a. T a, в компайлтайме проведена аппликация и получился монотип T x (где х - монотип). И в рантайме у вас теперь везде этот T x. И никакого способа из этого T x получить полиморфный оригинал нет, т.к. информация о нем в рантайм не проходит. После компиляции остаются только монотипы. Это и есть параметрический полиморфизм через type erasure - и это одинаково как для с++, так и для жабы, хаскеля и 99% других ЯП, в которых не осилили сделать первоклассные полиморфные ф-и. Еще раз, type erasure - когда после компиляции остаются только монотипы. То есть вся информация о полиморфных типах затирается, а везде вместо полиморфного типа подставляется результат аппликации этого типа к полиморфному аргументу. С другой стороны, в C# ничего не затирается. Полиморфная функция так и компилируется в полиморфную функцию, которая содержит всю информацию о своем полиморфном типе.

Алсо шаблоны поддерживают специализацию, то есть генерацию различных функций/классов в зависимости от параметров шаблона - то что вам нужно?

Нет, мне нужна поддержка полиморфных ф-й на уровне рантайма. То есть чтобы в рантайме могли полноценно существовать сущности имеющие полиморфный тип, а не только монотип.

>> Для каждого инстанцирования шаблона создается новая функция/класс работающая так, что от обычной её нельзя отличить.

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

Если generic - это единый код функции для всех типов, с которыми она работает, то в Си++ просто нет generic'ов, и type erasure тоже нет.

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

Так вам это и пытаются вдолбить. full type inference - зло, и его следует ограничивать по крайней мере текущей единицей компиляции.

Ну а если лениться и не прописывать..

Ну оно так и гц не нужен - главное не лениться и внимательнее работать с указателями. И вообще высокоуровневые ЯП не нужны. Надо просто не лениться и писать на ассемблере. Речь идет о том, что полный вывод типов предоставляет замечтельные возможности выстрелить себе в ногу. а возможность выстрелить себе в ногу - это всегда недостаток.

> Если generic - это единый код функции для всех типов, с которыми она работает, то в Си++ просто нет generic'ов, и type erasure тоже нет.

И генерики и темплейты - это просто реализация параметрическго полиморфизма. Единый там код для функции или генерация инстансов на каждую аппликацию - это не важно. Важно, остаются ли полиморфные типы после компиляции. Если не остаются - это затирание типов.

> я сказал «в первом приближении»; и кроме того, в моно бинарный код не один и тот же

Один и тот же.

в первом приближении да

Ни в каком ни в первом приближении, это и есть определение затирания типов.

но где ты увидел *такое* в с++? код приведи! код!

Любой шаблонный код.

какие «объекты»?

Не понял вопроса.

функции с полиморфным типом в яве существуют

Не существуют. В рантайме явы существуют только объекты с монотипом. То есть имеется ф-я с монотипом, которая _как бы_ ведет себя как полиморфная. Но это не делает ее полиморфной.

ну... я тебе могу такую аппликацию сделать, что *ВСЯ* инфа о типе пойдет в рантайм, где будет с успехом использоваться (хинт: одерски примерно это делает в скале)

А кто-то спорил с тем, что можно сделать компилятор ЯП, в котором ВСЯ инфа о типе попадет в рантайм? Вобщем-то в шарпе это и сделано.

по-моему, type erasure — это специальная комбинация слов, описывающая лень разрабов и сохранение совместимости из явы (и даже не jvm, а именно из явы), и к другим языкам мало применима

Как вообще type erasure связано с джавой? type erasure связано с параметрическим полиморфизм, который появился тогда, когда джавы еще не было и в проекте.

Разве type erasure - не затирание информации о параметрах шаблона? Просто изначально в моем представлении это именно так. Если нет, то и ничего плохого в этом нет.

>> но где ты увидел *такое* в с++? код приведи! код!

Любой шаблонный код.

давай, накропай пару строк «любого шаблонного кода», ну или признай, что бредил на тему стирания типов в с++

Не существуют. В рантайме явы существуют только объекты с монотипом. То есть имеется ф-я с монотипом, которая _как бы_ ведет себя как полиморфная. Но это не делает ее полиморфной.

раскрой тему подробнее

что значит _как бы_?

чем ее поведение отличается от поведения Действительно По Настоящему Ну Точно Точно Мамой Клянусь полиморфной функции?

> Если generic - это единый код функции для всех типов, с которыми она работает, то в Си++ просто нет generic'ов, и type erasure тоже нет.

формально это правильно, но нет проблемы реализовать дженерики ручками — и я все пытаюсь понять, бредит анонимус (что наиболее вероятно), или и правда имеет что-то в виду

при реализации ручками, опять же, нет проблем пропихнуть инфу о типах в рантайм

если он упорно будет отделываться словами «Любой шаблонный код», может я и не поленюсь набросать че-то похожее на имплициты скалы на плюсах

Если нет, то и ничего плохого в этом нет.

Есть. Становятся невозможными конструкции типа:

struct Factory {
  template <typename T>
  T* create() {
    // готовим параметры итп...
    return new T(arg1, arg2, arg3);
  }
};

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

А в этом точно виноват гипотетический type erasure? Насколько я знаю, Си++ всегда запрещал функции, различающиеся только типом возврата.

> Разве type erasure - не затирание информации о параметрах шаблона?

Именно оно и есть. Кривой костыль, короче говоря.

давай, накропай пару строк «любого шаблонного кода», ну или признай, что бредил на тему стирания типов в с++

Ну хорошо, вот пример:

template< T > T id(T x){return x;}

Если скомпилировать этот шаблон, то типы затрутся и полиморфной ф-и id в результате компиляции мы не получим.

чем ее поведение отличается от поведения Действительно По Настоящему Ну Точно Точно Мамой Клянусь полиморфной функции?

Полиморфная ф-я - это ф-я из типов в значения. Неполиморфная - из значений в значения. Полиморфную ф-ю нельзя применить к значениям, ее можно применять только к типам. В жабе «полиморфные» ф-и применяются к значениям. По-этому они и «полиморфные», а не полиморфные.

> формально это правильно, но нет проблемы реализовать дженерики ручками

Какие генерики? При чем тут генерики? Никто вообще не говорил ни о генериках, ни о темплейтах, речь шла искючительно о различных реализациях параметрического полиморфизма.

при реализации ручками

Реализации ручками чего? Компилятора?

Еще раз. Type erasure - стирнаие информации о полиморфных типов при компиляции. То есть в результате type erasure после компиляции полиморфных типов в программе не остается. Ответь на вопрос: остаются ли полиморфные типы после компиляции программы на с++?

Я не понял, у нас уже любой статический полиморфизм - это сразу type erasure?

> Я не понял, у нас уже любой статический полиморфизм - это сразу type erasure?

Нет, type erasure - это только если применение к полиморфному аргументу в компайлтайме происходит.

> Не существует такой штуки, как алгоритм Хиндли-Милнера, десу.

А еще не существует законов гравитации.

http://ru.wikipedia.org/wiki/Вывод_типов

> Полиморфная ф-я - это ф-я из типов в значения. Неполиморфная - из значений в значения.

«Век живи - век учись» подумал Ржевский и переложил серебрянный портсигар в карман пальто.

Где это Вы нашли _такое_ определение полиморфной функции? :)

тогда тебе надо юзать dynamic_cast. Там как раз проверка есть.

>Насколько я знаю, Си++ всегда запрещал функции, различающиеся только типом возврата.

Это не overload'ы одной ф-ции, а шаблонная ф-ция - тут можно. Этот код нормально работает:

struct A
{
	A(const char*) {}
};

struct B
{
	B(const char*) {}
};


struct Factory
{
	template <typename T>
	T* create() {
		return new T("a");
	}
};


int main(int argc, char **argv)
{
    Factory f;
    A* a = f.create<A>();
    B* b = f.create<B>();
    return 0;
}

>Именно оно и есть. Кривой костыль, короче говоря.
Информация о параметрах шаблона в С++ не затирается.

Еще раз. Type erasure - стирнаие информации о полиморфных типов при компиляции. То есть в результате type erasure после компиляции полиморфных типов в программе не остается.

Что ещё за полиморфные типы? Generic? Но ведь выше вы подтвердили, что type erasure - это затирание информации о типах-параметрах генерика(или шаблона), а не затирание самих генериков?

остаются ли полиморфные типы после компиляции программы на с++

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

Если type erasure - это не затирание типов-параметров шаблона, то ничего плохого в нём нету. Просто со слов анонимуса не понятно что он подразумевает под type erasure.

Не существует такой штуки, как алгоритм Хиндли-Милнера-Десу.

конечно не существует

десу

Нет такого слова.

Вот ещё: «type erasure — a process where the compiler removes all information related to type parameters and type arguments within a class or method.» Т.е(по версии oracle) - type erasure именно удаление информации о типах-параметрах, чего в С++ не происходит.

> Type erasure - стирнаие информации о полиморфных типов при компиляции. То есть в результате type erasure после компиляции полиморфных типов в программе не остается. Ответь на вопрос: остаются ли полиморфные типы после компиляции программы на с++?

гы-гы

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

/*  выхлоп: 
 
compiler_specific_name=i demangled_name=int demangle_status=ok 
7 
compiler_specific_name=7MyClassILi19EE demangled_name=MyClass<19> demangle_status=ok 
19 
 
*/
#include <stdlib.h> 
#include <iostream> 
#include <cxxabi.h> 

template<class T> void print_type_name(T& u)
{
    int     status;
    char   *realname;

    const std::type_info  &ti = typeid(u); /// это стандарт с++

    std::cout << "compiler_specific_name=" << ti.name() ; /// это стандарт с++
    std::cout << " demangled_name=" << (realname = abi::__cxa_demangle(ti.name(), 0, 0, &status)) ; /// а это уже расширение ж++
    std::cout << " demangle_status=" << (status==0? "ok" : "failed") << '\n';
    free(realname);
}

template<class T> T id(T x)
{
    print_type_name(x);
    return x;
}

template<int i> struct MyClass {.
    int f() { return i; }
};

int main()
{
    std::cout << id(7) << "\n";
    std::cout << id( MyClass<19>() ).f() << "\n";
    return 0;
}
[[/code]]

> template<int i> struct MyClass {.

лишняя точка пролезла после копирования из окна мс

>> Полиморфная ф-я - это ф-я из типов в значения. Неполиморфная - из значений в значения.

«Век живи - век учись» подумал Ржевский и переложил серебрянный портсигар в карман пальто.

по последним данным криптоаналитиков, анонимус хотел сказать: в яве невозможна полиморфная функция вида

import java.util.*;

class Test {
    static <T> int is_instance_of_list_of_string (T list) {
        if (list instanceof List<String>)  // error: illegal generic type for instanceof
            return 1;
        else
            return 0;
    }
};
public class BadBadJava {
    public static void main(String[] args) {
        List<String> list = new ArrayList<String> ();
        System.out.println( Test.is_instance_of_list_of_string(list) );
    }
}

точный ответ на твой вопрос: все зависит от того, как *ты* реализуешь дженерики в плюсах (в самом языке их нет)

сделать так, чтобы компилятор проверял полиморфизм можно только костыльно; но не стирать информацию о типах можно довольно легко (для этого пишется например класс Boxed<T>, я его уже постил на лоре)

и пиши яснее, а иначе я разорюсь на зарплате группе криптоаналитиков :-/

> Просто оставлю это здесь: The Dark Side of C++

Просто феерический бред!

Dark side of men

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

Вывод - человечество должно быть уничтожено, потому как несовершенно.

Мозг включайте, когда такие опусы читаете! А то опять чей-то высер за истину последней инстанции принимаете. Так и умрете от опечатки. Хотя бы задайтесь вопросом, а почему эта вешь/понятие/принцип/существо сделано именно так, а не иначе.

Как только начнешь выковыривать у себя бревна из глаз, то и другие соломинки кажутся уже украшением.

Даже на ЛОРе не стоит всякое говно оставлять.

А зачем вообще С++? На нём ещё проекты остались что ли?

> А зачем вообще С++? На нём ещё проекты остались что ли?

ну вот я сейчас, например, собираю unity( на C++ ) без кнопки меню в доке

забыл добавить - заодно пользуясь KDE( на C++ )

// написано из Chromium( на С++ )

Юнити не чистый С++, KDE к 5 версии будет почти весь на QML. Смиритесь, не нужен никому монстр в виде С++.

> Юнити не чистый С++

на 95%, сам не думал, что тут столько плюсового кода

KDE к 5 версии будет почти весь на QML

описание гуя != логика, тот же kate, например, хрен напишешь на JS

Смиритесь, не нужен никому монстр в виде С++.

можешь так считать, дело твое конечно

>на 95%, сам не думал, что тут столько плюсового кода

Ух ты. Не знал. А что тогда там на вала?

описание гуя != логика, тот же kate, например, хрен напишешь на JS

QML + JS там не только гуй будет. Там получаются достаточно быстрые приложения.

можешь так считать, дело твое конечно

Скажи честно, тебе доставляет удовольствие писать на таком сборе костылей?

> Ух ты. Не знал. А что тогда там на вала?

по сути ничего, просто поддержка для написания стороннего кода для unity на vala

QML + JS там не только гуй будет. Там получаются достаточно быстрые приложения.

посмотрим, но очень врядли, не тот JS язык, чтоб на нем подобное DE крутилось

Скажи честно, тебе доставляет удовольствие писать на таком сборе костылей?

с удовольствием использовал бы другой ЯП, но нормальных С-подобных( не только по синтаксису ) языков нет

>посмотрим, но очень врядли, не тот JS язык, чтоб на нем подобное DE крутилось

А С++ слишком громоздок и сложен. Хорошо, что разрабы KDE вовремя поняли это.

с удовольствием использовал бы другой ЯП, но нормальных С-подобных( не только по синтаксису ) языков нет

Мне нравится Java. Но она не для прикладного софта.

А чем С# не подходит? Или чистые Си?

> Хорошо, что разрабы KDE вовремя поняли это.

они и сейчас пишут на С++ :) как я уже говорил - не будем загадывать

А чем С# не подходит?

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

Или чистые Си?

нравятся, но таки не хватает плюшек из С++, приходится писать больше кода, а хочется писать компактно, но используя «мощь» языка С

>не хочется завязываться на mono, не уверен, что его долго будут развивать и поддерживать

Хотя бы есть надежда. А на С++ только легаси и ни одного нового проекта.

> и ни одного нового проекта.

а что же я сейчас ковыряю( unity ) ? :) есть конечно, и очень много, и даже под всякие андроиды и пр., просто больших мало новых появляется( если не считать игры ), но то к любому языку относится