Category: it

Tsukasa

multi-core programming в линуксе?

Хочу попробовать написать мульти-ядерную програмку (Федора линукс). Нужно очень мало: чтобы каждое ядро просто обсчитывало одну и ту же процедуру с разными параметрами и в виде какого-нибудь message передавало результат управляющему треду и получало новое задание. Внутри себя задачи будут полностью автономны, т.е. вещи типа mutexов будут неактуальны. Просто надо посчитать кучу одинаковых процедур.

Познания в параллельном программировании у меня теоретические. Какие тулкиты сейчас следует использовать? Желательны ссылки с примерами для быстрого старта.
Vasiliy Deynega, Василий Дейнега

о методах оптимизации и работы с памятью в C++

Хочу поделиться своим опытом по программированию и работе с памятью. Уже давно пришел к выводу, что для того, чтобы написать эффективный код (который будет быстро работать) нужно учитывать в первую очередь размещение объектов в памяти. Особенно это проявляется в методе программирования Data oriented designЭто метод, при котором в первую очередь проектирование новой системы начинают с решения, как будут в памяти размещаться ее элементы.

Современные CPU работают очень быстро и эффективность алгоритмов в значительной мере зависит не от самого алгоритма, а от того, как эти алгоритмы работают с памятью (тут речь идет не про фундаментальные алгоритмы сортировки, поиска и т.п. а прикладные алгоритмы реальных программ).
Вот базовые рекомендации при проектировании системы и написании кода, которые я выработал для себя:
1. Минимизируйте количество выделений памяти
2. Используйте хранилища данных
3. Храните одинаковые данные вместе
4. Работайте не с объектами а с коллекциями объектов
5. Поблочное выделение памяти
6. Учитывайте выравнивание
7. Знайте размер типов
Все это, с примерами, и деталями реализации и объяснениями и описал в своей статье: http://itw66.ru/blog/c_plus_plus/491.html

Помогите слинковать бустовую либу

Пытаюсь собрать потокобезопасный json_spirit под виндой (mingw).

Компилю boost thread:
b2 toolset=gcc threading=multi link=shared

Либе json_spirit, если она собирается потокобезопасно, нужен boost_thread. Я добавил его в линковку, но на этапе линковки вываливается такая ошибка:
<много символов>: undefined reference to `_imp___ZN5boost6detail12set_tss_dataEPKvNS_10shared_ptrINS0_20tss_cleanup_functionEEEPvb'

Причем, если открыть бустовую .dll в текстовом редакторе, то можно найти, что строка _imp___ZN5boost6detail12set_tss_dataEPKvNS_10shared_ptrINS0_20tss_cleanup_functionEEEPvb там есть (правда, начинается с двух подчеркиваний). dependency walker показывает эту функцию в либе без префикса _imp___

линкую так:
g++ -shared -Wl,--out-implib,libjjson_spirit.a -o json_spirit.dll -L "D:\qtcreatorApps\boost\boost_1_48_0\stage\lib" -lboost_thread-mgw44-mt-1_48.dll json_spirit_reader.o json_spirit_writer.o json_spirit_value.o

полный вывод ошибки занимает >100кб, суть ошибок сводится к тому, что не получается найти функции, которые в dll явно есть. Что я делаю не так? Второй день бьюсь без результата. Перепробовал методом тыка кучу вариантов. Статически собрать получается, но статическая либа не хочет линковаться с проектом по аналогичной причине - не находит функции с именем _imp___многабукв
small

Совет почтенной публики.

Уважаемые участники сообщества, прошу вашего совета.

Два года назад я ушел из фирмы А в фирму Б. Меня сейчас приглашают вернуться назад в фирму А. На приблизительно такую же зарплату, как и то, что я в Б получаю. Мне сейчас сложно выбрать, как правильно поступить.

Collapse )
Будет кросс-пост в ru_programming, как только получу членство в нем.

anubis

Segmentation fault не по делу

Многократно ранее компиленный код на С дает ошибку на пустом месте при попытке компиляции на новой системе. В чем может быть дело?

Есть процедура:
void strjoin(int numparts,char *dest, ...) {
strcpy(dest,"111");
(...)
}

и последняя строчка вызывает SEGV (gdb говорит #0 0x0000003424278810 in strcpy () from /lib64/libc.so.6). Вызывается это всё c dest типа сhar[255]. Ранее всё работало, тут попробовал на новой системе (64-бит) -- не хочет.

Linux 2.6.18-128.7.1.el5 #1 SMP Mon Aug 24 08:21:56 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44)

C++ -- удаление неполных типов

Трудно сказать, чем руководствовались умные дядьки, создавая стандарт языка, в котором оператор delete можно применить к объекту, тип которого в этой точке удаления может быть еще полностью не определен.
В языке и без этого хватает undefined behavior (читай -- граблей), а описанное выше послабление приводит к появление еще одного, описанного в разделе стандарта 5.3.5/5:

"If the object being deleted has incomplete class type at the point of deletion and the complete class has a
non-trivial destructor or a deallocation function, the behavior is undefined."


Теоретически, компилятор очень легко может детектировать эту потенциально опасную ситуацию, и выдавать соотвествующее предупреждение, однако полагаться на это не стоит, т.к. компиляторы бывают разные, да и вообще, кто читает эти глупые ворнинги? Разве что те, кому лень их отключать.
Шутка.

Чаще всего проблема удаления неполного типа возникает рядом с хорошо известным паттерном Pimpl, который удобнее всего реализовывать на boost::scoped_ptr. Ужжжасный класс std::auto_ptr можно посоветовать использовать разве что врагу, тем более, что в новый стандарт языка умные указатели из boost'а скорее всего войдут.
Collapse )
морда

Serialization standards in c++

Есть ли лёгкий способ сериализации (и обратно) для сложных структур в с++? Лучше всего на уровне компилятора (как атрибуты в .NET) Я чего-то конечно написал. Оно пока работает. Однако, если есть что-то общепринятое и хорошо продебагенное (и желательно не слишком сложное в интеграции) то конечно это было бы лучше. Дайте направление, куда копать?
Пятачок

Про двойные инкременты

Господа, проясните пожалуйста ситуацию.

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

int i;
++ ++i;//работает
i++ ++;//ошибка

Далее хочу перегрузить префиксный и постфиксный операторы в классе и проделать ту же операцию. Но при проверке оказывается, что срабатывает и префиксный, и постфиксный операторы. Объясните, пожалуйста, почему срабатывает постфиксный?

class Rational
{
int p,q;
public:
Rational(int a = 0, int b = 0){p = a; q = b;}
~Rational(){}
Rational& operator++();
Rational operator++(int noused);

void out(){cout<<"p = "<

<<" q = "<<

};

Rational& Rational::operator++()
{
++p;
++q;
return *this;
}

Rational Rational::operator++(int noused)
{
Rational temp = *this;
++p;
++q;
return temp;
}

int main ()
{
Rational z(1,2), x(1,2);
++++z;
z.out();//выводится 3,4
x++++;
x.out();//выводится 2,3
return 0;
}

UPD:Спасибо, ответ в комментариях. Нужно изменить возвращаемое значение в постфиксном инкременте с Rational на const Rational.

Сравнение сред Builder C++ (6.0) и Visual Studio (2005)

С билдер проработал год профессионально и гдето 2 года лабы в инсте делал. Со студией уже полгода профессионально (Qt) и еще немного до этого имел дело. Сразу оговорюсь что возможно некоторые проблемы как-то решаются, но я не знаю этих способов, хотя и искал.
Итак. Первый же существенный минус студии - нельзя переключаться между хедером и его сиплюсплюсником (файлом), а также формой, соответствующей данному файлу (это Qt). Можно только сделать go to header. Это крайне существенный минус, который не дает нормально работать, ибо задалбливаешься мышкой щелкать, да еще надо найти файл (в закладках хотя бы).
И в той и в другой среде бывают косяки со списком методов класса (это когда в срр тыкнуть в какойто метод и наверху в комбобоксе появятся методы класса в который тыкнули), то есть они не видятся при какихто условиях. Разумеется это тоже не добавляет удобства ибо когда файл большой то задолбаешься искать. В таких случаях в студии не работает и go to definition.
Компиляция - здесь с громадным отрывом лидирует студия, ибо ребилд среднего приложения (12-15 файлов срр) занимает (точно не засекал) секунд 40, тогда как примерно такого же уровня приложение в билдере может по 300 секунд занимать (без всяких шуток, ребилд в билдере это вещь конечно приятная, ибо несколько минут можно о чемто помечтать, но все таки иногда на это уходит слишком много времени). Также в билдере есть другая беда - зачастую надо ребилдить весь проект, ибо не хватает перекомпиляции только файлов в которых были произведены изменения (с учетом зависимых хедеров), за полгода ни разу не столкнулся с такой бедой в студии.
В студии есть неплохая возможность располагать файлы в 2 таба, то бишь видеть сразу 2 файла на экране, в принципе помогает, я ей всегда пользуюсь, еще бы экран так в 22 инча...
В студии также можно проект сразу билдить в либу или длл (всего лишь указав в опциях тип выхода), в билдере для этого надо создавать отдельный проект специального типа.
Вобщем это были основные моменты которые для меня имеют большое значение. Про дизайнер говорить не хочется ибо там билдер на 10 корпусов впереди Qt-шного.
Конец.