Пример из документации 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++) они есть.

Новые блоги и статьи Все статьи Все блоги /
Первый деплой lagorue 16.01.2026 Не спеша развернул своё 1ое приложение в kubernetes. А дальше мне интересно создать 1фронтэнд приложения и 2 бэкэнд приложения развернуть 2 деплоя в кубере получится 2 сервиса и что-бы они. . .	Расчёт переходных процессов в цепи постоянного тока igorrr37 16.01.2026 / * Дана цепь постоянного тока с R, L, C, k(ключ), U, E, J. Программа составляет систему уравнений по 1 и 2 законам Кирхгофа, решает её и находит токи на L и напряжения на C в установ. режимах до и. . .	Восстановить юзерскрипты Greasemonkey из бэкапа браузера damix 15.01.2026 Если восстановить из бэкапа профиль Firefox после переустановки винды, то список юзерскриптов в Greasemonkey будет пустым. Но восстановить их можно так. Для этого понадобится консольная утилита. . .	Изучаю kubernetes lagorue 13.01.2026 А пригодятся-ли мне знания kubernetes в России?
Сукцессия микоризы: основная теория в виде двух уравнений. anaschu 11.01.2026 https:/ / rutube. ru/ video/ 7a537f578d808e67a3c6fd818a44a5c4/	WordPad для Windows 11 Jel 10.01.2026 WordPad для Windows 11 — это приложение, которое восстанавливает классический текстовый редактор WordPad в операционной системе Windows 11. После того как Microsoft исключила WordPad из. . .	Classic Notepad for Windows 11 Jel 10.01.2026 Old Classic Notepad for Windows 11 Приложение для Windows 11, позволяющее пользователям вернуть классическую версию текстового редактора «Блокнот» из Windows 10. Программа предоставляет более. . .	Почему дизайн решает? Neotwalker 09.01.2026 В современном мире, где конкуренция за внимание потребителя достигла пика, дизайн становится мощным инструментом для успеха бренда. Это не просто красивый внешний вид продукта или сайта — это. . .

@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