Skip to Content

C++

Об исключениях (C++)

СР, 12/28/2011 - 13:37 — lexa

Я не люблю C++-ные exceptions (за второй поток управления), как следствие - стараюсь их не использовать, а если использую, то перехватываю только те, которые порождает мой код. Как следствие, правил хорошего тона в этой области не знаю.

Возник вопрос, как правильно поступать. Вот есть такой примерно код:

  1. int some_class::some_function(std::filebuf& buf)
  2.  
  3.   try {
  4.       ....
  5.       buf.sgetn(....);
  6.       .....
  7.       return 0; // OK
  8.   }
  9.   catch (my_own_exception_type t) {
  10.         аккуратно_склеить_ласты();
  11.         return errorcode;
  12.    }
  13. }
Вопрос: должен ли я в подобном коде ловить исключения, порожденные std::filebuf? Ну там не смог он ничего прочесть? А вообще все исключения? Как требуют понятия хорошего тона?

Должны ли быть эти правила хорошего тона разными в таких двух случаях

  • Этот самый std::filebuf - на самом деле хранится внутри класса, где-то раньше был создан/открыт и все такое. То есть это наш сукин сын.
  • Этот самый IO-хэндл (std::filebuf) передан нам снаружи т.е. это чужой сукин сын.
?

P.S. Нашелся йузер у которого для файлов с SD-читалки не работает std::filebuf IO. Linux, холст, масло....

О семантике C++

СР, 10/05/2011 - 09:37 — lexa

В продолжение кулуарного разговора с Highload++, навеянного 26-м слайдом презентации Андрея Аксенова.

Вот такой вот код:

  1. class someShit{
  2.         char *m_sBuffer;
  3.         size_t m_iLimit, m_iCounter;
  4. };
  5. void someShit::try1()
  6. {
  7.         m_iCounter = 0;
  8.         while (m_iCounter< m_iLimit && m_sBuffer[m_iCounter])
  9.                 m_iCounter++;
  10. }
  11.  
  12. void someShit::try2()
  13. {
  14.         size_t l_iCounter = 0;
  15.         while (l_iCounter< m_iLimit && m_sBuffer[l_iCounter])
  16.                 l_iCounter++;
  17.         m_iCounter = l_iCounter;
  18. }
Компиляторы (смотрел gcc 4.6, Visual Studio 2010 и Intel 11.0, все с включенной стандартной оптимизацией -O3/O2 без тонких настроек) делают разное:
  • gcc и Visual Studio генерируют код с той семантикой, какой написано;
  • Intel C++ делает так же, если компилирует "библиотеку", но оптимизирует первый случай до второго, если все потроха (методы класса и вызывающий их main()) лежат в одном файле.

C++ streams compatibility...

Втр, 10/05/2010 - 18:58 — lexa

Граждане программисты,

Я - человек темный, граблями причесываюсь на фортране-77 все еще программирую. Но мне пишут, что дескать в современных C++-стримах все сделано по уму в смысле буферизации и работают они временами сильно быстрее, чем любимый мой FILE*

Собственно, сомневаться причин нет, в тестах так оно и получилось (и разница заметная), но мучает меня вопрос с совместимостью.

Мою LibRaw на чем только не собирают, вот даже на Maemo, а давеча я проблемы с Visual Studio 2003 правил.

Отсюда вопросы (сам я за всем этим не слежу, проще спросить):

  • Интерфейс то стримовый за последние лет 7-10 - он вообще как, стабилизировался?
  • Следует ли ожидать всяких открытий чудных, вроде того что метод есть, но не работает?
  • С Linux/Mac проблем нет, я вижу что в gcc 4.x все (на первый взгляд) нормально. А что с виндами, причем как в ипостаси Visual Studio, так и cygwin/MinGW? Может есть какая-то табличка по совместимости хотя бы по Visual C++

Ужасы программирования

Втр, 11/18/2008 - 18:11 — lexa

Сортирую записи по 8-байтным ключам в byte order (не в numeric). Записей много (сотни миллионов). Оказывается, сравнивать ключи надо так: 

  1.     unsigned char *p1 = (unsigned char *)d1;
    2. 

  2.     unsigned char *p2 = (unsigned char *)d2;
    3. 

  3. #define CMP(i) if(p1[i]!=p2[i]) return p1[i]-p2[i]
    4. 

  4.     CMP(0); CMP(1); CMP(2); CMP(3); CMP(4);CMP(5); CMP(6); CMP(7);
    5. 

  5.     return 0;
    6. 

  6. #undef CMP
    7.

А банальный memcmp/__builtin_memcmp оказывается в 2.2 раза медленнее на общее время исполнения qsort(), во сколько раз различается сравнение - боюсь думать.

С numeric-сортировкой тоже весело, естественно наступил на (value2-value1) - это быстро и неверно (а верный вариант - получился не быстрее побайтового).

Обожаю язык C++

ЧТ, 02/14/2008 - 13:40 — lexa

cd STLport-5.1.5/build/test/unit
gmake -f gcc.mak all-static 2>build.error >build.log

Получаю одно (!) сообщение об ошибке, размер сообщения 795 килобайт.

Syndicate content


.