Должен ли я использовать функции C ++ 0x сейчас?

Question

С официальным выпуском VS 2010, безопасно ли мне начать использовать частично реализованный набор функций C ++ 0x в моем новом коде?

Функции, которые меня сейчас интересуют, реализованы в VC ++ 2010 и последних версиях GCC. Это единственные два, которые у меня есть для поддержки.

С точки зрения «безопасности», упомянутой в первом предложении: могу ли я начать использовать эти функции (например, лямбда-функции) и при этом быть гарантированно, что мой код скомпилируется через 10 лет на компиляторе, который должным образом соответствует C ++ 0x когда он будет официально выпущен?

Полагаю, я спрашиваю, есть ли шанс, что VC ++ 2010 или GCC в конечном итоге превратятся в VC ++ 6; он был выпущен до того, как язык был официально стандартизирован, и, следовательно, позволил скомпилировать чрезвычайно плохо сформированный код.

В конце концов, Microsoft действительно говорит, что «10 - это новая 6». ;)

Answer 1

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

struct test {
  int operator()(int);
};

std::cout << typeid( std::result_of<test(int)>::type ).name() << std::endl;

Согласно сайту википедии на C ++ 0x, это должно быть. Очевидно, VS2010 использует определение TR1 для result_of, которое отличается от того, что будет в C ++ 0x (на основе decltype).

Также это не работает:

std::bind<int>([](int i)->int {return i; });

Сбой из-за того, что вызов std :: result_of (ну, его реализация) завершился неудачей, потому что у лямбда-типа нет result_of typedef. Именно поэтому вы предоставляете тип возвращаемого значения для вызова bind, но, по-видимому, он по какой-то причине игнорирует его и продолжает поиск самостоятельно. Буст-версия bind работает как положено. По этой причине мы продолжаем использовать улучшенную версию bind в нашем проекте.

Кроме того, если вы заметите на http://blogs.msdn.com/vcblog/archive/2010/04/06/c-0x-core-language-features-in-vc10-the-table.aspx?CommentPosted=true#commentmessage, что VS2010 еще должен внести некоторые изменения, которые будут влиять на лямбда-выражения. Я не смог их сломать, но тогда я не использовал вложенные лямбды и, вероятно, никогда не буду.

Вы также должны иметь в виду, что boost :: shared_ptr и std :: shared_ptr несовместимы. Не удивительно, но вы должны знать это, если собираетесь использовать одно или другое ... Я бы не советовал оба варианта, и мы просто будем придерживаться наддува.

В VS2010 также нет declval. Хотя достаточно легко сделать:

<code>
template < typename T > T&& declval();

Пример использования:

template < typename T >
struct point
{
  T x,y;
};

template < typename T1, typename T2 >
point<decltype(declval<T1>() + declval<T2>())> operator + (point<T1> const& lh, point<T2> const& rh)
{
 ...
}

Вы также заметите, что на странице, на которую я ссылался выше, я уже обсуждал с членами команды разработчиков (или PR-частью или кем-то еще), что в decltype есть ошибка Я упоминаю больше, чем один, поэтому я покажу оба:

template < typename T1, typename T2 >
auto operator + (point<T1> const& lh, point<T2> const& rh)
  -> point<decltype(lh.x + rh.x)>
{
...
}
point<int> x; point<double> y;
point<double> pt = x + y; // fails, operator + returned point<const double>

void f();
auto ptr = &f;

std::cout << typeid( decltype(*ptr) ).name() << std::endl;
std::cout << typeid( decltype(*&f) ).name() << std::endl; // should output the same thing...outputs void (*)()

Также ... согласно некоторым сообщениям электронной почты о decltype и result_of, это должно работать:

std::result_of< decltype(f)() >::type x = f();

С моей домашней версией std :: result_of, которая использует decltype, это будет работать, если выражение decltype (f) () работает правильно. Это не. Выдает некоторую ошибку о функции, возвращающей функцию. Вы должны использовать "decltype (& f) ()", чтобы выражение работало.

Итак, конечно ... мы используем это. Есть некоторые ошибки и дерьмо, хотя. Преимущества перевешивают ожидание ИМХО. Не ожидайте, что ваш код будет стандартным, когда выйдет стандарт, и будущие компиляторы MS могут его нарушить.

Answer 2

Набор функций C ++ 0X к настоящему времени довольно исправлен, поэтому я бы сказал, пойти на это. Окончательный проект предложения должен быть составлен в августе согласно википедии.

Многие вещи доступны в любом случае от Boost (на самом деле, многие вещи от 0X приходят от Boost) - см. Boost TR1 . Вы можете повторно использовать эти функции через boost, даже если компилятор не полностью C ++ 0X.

Answer 3

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

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

Answer 4

Если вы ожидаете, что ваш код останется нетронутым в течение многих лет и хотите, чтобы он выдержал изменения компилятора без вмешательства, я бы предложил вам придерживаться C ++ 98/03.

Однако большая часть кода поддерживается с течением времени, поэтому я не думаю, что это такое важное соображение. Я бы рекомендовал использовать то, что делает ваш код лучше, и планировать некоторую работу при обновлении компиляторов.

Answer 5

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

Answer 6

Полагаю, я спрашиваю, есть ли шанс, что VC ++ 2010 или GCC в конечном итоге превратятся в VC ++ 6; он был выпущен до того, как язык был официально стандартизирован, и, следовательно, позволил скомпилировать чрезвычайно плохо сформированный код.

Это возможно, но очень маловероятно, ИМХО. Не только MS, но и другие поставщики компиляторов уже поддерживают некоторые функции C ++ 0x, и я ожидаю, что Комитет по стандартизации будет крайне осторожен в отношении нарушения совместимости на этом этапе.