Пример из документации BOOST

@Lopster92 · Регистрация: 25.12.2009

Студворк — интернет-сервис помощи студентам

Доброе утро) Скопировал пример из документации boost, компилирую в среде Visual Studio 2012...

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
int main(int argc, char *argv[]) {
    std::string str1("hello abc-*-ABC-*-aBc goodbye");
 
    typedef std::vector< boost::iterator_range<std::string::iterator> > find_vector_type;
    find_vector_type FindVec; // #1: Search for separators
    ifind_all( FindVec, str1, "abc" ); // FindVec == { [abc],[ABC],[aBc] }
 
    typedef std::vector< std::string > split_vector_type;
    split_vector_type SplitVec; // #2: Search for tokens
    boost::split( SplitVec, str1, boost::is_any_of("-*"), boost::token_compress_on ); // SplitVec == { "hello abc","ABC","aBc goodbye" }
 
    return 0;
}

Ошибка следующая:

C++
1
Ошибка    1   error C4996: 'std::_Copy_impl': Function call with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To disable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators'   c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility 2176    1   clock6

Странно, до этого создал 3 проекта c абсолютно идентичными параметрами и такой ошибки не было, а теперь вдруг выскочила, подскажите что не так?
Добавил атрибут -D_SCL_SECURE_NO_WARNINGS при компиляции и ошибка исчезла, но является ли это решением проблемы, не опасно ли так делать?

@Avazart · 07.05.2013, 18:02

Сообщение от oxotnik

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

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

@ForEveR · 07.05.2013, 18:09

Avazart, Ничего странного. Стандарт языка С++ написан не просто так. Компилятор, который реализует этот стандарт, ОБЯЗАН реализовать его как можно точнее и как можно более полно. Да, никто не запрещает писать свои функции, более безопасные и все дела, да стандартные функции (sprintf и прочие) по большому счету небезопасны, ибо запросто могут вызвать переполнение буфера, НО сыпать на это ворнингами с призывом использовать более безопасные НЕ стандартные (compiler extension) функции - моветон.

@Avazart · 07.05.2013, 18:23

Сообщение от ForEveR

Компилятор, который реализует этот стандарт, ОБЯЗАН реализовать его как можно точнее и как можно более полно.

Да ну ладно, а кто заботится о разработчиках компиляторов ? Вспомним тот-же экспорт шаблона.

Добавлено через 1 минуту

Сообщение от ForEveR

да стандартные функции (sprintf и прочие) по большому счету небезопасны, ибо запросто могут вызвать переполнение буфера, НО сыпать на это ворнингами с призывом использовать более безопасные функции - моветон.

Призывать писать более безопасный код это моветон ?

Опять же если не призывать, то как пользователь узнает что есть более безопасные ф-ции ?
А если не узнает, значит ф-ции писались напрасно

@ForEveR · 07.05.2013, 18:35

Avazart,

Призывать писать более безопасный код это моветон ?

Да, потому что призывают использовать непереносимые нестандартные функции.

Опять же если не призывать, то как пользователь узнает что есть более безопасные ф-ции ?

Бред. Разрабатывающий исключительно под MSVC более чем вероятно знает про эти функции. В конце концов в данном случае, вариант с установкой дефайна/уровня предупреждений был бы профитнее.

Да ну ладно, а кто заботится о разработчиках компиляторов ? Вспомним тот-же экспорт шаблона.

А кто-то должен заботится? Разработчики взялись за разработку компилятора - обязаны соответствовать стандарту. Про экспорт шаблонов - тема заезженная, оказалась эта фича слишком сложной для разработчиков компиляторов, что в итоге дошло до Комитета и в итоге отменили эту фичу.
Те же clang/gcc ведь не предлагают использовать "безопасные" функции, взамен использования стандартных? Думаете у них их нет?

@Avazart · 07.05.2013, 18:50

Сообщение от ForEveR

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

Сообщение от ForEveR

тема заезженная, оказалась эта фича слишком сложной для разработчиков компиляторов, что в итоге дошло до Комитета и в итоге отменили эту фичу

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

Разработчики компилятора исходят из своих интересов, и думаю нормально то что одним из этих интересов является то что бы на их компиляторах ( а в данном случае и на платформе) писались программы с более безопасным кодом.

Сообщение от ForEveR

Бред. Разрабатывающий исключительно под MSVC более чем вероятно знает про эти функции. В конце концов в данном случае, вариант с установкой дефайна/уровня предупреждений был бы профитнее.

С этим согласен, было бы удобнее.

Сообщение от ForEveR

Те же clang/gcc ведь не предлагают использовать "безопасные" функции, взамен использования стандартных? Думаете у них их нет?

Но, то чего не делают другие компиляторы- это не показатель.

@ForEveR · 07.05.2013, 18:58

Avazart,

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

Потому что обычно именно разработчики компиляторов проверяют фичи стандарта, а не комитет.

Разработчики компилятора исходят из своих интересов, и думаю нормально то что одним из этих интересов является то что бы на их компиляторах ( а в данном случае и на платформе) писались программы с более безопасным кодом.

Как уже сказал gray_fox

Сообщение от gray_fox

Не по теме:
Может стоило сразу писать: C++: this programming language may be unsafe. Consider using C++/CLI instead?

Но, то чего не делают другие компиляторы- это не показатель.

Быть может. Однако, если лучшие компиляторы (clang - единственный на данный момент компилятор, реализовавший полностью все фичи из ядра нового стандарта) не делают таких вещей, то почему я должен считать, что MS поступает корректно?

@BRcr · 07.05.2013, 19:41

Тут маленько на небезопасность некоторых стандартных функций грешили... это-таки зря. Можно и ластиком насмерть убиться - что ж он теперь, небезопасный что ли?

Просто об известных уязвимостях следует помнить и защищаться от них, по большей части это нетрудно. И не понадобится никаких непереносимых наворотов.

@diagon · 07.05.2013, 20:04

Сообщение от Avazart

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

Ну, допустим, через несколько лет майкрософт будет на грани банкротства и взвинтит цены на свой софт. Тогда вы сможете просто переехать от них на другой компилятор. Ну или все та же студия легко может отказаться компилировать код без объяснения причин. Даже я пару раз нарвался на такое, хотя написал под студию всего 2 исходника, которые были длиннее 500 строк. Ни один из этих исходников студия не потянула. Тогда я просто перешел на qt creator + gcc.
Наконец, сейчас можно использовать все возможности с++11 на gcc, а затем перейти на clang с более приятной лицензией, когда он обойдет по возможностям gcc.

Сообщение от ForEveR

clang - единственный на данный момент компилятор, реализовавший полностью все фичи из ядра нового стандарта

Хм? Не все же. gcc 4.8.1 и clang 3.3 имеют примерно одинаковый список реализованных фич, но, если вернуться к реальности, то gcc 4.8.0 реализует значительно больше фич, чем clang 3.2. Ну, правда, вроде как гнусная stl проигрывает libc++.

Jupiter · 07.05.2013, 20:12

о чем спор!? установил cmake и прописал гребаный макрос для студии...делов то

@ForEveR · 07.05.2013, 21:13

diagon, http://isocpp.org/blog/2013/04... his-summer

As Clang usually releases twice a year, industry observers expect this means we will see at least one fully C++11-conforming commercial compiler available in the marketplace by this summer.

Ну, правда, вроде как гнусная stl проигрывает libc++.

What? Может libstc++ проигрывает libc++?

@diagon · 07.05.2013, 21:57

Сообщение от ForEveR

we will see

Сообщение от ForEveR

will

Т.е. в clang 3.3 (который пока не релизный). Текущий же клэнг имеет достаточно много нереализованных фич.
В то время как вполне релизный gcc 4.8.0 реализует весь стандарт кроме двух пунктов, один из которых будет реализован в 4.8.1, а второй лично мне нафиг не нужен.

Сообщение от ForEveR

libstdc++

Ну, это и есть гнусная (то бишь от gnu) STL.
И в ней нету, к примеру, регексов. А в STL от clang'a (libc++) они есть.

Новые блоги и статьи Все статьи Все блоги /
интеграция AnyLogic с самописным REST API и переход на Odoo anaschu 03.07.2026 Успешная интеграция AnyLogic с самописным REST API и переход на промышленную Odoo WMS Сегодня проделал огромный путь от простой симуляции физических процессов до построения полноценной. . .	Поиск всех путей на ориентированном графе. Linux dcc0 02.07.2026 Переработка старого кода из моей статьи. Через несколько переработок от PHP кода к C89 (надеюсь, 89). Но довольно запутанно получилось. Код для Linux. Но если убрать time и то, что с ним. . .	Сам себя обучал rest api anaschu 02.07.2026 Педагогический лайфхак: Почему чистый REST API для ученика намного круче, чем готовые библиотеки Когда мы отказались от капризного JAR-файла AnyLogic и переписали код на стандартный HttpClient,. . .	rest api anylogic - выполнение модели на своём русском сайте anaschu 02.07.2026 Как подружиться с AnyLogic Cloud API, победить провайдеров и развернуться Java-бэкенд в Docker на бесплатном хостинге: Двухдневный лог борьбы Всем привет! Хочу поделиться свежим (и довольно. . .
Где деньги лежат kumehtar 02.07.2026 Это - японская подводная лодка I-52 (тип C2, кодовое имя Momi) вышла из Японии в марте 1944 года с миссией в оккупированную немцами Францию (Лорьян). Это была одна из «Янаги»-миссий по обмену. . .	Krabik для WoW 3.3.5a, многоязычный AmbA 02.07.2026 Допилил бота, думаю что окончательно. Изменения: - добавлена многоязычность - добавлено снятие скриншотов - добавлено поддержание бафов хождения по воде (для жреца, дк и шамана) - и так, по. . .	Алиса нашла кучу ошибок компиляции и запуска в проекте, который без проблем компилировался и запускался))) anaschu 30.06.2026 Я пока посмеюся, но завтра проверю. А вообще интерсно. Дал алисе файл, в котором точно нет ошибок компиляции и запуска, и попросил их найти. Нашла кучу))) Критические ошибки, мешающие компиляции и. . .	сукцессия 16. Общий обзор, в основном что бы другие ии поняли anaschu 29.06.2026 # Передаточный документ: модель микоризной сукцессии (для нового чата) Этот документ предназначен для того, чтобы новый чат Claude мог продолжить работу без необходимости заново разбираться в. . .

@ForEveR В астрале 8049 / 4806 / 655 Регистрация: 24.06.2010 Сообщений: 10,562
	07.05.2013, 18:09
	Avazart, Ничего странного. Стандарт языка С++ написан не просто так. Компилятор, который реализует этот стандарт, ОБЯЗАН реализовать его как можно точнее и как можно более полно. Да, никто не запрещает писать свои функции, более безопасные и все дела, да стандартные функции (sprintf и прочие) по большому счету небезопасны, ибо запросто могут вызвать переполнение буфера, НО сыпать на это ворнингами с призывом использовать более безопасные НЕ стандартные (compiler extension) функции - моветон. 0

@BRcr 4043 / 2333 / 292 Регистрация: 03.02.2011 Сообщений: 5,066 Записей в блоге: 10
	07.05.2013, 19:41
	Тут маленько на небезопасность некоторых стандартных функций грешили... это-таки зря. Можно и ластиком насмерть убиться - что ж он теперь, небезопасный что ли? Просто об известных уязвимостях следует помнить и защищаться от них, по большей части это нетрудно. И не понадобится никаких непереносимых наворотов. 0

Jupiter Каратель 6610 / 4029 / 401 Регистрация: 26.03.2010 Сообщений: 9,273 Записей в блоге: 1
	07.05.2013, 20:12
	о чем спор!? установил cmake и прописал гребаный макрос для студии...делов то 1