C++ haters handbook :-)

[homo ludens]

обещанный пример из реальной жизни где работает С и не работает С++.
будет состоять из нескольких постов.

часть первая.
итак возьмем два блока кода. Однис с malloc, другой с обычным порошком - try/catch
первый блок я напишу сам, причем с ошибками, и не используя разных полезных техник (например alloca).
Второй код - аналог на try/catch я попрошу написать кого-то из присутствующих здесь объектников.
Итак. Инициализатор структуры foo.

typedef void* foo_t;
typedef struct
{
   bar_t bar;
   baz_t baz;
} foo_int_t;

foo_t foo_init(int z)
{
   foo_int_t* rv=0;
   
   if(!(rv=malloc(sizeof(foo_int_t)))
     return 0;

  {
   char *p=malloc(14);  // имитируем необходимость в динамической памяти,
                                      // забыли проверить на 0
   
   if(!(rv->bar=bar_init()))
      goto leave;	// забыли освободить память

    bar_setmem(p);      // реально если p требуется в инициализации, то должен быть там. но мы ведь пишем неправильно. :-)
    free(p);
  } 
   if(rv->baz=baz_init())
     return rv;

    free(rv->baz);
  leave:
    free(rv->bar);
    free(rv);    
}

А теперь ждем его функциональный аналог аналог на С++, причем написанный правильно (оказывается очень многие вещи на С++ можно писать неправильно!)

[Ull9]

смотрел смотрел. не понял. Конечно автор предупредил
что будет сошибками...
ну допустим чего нибудь такое...
но если знать что поинтер foo_t будет использоваться только
в с++ коде. написал бы еще проще.

typedef void* foo_t;
void release_foo_t (foo_t);
typedef struct
{
bar_t bar;
baz_t baz;
} foo_int_t;

foo_t foo_init(int z)
{
foo_int_t* rv=0;
try
{
rv=new foo_int_t;
char *p=malloc(14); // имитируем необходимость в динамической памяти,
// забыли проверить на 0
rv->bar=bar_init();
bar_setmem(p); // реально если p требуется ...
free(p);
rv->baz=baz_init();
return rv;
}
catch (bar_init_ex &)
{
delete rv;
}
catch (baz_init_ex &)
{
bar_release(rv->bar);
delete rv;
}
catch (std::bad_alloc &)
{

}
return 0;
}

ты бы лучше словами обьяснил чем с++ хуже. мне вот интересно
как по мне большие проекты на c писать сложнее.

[pal]

на двух тачках с разными архитектурами.
gcc version 3.4.4 20050526
gcc version 4.1.0

x.cc:6: error: call of overloaded 'abs(int&)' is ambiguous
/usr/include/c++/4.1.0/cmath:89: note: candidates are: double std::abs(double)
/usr/include/c++/4.1.0/cmath:93: note: float std::abs(float)
/usr/include/c++/4.1.0/cmath:97: note: long double std::abs(long double)

мне кажется, вы бы могли порадоваться такой обратной совместимости. std::abs(double) находится в <cmath>, т.к. fabs находится в <math.h>, а std::abs(int) находятся в <cstdlib>, т.к. abs находится в <stdlib.h>. а также сообщению об ошибке - с просто проглотил бы и вызвал неправильную функцию

какой void*? человек видит transglukator_t.

typedef он тоже видит в заголовке.

нету void*. человек делает вызов trasglukator_t t=transglukator_init(); Зачем его передавать потом в bukazoid_destroy ?

потому что этот t мало чем отличается от соседнего tt ?

что мешает программисту взять кубический корень из windows handle? Очевидно здравый смысл.

ничего не мешает, это то и плохо. у класса апи определен четко, а с интом можно делать что угодно.

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

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

У меня CXXFLAGS установлены в одно, у кого-то - в другое значение. Все довольны.
Расскажите, почему этого нельзя было сделать. Почему я могу компилировать K&R программы многолетней давности на С и немогу это делать на С++. Нарушение обратной совместимости - имхо признак дикой неряшливости дизайна.

k&r - не стандарт, так что очень трудно быть уверенным в возможности его компилировать. в частности, gcc его не поддерживает.

И надо очень сильно молиться на систему типов, чтобы поставить ее выше в своей системе ценностей.

дык, система типов - краеугольный камень.

Ознакомьтесь с историей и целями создания С и UNIX. С - первый язык высокого уровня, который позволил эффективно писать низкоуровневые блоки. До С все ядра ОС писались на ассемблере и портируемость ОС ограничивалась двумя-тремя архитектурами. Вместе С была создана первая коммерческая ОС полностью написанная на машинно-независимом языке. Эта ОС (UNIX) живет до сих пор. Ничего близкого С++ не создавал и не создаст. Нет задач, которые может решить только С++. Были задачи которые смог решить только С.

By 1973, the C language had become powerful enough that most of the Unix kernel, originally written in PDP-11 assembly language, was rewritten in C. This was one of the first operating system kernels implemented in a language other than assembly. (Earlier instances include the Multics system (written in PL/I), and MCP (Master Control Program) for the Burroughs B5000 written in ALGOL in 1961.)

Они есть и сейчас, никто не мешает написать свой драйвер ядра на С++. Но почему-то желающих нет. А если находятся, то не находятся желающие этим драйвером пользоваться.

beos как-то написали, а сдох он совсем не из-за выбора языка. все виндовсы с 95 написаны на с++, правда, неизвестно, на какую глубину. и у них это плохо получается
в общем, на ура пишут на с++ и ядра и вообще крупные проекты

Удобство - критерий субъективный. Мне неудобнее. Программисту, которому на выбор надо выучить с нуля С и написать на нем проект, либо программисту который должен с нуля выучить С++ + ООП + все аббревиатуры + все шаблоны + как правильно писать (это ведь нетривиальная задача неудобнее.

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

Програмисту, который матюкаясь читает код, переполненный перегруженными функциями и операторами

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

и 10 (! сам видел) уровнями наследования - неудобнее, но это он матюкается пока не сел за отладчик, вот тут он поймет, что такое неудобно.

если бы то же самое сделали с помощью glib/gobject, стало бы легче ? с++ всего-лишь сделал наследование более удобным в применении, наследовать можно было вручную и раньше.

Руководству eBay в проектах которого количество членов класса превышало возможности компилятора - неудобно.

это свидетельствует о двух вещах: кривом дизайне и кривом компиляторе

Давайте лучше к объективным критериям вернемся.

объективные критерии у нас уже были - ручное слежение за ресурсами - вообще непосильная задача по сравнению с raii

Есть ли жизнь за пределами компилятора? Или лучше так - если компилятор чего-то не может, то этого не может никто
Если для вас даже задачи статического чекинга должны выполняться компилятором, то я даже не знаю что сказать.

а зачем делать отдельной программой то, что и так делает компилятор ?

Есь очень много программ, работающих с кодом напрямую без компилятора. На С++ их меньше, так как у С++ усложненный синтаксис.

и еще потому что ему их меньше нужно. сообразительные товарищи выдирают парсер из gcc

Что убъет язык в тот момент, когда на рынок придут функциональные языки индустриального класса.

чисто функциональные никуда не придут, т.к. на них можно писать только калькуляторы. а грязно функциональным с++ и сам является

Что характерно, С выживет.
Кстати, вы с openC++ не работали?

нет. я полагаю, что проект сдох, т.к. последний релиз 2001 года.

если я контролирую thread pool, то мне может понадобиться массив pthread_once_t. И в этом случае он действительно удобней как int и инициализация будет в цикле.

я начинаю опасаться, что вы не знаете, что такое pthread_once_t. ему совершенно все равно пул у вас или нет, он нужен, чтобы выполнить глобальное действие только один раз, независимо от числа потоков, пытающихся его выполнить. если вы хотите выполнить по действию на поток, то pthread_once_t вам не нужен. кстати, в с++ он не нужен вообще, т.к. инициализация статических объектов и так thread-safe.

А вот массив cond_t либо condattr_t никому не нужен, обычно это один объект, на который ссылаются другие.

казалось бы, при чем тут массив ?

Хотя конечно, при работе с pthread эффективность всегда на первом месте, удобство пользования все-таки есть, но это не удобство в понимании объектников (пусть придет мама (необъектная) и сделает мне хороший компилятор, который все сделает за меня), это аскетическая простота использования и минимализм.
pthread не относится напрямую к glibc, я его просто с потолка выбрал, по причине простоты. А вообще glibc - относительно старая библиотека с феноменальной портируемостью и очень неплохой эффективностью. Т.е. в моих терминах показатели функциональности и эффективности на высоте, удобства - в приемлимых рамках.

glibc не портируется туда, где нет gcc, да и там, где есть, портируется на полторы системы. в то же время, с каждым gcc идет стандартная библиотека с++. и с другими компиляторами тоже должна идти.

Я не думаю, что boost при своей идеологии в состоянии повторить эту аскетичность и простоту.

boost уже портируется на больше систем и компиляторов, чем glibc. а 10 его библиотек уже вошли в tr1 и другие на подходе в tr2 и c++0x.

[pal]

обещанный пример из реальной жизни где работает С и не работает С++.

трудно понять, что оно должно делать, т.к. половина типов и функций не описана, но я попробую пофантазировать

[pal]

//header
struct A;
A*newA();
void f(A*);
void deleteA(A*);
//source
struct A{
A(const char*a,int b):s(a){
v.push_back(b);
}
std::string s;
std::vector<int> v;
};
A*newA(){
return new A("123", 456);
}
void f(A*a){
std::cout<<a->s<<std::endl;
}
void deleteA(A*a){
delete a;
}
------------
эот максимально приближенный по интерфейсу вариант. я бы так не делал. прошу обратить внимание на отсутствие try/catch

[Ull9]

------------
эот максимально приближенный по интерфейсу вариант. я бы так не делал. прошу обратить внимание на отсутствие try/catch

да, ты не написал try/catch, но при этом, строго говоря,
ты потенциально выбрасываешь экцепшн наружу. и при этом
никого не предупредив.
Во всяком случае твой интерфейс об этом молчит.
operator new, может выбросить эксепшн.

либо интерфейс плох, лио код.

[pal]

да, ты не написал try/catch, но при этом, строго говоря,
ты потенциально выбрасываешь экцепшн наружу. и при этом
никого не предупредив.
Во всяком случае твой интерфейс об этом молчит.
operator new, может выбросить эксепшн.

либо интерфейс плох, лио код.

??
у вас какое-то особое представление об обработке исключений ? конечно, я их выбрасываю, т.к. я понятия не имею, что с ними делать. а в качестве предупреждения работает отсутствие throw ( ) в прототипах.

[Ull9]

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

представте ситуацию, я работаю с ваше библиотекой. так что?
мне прикажете, каждый вызов вашей функции обрамлять
try
{
foo()
}
catch (...)
{
log ("Ups: something bad happened")
}

по ВАШЕМУ это нормальный дизайн?

[homo ludens]

мне кажется, вы бы могли порадоваться такой обратной совместимости. std::abs(double) находится в <cmath>, т.к. fabs находится в <math.h>, а std::abs(int) находятся в <cstdlib>, т.к. abs находится в <stdlib.h>. а также сообщению об ошибке - с просто проглотил бы и вызвал неправильную функцию

Вы совершенно правы, labs определена в stdlib. Я сначала хотел написать для fabs, который Вы определили. И забыл поменять include. Я редко пишу сразу на экран, и это дает о себе знать на этом форуме. Тем не менее у меня есть правило, если код с флагом -Wall дает хоть один warning - он идет в корзину. Если бы компилятор не нашел прототипа для labs он бы дал такой ворнинг. Он его не дал, следовательно с кодом все ок. Строго говоря это будет ошибкой для мультиплатформенного кода при переносе - там появятся варнинги, что послужит сигналом для доработки.
Однако в результатах это ничего не меняет - результирующее количество строк кода 1033 - что по прежнему в 15 раз меньше показателя С++. Вы делаете ночные билды всего проекта?

By 1973, the C language had become powerful enough that most of the Unix kernel, originally written in PDP-11 assembly language, was rewritten in C. This was one of the first operating system kernels implemented in a language other than assembly. (Earlier instances include the Multics system (written in PL/I), and MCP (Master Control Program) for the Burroughs B5000 written in ALGOL in 1961.)

и multix и MCP были более экспериментальными вещами. Жили они мало, хотя Unix действительно был во многом вдохновлен мультиксом. Как человек когда-то учивший алгол и писавший реальные программы на PL/I могу сказать, что жизнеспособность этих систем была очень ограничена.
Unix был прорывом.

в общем, на ура пишут на с++ и ядра и вообще крупные проекты

я ж говорю, если пишут, то никто этим не пользуется.
Про крупные проекты на С++ я наверное заведу отдельную ветку.

вы совершенно зря полагаете, что с++ сильно сложнее изучить, чем с.

Да, вы правы, объем тестов на brainbench которые я сдавал по С++ был идентичен размеру на С. Но перед тем как его сдавать надо было еще пройти тесты на ООП, которые в два раза превышали сам С++.

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

если на С написано + то это + всегда и везде. Не выглядело бы на С хуже.

а зачем делать отдельной программой то, что и так делает компилятор ?

элементарное понимание Unix way. И желание сделать то, что в компиляторе не появится никогда. И независимость от умников из technical report.

чисто функциональные никуда не придут, т.к. на них можно писать только калькуляторы. а грязно функциональным с++ и сам является

боюсь, что вы плохо понимаете их преимущества.

я начинаю опасаться, что вы не знаете, что такое pthread_once_t.

The first call to pthread_once() by any thread in a process, with a given once_control, shall call the init_routine with no arguments. Subsequent calls of pthread_once() with the same once_control shall not call the init_routine. On return from pthread_once(), init_routine shall have completed. The once_control parameter shall determine whether the associated initialization routine has been called.
примеры использования на
http://publib.boulder.ibm.com/infoce...alizations.htm

А теперь мой пример использования в массиве.

typedef struct
{
  void (*func)(void);
  pthread_once_t once;
} globalinit_t;

void init_subsystem1(void);
void init_subsystem2(void);
...

globalinit_t globalinits[]=
{
  {init_subsystem1,PTHREAD_ONCE_INIT},
  {init_subsystem2,PTHREAD_ONCE_INIT}
 ...
};

#define GOBALINITSIZE (sizeof(globalinits)/sizeof(globalinit_t))

Я на самом деле такие вещи предпочитаю делать не через pthread_once, а через явный инициализатор. Но наверное кому-то это надо.

glibc не портируется туда, где нет gcc, да и там, где есть, портируется на полторы системы. в то же время, с каждым gcc идет стандартная библиотека с++. и с другими компиляторами тоже должна идти.

boost уже портируется на больше систем и компиляторов, чем glibc. а 10 его библиотек уже вошли в tr1 и другие на подходе в tr2 и c++0x.

полторы системы? гм. ну, ну. вообще-то кроме списка http://www.gnu.org/software/libc/ports.html надо помнить что glibc реализует POSIX. Который как-бы стандарт тоже не на полторы системы. И что с++ библиотеки строятся обычно поверх POSIX так как представляют собой большей частью интерфейсы к тому же POSIX. Или библиотека с++ сама реализует доступ к файловой системе или сама вычисляет гамма-функцию?
Что характерно, я не нашел списка портов boost'а на их страничке. Поиск по слову porting дал неожиданные результаты, оказалось что boost'овцы понимают под портированием несколько другие вещи - например porting to VC++

ты бы лучше словами обьяснил чем с++ хуже. мне вот интересно
как по мне большие проекты на c писать сложнее.

Напишу с примерами кода. Просто пост большой получается.

[pal]

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

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

представте ситуацию, я работаю с ваше библиотекой. так что?
мне прикажете, каждый вызов вашей функции обрамлять
try
{
foo()
}
catch (...)
{
log ("Ups: something bad happened")
}

по ВАШЕМУ это нормальный дизайн?

нет, это отвратительный дизайн. это инфекция из явы. у меня вообще нет ни одного try/catch, у вас же их больше, чем собственно кода. забудьте все, чему вас научила ява, и пишите программы по человечески

[pal]

Вы совершенно правы, labs определена в stdlib. Я сначала хотел написать для fabs, который Вы определили. И забыл поменять include. Я редко пишу сразу на экран, и это дает о себе знать на этом форуме. Тем не менее у меня есть правило, если код с флагом -Wall дает хоть один warning - он идет в корзину.

[11:12:43 pal@underdark ~/tmp/math]$ cat e.c
#include <stdlib.h>
#include <stdio.h>
int main ( ) {
float a = 1.5;
a = abs ( a );
printf ( "%f\n", a );
long b = 1000000000000L;
b = abs ( b );
printf ( "%ld\n", b );
return 0;
}
[11:13:10 pal@underdark ~/tmp/math]$ gcc -Wall -o e e.c
[11:13:13 pal@underdark ~/tmp/math]$ ./e
1.000000
727379968
---------
чето ворнингов не было

Однако в результатах это ничего не меняет - результирующее количество строк кода 1033 - что по прежнему в 15 раз меньше показателя С++. Вы делаете ночные билды всего проекта?

не знаю, как вы считаете строки
после препроцессирования остается от
cmath 1908
math.h 1058
cstdlib 1475
stdlib.h 1339
строк. бОльшая часть добавленных 850 и 136 строк - перегруженные функции, ради которых все и затевалось

и multix и MCP были более экспериментальными вещами. Жили они мало, хотя Unix действительно был во многом вдохновлен мультиксом. Как человек когда-то учивший алгол и писавший реальные программы на PL/I могу сказать, что жизнеспособность этих систем была очень ограничена.
Unix был прорывом.

unix _стал_ прорывом. а были они все одинаково экспериментальные и плохие. просто unix был открытым и сравнительно простым, что позволяет быстро размножаться

я ж говорю, если пишут, то никто этим не пользуется.

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

Да, вы правы, объем тестов на brainbench которые я сдавал по С++ был идентичен размеру на С. Но перед тем как его сдавать надо было еще пройти тесты на ООП, которые в два раза превышали сам С++.

я уже говорил о glib/gobject, там ведь тоже без ооп никуда, только помощи от компилятора никакой

если на С написано + то это + всегда и везде. Не выглядело бы на С хуже.

т.е. strcat не выглядит хуже + ?

элементарное понимание Unix way. И желание сделать то, что в компиляторе не появится никогда. И независимость от умников из technical report.

unix way не предполагает написания тысячи одинаковых парсеров. более того, он, как и ооп, не везде применим. вы много видели unix баз данных на пайпах ? про возможность использования парсера из gcc я уже писал.
про умников я не осилил

боюсь, что вы плохо понимаете их преимущества.

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

А теперь мой пример использования в массиве.

typedef struct
{
  void (*func)(void);
  pthread_once_t once;
} globalinit_t;

void init_subsystem1(void);
void init_subsystem2(void);
...

globalinit_t globalinits[]=
{
  {init_subsystem1,PTHREAD_ONCE_INIT},
  {init_subsystem2,PTHREAD_ONCE_INIT}
 ...
};

#define GOBALINITSIZE (sizeof(globalinits)/sizeof(globalinit_t))

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

полторы системы? гм. ну, ну. вообще-то кроме списка http://www.gnu.org/software/libc/ports.html

linux - 1 система, hurd - пол системы

надо помнить что glibc реализует POSIX. Который как-бы стандарт тоже не на полторы системы.

но это не относится к портируемости glibc

И что с++ библиотеки строятся обычно поверх POSIX так как представляют собой большей частью интерфейсы к тому же POSIX. Или библиотека с++ сама реализует доступ к файловой системе или сама вычисляет гамма-функцию?

с++ библиотеки строятся и поверх posix и поверх win32 и не только. стандартная библиотека с++ - тоже стандарт, реализованный на большем числе систем, чем posix.

Что характерно, я не нашел списка портов boost'а на их страничке. Поиск по слову porting дал неожиданные результаты, оказалось что boost'овцы понимают под портированием несколько другие вещи - например porting to VC++

http://boost.org/more/getting_started.html#Tools

[Ull9]

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

Ну, давайте по порядку. Во первых, если я непоймаю эксепшн, то ... у меня наступит краш программы. и никакого во вторых уже ненаступит, все... точка, моего процесса нет. Причем тут ресурсы? все! тю-тю. Баржоми непоможет.
далее. ловить std::exception тоже непоможет. а что если либина выбросит допустим std::string? как у меня уже как то и было? А автор либины находится в сингапуре? Вот красота!!!

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

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

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

А что касается моуг трай кэтч, то... дурная постановка задачи, дурной неясный пример. вот оно и получилось так.
я лично вообще предпочитаю не работать с эксепшнами. Но такова была постановка задачи.
Еще раз. было написано
проверять malloc на ноль. это С
ловить эксепшн........... это С++

У вас эксепшн не ловится.

[homo ludens]

[11:13:10 pal@underdark ~/tmp/math]$ gcc -Wall -o e e.c
чето ворнингов не было

обычное переполнение. В чем проблема.
int16_t x=32767;
x+x+x вам даст неожиданный результат что в С что в С++. long и int взаимозаменяемы. Компилятор выдаст ворнинг если допустим сравнение знакового и беззнакового и иногда это полезно. Опять таки labs юзать надо, если ожидаешь таких значений. Не ожидаешь - не юзай.

не знаю, как вы считаете строки

<algorithm> забыли.

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

Странно почему они не убили Линукс. : -)
Я не лазил внутрь винды давно, но HWND вроде был интом?

я уже говорил о glib/gobject, там ведь тоже без ооп никуда, только помощи от компилятора никакой

Потому и не юзаю glib.
А про ГУИ я уже писал - это та точка, где ООП необходим, однако и это является проблемой дизайна, а не программиста.

т.е. strcat не выглядит хуже + ?

нет конечно. он несколько менее компактен, но он всегда однозначно идентифицирует действие и типы аргументов. А переопределяя операторы вы всегда придете к проблеме yo-yo.

unix way не предполагает написания тысячи одинаковых парсеров.

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

более того, он, как и ооп, не везде применим. вы много видели unix баз данных на пайпах ?

Unix базы делаются не на пайпах а на сокетах (в т.ч. и локальных) и shared memory.
Встречный вопрос, вы много видели объектно-ориентированных баз данных? Вы вообще их видели? История ООП баз напоминает бразильский сериал под названием "Убитое время между вторым и третьим манифестом или почему был продан Информикс". : -) Стандарт ODMG если вам это неизвестно накрылся медным тазом, в результате чего высказывание, что все крупные проекты пишутся на ООП становится в высшей степени сомнительным. Если проект крупный - то он использует базу данных. Если он объектный - то очевидно объектную. А таковых как известно нет, есть только миллиарды долларов убытка.
ORM технологии в виде маленькой инвалидной коляски прицепленной на нижний конец каждого костыля не предлагать. : -)

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

Представьте себе автоматический генератор кода по спецификации на SKI-комбинаторах. Я думаю при появлении такой вещи половина программистов мира уйдут искать работу. И это только часть айсберга, потому что достаточность лямбда исчисления и комбинаторного исчисления для описания мира, в отличие от ООП является математическим фактом. Мир вокруг не объектный - он функциональный. Вас кто-то обманул.

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

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

linux - 1 система, hurd - пол системы

дайте поиск по слову glibc+Darwin или glibc+Irix или еще что-то.

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

http://boost.org/more/getting_started.html#Tools

так я не понял, там своя реализация гамма-функции или нет? : -)
По ссылке на boost видно что я был прав. Там огромный список портов, включающих в себя такие сверхважные для человечества платформы (!) как Borland C++ и Kylix. : -) Это действительно круто.
Кроме линукса и Hurd glibc ставится на кучу систем. Обычно это непрактично, но фанаты найдутся. Дайте поиск по инету по glibc+Darwin или glibc+IRIX. Много интересного найдете. По поводу того, что библиотека C++ более портируема чем Portable Operating System Interface (POSIX) которого придерживается даже винда я тоже не хочу спорить. Пока что boost портируется не под платформы - под компиляторы!

[Ull9]

прошу прощения, что вмешиваюсь в высокий спор, но хочу сказать свою точку зрения.

с/с++. Писал и на первом, писал и на втором. Сейчас поддерживаю продукт, где большой кусок наисан на с, и еще больший на с++. на с писать большие проекты тяжелей, тежелей выявлять взаимосвязи. без обектов, тэжело реализовывать бизнес логику.
Вам Homo ludens могу сказать, что кроме пафоса и мельтешения от перечисления технологий у вас ничего нет. нашел также немало мест где просто логика страдает.

типа здесь
<<Если проект крупный - то он использует базу данных. Если он объектный - то очевидно объектную. А таковых как известно нет, есть только миллиарды долларов убытка.
>>
С какой стати ооп код ДОЛЖЕН пользовать обьектную базу? да мне вообще все равно как написана БД, есть с ней интерфейс, и все. если надо напишу ооп оболочку к интерфейсу. Нет? буду пользоватся С интерфейсом.

На С писать можно, можно написать что угодно, также как и на ассемблере. Ну ичто?
на С++ это пишется быстрее, легче, при небольших потерях скорости.

[homo ludens]

блин, наконец то добрался до обещанного кода.
Хотел все сделать только кодом но наверно это будет долго.
Итак гм. преамбула.
Мы берем тот неряшливый код с ошибками, который я привел выше. И сравниваем с тем кодом, который привел pal с поправками Ull9.
Первый код глючен и неряшлив. Второй красив и гарантирует освобождение памяти. С этим согласны все и даже я.
Кроме того, если кто-то хочет сказать, что компилятор С не отлавливает ошибки программиста, а С++ - отлавливает, то я с ним спорить не буду. Потому что с моей точки зрения компилятор должен компилировать. А отлавливатель ошибок - отлавливать ошибки. Поэтому мне пофиг все ошибки динамической памяти. Просто пофиг. Пусть об этом заботятся люди, которые жалуются на то, что отвертка плохо забивает гвозди. Первым делом после компиляции (и предшествующего статического чекинга ибо никакой компилятор этого не заменит) я запускаю программу по отлову динамических ошибок памяти. Она называется valgrind. Очень рекомендую всем, кто ей никогда не пользовался. valgrind мне покажет все проблемы с динамической памятью, которые возникли при выполнении программы. Я их правлю.
Следующий этап.
vg показал мне все ошибки с ДП которые были при выполнении. Но он не покажет те ошибки которые могут возникнуть. Для того, чтобы он показал нам их мы делаем вот такой трюк. Блок кода (или весь файл) который мы хотим исследовать на потенциальные ошибки ДП мы заключаем в следующие скобки:

#define if(x) if(if_handler(x, __func__,__FILE__,__LINE__))
...
#undef if

Что делает if_handler? Да что угодно. Например если мы дадим return (rand()%2) || x; то получим тестирование методом Монте-Карло. Более практичным является методика, когда эта функция перебирает или генерирует нужные тестовые последовательности, нужные для гарантированного покрытия всего множества возможных ветвлений. Алгоритм давать надеюсь не надо. :- )
После этого гоняем прогу под valgrindom с разными последовательностями, а пока она так гоняется, топчем клаву здесь на форуме. Это пока жители Виллабаджо пишут юнит-тесты и изучают RAII.

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

Что еще может не поймать такая схема? Практически ничего. Например, выделение памяти внутри цикла, который выполняется 0 раз при любой тестовой последовательности. Приведенными выше средствами это не лечится, но это можно отследить вручную. Либо использовать артилерию потяжелее. Я предпочитаю вручную.

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

Вот собственно и обещанный пример...

PS в реальной жизни юзаю чуть другую схему, с m4 плюс еще несколько фич. Но и эта вполне рабочая.

2 Ull9
Крупный ООП проект на С++ это проект в котором сетевые интерфейсы и базы данных объектными не являются, а объектной является лишь бизнес-логика?
Я правильно понял?

[pal]

Ну, давайте по порядку. Во первых, если я непоймаю эксепшн, то ... у меня наступит краш программы.

если программа не поймает. совсем необязательно его ловить вам и совсем необязательно в каждой строчке.

далее. ловить std::exception тоже непоможет. а что если либина выбросит допустим std::string? как у меня уже как то и было? А автор либины находится в сингапуре? Вот красота!!!

я же сказал ловите ...
и не бросайте std::string, а если бросаете, то документируйте это.

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

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

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

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

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

не работать с исключениями не получится, если пользоваться стандартным с++

Еще раз. было написано
проверять malloc на ноль. это С
ловить эксепшн........... это С++

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

У вас эксепшн не ловится.

а зачем мне это ? у меня ресурсы не текут и объекты в неработоспособном состоянии не остаются. или вы видите что-то, чего не вижу я ?

[TechInsightJobs]

А отлавливатель ошибок - отлавливать ошибки. Поэтому мне пофиг все ошибки динамической памяти. Просто пофиг. Пусть об этом заботятся люди, которые жалуются на то, что отвертка плохо забивает гвозди. Первым делом после компиляции (и предшествующего статического чекинга ибо никакой компилятор этого не заменит) я запускаю программу по отлову динамических ошибок памяти. Она называется valgrind. Очень рекомендую всем, кто ей никогда не пользовался. valgrind мне покажет все проблемы с динамической памятью, которые возникли при выполнении программы. Я их правлю.

счастливы люди пишущие раз за разом программы не сложнее хеллоу ворлд

[Ull9]

блин, наконец то добрался до обещанного кода.
Кроме того, если кто-то хочет сказать, что компилятор С не отлавливает ошибки программиста, а С++ - отлавливает, то я с ним спорить не буду. Потому что с моей точки зрения компилятор должен компилировать. А отлавливатель ошибок - отлавливать ошибки. Поэтому мне пофиг все ошибки динамической памяти. Просто пофиг. Пусть об этом заботятся люди, которые жалуются на то, что отвертка плохо забивает гвозди. Первым делом после компиляции (и предшествующего статического чекинга ибо никакой компилятор этого не заменит) я запускаю программу по отлову динамических ошибок памяти. Она называется valgrind. Очень рекомендую всем, кто ей никогда не пользовался. valgrind мне покажет все проблемы с динамической памятью, которые возникли при выполнении программы. Я их правлю.

Компилятор должен компилировать. это так, Но если он еще и может отлавливать ошибки логики разве это плохо? Разве плохо, что он поможет предотвратить ошибли бизнесс-логики? Краш? О чем спор? ЗАЧЕМ ОТКАЗЫВАТСЯ ОТ ТОГО ЧТО ДАЕТ БЕСПЛАТНО ЛЮБОЙ КОМПИЛЯТОР С++?

Теперь по поводу твоего тула. Ну а если нет у меня этого тула? на моей платформе его нет вообще. AIX. И не говори мне про другие тулы. нельзя мне ничего ставить на машину заказчика. Дальше что? Что мне делать с твоими советами?
Надо пользоватся компилятором с++. его вполне хватит чтоб писать правильные проги.

2 Ull9
Крупный ООП проект на С++ это проект в котором сетевые интерфейсы и базы данных объектными не являются, а объектной является лишь бизнес-логика?
Я правильно понял?

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

[pal]

обычное переполнение. В чем проблема.
int16_t x=32767;
x+x+x вам даст неожиданный результат что в С что в С++. long и int взаимозаменяемы. Компилятор выдаст ворнинг если допустим сравнение знакового и беззнакового и иногда это полезно. Опять таки labs юзать надо, если ожидаешь таких значений. Не ожидаешь - не юзай.

это не обычное переполнение. у меня лонг 64 бит, и abs даже не поругался, что я ему даю вместо 32 бит 64. или число с плавающей точкой. а в с++, если вы забыли подключить заголовок, то ошибка, а если не забыли, то вызовется правильная функция. вот вам и система типов и перегруженные функции

<algorithm> забыли.

не более, чем /usr/include/*
зачем мне подключать <algorithm>, если нужные мне функции определены в <cmath> или <cstdlib> ?
интересный подход

Странно почему они не убили Линукс. : -)

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

Я не лазил внутрь винды давно, но HWND вроде был интом?

не знаю. если вы о с апи, то без него ведь на с программы под винды писать не получилось бы.

Потому и не юзаю glib.

ну я полагаю, что те, кто юзает, делает это не назло кондуктору

А про ГУИ я уже писал - это та точка, где ООП необходим, однако и это является проблемой дизайна, а не программиста.

учитывая, что там ооп у всех, это скорее является особенностью прикладной области, а не проблемой

нет конечно. он несколько менее компактен, но он всегда однозначно идентифицирует действие и типы аргументов. А переопределяя операторы вы всегда придете к проблеме yo-yo.

специально для вас имеется в наличии std::string::append, все остальные могут использовать более интуитивный +

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

в таком случае, с++, как язык с мощными средствами для создания библиотек, является ярким примером unix way.
однако, непонятно, как более сложный синтаксис с++ делает его менее приспособленным для unix way. как раз наоборот, больше стимул сделать одну библиотеку вместо тысячи по своему кривых парсеров на коленке.
вы можете взять другой парсер, или в конце концов сделать самую правильную библиотеку

Unix базы делаются не на пайпах а на сокетах (в т.ч. и локальных) и shared memory.

и что, в эти сокеты вставляются grep, sort и т.п. ?

Встречный вопрос, вы много видели объектно-ориентированных баз данных? Вы вообще их видели?

я всего видел две базы данных. mysql написан на с++, postgresql сам себя называет object-relational dbms.

Если проект крупный - то он использует базу данных. Если он объектный - то очевидно объектную.

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

Представьте себе автоматический генератор кода по спецификации на SKI-комбинаторах. Я думаю при появлении такой вещи половина программистов мира уйдут искать работу.

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

И это только часть айсберга, потому что достаточность лямбда исчисления и комбинаторного исчисления для описания мира, в отличие от ООП является математическим фактом. Мир вокруг не объектный - он функциональный. Вас кто-то обманул.

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

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

не правильный ответ. массив то у вас общий все равно, вот и ставьте ifdef вокруг его элементов

дайте поиск по слову glibc+Darwin или glibc+Irix или еще что-то.

This project is a stab at providing a port of the GNU c library (glibc) to Apple's new Darwin platform, the nix-based platform for OS X. релизов нет. про irix вообще непонятно, я полагаю, что у них есть эмуляция linux, как в freebsd. и к чему это все ? glibc содержит код для полутора систем как и раньше.

так я не понял, там своя реализация гамма-функции или нет? : -)

я не совсем понимаю, чего вы добиваетесь. в стандарт с++ она вообще не входит. в tr1 появились lgamma и tgamma. стандарт не определяет, своя должна быть реализация или нет. в gcc 4.1 их еще нет, в svn реализации выглядят примерно так:
using ::lgamma;
...
inline float
lgamma(float __x)
{ return __builtin_lgammaf(__x); }

inline long double
lgamma(long double __x)
{ return __builtin_lgammal(__x); }

По ссылке на boost видно что я был прав. Там огромный список портов, включающих в себя такие сверхважные для человечества платформы (!) как Borland C++ и Kylix. : -) Это действительно круто.

видно совсем наоборот. это список того, что поддерживает тарболл, который вы скачаете. в список входят все системы, поддерживаемые glibc

Кроме линукса и Hurd glibc ставится на кучу систем. Обычно это непрактично, но фанаты найдутся.

фанаты могут делать что им нравится. glibc поддерживает полторы системы и один компилятор. boost поддерживает все то же самое плюс много больше.

По поводу того, что библиотека C++ более портируема чем Portable Operating System Interface (POSIX) которого придерживается даже винда я тоже не хочу спорить.

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

Пока что boost портируется не под платформы - под компиляторы!

т.е. msvc, sunpro и tru64cxx - это все компиляторы под linux или hurd ?

[Ull9]

если программа не поймает. совсем необязательно его ловить вам и совсем необязательно в каждой строчке.

если я непоймаю какой-либо эксепшн, это означает что он вылетит наружу. А я обязан выбрасывать только мои эксепшны. любой другой эксепшн я должен преобразовывать в свой. вышестоящий модуль может ловить ТОЛьКО нои эксепшны.
Возникает, непойманный эксепшн. дальше креш. Приехали.

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

Вот тот умник, который бросал string, он рассуждал ТОЧНО ТАК ЖЕ КАК ТЫ.
Он говорил, примерно так: Ну я же нигде неписал throw (). Т.е как бы он задокументировал в коде, что бросаю любые обьекты. Так что же вы хотите?
Пишите catch (...)... Вы с ним случаем не в одной школе учились?

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

Я ушодил из того что данный код написан на С, Из этого сделал вывод, исключения бросать ненадо. Т.к вполне вероятно что вызывающий код написан не на с++.
Пример дурной.

не работать с исключениями не получится, если пользоваться стандартным с++

Вполне получится, пишите например new (std::nothrow).

а зачем мне это ? у меня ресурсы не текут и объекты в неработоспособном состоянии не остаются. или вы видите что-то, чего не вижу я ?

Да но бросая, эксепшн непредупредив, бы лонаете мои ресурсы, мой код становится в неработоспособном состоянии.
И не надо мне говорить, что ненаписав throw(), ты меня предупредил.
из-за такого умника, который меня так "предупредил", код имел уродливый
catch(...). И главное он так и непонял, почему его уволили. все бубнил, что
раз ненаписано throw(), it means alles ok.