» Вопросы по программированию на C/С++

Не совсем так. hash_map не попал в стандарт по причине того, что предложение о включении в стандарт хеширующих контейнеров поступило слишком поздно. В это время приём предложений был уже прекращён. Иначе бы стандарт никогда не вышел, наверное.
xdude
Более эффективный путь - это использование устаревшего с точки зрения стандарта istrstring. Но он не такой внятный, как istringstream. Последний использует копию буфера вполне обоснованно. Все классы потоков используют собственный буфер. Кроме istrstring, и то не всегда. В условиях мультитридности это в общем случае единственный способ гарантировать владение собственным буфером.

WiseAlex

Цитата:

и какие здесь заморочки?

Да, действительно, протупил.

Цитата:

The Boost license encourages both commercial and non-commercial use.

Насчет стрингстрима:

Цитата:

можно использовать стандартную библиотеку С - strtok например

На сайте того же boost-а говорится, что strtok является потенциально опасной при использовании в мультипоточном приложении:

Цитата:

Certain C++ Standard Library functions inherited from C are particular problems because they hold internal state between calls: rand strtok asctime ctime gmtime localtime

Блин, а у меня сплошь и рядом в этом приложении встречаются перечисленные функции. Причем предлагается использовать бустовские заменители этих функций, обеспечивающие thread-safety. У них есть random number generator и tokenizer library. А как же быть с gmtime/localtime и иже с ними? И можно ли доверять их генератору случайных чисел? Не будет с ним глюков?

Добавлено:
Qraizer
istrstring действительно устарел, и MSDN, например, не советует его использовать. Наверное попробую-таки tokenizer от буста, хотя раньше вообще даже с функцией strtok не сталкивался.

О, блин, сколько я тут интересного пропустил...
xdude

Цитата:

О, и в чем еще отличие list от vector, и что в каком случае предпочтительней использовать?

Практически, по определению, list - двухсвязный список, vector - обычный (почти) массив - индексированный. Соответственно, прямой доступ к списку имеет порядок n, прямой доступ к вектору - порядок 1. С другой стороны, исключение элемента из списка - порядок 1, из вектора - не уверен, что возможно.
WiseAlex
strtok точно лучше не использовать. У нее один внутренний буфер на все потоки - задолбаешься разруливать его. Правда, если поставить мьютекс, можно и ей работать.
xdude
Про токенайзер - не знаю, не работал, но вот думаю, что можно это сделать в т.ч. и регулярными выражениями из того же буста.

Друзья-программеры, есть ещё один вопрос: что происходит при таком вот раскладе:

Код:
std::string str1;
std::string str2;
...
str2=str1.substr(1,5);

Доброго времени суток.

Извеняюсь за долгое отсутсвие и сразу перехожу к делу.

TeXpert
Увы, у меня просто нет возможности продолжить дискусию на даную тему. (Думаю не стоит писать о чём я?).

Вопросы:
1. В первые месяцы после начала изучения С++, передомной вставала проблема: в какие ковычки предворять имена заглавочных файлов. Сообственно эту проблему я решил методом научного тыка, просто пробуя всё подряд. Теперь думаю к проблеме надо вернуться. Ведь надо же понять что есть что! И так сам вопрос для чего используют обычные ковычки (" ") и для чего нужны необычные ковычки (< >)?
2. Можно начать с отступления? Есть у моего провайдера локалка, порядком заляпаная некими кулхацкерами (Я не ошибся с выроженим?). Так вот, появилось у меня желание поговорить с этими самыми персонами, что называеться с глазу на глаз. То есть просканит он мои порты, к примеру, а я ему качаю свой *.txt (15 штук на рабочий стол, чтоб не проворонил) где пишу что "побаловался и хватит", и ссылку на двух битовый номер в троичной системе счисления. Ну а теперь вопрос! Что мне нужно для реализации этого примера? Точнее, что мне надо изучить, какая литература, справочники могут потребоваться?

xdude
Он устарел в том смысле, что является менее удобным и безопасным. Все "форматирующие в памяти" потоки были перенесены с char[] на std::basic_string<>-и и получились std:: (i/o)stringstream<>-ы, которые и рекомендуются к использованию. Так как интерфейс этих новых классов претерпел немного более существенные изменения, чем другие классы потоков (которые сохранили совместимость со старым кодом, благодаря соответствующим typedef-ам), то их и переименовали. Однако старые классы оставили (и не рекомендуют ими пользоваться) для совместимости. Я не думаю, что эти классы когда-нибудь уберут. Слишком уж много кода написано с их использованием.
Тем не менее, они безусловно правы, когда не советуют ими пользоваться, ибо помимо производительности и совместимости имеются и другие критерии выбора. И мне кажется, что новые возможности, включая поддержку локалей и автоматическое слежение за своим стораджем, гораздо чаще являются более сильным аргументом. И только при действительной необходимости имеет смысл использовать старые классы.
Насчёт "нерекомендованных" функций - так эта проблема решена в мультитридных библиотеках. Т.е. если ты используешь такие библиотеки - эти функции имеют по отдельному буферу на каждую нитку. Во всяком случае, так поступают MS и Borland, если новые нитки создаются не API-функцией CreateThread(), а библиотечной же какой-нибудь _beginthread().
Ты прав в своих опасениях насчёт substr(). Ты получишь именно то, что просишь. Слышал афоризм "компьютер делает не то, что вы хотите, а то, что вы сказали ему сделать"? Попробуй рассмотреть варианты
Код: std::string str2(str1, 1, 5);
/* ... */
str2.assign(str1, 1, 5);

FMeat
По поводу первого вопроса.
В угловых скобках в #include пишутся имена заголовочных файлов, которые компилятор должен искать в месте своей установки, то есть т.н. "системные заголовочные файлы". При поиске такого файла компилятор не смотрит в текущий каталог.
В кавычках пишутся имена заголовочных файлов пользователя. При поиске этих файлов компилятор в первую очередь смотрит в текущий каталог, а затем - в системный.
Вот и все отличие.
По второму вопросу.
А оно тебе надо? Если они "реальные кулхацкеры", они начнут свои гадости с удвоенной силой. Тут проще решить орг. мерами. Поймал такого на чем-нибудь - или штраф выставляй или вообще нафиг отключай. А за вдувание на рабочий стол чего-то там они могут тебе еще счет выставить. Или просто firewall поставить.

Qraizer
В основном - полностью согласен, есть одно маленькое но... Сколько ты мультитридные библиотеки не используй, strtok не исправишь . Там просто это по определению невозможно (если разработчики не используют, конечно, TLS). Есть функции, которые безопасно работают в multithread окружении при использовании соотв. библиотек, а есть - небезопасные. Хотя, наверно, это сильно зависит от разработчика компилятора и библиотек.

Ну и вопрос, напоследок. Где-то краем глаза читал или краем уха слышал, что std::string реализует отложенное копирование. Это так? Кто может подсказать?

Mickey_from_nsk

Цитата:

Где-то краем глаза читал или краем уха слышал, что std::string реализует отложенное копирование. Это так? Кто может подсказать?

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

Qraizer

Цитата:

Не всё в этом мире делается через оператор присваивания, и далеко не всегда нужны подстроки.

Спасибо, именно это я и хотел узнать

Еще вопросик:
stringstream - это что, в STL единственный метод конвертировать строки в числа и обратно? Если да, то как можно заставить istringstream не копировать уже существующую строку в свой буфер, а использовать ее (или ее часть) в качестве оного? Иначе проделывается куча работы по выделению/освобождению памяти, если мне надо часто конвертирвать строки в числа.
И еще я прочитал, что конвертирование чисел в строки и наоборот с помощью stringstream гораздо медленнее, чем с помощью atoi, atof, itoa и т.д. Так почему бы не использовать их? Только потому что это функции С, и стандарты не позволяют их использовать?

xdude
если нужна очень высокая скорость лучше вообще ничего стандартного для преобразований не использовать - посмотри на rsdn - там пробегала функция быстрого преобразования. можешь и сам написать, но я бы сначала сделал по-простому ч/з stl или c-stdlib и после профилирования уже думал что делать дальше

И еще один вопрос:

Код:

const std::string &somefunc()
{
...
return somestring;
};

...

std::string str;
...
str=somefunc();

Mickey_from_nsk
Мне оно действительно надо и вот почему:
"Реальные кулхацкеры" - наверное я перепутал данное вырожение, но я имел в виду что - это озабоченные малолетки, накачавшие себе "хакерских" утил, долбящиеся куда нипоподя с дурацкими приколами, вроде удаления ntldr, отключения windowsInstaler, закачивания за твой счёт чего либо с интернета и самого пожалуй изощрённого - прописать строку в boot.ini, точнее в строке названия операционной системы, что мол "У вас установленна нелецензионная копия Windows! Некоторые возможности будут недоступны! ".
Рабочий стол - после целого дня трещания телефона, с вопросами "Ой! А у меня деньги со счёта пропали! Что делать?" или "А у меня что то пираты с Windows'ом сделали!" просто на стену лезеш... Так что руки ой как чешуться чтобы надрать точку схождения двух прямых!
Вы можете посоветовать как их подловить?

Спасибо.

FMeat
Реально легче накачать таких же хакерских утилит, и всех этих кулхацкеров - ими же да по тому же месту. А для того чтобы что-то толковое самому написать - уйдет уйма времени на изучение всех тонкостей системного и сетевого программирования. А лучше всем юзерам в сети рекомендовать пользоваться файрволами, но это уже другой топик.

Код: const std::string &somefunc()
{
...
return somestring;
};

...

std::string str;
...
str=somefunc();

Mickey_from_nsk
Цитата:

Там просто это по определению невозможно (если разработчики не используют, конечно, TLS).

Именно TLS для этого и используется. Посмотри исходники rtl-я.
Отложенное копирование - это когда при создании копии строки на самом деле сохраняется только ссылка на оригинал, а разделение происходит только при необходимости, например, при модификации? Когда-то это считалось круто. На самом деле это только добавляет головной боли разработчикам и весьма не сильно влияет на производительность. Достаточно посмотреть такой пример
Код: std::string str1("some string"), str2(str1);

char &ch=str2[3];
ch='E';

Labutin

Цитата:

Это страшная вещь! Лучше так вообще не пытаться. На что будет возвращаться ссылка? somestring где объявлена?

На самом деле все не так уж страшно Возвращается ссылка на приватную мемберскую переменную класса, так что она не уничтожится до конца жизни экземпляра класса.

Qraizer

Цитата:

Ну так и объяви её ссылкой: std::string& str;

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

Цитата:

Строки можно подменять методом std::basic_stringbuf<>::str()

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

Цитата:

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

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

xdude

Цитата:

На самом деле все не так уж страшно Возвращается ссылка на приватную мемберскую переменную класса, так что она не уничтожится до конца жизни экземпляра класса.

Ну тогда да - проблем не будет. Просто из заголовка функции нельзя было понять, что это метод класса. Я предположил, что это обычная функция.

xdude
Цитата:

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

Значит совет был лишний. Я имел в виду, что можно сэкономить на создании/уничтодении самого stringstream-f и его буфера. Объясни только, зачем читать из потока (файла) в строку, затем передавать её копию другому потоку (памяти), и только оттуда уже парсить? А сразу парсить файл не вариант? Вообще-то stringstream-ы предназначены для форматирования именно в памяти.
Мне в общем-то тоже не совсем понятно, почему в STL не предусмотрели возможность просто указать строку-буфер. Может имеет смысл сделать производный от std::basic_stringbuf<> класс, т.е. создать свой класс буфера? И в нём позволить работать с буфером совместно с другим кодом программы.
Цитата:

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

Ой ли? Вот это ты зря. Не пробовал пользоваться
Код: std::locale locRus("RUS");
someStream.imbue(locRus);

Цитата:

Объясни только, зачем читать из потока (файла) в строку, затем передавать её копию другому потоку (памяти), и только оттуда уже парсить?

Ну, например, если я читаю не из обычного файла, а из сокета. Более того: данные могут быть зашифрованы (OpenSSL), т.е. их еще нужно пропустить через библиотеку OpenSSL. Можно, конечно, написать свой класс потока (или буфера, незнаю точно) для чтения из сокетов, и как вариант - из зашифрованных сокетов, но это долгий путь. Мне это нужно было всего-то для одной маленькой части одного большого проекта. Вот я и использовал std:string как накопительный буфер для получаемых данных, которые получались кусочками по 512 байт (специфика протокола), и все эти кусочки склеивал в std::string, а потом эту строку передавал в istringstream::str() и оттуда парсил. В общем, создавалась куча временных объектов, с множеством копирований/дублирований одних и тех же кусков одной и той же строки, и всего этого можно было избежать, если б время не поджимало. И вот теперь время не очень поджимает, и хочется разобраться. Но ситуация немного другая: есть входной буфер данных, я его пока что держу в std::string. Для парсинга юзаю string::find_first_of, string::find_last_of, string::find_first_not_of, string::find_last_not_of. Так вот, у меня теперь такой вопрос: допустим, я нашёл какой-то кусок строки (скажем, начиная с 3-го и заканчивая 8-м символом строки), который мне нужно теперь преобразовать в число. Как это можно сделать наиболее оптимальным образом? Или, например, мне нужно передать этот кусок в функцию, которая потом скопирует его в std::string. Как это сделать без испотльзования лишних объектов/копирований? Можно ли использовать 2 итератора (на начало и конец отрезка), передать их в функцию, которая потом уже с их помощью инициализирует std::string? Или лучше/оптимальней передать этой функции найденные числовые индексы начала и конца строки, и ссылку на строку-буфер?


Цитата:

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

Вот эту табличку я сегодня нарыл в инете, поэтому и поднял вопрос:
http://www.codeproject.com/string/string_conversions.asp


Цитата:

Не пробовал пользоваться
Код:std::locale locRus("RUS");
someStream.imbue(locRus);
?

Дык в том-то и дело, что мне не нужна работа с локалями. Я работаю в основном с сетевыми протоколами, а там везде локаль один стандартный юзается - С (или POSIX). Т.е., мне не нужно число 12345678 представлять в форме 12 345 678 или 12,345,678, и наоборот тоже.

FMeat
Думаю, в этом случае надо решать вопрос организационно. Чтобы определить кто это, когда и как делает - надо знать топологию сети. Если у вас один backbone, можно поставить на него свою машину-ловушку. Далее - по IP выяснить, кто в сети урод и принять меры вплоть до показательного перекусывания его кабеля (не обязательно сетевого ).
Отвечать уродством на уродство - это еще большее уродство. Просто таким придуркам надо сразу дать понять, что возмездие неотвратимо - сразу успокоятся.
Ну и намекнуть им, что то что они делают - реальное уродство, а пользоваться вороваными кулхацкерскими прогами - реальная возможность нарваться на ОБЭП
В общем, главное найти уродов. Если напишешь как устроена сеть - попробуем помочь с комплексом оперативно-розыскных мероприятий. Правда, боюсь, что тема offtopic.
Qraizer
Именно TLS для этого и используется. Посмотри исходники rtl-я.
Хм... Возможно. Но все равно, прелести strtok одной многозадачностью не ограничиваются. Полное отсутствие реентерабельности не позволяет организовать отдельно парсинг подстрок. В общем - хреноватая функция. Мой выбор - regex.

Добавлено:
Qraizer
Ну и еще - в догонку. Случаем string::operator [] не const ли char возвращает?

xdude

Цитата:

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

Не долгий. Если возьмёшь базовым классом уже готовой std::basic_stringbuf<>, и добавишь в него функциональность, которую ты и так должен будешь написать, то время не изменится. И новый "форматирующий" класс писать не надо. Простой std::basic_istream<> тебе вполне подойдёт.
Табличку не смотри - так, как это там сделано, можно и самому результаты получить, поэтому на серьёзное исследование это статья не похожа. Ещё раз глянь мою ссылку и попробуй найти хоть одно существенное отличие.
Цитата:

...допустим, я нашёл какой-то кусок строки (скажем, начиная с 3-го и заканчивая 8-м символом строки), который мне нужно теперь преобразовать в число. Как это можно сделать наиболее оптимальным образом?

Наиболее оптимальный - прямое использование std::num_get<>::get, как это сделано в коде по ссылке из предыдущего поста. Тебе понадобятся итераторы. Аналогично итераторы же (или пару индекс/размер) выгоднее передавать в функцию, т.к. инициализация почти всегда эффективнее, чем переинициализация.
Mickey_from_nsk
Насчёт "других" недостатков strok я и не говорил. Я утверждал только наличие многопоточной безопасности. Причём для всех "неудобных" с этой точки зрения функций.
Цитата:

Ну и еще - в догонку. Случаем string::operator [] не const ли char возвращает?

Их два:
Код: const_reference operator[](size_type _Off) const;
reference operator[](size_type _Off);

xdude
Ну такой способ я сам назыаю юзерством. По мойму не стоит делать того что сам не понимаеш. То есть качать неизвестно что, затем что б сделать нипойми чё. Раз оффтоп, обсуждать не будем, просто хочу заметить что юзеры, на то и юзеры, что файрвол им, как однокнопочная мыш...
Mickey_from_nsk
Спасибо за предложение, но думаю что я если мне не понятен смысл слова "backbone" то остальное будет мне тёмным лесом. Кстати, я не админ, просто его хороший друг, который не редко заходит на кружку чая.

Чтоб мой пост не был полным оффтопом, всй же порошу вас, посоветовать мне какой либо ресурс, посвещённый данной проблеме, естественно применительно к C++.

Цитата:

Отвечать уродством на уродство - это еще большее уродство.

Цитата:

Ну такой способ я сам назыаю юзерством.

Блин, я не имел в виду заниматься тем же, чем и они. Я имел в виду накачать таких же уже готовых хакерских/крякерских утилит (а не писать их самому), чтобы отследить, кто этим уродством страдает. Изначально задача как была поставлена?

Цитата:

просканит он мои порты, к примеру, а я ему качаю свой *.txt (15 штук на рабочий стол, чтоб не проворонил) где пишу что "побаловался и хватит", и ссылку на двух битовый номер в троичной системе счисления.

Добавлено:
Qraizer

Цитата:

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

Дык я так и не понял, что все-таки выгоднее (или удобнее) передавать: итераторы или начальный/конечный индекс (или индекс/размер) + ссылку на строку? Или это уже без разницы?

Цитата:

std::num_get<>::get

Разбираюсь потихоньку

Без разницы. Стандартом гарантируется, что операции копирования над итераторами являются дешёвыми. Подтверждение тому - практически везде по STLю они передаются по значению. Разыменование их - аналогично.

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

Код:
config.Load("config.ini");
task=task_manager.LoadTask(config);
task->perform;

xdude

Цитата:

И вообще, кто-нибудь может мне порекомендовать какие-нибудь источники, в которых можно почитать о стилях оформления исходного кода?

Керниган и Пайк, Практика программирования.

А вот я предпочитаю такой стиль:

Код:
int some_func1(){
...
if (some_func2() == err){
...
return err1;
};
...
if (some_func3() == err){
...
return err2;
};
...
if (some_func4() == err){
...
return err3;
};
...
return ok;
};

TeXpert

Цитата:

Керниган и Пайк, Практика программирования

Спасибо, надо будет поискать.


Цитата:

А вот я предпочитаю такой стиль...

А вот такой ещё вопросик тогда При программировании WinAPI/COM/OLE сталкивался. В функции последовательно инициализируются какие-то OLE-объекты (причем, это не С++, а С. т.е., классов нет, возвращаются указатели на структуры), для этого нужно вызвать около 10 функций, и если какая-то из них что-то инициализировать не смогла, то все инициализированные перед этим указатели нужно освободить и вернуть из функции код ошибки. Это как оптимальнее всего сделать? Я использовал сначала типа такой конструкции:

Код:
void* somefunc()
{
int err;
void *obj1=NULL,*obj2=NULL,...,*objN=NULL;
...
obj1=APIfunc1(...);
if (!obj1)
{
return NULL;
};
...
obj2=APIfunc2(...);
if (!obj2)
{
free(obj1);
return NULL;
};
...
objN=APIfuncN(...);
if (!objN)
{
free(objN-1);
...
free(obj2);
free(obj1);
return NULL;
};

return SOMETHING;
};

xdude

Цитата:

free(obj1);

А где malloc?

Сам по себе goto неплох, но вот

Цитата:

Но получилось гораздо более компактно

у тебя там ошибка -- ты рискуешь освобождать нулевые указатели. А насчёт другого способа надо подумать.
Можно так: указатели obj1, obj2,..., objN заносишь в массив, а с массивом всё компактней в цикле.

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

TeXpert

Цитата:

у тебя там ошибка -- ты рискуешь освобождать нулевые указатели.

Да, протупил, торопился - забыл if-ы повставлять. Исправил исходный пост, на самом деле оно вот так выглядит.

Цитата:

Я думаю, читать из бефера можно,

Я тоже так думаю, но хотелось бы убедиться наверняка.

Цитата:

В противном случае катастрофы вряд ли произойдёт

А это точно? Система не завершит работу программы? Или могут быть и такие системы, которые при этом тупо убьют процесс?

xdude

Цитата:

Можно так: указатели obj1, obj2,..., objN заносишь в массив, а с массивом всё компактней в цикле

Цитата:

А это точно? Система не завершит работу программы? Или могут быть и такие системы, которые при этом тупо убьют процесс?

Вот не могу знать это для всех систем).