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

Mickey_from_nsk

Толком объяснить вряд ли смогу, но возможно, что это связано с разными реализациями косвенной адресации. Если как в примере с массивом который создается в стеке, то ничего кроме SP::BP+off компилятор сотворить не сможет, а реализации map<> могут работать и через MMX расширения.

Vladimir_Pashutin

Цитата:

а реализации map<> могут работать и через MMX расширения

даже если и так, не думаю, что это поможет - с map действий всегда больше - поиск по ключу и извлечение второй части из pair. Плюс для создания и удаления map тратится больше времени, даже с умными аллокаторами из boost или StlPort

WiseAlex
Согласен конечно, что действий больше, но на некоторых реальных задачах map<> у меня работал быстрее чем массивы в стеке. Конечно руку на рельс не положу, что это достоверный факт, мож там было что-то кроме этого, но как говорится ложку-то мы нашли, но осадок остался.

Vladimir_Pashutin

Цитата:

но на некоторых реальных задачах map<> у меня работал быстрее чем массивы в стеке.

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

WiseAlex
Серьёзных исследований по этому вопросу не проводил - говорю же чисто внешнее ощущение, хотя когда не сильно жмёт я привык доверять таким ощущениям и довольно редко в последнее время налетаю на грабли. Использовал последнее время только шестую стройку, до этого были опятьже Borland-ские 3.1 и 4.5 си-шные компиляторы. Вообще профилирование я делал только раз в жизни, когда надо было прорисовывать в реальном времени имитацию движения автомобиля ещё на AT-шках. В результате выявилось, что оптимизацией отдельных частей алгоритма, как-то разных аллокаторов, страничных ухищрений и тому подобными фокусами ускорить работу можно от силы на 20-30%, а требовалось в разы. Тогда я убил на это профилирование больше месяца практически без толку. Так что теперь доверяюсь ощущениям.
Извиняюсь, но больше на эту тему распространяться не охота.

а что, STL бывает нескольких видов? и что такое STLPort - проведите ликбез пожалуйста..

Collapse Troll

Портированная под несколько компиляторов (кросс-компилерная)
реализация STL от SGI
Активно развивается.
__http://www.stlport.org/

RedLord, спасибо! иногда встречал в лбъявлениях "знание STLPort", вот и заинтересовался. то есть по сути это просто STL Степанова?

Collapse Troll

SGI STL естественно является наследницей либы Степанова.
но в ней реализованы более широкие возможности (не включенные в стандарт),
на что есть сноски в доке.

"Стандартная" STL изменяется. сейчас уже есть промышленные реализации TR1 (недавние расширения стандарта STL)
Думаю изменяется и STLPort

RedLord, спасибо за пояснения!

STL Степанова ?! Так что же, стандартную STL, получается, сделал "простой советский паренек"?!

SaDFromSpb
Ну этот простой паренек уже давно работает не "в союзе" но к С++ это мало относится.
По поводу map vs array по собственному опыту могу сказать, что как ни крути, какие MMX не используй, быстрее косвенной только прямая адресация. Правда, помнится, была загадочная для меня команда ассемблера XLAT, но не думаю, что она работает быстрее косвенной адресации.
Остаются вопросы только в том, что у некоторых "продвинутых" программистов могут возникать заморочки с вычислением индексов массивов. То есть, время, требуемое для вычисления индекса может вполне быть сравнимым со временем прохода по дереву в map (а оно, кажись, на балансированных деревьях сделано). Отсюда и может возникать это "ощущение" той же скорости.
Прошу не воспринимать этот пост ни в чей адрес. Написано про абстрактных программистов, в т.ч. и про себя. Просто, проверьте выражение в квадратных скобках

Intel оставила XLAT в системе команд 8086 для совместимости с 8085. Как и LAHF/SAHF.

Подскажите что можно использовать для так называемого словаря. Есть масив структур пара: слово перевод ... необходимо получать быстрый перевод того или иного слова, что то типа функции translate("horse") которая вернёт на русском "лошадь". Естестевнно набор данных для словаря будет подготовлен заранее. Наверняка это уже кто реализовывал ?

ivanmara
А чем map<string> не устраивает?

ivanmara
В дополнение к Vladimir_Pashutin
Надо только еще реализовать case insensitive поиск по строке.

Подход через map очень удобен в случае, если нужно однозначное отображение "английское слово"->"русское слово". Если у исходного слова возможны различные формы все существенно усложняется. Тогда надо реализовывать анализатор, который бы приводил слова к каноническому виду.

Mickey_from_nsk
Изначально вопрос был задан об однозначном переводе: "что то типа функции translate("horse") которая вернёт на русском "лошадь""
Но в принципе, так как слово может иметь несколько переводов, можно сделать что-то типа map<string,vector<string>>, тогда возвращаться будет список возможных переводов заданного слова. А case-insensitive-поиск с мапой вообще не проблема, получится что-то в этом роде:

Код:
struct compare_t
{
bool operator()(const string s1, const string s2) const
{
return strcasecmp(s1.c_str(), s2.c_str());
}
};

map <string,vector<string>,compare_t> vocabulary;

Как проверить выделена ли память для указателя на класс ?
Данный вариант не проходит.

Код:
SomeClass * sc;
if (!sc)
sc = new SomeClass();

Jim_Web
Дык инициализировать его надо сначала в NULL:

Код:
SomeClass * sc=NULL;
if (!sc)
sc = new SomeClass();

Цитата:

Дык инициализировать его надо сначала в NULL:

А без инициализации никак нельзя?

SPlyer
Нет, иначе указатель будет ненулевой (т.е. !sc будет true), но указывать будет х.з. куда, на случайный участок памяти.

Кстати, вместо NULL лучше использовать просто 0.

Не факт. Некоторые компиляторы этого просто могут не понять, и будут ругаться на несоответствие типов. Хотя, я чаще использую именно 0, так как не включаю стантартные .h, где описывается NULL.

Цитата:

Не факт. Некоторые компиляторы этого просто могут не понять, и будут ругаться на несоответствие типов. Хотя, я чаще использую именно 0, так как не включаю стантартные .h, где описывается NULL.

Это только в старых C компиляторах, в С++ лучше пользоваться 0 и проблем с этим не возникнет.

SPlyer
А чем именно лучше? Меня всегда этот вопрос мучал: что лучше, 0 или NULL

Например в некоторых случаях, когда требуется константа при использовании NULL могут возникнуть проблемы, так как в C++ более строгая типизация чем в C. Использование 0 вместо NULL в C++ это как "внегласное соглашение", но разницы в использовании NULL или 0 с указателями никакой нет.
В C NULL определен как ((void*)0), т.к его подразумевалось использовать только с указателями, поэтому эсли NULL в C использовать например с int'ом компилятор будет ругаться.

SPlyer

Цитата:

Кстати, вместо NULL лучше использовать просто 0.

А чем лучше? В смысле типизации, что ли? То есть мы, засандаливая в указатель целое число говорим, что лучше типизируем? Не, понятно, что компилятор разрулит это, но зачем оно надо? Если NULL это уже указатель?
С моей т.з., использование NULL показывает явно, что дело мы имеем с указателем.

Цитата:

А без инициализации никак нельзя?

Лучше привыкать сразу все переменные инициализировать, хотя бы NULL-значением. Проще будет в отладке - assert можно будет выставлять и т.д.

Существует ли чисто плюсовой аналог микрософтовской конструкции __try - __finally?
Или как проще записать на чистом C++ нижеследующее:
Код: занять ресурс;
__try{
..
if (...) return;
..
throw ...
...
if (...) return;
..}
__finally{
освободить ресурс;
}

FireZone
Можно использовать "умные указатели"...

FireZone
выделение ресурса есть инициализация (Б.Страуструп)


struct RcHelper
{
RcHelper()
{
// выделить ресурс
}

~RcHelper()
{
// освободить ресурс
}
}

работа с ресурсом:

{
RcHelper save_state; // захватываем ресурс
....
if (...) return;
..
throw ...
...
if (...) return;


}// здесь отработает деструктор и освободит ресурс

естественно это только пример. RcHelper - только пример.
вместо него можно юзать boost::shared_ptr или подобных

основное - идея, что выделение ресурса есть инициализация.