В стандартных пока что нет (работы по добавлению ведутся), но в GCC и clang давно уже да.

Нельзя называть уязвимостью то, что не участвует в атаке. Критерий — наличие PoC, если а PoC нет, это слабое место, недостаток (а не «дефект безопасности», чтобы не значил этот странный термин), что угодно, только не уязвимость.
Я понимаю, что вы хотите сказать, и даже понимаю, зачем именно, но называть любую обнаруженную «weakness» словом «vulnerability» — это буллшит чистой воды, потому что это максимум «potential security issue».
Мужики, у вас отличный продукт без дураков, и хорошая рекламная стратегия (была, по крайней мере) со всеми этими статьями, но не скатывайтесь, прошу вас, в рекламу змеинного масла.
PVS-Studio находит не «уязвимости», а «слабые места в коде, которые могут привести (или не привести) к уязвимости». По настоящему с уязвимостями борятся технологии предотвращения эксплуатации вроде VBS, CFG, RAP, и т.п. Вот слайды с недавнего доклада специалистов из Microsoft о них.

Можно и без с++11 решить вполне поставленную задачу про перемену мест слагаемых в дате:

class Date
{
public:
    void set(const Day& d);
    void set(const Month& m);
    void set(const Year& y);
};


template<class D, class M, class Y>
Date createDate(const D& d, const M& m, const Y& y)
{
    Date date;
    date.set(d);
    date.set(m);
    date.set(y);

    return date;
}

//теперь можно вызывать
createDate(Day(3), Year(4), Month(55));
createDate(Year(4), Month(55), Day(3));
createDate(Month(55), Day(3), Year(4));

Да, менять местами параметры такой подход не позволит, но это не так и важно.

Почему же? Добавим немного С++ 11:

struct width {
  explicit width(int val) : v{val} {}
  int v;
};

struct height {
  explicit height(int val) : v{val} {}
  int v;
};

template <typename... T> int getVolume(T... args) {
  auto t = make_tuple(args...);

  int w = get_element_by_type<width>(t).v;
  int h = get_element_by_type<height>(t).v;

  return w * h * h;
}

int _tmain(int argc, _TCHAR *argv[]) {
  cout << getVolume(height(2), width(1)) << endl;
  cout << getVolume(width(1), height(2)) << endl;

  return 0;
}

Функция get_element_by_type возвращает элемент кортежа по его типу. В С++ 14 функция std::get ведёт себя аналогично.

Не пойму смысла идеи, с учетом факта существования китайцев.
Seedstudio, ITEAD Studio, и главное — Dirt Cheap Dirty Boards. И т.д. и т.п. 25$ с доставкой за 10 плат 10х10 может позволить себе любой инди разработчик. Никаких дополнительных пошлин за подготовку и т.д. Маска, шелкография, HASL (лужение). Качество отличное, выложу фотки.
Там смысл этого всего, как раз в панелировании. Из-за стандартных размеров плат их легко комбинировать. Эти компании агрегируют заказы в панели и шлют изготовителям плат.
Единственный способ потягаться с этими компаниями — самому стать агрегатором. Для этого нужно иметь выход на производителей плат.

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

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

Изначально всё пошло от того, что когда появились исключения их начали использовать вместо возвращения ошибок. Основных причин было две: во-первых возврат ошибок в языках где нет удобной поддержи кортежей приводил к необходимости смешивать в возвращаемом значении два типа данных (результат и ошибку) что всегда воспринималось как не элегантный подход от которого с радостью избавились; во-вторых обработка ошибок дело нудное и сложное, а исключения дали возможность с (относительно) чистой совестью избавиться от обработки ошибок здесь и сейчас, и отложить её «на потом».

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

Тут возникает логичный вопрос: а как мы узнаем, критическая это ошибка или нет — ведь всё зависит от требований высокоуровневой задачи. Например, ошибка DNS для задачи выкачки url — критическая или нет? Вроде бы да… но если у нас задача выкачивать url параллельно тысячами в секунду ошибка с одной из url вряд ли действительно является критической. Правильный ответ на этот вопрос — только сама высокоуровневая задача (т.е. ваше основное приложение) знает, что для неё является критической ошибкой, а что нет.

Следствием из этого является то, что любые модули/библиотеки, по определению, не знают, в каком приложении их используют, и какие ошибки являются критическими, а какие нет. Поэтому они не должны выкидывать исключения (на самом деле это не совсем так — если в них возникают ошибки вроде out of memory или segmentation fault и им подобные — это вполне себе типичные исключения, которые можно и нужно выкидывать как исключения, а не возвращать кодами ошибок — но это типичное «исключение из правила, только подтверждающее это правило»). При этом внутри себя библиотеки вполне могут пользоваться исключениями, когда необходима именно раскрутка стека — например, в задачах рекурсивного парсинга — но все свои внутренние исключения эти библиотеки должны сами и перехватывать, а наружу возвращать обычные ошибки.

При таком подходе всё работает совершенно адекватно: все ошибки, которые можно нормально обработать, обрабатываются в том месте, где они возникли (и без излишних простыней try/catch); исключения возникают крайне редко, их очень немного, и большая их часть просто честно убивает приложение (если в приложении и есть глобальный перехват всех исключений, то он используется для попытки вывода сообщения об исключении в лог перед тем как приложение будет аварийно завершено, а не для молчаливого заглушения исключений), а явно обрабатывается очень небольшое количество вполне конкретных исключений, специфичных для вашего приложения (вроде выше упомянутых примеров, когда из-за ошибки парсинга или выкачки url необходимо прервать с раскруткой стека большой блок логики приложения).

Читаю пост и нравится то, что хабр ушел таки с тренда «олололо Билли сволочь. Гроб, гроб, кладбище, windows» на нормальный диалог.

Я честно пытался использовать линукс пол года. Я посмотрел несколько видеокурсов по разным консольным штукам, прочитал тонны форумов и мануалов, и вернулся обратно на винду. Вот мое ужасное мнение поборника опенсорса: я никогда не перейду на систему, где нужно самому править некомпилирующиеся драйвера, пока у меня будет возможность купить за 40$ систему в которой все сразу заработает. И мне глубоко и сильно все равно, чья в этом вина: производителей железа, которые не пишут (или не поддерживают при изменении ядра) дрова под линукс или разработчиков линукс, которые взяли вот так и выкинули какие-то строчки из сорцов, на которых у других код мог быть завязан, и неизвестно сколько еще чего развалилось.

Я просто хочу включить компьютер и делать то что мне нужно. И да, windows 8 охренительна. Если уберут полноэкранный пуск, это, на мой взгляд, будет самой большой ошибкой майкрософта за вообще всю жизнь. Потому что они придумали и не побоялись сделать что-то действительно охренительное. Я бы в данном вопросе прислушался к Генри Форду про быструю лошадь.

Нет, сколько хочу друзей столько и завожу :)

Насчет копирайта вы ошибаетесь, раньше конфликты были даже серьезнее, почитайте как издатели сопротивлялись созданию публичных библиотек. Или вот хотя бы хроника 20 века:

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

В конце двадцатых годов, после массового начала музыкальных радиотрансляций, держатели авторских прав выступили с коллективным иском, требуя возместить их ущерб. Их прибыль упала с $75 млн. в 1929 году до $5 млн. через четыре года. Спад совпал с Великой Депрессией.

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

В сороковых годах киноиндустрия выступала против показа фильмов по телевидению — «Какой идиот будет ходить в кино, если будет возможность посмотреть фильм дома бесплатно?»

В 1972 году ассоциации книжных издательств пыталась запретить производство и продажу ксерокса — «Не за горами тот день, когда никто не станет покупать книги».

В семидесятых годах возмущение музыкальной индустрии вызвало появление кассетных магнитофонов, на которых было легко копировать любую запись — «Кассета убьет музыку!»

В восьмидесятых годах киноиндустрия выступила с коллективным иском к производителю видеомагнитофонов. «Записывающий видеомагнитофон для производителей американских фильмов и американского народа это тоже самое что серийный убийца (в оригинале — Бостонский душитель) для одинокой женщины». Дело против Betamax рассматривалось в Верховном суде и было выиграно с перевесом всего в один голос…

torrentfreak.com/the-copyright-industry-a-century-of-deceit-111127/

Хабр, проснись! Куда Вы катитесь хомячки?! Сайт-то для информатически подкованных людей, а здесь какое-то фуфло на 1-2 дня!?! Что это за «статьи»?
Ну блин, это-же всё желтизна! У меня скоро пена изорта пойдёт. Что вот ЭТО ТАКОЕ: «Голосуйте, пожалуйста, за твиты чтобы отсеивать всю чушь, оставляя только самое вкусное», ОБьЯСНИТЕ, ПОЖАЛУЙСТА?! Вы сами чушь здесь какую-то несёте. Кому вот ЭТО нужно: «Недобежал до туалета #спасибопутинузаэто», скажите пожалуйста? Это разве достойно вашего внимания!? Вы лучше идите решите хоть один пример по математике да поймите его суть. Вы прочитайте лучше ещё раз «Мастер и Маргарита». Хабр, пойми, твой уровень стремительно >>падает<<.