Novell подружит KDE и GNOME

> И насколько он прижился в Гноме? Или Гном разрабатывают приверженцы С89 ?

Самое смешное, что в гноме действительно приверженцы старого стандарта. Потому как им важно, чтобы гном собирался старыми (2.9) версиями gcc. Поэтому все С99-измы рапортуются как баги и фиксятся. А уж вводить inline внутри всяких ifdef точно народ ленится:)

> А какие проблемы с потоками, если не секрет?

Попробуйте померять скорость операции cout<<. И сравнить с printf. Будет просто жуть. Есть некая опция (сорри, точно не помню какая - но для меня неочевидная, связанная с работой с буферами), которая резко ускоряет механику.

Точно sizeof bool 1? А как же с производительностью быть? На некоторых архитектурах работа с int дешевле, чем с char...

Во! Нашел в архивах. Для ускорения нужно было сделать так:

cout.sync_with_stdio(false);

Подробности тут: http://www.linux.org.ru/profile/svu/view-message.jsp?msgid=429328

Еще раз проверил. Вывел 100000 раз "Hello world" на stdout. Результаты тестирования:

sligo% time ./c_test > /dev/null

real 0m0.052s user 0m0.040s sys 0m0.010s sligo% time ./cpp_test > /dev/null

real 0m0.833s user 0m0.780s sys 0m0.010s sligo% time ./cpp2_test > /dev/null

real 0m0.062s user 0m0.040s sys 0m0.020s

c_test - это просто printf. cpp_test - это просто "cout <<". cpp2_test - то же, что сpp_test, только с cout.sync_with_stdio(false). Проги компилились и запускались на сановской машинке, обычным gcc(g++) безо всякой оптимизации.

Чорт, форматирование уехало

sligo% time ./c_test > /dev/null 

real    0m0.052s
user    0m0.040s
sys     0m0.010s
sligo% time ./cpp_test > /dev/null 

real    0m0.833s
user    0m0.780s
sys     0m0.010s
sligo% time ./cpp2_test > /dev/null 

real    0m0.062s
user    0m0.040s
sys     0m0.020s

>Самое смешное, что в гноме действительно приверженцы старого стандарта. Потому как им важно, чтобы гном собирался старыми (2.9) версиями gcc. Поэтому все С99-измы рапортуются как баги и фиксятся. А уж вводить inline внутри всяких ifdef точно народ ленится:)

inline на 2.95 компилируется. Только что проверил.
Так что пора потихоньку макросы на свалку двигать...

>Точно sizeof bool 1? А как же с производительностью быть? На некоторых архитектурах работа с int дешевле, чем с char...

Да, конечно. Не знаю, что и думать...

------------------------ 1.c
#include <stdbool.h>

int main()
{
printf("%d\n", sizeof(bool)); // выводит 4
return 0;
}

------------------------ 1.cpp
int main()
{
printf("%d\n", sizeof(bool)); // выводит 1
return 0;
}

gcc 2.95

> inline на 2.95 компилируется. Только что проверил.

> Так что пора потихоньку макросы на свалку двигать...

Ну, я упростил. Ведь есть же еще сановские компайлеры и пр. - короче, народ пока стремается. А может, инерция мышления. Не знаю. Во всяком случае, на int a = b посреди сишного текста они ругались. И даже на комментарии в стиле //.

C bool действительно как-то нехорошо получилось. Даже не знаю, кто тут больше уроды - то ли С++ с неэффективным типом, то ли С, который не посмотрел на то, что уже есть в С++. Хотя, если принимать, что С не должен оглядываться на С++ (типа, я тут это проповедовал:), тогда С++ всегда больше уроды:)

>Еще раз проверил. Вывел 100000 раз "Hello world" на stdout. Результаты тестирования:

И не лень было?) Ладно, дурной пример заразителен.
У меня повторяемость плохая, поэтому привожу лучшие результаты.
1000000 раз.

CPP:
real 0m0.300s
user 0m0.290s
sys 0m0.000s

С: (printf)
real 0m0.312s
user 0m0.310s
sys 0m0.000s

C: (puts)
real 0m0.282s
user 0m0.280s
sys 0m0.000s

Если не сложно, можно код в студию? Если ломает давать все - хотя бы плюсовый. А также инфу о платформе, компиляторе, опциях компиляции.

>Для ускорения нужно было сделать так:
>cout.sync_with_stdio(false);
Как следует из названия, тормоза в C++ потоках связаны с необходимостью синхронизоваться с функциями из stdio.h (которая по умолчанию включена).
Т.е. проблема в обратной совместимости. Если ее выключить, то все со скоростью нормально. Может быть со временем и выключат по умолчанию (в ответ на принятие стандарта C99 ;))
Интересно, а если заставить библиотеку <stdio.h> синхронизоваться с <iostream>, что будет с тормозами в сишном I/O ? ;))

> Если ее выключить, то все со скоростью нормально

Да. У меня на тесте получилось только чуть-чуть медленнее, чем на С.

> Интересно, а если заставить библиотеку <stdio.h> синхронизоваться с <iostream>, что будет с тормозами в сишном I/O ? ;))

Значит так. Тут даже не ситуация курицы и яйца. С первичен.

Я, вообще, не очень беспокоюсь за производительность плюсов в этом месте - все-таки всегда есть возможность сделать printf. Меня только озадачило, что одна функция (которая совсем не широко известна) столь драматически влияет на производительность.

>Если не сложно, можно код в студию? Если ломает давать все - хотя бы плюсовый. А также инфу о платформе, компиляторе, опциях компиляции.

Код как код...
Компиляция с опциями по умолчанию. gcc 2.95.

int main()
{
const char* HELLO = "Hello World";

int i;
for(i=0; i<1000000; i++)
puts(HELLO);
return 0;
}


#include <iostream>

int main()
{
const char* HelloWorld = "Hello World";

for(int i=0; i<1000000; i++)
std::cout << HelloWorld;

return 0;
}

>Меня только озадачило, что одна функция (которая совсем не широко >известна) столь драматически влияет на производительность.
Причина влияния понятна. С другой стороны выставлять по умолчанию
cout.sync_with_stdio(false);
нельзя, так как смешанное использовании C и C++ I/O может привести к некорректному результату. А это гораздо хуже, чем гипотетические "тормоза", которых никто не заметит в 99 случаях из 100. А кто заметит и использует <iostream> тот наверняка знает о cout.sync_with_stdio();

У меня тоже все было просто. Даже еще проще. 

#include <stdio.h>

int main()
{
  int i;
  for ( i=0;i<100000;i++ )
    printf( "Hello, world!\n" );
}
----------------------
#include <iostream>

using namespace std;

int main()
{
  int i;
  for ( i=0;i<100000;i++ )
    cout << "Hello, world!\n";
}
----------------------
#include <iostream>

using namespace std;

int main()
{
  int i;
  cout.sync_with_stdio(false);
  for ( i=0;i<100000;i++ )
    cout << "Hello, world!\n";
}

Компилятор gcc 3.3.2. Почему же столь разные соотношения результатов
 для C и C++ в Вашем и моем случае? Из-за поколения компиляторов - 
или из-за того, что я тестировал на спарке?...

> Вывел 100000 раз "Hello world" на stdout.

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

У меня тоже все было просто. Даже еще проще.

Ваши примеры на моей машине:

С:
real 0m0.040s
user 0m0.030s
sys 0m0.010s

CPP:
real 0m0.040s
user 0m0.040s
sys 0m0.000s

CPP2:
real 0m0.040s
user 0m0.030s
sys 0m0.010s

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

>Компилятор gcc 3.3.2. Почему же столь разные соотношения результатов
для C и C++ в Вашем и моем случае? Из-за поколения компиляторов -
или из-за того, что я тестировал на спарке?...

Для этого нужно найти кого-нибудь третьего, у кого есть спарк и gcc 2.95 или intel и gcc 3.3.2 :)

Довел до миллиона число повторений. Получилось так:

% time ./c_test > /dev/null 

real    0m0.463s
user    0m0.400s
sys     0m0.000s
sligo% time ./cpp_test > /dev/null 

real    0m13.533s
user    0m8.090s
sys     0m0.010s
sligo% time ./cpp2_test > /dev/null 

real    0m0.602s
user    0m0.440s
sys     0m0.010s

Справедливости ради должен сказать, что на некоторых прогонах cpp2
 бывает иногда чуть лучше, чем c, иногда чуть хуже. В среднем,
 примерно одинаково. Но вот cpp в любом случае страшно тормозит.
 Вечерком попробую на gcc 3.1 на интеле.

Все-таки пытаются привить inline в гноме. Вот из gutils.h:

#ifdef G_IMPLEMENT_INLINES
#  define G_INLINE_FUNC extern
#  undef  G_CAN_INLINE
#endif
#ifndef G_INLINE_FUNC
#  define G_CAN_INLINE 1
#endif
#if defined (G_HAVE_INLINE) && defined (__GNUC__) && defined (__STRICT_ANSI__)
#  undef inline
#  define inline __inline__
#elif !defined (G_HAVE_INLINE)
#  undef inline
#  if defined (G_HAVE___INLINE__)
#    define inline __inline__
#  elif defined (G_HAVE___INLINE)
#    define inline __inline
#  else /* !inline && !__inline__ && !__inline */
#    define inline  /* don't inline, then */
#    ifndef G_INLINE_FUNC
#      undef G_CAN_INLINE
#    endif
#  endif
#endif
#ifndef G_INLINE_FUNC
#  if defined (__GNUC__) && defined (__OPTIMIZE__)
#    define G_INLINE_FUNC extern inline
#  elif defined (G_CAN_INLINE) && !defined (__GNUC__)
#    define G_INLINE_FUNC static inline
#  else /* can't inline */
#    define G_INLINE_FUNC extern
#    undef G_CAN_INLINE
#  endif
#endif /* !G_INLINE_FUNC */
                                                                                          
Во как!:) Теперь всякий может пользовать макрос G_INLINE_FUNC к тому, что хочет заинлайнить. Только сколько народу его реально пользует - ... неизвестно.

Если по топику, то объединить KDE и Gnome может помочь общий язык программирования.
Естественно, ни С, ни С++, ни Java c Mono...
А такой, например, как http://www.digitalmars.com/d/index.html
Есть версия компилятора для Linux и frontend для GCC.
Что скажете?

Забавно (особенно - сравнительная таблица). Но язык - не архитектура (java, молчать!). Это все-таки разные вещи. Тут нужно архитектуры итегрировать - а это геморрой страшный. И требует компромиссов. А тут уже начинается политика, маркетинг и пр...

Для интеграции архитектур ни С, ни С++ не подходят. Это как вывод из всего топика.
И в том и в другом есть свои недостатки. А бороться надо коренным образом: нужно использовать нейтральный язык.
На D перенести C/C++ проекты в принципе возможно. Поделить работу между Gnome/KDE разработчиками пополам и потихоньку начинать писать. Для начала подкинуть идею на freedesktop ;)

Мне только не понятно, зачем они в D добавили вложенные функции?

P/S В С# MS не исправила всех ошибок С++, поэтому D в этом плане дает некоторое преимущество.

> Мне только не понятно, зачем они в D добавили вложенные функции?

Видимо D вдохновлялся не столько C{++,#,...}, сколько Алголом или может Паскалем (по крайней мере про модули и вложенные функции видимо оттуда). А вложенные функции очень удобная вещь, когда нужно сделать функцию, которая используется в единственной другой функции и общемодульная область видимости ей просто вредна.

В Паскале очень удобно использовать было: каждая процедура/функция эквивалентна целому модулю. В общем настолько же полезно, как и объявление переменных в блоке.