Вывод параметров шаблона в C++17 - C/C++

Здравствуйте, _NN_, Вы писали:

_NN>Никто не знает планируется ли такая фишка в будущем ?

_NN>

_NN>template<typename T>
_NN>struct A
_NN>{
_NN>  A(T) {}
_NN>};

_NN>A x(1); // Вывод T = int
_NN>

_NN>Может в С++11 можно что-то сделать ?

Насколько я понял уже приняли в черновик C++17 — называется "deduction guides":
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0091r3.html
http://eel.is/c++draft/temp.deduct.guide

Примеры из статьи.
Было:

pair<int, double> p(2, 4.5);
auto t = make_tuple(4, 3, 2.5);
copy_n(vi1, 3, back_inserter(vi2));
// Virtually impossible to pass a lambda to a template class' constructor without declaring the lambda
for_each(vi2.begin(), vi2.end(), Foo<???>([&](int i) { ...}));
lock_guard<std::mutex> lck(foo.mtx);
lock_guard<std::mutex, std::unique_lock<std::mutex>> lck2(foo.mtx, ul); // Notation from N4470

Стало:

pair p(2, 4.5);
tuple t(4, 3, 2.5);
copy_n(vi1, 3, back_insert_iterator(vi2));
for_each(vi.begin(), vi.end(), Foo([&](int i) { ...})); // Now easy instead of virtually impossible
auto lck = lock_guard(foo.mtx);
lock_guard lck2(foo.mtx, ul);

31.12.16 02:03: Ветка выделена из темы [Предложение] Вывод типа шаблона класса из конструктора — Кодт

но вообще, конечно, радует что хоть и медленно, но развитие языка идет.

Здравствуйте, night beast, Вы писали:

NB>некропост детектед

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

NB>но вообще, конечно, радует что хоть и медленно, но развитие языка идет.

Хорошо что после периода относительной тишины C++98 — C++11 (с промежуточным C++03) пошло заметное ускорение — C++14, C++17 (надеюсь таки примут в семнадцатом и сохранят темп).

NB>>некропост детектед

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

Видимо всё-таки лучше было создать отдельную тему со ссылкой на старую, ибо не только лишь все смотрят на дату сообщений

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Насколько я понял уже приняли в черновик C++17 — называется "deduction guides":
EP>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0091r3.html
EP>http://eel.is/c++draft/temp.deduct.guide

И дополню ссылкой, которую привёл antropolog в том некропосте:

http://en.cppreference.com/w/cpp/language/class_template_deduction

там с примерами и человечьим, хоть и нерусским, языком расписано (почти то же самое, что в черновике, но без "we propose...")

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>приняли в черновик C++17 — называется "deduction guides"

EP>

а ни у кого нет опасений по поводу распространения неявного duck-typing за счет подобных вещей?
мне, например, не очень нравится, что стандарт не дает возможности контроля за подобными вещами. можно было бы синтаксис сделать наподобие

std::pair<auto, auto> p(2, 4.5);

для тех, кто хочет пользоваться данной фичей, чтобы предупредить скрытое выведение как в

std::pair p(2, 4.5);

Здравствуйте, _hum_, Вы писали:

EP>>приняли в черновик C++17 — называется "deduction guides"
EP>>

__>а ни у кого нет опасений по поводу распространения неявного duck-typing за счет подобных вещей?

Нет, duck-typing'а и так много. А вот снятие необходимости педалить make_* обёртки — это ощутимое улучшение.

__>мне, например, не очень нравится, что стандарт не дает возможности контроля за подобными вещами. можно было бы синтаксис сделать наподобие
__>

__>std::pair<auto, auto> p(2, 4.5); 
__>

Много буковок/закорючек, больше чем в make_pair.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, _hum_, Вы писали:

EP>>>приняли в черновик C++17 — называется "deduction guides"
EP>>>

__>>а ни у кого нет опасений по поводу распространения неявного duck-typing за счет подобных вещей?

EP>Нет, duck-typing'а и так много. А вот снятие необходимости педалить make_* обёртки — это ощутимое улучшение.

я про неявный duck-typing говорил. а его не так уж и много было (только в функциях)

__>>мне, например, не очень нравится, что стандарт не дает возможности контроля за подобными вещами. можно было бы синтаксис сделать наподобие
__>>

__>>std::pair<auto, auto> p(2, 4.5); 
__>>

EP>Много буковок/закорючек, больше чем в make_pair.
ну, ок, сделайте

>std::pair<auto...> p(2, 4.5);

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

Здравствуйте, _hum_, Вы писали:

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

так и используй полное указание параметров как раньше, в чем проблема то?

Здравствуйте, night beast, Вы писали:

NB>Здравствуйте, _hum_, Вы писали:

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

NB>так и используй полное указание параметров как раньше, в чем проблема то?

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

Здравствуйте, _hum_, Вы писали:

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

NB>>так и используй полное указание параметров как раньше, в чем проблема то?

__>во-первых, речь шла о синтаксисе новой функциональности. поэтому "как раньше" тут неуместно,

с чего бы вдруг? новая функциональность здесь просто синтаксический сахар.

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

и? ты же не жалуешься что когда компилер не ругается, если ты вместо i поставил j в цикле?
вот ты auto в коде используешь? если да, то почему?

Здравствуйте, night beast, Вы писали:

NB>Здравствуйте, _hum_, Вы писали:

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

NB>>>так и используй полное указание параметров как раньше, в чем проблема то?

__>>во-первых, речь шла о синтаксисе новой функциональности. поэтому "как раньше" тут неуместно,

NB>с чего бы вдруг? новая функциональность здесь просто синтаксический сахар.

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

wiki/Syntactic_sugar
a construct in a language is called syntactic sugar if it can be removed from the language without any effect on what the language can do: functionality and expressive power will remain the same.

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

NB>и? ты же не жалуешься что когда компилер не ругается, если ты вместо i поставил j в цикле?

потому что в большинстве случаев он ругается

NB>вот ты auto в коде используешь? если да, то почему?

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

Здравствуйте, _hum_, Вы писали:

NB>>с чего бы вдруг? новая функциональность здесь просто синтаксический сахар.

__>у вас какое-то слишком широкое понимание синтаксического сахара я придерживаюсь
__>

wiki/Syntactic_sugar
__>a construct in a language is called syntactic sugar if it can be removed from the language without any effect on what the language can do: functionality and expressive power will remain the same.

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

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

NB>>и? ты же не жалуешься что когда компилер не ругается, если ты вместо i поставил j в цикле?

__>потому что в большинстве случаев он ругается

кто конкретно?

for (int i = 0; i < size_i; ++i) for (int j = 0; i < size_j; ++j) ...

NB>>вот ты auto в коде используешь? если да, то почему?

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

то есть используешь? а теперь представь, что тебе для авто просто дали возможность уточнить тип.
ну видно, и дальше че?

__>к тому же сложно так описаться, чтобы изменить семантику.

хз, как можно описаться и поставить лишние <>
это тебе не один символ перепутать.

Здравствуйте, night beast, Вы писали:

NB>Здравствуйте, _hum_, Вы писали:

NB>>>с чего бы вдруг? новая функциональность здесь просто синтаксический сахар.

__>>у вас какое-то слишком широкое понимание синтаксического сахара я придерживаюсь
__>>

wiki/Syntactic_sugar
__>>a construct in a language is called syntactic sugar if it can be removed from the language without any effect on what the language can do: functionality and expressive power will remain the same.

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

ну, так тогда с++ — это синтаксический сахар ассемблера, потому как с помощью последнего можно воспроизвести все конструкции первого

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

NB>>>и? ты же не жалуешься что когда компилер не ругается, если ты вместо i поставил j в цикле?

__>>потому что в большинстве случаев он ругается

NB>кто конкретно?
NB>

NB>for (int i = 0; i < size_i; ++i) for (int j = 0; i < size_j; ++j) ...
NB>

это исключительный случай ("каноническое" итерирование двумерного массива), а не "большинство".

NB>>>вот ты auto в коде используешь? если да, то почему?

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

NB>то есть используешь? а теперь представь, что тебе для авто просто дали возможность уточнить тип.
NB>ну видно, и дальше че?

__>>к тому же сложно так описаться, чтобы изменить семантику.

NB>хз, как можно описаться и поставить лишние <>
NB>это тебе не один символ перепутать.

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

struct Pair{char first; char second;};

Pair x{"a",'b'}; // compiller error

может одним нечаянным недонажатием shift легко превратиться из-за всеядности stl-овского класса в компилируемый

struct Pair{char first; char second;};

pair x{"a",'b'}; // ок

Здравствуйте, _hum_, Вы писали:

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

__>ну, так тогда с++ — это синтаксический сахар ассемблера, потому как с помощью последнего можно воспроизвести все конструкции первого

какого конкретно ассемблера?

NB>>>>и? ты же не жалуешься что когда компилер не ругается, если ты вместо i поставил j в цикле?

__>>>потому что в большинстве случаев он ругается

NB>>кто конкретно?
NB>>

NB>>for (int i = 0; i < size_i; ++i) for (int j = 0; i < size_j; ++j) ...
NB>>

__>это исключительный случай ("каноническое" итерирование двумерного массива), а не "большинство".

не один раз нарывался на этот исключительный случай. наверно я исключительный человек...

__>>>auto имеет явный синтаксис, и потому его использование сразу видно.
NB>>ну видно, и дальше че?
__>

__>>>к тому же сложно так описаться, чтобы изменить семантику.

NB>>хз, как можно описаться и поставить лишние <>
NB>>это тебе не один символ перепутать.

__>я же к тому и веду — раньше из-за требования явного указания скобочного синтаксиса шаблона вероятность описаться незаметно для компилятора была низкая. теперь же эту защиту убрали. и значит, например, ошибочный код
__>

__>struct Pair{char first; char second;};

__>Pair x{"a",'b'}; // compiller error

__>

кто-то вместо 2-х ' опечатался и поставил 2-а " , а потом еще раз опечатался? итого три (ладно, две учитывая иде) опечатки на одну строку кода. ничего не скажешь, замечательный пример.

__>может одним нечаянным недонажатием shift легко превратиться из-за всеядности stl-овского класса в компилируемый
__>

__>struct Pair{char first; char second;};
__>pair x{"a",'b'}; // ок
__>

и? получил ты std::pair, что с ней будешь делать? передавать в функцию которая ждет Pair?

Здравствуйте, night beast, Вы писали:

NB>Здравствуйте, _hum_, Вы писали:

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

__>>ну, так тогда с++ — это синтаксический сахар ассемблера, потому как с помощью последнего можно воспроизвести все конструкции первого

NB>какого конкретно ассемблера?

любого

NB>>>>>и? ты же не жалуешься что когда компилер не ругается, если ты вместо i поставил j в цикле?

__>>>>потому что в большинстве случаев он ругается

NB>>>кто конкретно?
NB>>>

NB>>>for (int i = 0; i < size_i; ++i) for (int j = 0; i < size_j; ++j) ...
NB>>>

__>>это исключительный случай ("каноническое" итерирование двумерного массива), а не "большинство".

NB>не один раз нарывался на этот исключительный случай. наверно я исключительный человек...

вы вообще различаете понятие "случай" и "фрагмент кода"?

__>>может одним нечаянным недонажатием shift легко превратиться из-за всеядности stl-овского класса в компилируемый
__>>

__>>struct Pair{char first; char second;};
__>>pair x{"a",'b'}; // ок
__>>

NB>и? получил ты std::pair, что с ней будешь делать? передавать в функцию которая ждет Pair?

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

ладно, ваше настроение понял. можно дальше не продолжать.

Здравствуйте, _hum_, Вы писали:

__>>>ну, так тогда с++ — это синтаксический сахар ассемблера, потому как с помощью последнего можно воспроизвести все конструкции первого

NB>>какого конкретно ассемблера?
__>любого

собственно, это и значит что плюсы не сахар ассемблера.

NB>>>>>>и? ты же не жалуешься что когда компилер не ругается, если ты вместо i поставил j в цикле?

__>>>может одним нечаянным недонажатием shift легко превратиться из-за всеядности stl-овского класса в компилируемый
__>>>

__>>>struct Pair{char first; char second;};
__>>>pair x{"a",'b'}; // ок
__>>>

NB>>и? получил ты std::pair, что с ней будешь делать? передавать в функцию которая ждет Pair?

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

__>ладно, ваше настроение понял. можно дальше не продолжать.

+1.
если вам кроме того что кто-то где-то может опечататься, предложить нечего, то действительно лучше закончить.

	От:	Evgeny.Panasyuk
	Дата:	28.12.16 20:16
	Оценка:	100 (5) +1

	От:	night beast
	Дата:	29.12.16 06:17
	Оценка:	+1

	От:	Evgeny.Panasyuk
	Дата:	29.12.16 21:02
	Оценка:	1 (1) +3

	От:	Evgeny.Panasyuk
	Дата:	30.12.16 09:32
	Оценка:	+3

	От:	Кодт
	Дата:	30.12.16 23:09
	Оценка:	20 (1)

	От:	_hum_
	Дата:	03.01.17 10:33
	Оценка:

	От:	_hum_
	Дата:	03.01.17 16:33
	Оценка:

	От:	_hum_
	Дата:	04.01.17 20:10
	Оценка:

	От:	_hum_
	Дата:	04.01.17 22:18
	Оценка: