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

> Это очень интересно. А где про это можно почитать? И как оно удалось? Или все-таки "смайлик"?:)

Да, интересно. Раза так в 2-4 ;)

3-ий раздел.

http://www.research.att.com/~bs/new_learning.pdf

>В смысле отношения к примитивным типам - да. Есть и другие стороны, мы о них не будем. Правда, жаба 1.5 приблизила простые типы к классам - поэтому в этом аспекте догнала С++:)

В любом случае, наличие/отсутствие простых типов в языке не определяет его объектную ориентированность.
Будем это считать "деталями реализации".

> Да, интересно. Раза так в 2-4 ;)

Да, сначала я даже в ступор попал. Потом дядечка все-таки объяснил, что С++ инлайнит операцию сравнения - тогда я уже поверил и простил. Это означает, что при сложных (читай - не поддающихся инлайнизации) операциях сравнения все-таки плюсы "прийдут в себя" и сравняются с С (а вдруг, не дай Бог, станут медленнее?:)

> В любом случае, наличие/отсутствие простых типов в языке не определяет его объектную ориентированность.

> Будем это считать "деталями реализации".

Скажем так, ООсть языка - не булевская функция, у нее много граней (что демонстрируют и плюсы, и жабка). И можно пытаться (осторожно) сравнивать языки по той мере ОО, которая в них есть. Так вот наличие примитивных типов снижает эту оценку, и здОрово. Потому как переменная простого типа не является объектом. Ее нельзя спросить про список доступных методов (рефлексия). Примитивный тип нельзя насширить. Его нельзя использовать в коллекциях, где работают объекты (для справки: все коллекции в стандартной жабке работают с объектами, примитивные типы запихать в хэш или вектор нельзя - или берите библиотеки сторонних производителей). Так что примитивные типы - зло с точки зрения ОО, единственное оправдание которому - производительность.

>Брукса ("MMM") читали? Там есть замечательные строки про вторую систему...:)
Нет. Вторую систему чего?

> А как сейчас - оно лучше?
После С99 вряд ли. Что самое обидное, там различия минимальные, но для совместимости это критично.
Представьте, меняете расширение файла на "CPP", компилируете тем же компилятором (gcc), все прекрасно компилится. Но! Результат уже другой. При этом ошибку найти в таком коде - это надо работать в комитете не один год.


> Вот оно, наследование по С++: сделать производный класс зависящим от базового!:))) Я думаю, разработчики С99 пытались реально решить те проблемы, которые возникают в С при НЕИСПОЛЬЗОВАНИИ С++ (и без ОО на уровне языка). А С++ решает эти же проблемы при помощи ОО. То решение, которое предлагаете Вы, отводит мощному языку ВЫСОКОГО УРОВНЯ роль какого-то ассемблера для С++. Т.е. если программисту на С не хватает чего-то, ему говорят: "Смотри, в С++ это делается так просто ..." и все. Это бы означало смерть С как самостоятельного языка. Я думаю, есть смысл в том, чтобы С развивался и рос без оглядки на С++. А вот С++, единожды задекларированный как производный от С, действительно должен смотреть, куда дует ветер С. Или просто однажды честно сказать: "Да пошел этот С с его развитием!.. Вот я буду совместим со стандартом 10-летней давности, а дальше буду делать, как мне кажется удобным, логичным, ..."

Послать-то можно. Тем более сейчас, когда у С++ огромная поддержка в мире. Но вдруг получится объединить?
Тем более есть люди, которого этого хотят даже в С-комитете.

А вообще С++ стал популярным именно благодаря совместимости с С. И совместимость всегда была на первом месте у Страуструпа.
Технически язык можно было сделать и лучше и проще без требований совместимости с С.
Но вряд ли бы он стал таким популярным, потому что:
- компиляторы пришлось бы писать самим;
- старый код было бы труднее "перевести на новые рельсы".
- много еще чего.

Кстати, когда руководство Bell Labs решило внедрять С++ повсеместно, то они потребовали 100%-ной совместимости с С.
Пришлось долго объяснять им, что тот же "class" мог где-то в С быть именем переменной и никаких 100% быть не может по определению.

> Нет. Вторую систему чего?

Очень рекомендую Брукса, Mythical Man-Month. В философическом, вневременнОм смысле мудрый мужик. Вторая система, для Брукса - сосредоточение всех "работ над ошибками дизайна" в первой системе, когда нужно не ошибки исправлять, а делать концептуально новые веши. Впрочем, в двух словах этого не расскажешь. Почитайте - оно того стОит.

> > А как сейчас - оно лучше?

> После С99 вряд ли.

Вот я и о том же:)

> > Послать-то можно. Тем более сейчас, когда у С++ огромная поддержка в мире. Но вдруг получится объединить?

А может, не надо в одну повозку коня и трепетную лань? Тем более, как Вы говорите, С++ уже прочно стоИт на собственных ногах (программистах).

> Тем более есть люди, которого этого хотят даже в С-комитете.

Не уверен, что это в интересах С. Очень не уверен. В интересах С++ - однозначно.

> И совместимость всегда была на первом месте у Страуструпа.

И никогда не была полной, при этом. Парадокс!:)

> Но вряд ли бы он стал таким популярным, потому что:

Это все понятно, это оставим историкам (которые еще долго будут выяснять, стОило ли отдавать понятность, простоту языка и защищенность его пользователей в жертву совместимости). Но сегодня, может, стОит признать очевидное - грааль совместимости с С недостижим. Может, тогда отдать приоритет более реальным целям - например, сделать язык более простым и менее опасным для начинающих?

Кстати, мы таки вошли в топ10, поздравляю. Теперь по архивам искать не надо:)

> Да, сначала я даже в ступор попал. Потом дядечка все-таки объяснил, что С++ инлайнит операцию сравнения - тогда я уже поверил и простил. Это означает, что при сложных (читай - не поддающихся инлайнизации) операциях сравнения все-таки плюсы "прийдут в себя" и сравняются с С (а вдруг, не дай Бог, станут медленнее?:)

Думайте так, если Вам это приятнее) Но пример показывает, какие соки можно выжать от встраивания в С++ при умелом обращении.

> Так что примитивные типы - зло с точки зрения ОО, единственное оправдание которому - производительность.

Именно поэтому ОО не должно быть панацеей. А в целом, я согласен.

> Но пример показывает, какие соки можно выжать от встраивания в С++ при умелом обращении.

М-да. Т.е. реально соки сводятся совсем не к могучему ОО, а к тому, что в язык введено понятие inline без сопроцессора (точнее, сопроцессор С++ прикидывается компилятором:). Да, согласен, inline - могучее средство, а использование дурного cpp для этих целей изрядно хромает и дает больше проблем, чем решений. Однозначно. Только вопрос об относительной производительности всегда будет неполным, если не впомнить о потоках в С++ (народ тут делал бенчи - без спец. ухищрений результаты просто кошмарррные, с ухищрениями - вроде, не столь плохи, но тоже не сахар). Да и вообще, скорость плюсов меня мало колышат. Я охотно верю, что при аккуратном использовании они догоняют (а засчет инлайна могут даже перегонять) С. Только вспомните, что в C99 введен inline (а в gcc он был задолго до этого) - так что г-ну Страуструпу хорошо бы обновить бенчмарки:)

> А может, не надо в одну повозку коня и трепетную лань? Тем более, как Вы говорите, С++ уже прочно стоИт на собственных ногах (программистах).
> Не уверен, что это в интересах С. Очень не уверен. В интересах С++ - однозначно.

Разве в "С" не нужны inline-функции? И единный bool-тип, а не уродское __bool ?
Так что это прежде всего в интересах пользователей.

> И никогда не была полной, при этом. Парадокс!:)

Да. Но пользователи от такой неполной совместимости не страдали. Пока это касалось только производителей компиляторов.
Пока.
Впрочем, не все стандарты принимаются обществом. И при таком развороте событий пользователи могут отказаться от нововведений в С, если они будут сильно противоречить со стандартом С++.
Но это только время покажет. А пока я немного видел программ с __bool типом...

> Но сегодня, может, стОит признать очевидное - грааль совместимости с С недостижим. Может, тогда отдать приоритет более реальным целям - например, сделать язык более простым и менее опасным для начинающих?

Вряд ли этого можно ожидать от С++.
Разве что от какого-нибудь ++++С...

>Кстати, мы таки вошли в топ10, поздравляю. Теперь по архивам искать не надо:)

Да, это радует. "Воскресили из мертвых"...)

> Разве в "С" не нужны inline-функции? И единный bool-тип, а не уродское __bool ? > Так что это прежде всего в интересах пользователей.

Инлайн - уже есть. Про bool вопрос вообще тонкий. Одно дело - использование его в памяти, тогда для эффективности его бывает проще считать за int. Другое - складывание в файл. Тогда он вообще usigned char (если не bit:) Так что тут не все однозначно.

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

Жисть - она, конечно, все покажет:)

> Вряд ли этого можно ожидать от С++.

> Разве что от какого-нибудь ++++С...

Жаль, а могли бы выпрямить язык. Только я бы назвал его "С*=" :)))

>Только вопрос об относительной производительности всегда будет неполным, если не впомнить о потоках в С++ (народ тут делал бенчи - без спец. ухищрений результаты просто кошмарррные, с ухищрениями - вроде, не столь плохи, но тоже не сахар).

А как с этим у С?
Что касается С++, то мне асинхронных методов в Qt с головой хватает. И в 99% случаев вполне можно обойтись без потоков.

>Да и вообще, скорость плюсов меня мало колышат.

Какие тут могут быть аргументы? Мне нечего возразить.

>Только вспомните, что в C99 введен inline (а в gcc он был задолго до этого) - так что г-ну Страуструпу хорошо бы обновить бенчмарки:)

Разве? Чего-то я пропустил...

>И единный bool-тип, а не уродское __bool ?

Исправляюсь:

правильно: _Bool. Что, впрочем, не меняет суть.

>Только вспомните, что в C99 введен inline (а в gcc он был задолго до этого) - так что г-ну Страуструпу хорошо бы обновить бенчмарки:)

Да, нашел. Вопрос снимается.

Урря! Не настолько уж С хуже плюсов - inline добавили!:)

А про потоки - все-таки оно очень медленно, если не мудрить, а как в "Hello World":)

Кстати, запамятовал, а в плюсах sizeof bool = ?

>Урря! Не настолько уж С хуже плюсов - inline добавили!:)

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

>А про потоки - все-таки оно очень медленно, если не мудрить, а как в "Hello World":)

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

>Кстати, запамятовал, а в плюсах sizeof bool = ?
1.

Кстати, есть и bool (http://www.comeaucomputing.com/techtalk/c99/#bool). Только надо stdbool.h подключить (а без него только _Bool). Но если это часть стандартной библиотеки - я думаю, беда не очень велика:)

А в плюсах, вроде, он тоже sizeof int?

> И насколько он прижился в Гноме? Или Гном разрабатывают приверженцы С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

>Все-таки в полностью ОО языке все должно быть объектом.

Кстати, Страуструп хотел разрешить наследование от int, и т.п.
А потом подумал: "А чего там можно наследовать? Методов-то ведь никаких и нет-то!"
А эта идея в .NET вроде реализована?
Как оно? Переопределить для int operator+() и ... :)

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

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

> Кстати, Страуструп хотел разрешить наследование от int, и т.п.

Ну, это он, может, и сгоряча. Кстати, в жабке класс Integer все-таки final - т.е. от него нельзя наследовать. Но работает рефлексия, можно использовать в Collections и generics etc etc.

> Переопределить для int operator+() и ... :)

Ну ведь не для int же, а для IntPlusPlus extends int:)

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

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

> Интересно, а если заставить библиотеку <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();

>Ну, это он, может, и сгоряча. Кстати, в жабке класс Integer все-таки final - т.е. от него нельзя наследовать. Но работает рефлексия, можно использовать в Collections и generics etc etc.

Но в Java же и int есть? Так вот я про него. Чтоб без всяких костылей вроде Integer.

>Ну ведь не для int же, а для IntPlusPlus extends int:)

Конечно.

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

#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++ в Вашем и моем случае? Из-за поколения компиляторов - 
или из-за того, что я тестировал на спарке?...

Скажите, а как Страуструс собирался наследовать от инта без автобоксинга? Как в это случае он представлял себе RTTI?

> Вывел 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 :)

>Скажите, а как Страуструс собирался наследовать от инта без автобоксинга? Как в это случае он представлял себе RTTI?

Да не собирался он. Так, подумал только)
А что может дать языку возможность наследования от простых типов?
Надо ли это? Или это тот абсолютизм, который граничит с маразмом?

По поводу RTTI и виртуальных функций для простых типов.
Вряд ли они будут в таком случае "простыми". Это будет язык, в котором sizeof(char) будет 5 (а то и 8)...
Абсурд. В языке должны быть простые типы.

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

% 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 на интеле.

> Абсурд. В языке должны быть простые типы.

Да, наверное. Именно в этом сила автобоксинга - хотите, получите быстроту простых типов, хотите - всю мощь ОО. Только garbage collector жалко в этой ситуации:)

Все-таки пытаются привить 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{++,#,...}, сколько Алголом или может Паскалем (по крайней мере про модули и вложенные функции видимо оттуда). А вложенные функции очень удобная вещь, когда нужно сделать функцию, которая используется в единственной другой функции и общемодульная область видимости ей просто вредна.

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