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

Новые блоги и статьи Все статьи Все блоги /
Беседа с ИИ о программистах, недопускающих к созданию и правке кода генеративные ИИ и причины этого zorxor 21.09.2026 Раньше я радовался или получал некоторые эмоции, пусть небольшие, но всё же, от самого процесса написания кода, рекомпиляции и запуска, видя постепенное развитие программы и прочее. А теперь лень. . .	Мобильное приложение ColorStep pavlinmavlin 17.09.2026 Реализовал приложение Красный, Зеленый, Синий в Unity3d + c#. Название изменил на ColorStep. Приложение прошло модерацию и теперь доступно для скачивания. Делал его сам, шаг за шагом — и вот,. . .	Запрет дублирования строк в табличной части Maks 13.09.2026 Реализация из решения ниже выполнена на нетиповом справочнике "Нормы ТО" с табличной часть "Виды ТО", разработанного в КА2, со следующими реквизитами: - ВидТО (СправочникСсылка. ВидыТО); - ВидГСМ. . .	Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Jin X 06.09.2026 Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Работая с форумом и нейросетями в браузере часто хочется что-то подкорректировать или добавить какого-то функционала. Ниже прикреплён. . .
Программа опроса у.з. расходомера SLS-720F Argus19 02.09.2026 Программа опроса у. з. расходомера SLS-720F Программа опрашивает один раз в минуту три ультразвуковых расходомера SLS-720F через интерфейс RS-485 по протоколу Modbus RTU. Опрашиваются регистры. . .	Hyper-V: Компьютер должен поддерживать доверенный платформенный модуль 2.0. Maks 31.08.2026 При установке Windows 11 на виртуальную машину Hyper-V 2-го поколения вылезла такая ошибка: Решение: в параметрах виртуальной машины, в разделе "Безопасность" (Security) активировать флаг. . .	Архитектура биовида Стива в Майнкрафте: Зачем бонобо кубический каннибализм anaschu 30.08.2026 Кубический Вагинокапитализм в Minecraft: Математический инвариант ОДУ и рок Стивов-бонобо Главная задача разработанной «Модели Всего» — наглядно продемонстрировать наличие системной «судьбы». . .	Оттачиваю умение писать js программы. russiannick 30.08.2026 Проектом выходного дня стало написание Книги шифров Виженера. Итогом стала версия 200, синий туман. Синий туман назван так, потому что замораживает текст под собой. Нажатие синих кнопок управляют. . .

@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