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
Здравствуйте, night beast, Вы писали:
NB>некропост детектед
Я кстати не вижу проблем в некропостах, как минимум на технические темы.
NB>но вообще, конечно, радует что хоть и медленно, но развитие языка идет.
Хорошо что после периода относительной тишины C++98 — C++11 (с промежуточным C++03) пошло заметное ускорение — C++14, C++17 (надеюсь таки примут в семнадцатом и сохранят темп).
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>приняли в черновик C++17 — называется "deduction guides"
EP>
а ни у кого нет опасений по поводу распространения неявного duck-typing за счет подобных вещей?
мне, например, не очень нравится, что стандарт не дает возможности контроля за подобными вещами. можно было бы синтаксис сделать наподобие
std::pair<auto, auto> p(2, 4.5);
для тех, кто хочет пользоваться данной фичей, чтобы предупредить скрытое выведение как в
Здравствуйте, _hum_, Вы писали:
EP>>приняли в черновик C++17 — называется "deduction guides" EP>> __>а ни у кого нет опасений по поводу распространения неявного duck-typing за счет подобных вещей?
Нет, duck-typing'а и так много. А вот снятие необходимости педалить make_* обёртки — это ощутимое улучшение.
__>мне, например, не очень нравится, что стандарт не дает возможности контроля за подобными вещами. можно было бы синтаксис сделать наподобие __>
Здравствуйте, 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>это тебе не один символ перепутать.
я же к тому и веду — раньше из-за требования явного указания скобочного синтаксиса шаблона вероятность описаться незаметно для компилятора была низкая. теперь же эту защиту убрали. и значит, например, ошибочный код
Здравствуйте, _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>>это тебе не один символ перепутать.
__>я же к тому и веду — раньше из-за требования явного указания скобочного синтаксиса шаблона вероятность описаться незаметно для компилятора была низкая. теперь же эту защиту убрали. и значит, например, ошибочный код __>
кто-то вместо 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.
если вам кроме того что кто-то где-то может опечататься, предложить нечего, то действительно лучше закончить.