If a C programmer asks "do you want to see something cool?", run away.
--John Van Enk

Saturday, January 19, 2008

Линус критикует C++

Via aruslan узнал об ответе Линуса на вопрос Dmitry Kakurin почему Git написан на С а не на С++. Больше всего понравились цитаты
Quite frankly, even if
the choice of C were to do *nothing* but keep the C++ programmers out,
that in itself would be a huge reason to use C.
Что и говорить, тут трудно не согласиться, поскольку многие программеры на С++ считают себя сильно "мегакрутыми" (коими в действительности не являются) для того чтобы снизойти до чистого С. Это действительно хороший способ :-)
C++ leads to really really bad design choices. You invariably start using
the "nice" library features of the language like STL and Boost and other
total and utter crap, that may "help" you program, but causes:

- infinite amounts of pain when they don't work (and anybody who tells me
that STL and especially Boost are stable and portable is just so full
of BS that it's not even funny)

- inefficient abstracted programming models where two years down the road
you notice that some abstraction wasn't very efficient, but now all
your code depends on all the nice object models around it, and you
cannot fix it without rewriting your app.

In other words, the only way to do good, efficient, and system-level and
portable C++ ends up to limit yourself to all the things that are
basically available in C. And limiting your project to C means that people
don't screw that up, and also means that you get a lot of programmers that
do actually understand low-level issues and don't screw things up with any
idiotic "object model" crap.
Подобные мысли и меня когда-то одолевали. Ну а согласно The Cathedral and the Bazaar успех софтины зависит от других факторов. Ветвь дискуссии по вопросу Дмитрия. Занятное чтиво.

Sunday, January 13, 2008

Сертификация на brainbench

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

C++ Master Brainbench Certificate

Довольный, хоть многие и говорят, что brainbench - не показатель.

Thursday, January 10, 2008

А возможно и не const...

Прочитав недавно в блоге Алёны С++ статью Возможно, самый важный const, губоко задумался нельзя ли все-таки как нибудь обойти запрет на следующее

string&s = string("abc");
int&i = 1;

И совершенно неожиданно вспомнил, что когда-то давным-давно на далеком-далеком форуме (чет меня опять не туда понесло ;-)) прочитал о том, как тимлид учил зеленых программеров: "тыкаем в любое место throw 1; если программа летит - бьем дубиной по голове"

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

try {
throw 1;
}
catch(int&i){
//можем менять i
}
catch(...){}


Проверяем

try {
try {
throw 1;
}
catch(int&i){
cout<<"int& "<<i<<endl;
i=2;
throw;
}
catch(...){}
}
catch(int&i){
cout<<"int& "<<i<<endl;
}
catch(...){}


Факт повторной генерации исключения отмечается отсутствием операнда у throw. Причем повторно сгенерированное исключение является исходным исключением (копией или нет - думаю зависит от реализации, по крайней мере в Стандарте ничего не нашел по этому поводу. Может плохо искал? Пните меня в комментах, если найдете). Хотя по идее оно должно копироваться, так как это все же генерация, хоть и повторная. Однако в реализации gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21), которой я на данный момент пользуюсь, в момент повторной генерации эксепшн не копируется.


#include <iostream>
#include <cstdlib>

//класс исключения
class ex {
public:
ex(const ex&){cout<<"Copy ctor"<<endl;};
ex(){cout<<"ctor"<<endl;};
~ex(){cout<<"dtor"<<endl;}
};
//
int main(int argc, char *argv[])
{
try {
try {
throw ex();
}
catch(ex&){cout<<"Rethrow"<<endl;throw;}
catch(...){throw;}
}
catch(ex&){}
catch(...){}
return EXIT_SUCCESS;
}

Причем, что интересно, на отсутствие copy constructor ругается, если его private или explicit сделать, а в процессе распространения исключения и при генерации его не использует.

Update
В результате пинков открыл таки 15.1 пункт Стандарта и почитал его. И как правильно заметили в комментариях, время жизни ссылки все равно ограничено обработчиком и не превышает время жизни временной переменной, а время жизни временной переменной, в свою очередь, определяется другим механизмом, а не наличием ссылок на нее.

Update2
15.1.6
A throw-expression with no operand rethrows the exception beeing handled. The exception is reactivated with existing temporary; no new temporary exception object is created.

Так что во время повторной генерации исключения копирования не происходит.


Wednesday, January 9, 2008

gcc. Полное руководство

"GCC: The Complete Reference" однозначно must have для каждого программера под linux , который ценит свое время. Содержание вообще привело меня в неописуемый восторг - мало того что присутствуют разделы по конфигурированию, установке и тестировании компилятора, но также рассказано о сборке кросс-компилятора (чего мне пока с последними версиями gcc проделать на удалось - под ARM собираться не хочет, binutils собираются, bootstrap compiler тоже, а сборка libc - сваливается... или это сборка полноценного компилера? не помню уже... после десятка безуспешных попыток я это дело отложил на неопределенное время. Может книжка эта поможет?), расширениях GNU для С и С++, Objective-C, Java, Fortran и Ada, GDB, смешивание языков, сборка компилятора для ембедед систем тоже не обделены вниманием.

В общем и целом - 600 страниц ОЧЕНЬ ПОЛЕЗНОГО ТЕКСТА.

Monday, January 7, 2008

Сдвиг в индустрии?

В последнее время писать особо времени нет в виду подготовки к защите диплома в феврале. Да что там писать, даже на работу иногда времени нет, благо что она part time (хотя де-факто - в большинстве своем full time). Так вот, бродя по сайтам ведущих харьковских фирм, занимающихся разработкой ПО, наткнулся на сайте компании Program-Ace на вакансию Senior C++/Haskell developer.

Приглашаем к долгосрочному сотрудничеству специалиста профиля Senior C++/Haskell developer – для участия в разработке архитектуры в рамках уже сложившейся команды, которая имеет не только опыт в данной области, но и целый ряд успешно выполненных проектов (прекомпилятор ESQL/C и т.д.). Мы ищем настоящего профессионала, которому свойственны: стремление к решению нетривиальных и сложных задач с использованием самых современных подходов и решений; желание всесторонне планировать и активно разрабатывать архитектуру; высокая степень реализации профессиональных амбиций.

Обязанности:
• Разработка архитектуры.
• Составление плана работ.
• Оперативное и профессиональное решение поставленных задач.


Требования:
• Языки: С++, Haskell.
• Библиотеки общего назначения: STL, boost.
• Знание паттернов и современных подходов к разработке.
• Владение функциональными языками на высоком уровне.

Желательны: знания и опыт в области разработки компиляторов.


Чуть ранее о подобных наблюдениях писал lrrr: здесь и здесь. Может Erlang и Haskell, да и вообще распределенное и функциональное программирование - next big thing in industry? В последнее время наблюдается устойчивый интерес в блогах разработчиков к этим технологиям. Ваше мнение? Если несложно, то отпишитесь в комментах к этому посту.