LINUX.ORG.RU

C++0x: концептов не будет

 ,


0

0

Комитет по стандартизации ISO языка программирования С++ на июльском собрании принял решение отказаться от идеи концептов в новом стандарте. Основных причины две - сомнительная польза от столь существенного нововведения и сырость текущего предложения: за шесть лет разработки авторам так и не удалось определиться с полным и однозначным описанием.

Концепты предполагали дать возможность наложения ограничений на обобщённые типы в шаблонах функций и классов; можно провести аналогию с классами типов из Haskell.

По словам Майкла Вонга, члена комитета по стандартизации C++, пересмотра данного решения стоит ожидать не ранее чем через пять лет. Стоит заметить, что ранее из проекта стандарта была выброшена идея сборщика мусора; причиной была названа излишняя сложность в реализации.

Статья Страуструпа «Simplifying the Use of Concepts»: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2906.pdf

Статья Вонга (часть 1): http://www-949.ibm.com/software/rational/cafe/blogs/cpp-standard/2009/07/20/the-view-or-trip-report-from-the-july-2009-c-standard-meeting

Статья Вонга (часть 2): http://www-949.ibm.com/software/rational/cafe/blogs/cpp-standard/2009/07/20/the-view-or-trip-report-from-the-july-2009-c-standard-meeting-part-2

>>> Подробности

★★★★★

Проверено: Shaman007 ()

Ответ на: комментарий от funky_dennis

Мде... а ты точно уже не студент? Потому что студню, который только что освоил Си и прется от крутизны (своей и языка), такие заявления простить еще можно. Но для действующего прогера - это клиника...

tailgunner ★★★★★
()

Лямбды-то хоть живы еще? Или тоже зарежут? :(

rmammoth
()
Ответ на: комментарий от Manhunt

Я намекаю, что это было круто в старых версиях компилятора. В современных компиляторах после оптимизации оно итак будет register, если компилятор "видит", что переменная будет менять свое значение часто.

funky_dennis
()

Без паники :) Фактически это значит, что идея концептов отдана на откуп производителям компиляторов. Обкатают в виде нестандартных расширений С++, а там и в Стандарте появится.

greenMind
()
Ответ на: комментарий от funky_dennis

> Что, 2.95.хх тоже умел такое? :)

Думаю, да, но не в этом пойнт. Зачем делать _такую_ оптимизацию вручную? Лптимизируй алгоритмы, а оптимизацию кода оставь компилятору.

tailgunner ★★★★★
()
Ответ на: комментарий от funky_dennis

Объясню на пальцах - сейчас можно не беспокоиться о скорости выполнения участков кода, так как компиляторы стали настолько суровы, что программисты будут скоро не нужны. Можно будет писать прямо словами на своем родном языке :) Компилятор сделает наиболее оптимальный алгоритм выполнения задачи :)

funky_dennis
()
Ответ на: комментарий от tailgunner

Да что такое :) Алгоритмы нужно оптимизировать былокодерам. Вменяемый программист пишет код, скорость которого упирается в CPU или IO, где кроме как хардварного апгрейда (масштабирование вертикально) или масштабирования вширь производительность не увеличить.

funky_dennis
()
Ответ на: комментарий от greenMind

Не станет ли это началом почкования, подобного C++/ObjectiveC?

impfp
()
Ответ на: комментарий от funky_dennis

Вроде ж в ридонли собрались? ;)

>Компилятор сделает наиболее оптимальный алгоритм выполнения задачи :) 
Да, но это будет не родственник C++ :)

impfp
()
Ответ на: комментарий от funky_dennis

> Алгоритмы нужно оптимизировать былокодерам. Вменяемый программист пишет код, скорость которого упирается в CPU или IO

Спасибо, поржал.

> Я намекаю, что это было круто в старых версиях компилятора.

В суровые 80-е -- наверное.

Manhunt ★★★★★
()
Ответ на: комментарий от funky_dennis

> Алгоритмы нужно оптимизировать былокодерам

Ааааа я повелся на троллинг!!1111 %)

> Вменяемый программист пишет код, скорость которого упирается в CPU или IO, где кроме как хардварного апгрейда (масштабирование вертикально) или масштабирования вширь производительность не увеличить.

причем этот тролль еще и не умеет выражать свои мысли :D

tailgunner ★★★★★
()
Ответ на: комментарий от impfp

>>Компилятор сделает наиболее оптимальный алгоритм выполнения задачи :)
>Да, но это будет не родственник C++ :)


Боюсь, без квантовых компьютеров (чтобы решать np-полные задачи) этого не будет. Да и с ними - не факт.

Manhunt ★★★★★
()

Мать твою. А смысл тогда в этом какой? в новом стандарте

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

namezys ★★★★
()
Ответ на: комментарий от namezys

> А смысл тогда в этом какой? в новом стандарте

STL обновят. Слово auto. Конструкторы от &&. Variadic templates. Тебе этого мало? :)

Manhunt ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

> Где еще есть приличные type classes или аналоги?

В Jekyll же :)

tailgunner ★★★★★
()
Ответ на: комментарий от smh

> И еще лет 20 проживет. :-)

Будь моя воля, я бы его закопал. Вместе с Си. Семантика у языков этих - ахтунг полнейший. Взять хотя бы недавнюю новость про дырку в линуксячем ведре http://www.linux.org.ru/view-message.jsp?msgid=3880660 .

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

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

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

funky_dennis
()
Ответ на: комментарий от funky_dennis

> Там же написано, что бага не в ядре, а в компиляторе.

Вариантов 2: 1. Бага в стандарте (попросту кривой) и в компиляторе (он более единообразно обращается с указателями, чем формально обязан по стандарту). 2. Стандарт более-менее логичен, компилятор в точности ему следует, а бага все-таки - в ведре.

Какой из вариантов имеет место - я до конца не уверен. Предполагаю, что 1.

> Пытаются сделать из крмпилятора AI

Это нормально.

> чтобы быдлокод превратить в нормальный код.

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

Manhunt ★★★★★
()
Ответ на: комментарий от funky_dennis

> Там же написано, что бага не в ядре, а в компиляторе

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

tailgunner ★★★★★
()
Ответ на: комментарий от Manhunt

Боюсь, что оных не будет никогда (в сегодняшнем понимании - с кубитами и прочим найобиумом) :)

А вот компилятор английского - вполне себе возможно, и даже в обозримом будущем. Возможно даже и оптимизирующий :)

impfp
()
Ответ на: комментарий от Manhunt

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

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

if ($val == "bla")
                                   { // some evil code
            exit(); }

if ($val != "bla") { // some nice code
                                                         }

Ну дак а троллинг это что такое?

funky_dennis
()
Ответ на: комментарий от impfp

> А вот компилятор английского - вполне себе возможно, и даже в обозримом будущем. Возможно даже и оптимизирующий :)

Ага, basic называется :) Вот только "о построении _наилучшего_ решения задачи, сформулированной на чистом английском языке" можно даже не мечтать.

Manhunt ★★★★★
()
Ответ на: комментарий от funky_dennis

> А, ну да, читал уже, что в пространстве ядра a = b->c, при условии, что b == NULL, паники не будет.

Паники не будет. Будеет четкий осмысленный Oops, с дампом регистров, трейсом, блэкджеком и шлюхами.

tailgunner ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

Ну какбы старый добрый ML-like :)

Язык Coq; там, вроде как, вообще весь лямбда-куб реализован, в отличие от хаскеля того же...

impfp
()
Ответ на: комментарий от mannaz

>>сборщик мусора... уже реализовали(Qt4)

>ЩИТО?

Там сборщик мусора "Тарас Бульба"-style: если у объекта некоего класса-потомка QObject есть родитель, то этот родитель сам удаляет своих потомков.

MYMUR ★★★★
()
Ответ на: комментарий от Manhunt

Ну что Вы :) Я ж про нормальный компилер, и про нормальный английский :) Про такой компилер который в себе реализует к.-л. вероятностную грамматику языка со словарями, знаниями и прочими лингвистическими плюшками... >о построении _наилучшего_ решения задачи, сформулированной на чистом английском языке Уж ли не на Шекспировском? :) Хотя... посмотрим, куда закатятся те же суперкомпиляторы и иже с ними лет эдак через пяток-другой

impfp
()
Ответ на: комментарий от yk4ever

> Любителей перла надо сослать в Китай, нехай привычны к ероглифам.

У малшега детская травма? Взрослые бородатые перлисты трогали тебя во всяких местах?

AnDoR ★★★★★
()
Ответ на: комментарий от tailgunner

>Может, это и хорошо.

Как сказать - ты читал что оно такое? Это ж велосипед с квадратными
 колесами при чем крутить их надо раздельно руками! 

concept AB<typename T> {
    void a(T&);
    void b(T&); 
}; 
concept A<typename T> {
    void a(T&);
};

Ну объявили типа "класс типа".

> Obviously, every type that’s an AB is also an A, 

Очевидно.

template<A T> void g(T);
template<AB T> void f(T t)
{
    g(t); // valid call?
}

Вот и меня это интересует...

>Obviously, an AB has an a() as required by A. Obviously, A is a subset of AB.

Очевидно.

>Someone with some knowledge of concepts might say “no” and suggest 
>that AB needs to be derived from (a refinement of) A for the compiler
> to notice the obvious subset relationship.

А - то эсть это очевидно всем кроме писателя компилятора. 

>However, in real code we may not be able to modify the definition of AB.

Да не может быть! И каков же будет наш ответ парижу?

template<AB T> concept_map A<T> { } // every AB is an A

Долбонуться! В то время как народ бороздит моря дактайпинга реализуя в
 статических языках в виде структурных типов....

Короче ужос какой-то.

C++ типа объектный язык. Нахрена объектному языку классы типов хаскеля  да еще так жестоко?

r ★★★★★
()
Ответ на: комментарий от naryl

>В блоке constraint может быть абсолютно любой вычислимый при компиляции код.

Вот интересно. Вычсления темплейтов С++ как и собственно темплейтов D - это в принципе оверкил в том смысле что вычисляются специально руками объявленные структуры. А в компиляторах как дела с разработкой агресивных оптимизаций которые жестоко сворачивают константный код?

типа

int f(a,b) { return a + b }

f(3,f(4,5)) => откомпилируется в константу 12?

r ★★★★★
()
Ответ на: комментарий от r

Во избежание некоторых проблем в D такое происходит только если вызов в контексте, где необзодима константа времени компиляции. Можно использовать шаблон eval, инициализацию глобальной или статической переменной или pragma(msg).

import std.stdio;

int f(int a, int b) { return a + b; }

void main() {
    static val = f(3, f(4, 5));
    writefln(val);
}

pragma(msg, f(3, f(4, 5)));

Выводит 12 и при выполнении и при компиляции. Функция f во время выполнения не будет вызвана ни разу.

(опечаток и ошибок в коде нет)

naryl ★★★★★
()
Ответ на: комментарий от funky_dennis

>Херасе, я тут развел... :) Троллинг это что такое? :)

это то, что ты развел

registrant ★★★★★
()
Ответ на: комментарий от r

> f(3,f(4,5)) => откомпилируется в константу 12?

gcc при -O2 и больше - да.

yekm
()
Ответ на: комментарий от mannaz

>> сборщик мусора... уже реализовали(Qt4)

>ЩИТО?

разработчики Qt Software нахардкодили много random-мусора в Qt4... :)

shty ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>Бляяяяяяяяяяяяяяяя! И че, хаскелисты следующие 5 лет будут безнаказано нас чморить type class-ами?!

а Вы троллей не кормите и пиписьками не меряйтесь почём зря - не придётся расстраиваться... :)

shty ★★★★★
()
Ответ на: комментарий от fAX

>Еще никто не показал, что квантовые компьютеры могут решать...

пока ещё никто и самих квантовых компьютеров не показал во вменяемом виде

shty ★★★★★
()
Ответ на: комментарий от shty

Спасибо. Прошу прощения у сообщества, если чем то вызвал негативные эмоции :)

funky_dennis
()
Ответ на: комментарий от ferhiord

>> а отсутствие сборщика мусора?

>Это не задача языка.

Спорно. Возможно, что надо все-таки менять язык под сборщик мусора. Слишком многие вещи подразумевает последний. Там не так все просто. Одной перегрузкой new похоже не обойтись. Если бы было так просто, то давно бы что-нибудь придумали действительно простое и удобное.

Вот, пример языка со сборщиком мусора - С++/CLI. Правда, там еще используется CLR, и все классы, собираемые GC, также являются и управляемыми классами.

dave ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.