Текущий Стандарт С++ и перспективы его развития

Flex Ferrum, я думал об этом. Но иметь полиморфный вызов для сравнения - не по плюсовому как-то

Цитата MyNameIsIgor @ 26.07.10, 09:52

Flex Ferrum, я думал об этом. Но иметь полиморфный вызов для сравнения - не по плюсовому как-то

А иначе то - никак. По большому счёту. Хотя (по последней редакции стандарта) должно работать так:

   // При объявлении типа мапы:
   typedef std::multimap<int, A, bool (*)(A a1, A a2)> mmap_type;
    
   // при объявлении экземпляра мультимапы:
   mmap_type m([](A a1, A a2) {return a1.i < a2.i; });

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

Цитата Flex Ferrum @ 26.07.10, 09:55

А иначе то - никак. По большому счёту.

А чем вариант с отдельным компаратором не устраивает?

Цитата Flex Ferrum @ 26.07.10, 09:55

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

Но, опять же, на inline такого простейшего сравнения не приходится надеяться.

Цитата MyNameIsIgor @ 26.07.10, 09:58

А чем вариант с отдельным компаратором не устраивает?

Ну, это классика, которая уже перенесена в STL.

Добавлено 26.07.10, 10:49

Цитата MyNameIsIgor @ 26.07.10, 09:58

Но, опять же, на inline такого простейшего сравнения не приходится надеяться.

Да как сказать... Вполне может заинлайнить.

Цитата Flex Ferrum @ 26.07.10, 10:49

Ну, это классика, которая уже перенесена в STL.

В это же нет ничего плохого

Цитата Flex Ferrum @ 26.07.10, 10:49

Да как сказать... Вполне может заинлайнить.

Подумал... Да, может

Цитата Flex Ferrum @ 26.07.10, 09:55

Хотя (по последней редакции стандарта) должно работать так:

   // При объявлении типа мапы:
   typedef std::multimap<int, A, bool (*)(A a1, A a2)> mmap_type;
    
   // при объявлении экземпляра мультимапы:
   mmap_type m([](A a1, A a2) {return a1.i < a2.i; });

Интересное своей краткостью решение, но компилятор к сожалению ругается. Код (lambda.h):

#include <multimap.h>
 
struct A {
    int i;
};
 
class B {
 
        typedef std::multimap<A, int, bool (*)(A, A)> mmap_type;
    
        mmap_type m;
 
        B() : m([](A a1, A a2) {return a1.i < a2.i; })  {
        }
};

И сама ошибка:

lambda.h(13): error: no instance of constructor "std::multimap<_Key, _Tp, _Compare, _Alloc>::multimap [with _Key=A, _Tp=int, _Compare=bool (*)(A, A), _Alloc=std::allocator<std::pair<const A, int>>]" matches the argument list
            argument types are: (lambda [](A, A)->bool)
        B() : m([](A a1, A a2) {return a1.i < a2.i; })  {
               ^
 
compilation aborted for lambda.cpp (code 2)

В случае приведения в строке 13 к mmap_type::key_compare получаем это:

lambda.h(13): error: no suitable conversion function from "lambda [](A, A)->bool" to "bool (*)(A, A)" exists
        B() : m(mmap_type::key_compare([](A a1, A a2) {return a1.i < a2.i; }) ) {
                                       ^
 
compilation aborted for lambda.cpp (code 2)

Получается, еще недореализовали стандарт в тестируемом мною компиляторе?

Цитата ShapovalovTS @ 27.07.10, 03:01

Получается, еще недореализовали стандарт в тестируемом мною компиляторе?

Такие изменения - только в последней редакции стандарта (конец марта 2010-го года). Очевидно, что ещё ни один компиль это не реализует. Да и не зафиксировано это ещё окончательно.

Цитата Flex Ferrum @ 27.07.10, 05:47

в последней редакции стандарта

последней редакции предложения. Его же еще не приняли?

Цитата trainer @ 27.07.10, 06:02

последней редакции предложения. Его же еще не приняли?

Ну, да.

boost::variant? Проще некуда.

template<int I, typename ... T>
union variant_data;
 
template<int I, typename T, typename ... Tail>
union variant_data<I, T, Tail ...>
{
    T m_data;
    variant_data<I + 1, Tail ...> m_tail;
    
    variant_data() {;}
    ~variant_data() {;}
};
 
template<int I, typename T>
union variant_data<I, T>
{
    T m_data;
    variant_data() {;}
    ~variant_data() {;}
};
 
template<typename ... T>
struct variant
{
    int m_dataIdx;
    variant_data<sizeof ... (T), T ...> m_variantData;
};

Цитата Flex Ferrum @ 02.09.09, 08:49

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

Похоже, из C++0x могут удалить ни кем пока не реализованные фичи.

User-defined literals
Ref-qualifiers
Inheriting constructors

Работа комитета по стандартизации C++ радует всё больше и больше. Что правила C++ там толком не знают ([1][2][3]) я уже выяснил давно. Что некоторые члены комитета плохо владеют логикой и не пригодны для составления корректных формальных описаний выяснилось сравнительно недавно [1][2][3][4]. Теперь ещё нелепая мотивация добавления правил и удаления фич добавилась к послужному списку.

Hint: D. Krugler, A. Williams и S. Clamage состоят в рабочих группах комитета по стандартизации C++.

Цитата Masterkent @ 31.08.10, 00:53

Похоже, из C++0x могут удалить ни кем пока не реализованные фичи.

User-defined literals
Ref-qualifiers
Inheriting constructors

Ну, тут бабушка ещё на двое сказала. Это предложение только одной из стран (если я правильно понимаю аббревиатуру). С этим должны согласиться большинство, чтобы быть принятым. А переколбашивать драфт стандарта перед самым принятием - это жесть.

Цитата Flex Ferrum @ 07.09.10, 18:31

А переколбашивать драфт стандарта перед самым принятием - это жесть.

А когда состоится это самое принятие? Там по-любому ещё море исправлений надо внести - даже не считая те, которые пока не занесены в списки Core Language Active Issues и Library Active Issues.

Цитата Masterkent @ 08.09.10, 18:18

А когда состоится это самое принятие?

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

Цитата Flex Ferrum @ 09.09.10, 05:48

Ты намекаешь на то, что "никогда"?

Скорее, на то, что новый стандарт или выйдет нескоро, или выйдет скоро, но в нём будет много-много дефектов (впрочем, их и в C++03 море). У меня всё никак руки не дойдут составить подробный отчёт о некоторых дефектах, о которых в комитете предположительно не знают, и отправить его в CWG. Пока я только время от времени создавал темы на comp.lang.c++.moderated и comp.std.c++. Лишь малую часть описанных мной проблем D. Krugler и D. Gregor направили на рассмотрение в CWG: 978, 1005, 1055, 1059, 1068, 1093. Первую проблему уже пофиксили, остальные пока рассматриваются или дожидаются рассмотрения.

Сообщение отредактировано: Masterkent - 09.09.10, 11:07