» Какой выбрать язык програмирования?

Xarde

Цитата:

Кстати, жаба по определению не может работать быстрее кода, написанного на С++. Дело в том, что жаба интерпретируется и уже потом выполняется, а код С++ просто выполняется. Другое дело, если код написан неоптимально.

Не корректное замечание. В Java уже давно идет Jit-компиляция. (Она, кстати и в .NET тоже есть) Преимущество Jit-компилятора в том, что он в процессе компиляции может заточить программу под _конкретную_ машину, прописать ей все как надо, сгенерировать код под _конкретный_ процессор, а не под виртуальный i386. Другое дело, что используется ленивая модель компиляции, то есть, функция компилируется только тогда, когда она нужна в первый раз.
Другое дело, что в отличие от .NET, насколько я знаю, Java каждый раз при загрузке распаковывает и компилирует все используемые ей библиотеки (XDiaBLo поправь, если я не прав). Это сильно сказывается на процессе загрузки. Кроме того, в силу сугубо объектного подхода Java тяжело работать с графикой. Пришлось там изобретать спец. надстройки для нормальной работы.
Ну и в который уж раз повторюсь, что Java - надстройка над всеми ОС, а другие решения (в т.ч. и С++) работают непосредственно с ядром самих ОС без использования врапперов.

XDiaBLo

Цитата:

А платформа .NET требуется для С++ приложений написанных в VS 2005 только если использовать классы из .NET платформы?

Да.

Цитата:

Не корректное замечание. В Java уже давно идет Jit-компиляция.

Цитата:

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

Прекрасно, но почему использование Jit-компиляции в процессе выполнения должно дать ускорение по сравнению с уже откомпилированным кодом? Хотя, насчёт интерпретации я всё-таки немного лажанулся. Надо было попонятнее написать, чтобы вопросов-поправок не возникало.

Добавлено:

Цитата:

Хмм, почитайте ещё на эту тему. Джава и С++ давно уже дают мало разницы по скорости в своих программах

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

Цитата:

А в сторону Билдера я смотреть не хочу, эти Бормановские поделки мне не по вкусу.

Каждому своё. Просто мне тут пришлось с билдера пересаживаться на вижуал. Есть опыт расширения словарного запаса. ) Хотя, в конце концов, особой разницы, в какой среде писать нет - писать можно в любой, лишь бы нравилась.
И ежели тебя свежак не пугает, то это больше от незнания. Бояться, конечно, не стоит. Только и рассчитывать на скорое освоение среды - тоже. То "множесто вещей", что ты видел, вероятно, было структурой классов .NET. Там-то всё довольно удобно (знакомился на шарпе, но на С++ не должно быть особых отличий... вроде бы... ), а вот чистый Win32...

Цитата:

Прекрасно, но почему использование Jit-компиляции в процессе выполнения должно дать ускорение по сравнению с уже откомпилированным кодом?

Видимо я не совсем понятно написал.
Потому что когда проект на С++ компилируется, в него закладываются данные об обобщенном процессоре, даже если компилировать устанавливая опцию какую нибудь.
А Jit компилятор подстраивает все под текущий процессор, учитывая, целерон ли это или атлон какой-нить, под текущее окружение, в т.ч. объем оперативной памяти, под количество процессоров (не просто multithread, а под 4, или там, 8). Ну и т.д.
Есессно, это все чисто теоретически. Я реальных цифирок не имею на руках.

Цитата:

Далее, насчёт сборщика мусора. Всё сильно зависит от того, что за приложение пишется. Поверь мне, я видел собственными глазами код, который написан на жабе. Написан неплохо (хотя и можно улучшить, как обычно). И вот этот самый код зачастую тормозится сборщиком мусора. А всё из-за того, что приходится манипулировать большим числом объектов. Оптимизировать код можно, но от мусорщика всё равно не отделаешься.

По Java ничего не скажу - практически с ней не работал, но усиленно работаю с C#. Так вот. Сборщик мусора - полезнейшее явление природы. Надо только уметь им пользоваться. Естественно, стиль программирования меняется при пересадке с C++ на C#. Надо много учитывать. Все-таки платформы разные.

Xarde

Цитата:

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

Я как раз на C# и писал, программу которая с FTP-протоколом работает, графических приложений в .NET не писал, но немножко глянул, вроде не испугался :) Причём до написания той программы я абсолютно не был знаком ни с C#, ни с протоколом FTP. написал за один день, и на следующий день вечером пару багов отловил. Всё. Абсолютно не пришлось долго всё изучать :) Я конечно использовал найденную в инете библиотечку, по работе с фтп, но и в ней я часть кода переписал, не поддерживались русские названия папок, в больших директориях видел неполный список файлов, и пару фич ещё добавить пришлось. В общем работы хватало. Кстати, всё забываю автору библиотечки список багов выслать... Небось уже кто-то это сделал.


Цитата:

Написан неплохо (хотя и можно улучшить, как обычно). И вот этот самый код зачастую тормозится сборщиком мусора. А всё из-за того, что приходится манипулировать большим числом объектов.

Насчёт этого... Читал я про принципы работы С++ного менеджера памяти... Ужас... А вы говорите сборщик мусора... Хватит уже к нему придираться

Добавлено:
Хм, ну не про С++ там, а про С, ну я думаю и в С++ та же история.

http://russian.joelonsoftware.com/Articles/BacktoBasics.html

Цитата:

Это отдельная песня: управление памятью. Вы знаете, как работает malloc? malloc поддерживает связный список свободных блоков памяти. Когда вы вызываете malloc, он проходит по списку в поисках блока достаточной длины. Найдя таковой, malloc разбивает его на две части (одна запрошенного размера, другая -- что осталось), кладёт остаток обратно в список свободных блоков, и возвращает указатель на блок запрошенного размера. Когда вы вызываете free, он просто добавляет освобождаемый блок в список свободных. Через какое-то время оказывается, что все свободные блоки маленькие, а нужен кусок побольше. Соответственно malloc объявляет перерыв и начинает перетряхивать список свободных блоков, сливая соседние маленькие блоки воедино, на что уходит три с половиной дня. В результате в среднем производительность malloc оказывается так себе (ему приходится постоянно ходить по цепочке свободных блоков), и иногда, внезапно, становится совсем никакой (когда приходится заниматься дефрагментацией). (Кстати, точно так же ведут себя и системы со сбором мусора, кто б мог подумать, так что заявления, которые часто можно услышать про неэффективность сборки мусора не совсем верны, ибо типичная реализация malloc обладает теми же самыми проблемами, хотя и в меньшей степени.)

XDiaBLo

Цитата:

Причём до написания той программы я абсолютно не был знаком ни с C#, ни с протоколом FTP. написал за один день, и на следующий день вечером пару багов отловил.

У меня та же задача на Питоне при полном незнании такового заняла 2 часа. Вот кто рулит! :-)

Цитата:

Насчёт этого... Читал я про принципы работы С++ного менеджера памяти... Ужас... А вы говорите сборщик мусора... Хватит уже к нему придираться

А что тебе мешает написать кошерный распределитель? Последним необязательным параметром каждого контейнера идет распределитель памяти, вот и подставь. Разумеется, можно переопределить operator new().

С++ дает тебе возможности, но не определяет политику. Хочешь использовать стандартный распределитель --- пожалуйста! Не хочешь --- пиши свой. Кстати, в книге "Искусство программирования на C++" Шилдта есть распределитель со сборщиком мусора.

Но в жабе у тебя нет иного пути! Ты обязан использовать сборщик мусора, надо оно тебе или нет.

TheChampion
Про Питон наслышан, надо будет глянуть, я пока заинтересовался boost и STL, немножко отложу жабу и UML... Хм, и когда всё успеть?

TheChampion

Цитата:

У меня та же задача на Питоне при полном незнании такового заняла 2 часа. Вот кто рулит!

Может тут дело не в языке а в библиотеках? Думаю, что перл примерно то же в те же сроки сделает...
Да и вааще, наверно есть и для С++ библиотеки, позволяющие делать все то же самое.

Цитата:

А что тебе мешает написать кошерный распределитель? Последним необязательным параметром каждого контейнера идет распределитель памяти, вот и подставь. Разумеется, можно переопределить operator new().

Вот смотри, для того чтобы написать "кошерный" распределитель памяти надо:
1. Перелопатить гору литературы.
2. Определить как это все должно распределяться.
3. Посчитать количество классов у себя в проекте, у которых надо переопределять оператор new.
4. Расстроиться.
5. Долго и упорно переопределять этот оператор для нужных классов.
6. Обнаружить, что с массивами этот номер в принципе не проходит.
7. Расстроиться и забить на все.
8. Оставаться в радостном ощущении, что до сих пор НИ ОДИН человек не написал универсальный распределитель памяти для С++ за всю его (С++) 25 летнюю историю. По крайней мере, даже коммерческой библиотеки так и нет.

Mickey_from_nsk
Однако же :) На своём опыте всё прошёл? Мдаа... Неужели всё так плохо?

XDiaBLo
Было дело... В принципе потом нашел один извратный способ сделать более или менее универсальный распределитель, но там получилась куча нетривиальных требований на классы типа обязательного указания собственного размера и т.д. К тому же массивы так и не подчинились.
Пришел к выводу, что для большинства задач пойдет и обычный распределитель, а для классов, объекты которых часто и быстро выделяются и освобождаются не вломы написать спец. распределитель.
Кроме того, в С++ есть шикарная штука - стек. Процентах в 70 у меня объекты живут на стеке, а не в куче. Масса проблем снимается сразу.

Mickey_from_nsk

Цитата:

1. Перелопатить гору литературы.
2. Определить как это все должно распределяться.

Д. Э. К., Искусство программирования для ЭВМ, т. 3.

Цитата:

3. Посчитать количество классов у себя в проекте, у которых надо переопределять оператор new.
4. Расстроиться.
5. Долго и упорно переопределять этот оператор для нужных классов.

С. Майерс, Эффективное использование C++, Еще более эффективное использование C++, совет где-то 10. :-)

Цитата:

6. Обнаружить, что с массивами этот номер в принципе не проходит.

operator new[]() еще никто не отменял. У того же Шилдта в примере все распределяется :-) Проверял!

Цитата:

7. Расстроиться и забить на все.

Забить на книги серии "Ботва для чайников", "Complete idiot's guide on Botva", "Самоучитель игры на C++ за 21 день" и. т. д., читать классиков.

Цитата:

8. Оставаться в радостном ощущении, что до сих пор НИ ОДИН человек не написал универсальный распределитель памяти для С++ за всю его (С++) 25 летнюю историю. По крайней мере, даже коммерческой библиотеки так и нет.

"Серебряной пули нет", Ф. Брукс, Мифический человекомесяц.
Судя по сообщениям Xarde, в жабе тоже счастья нет.

C++, как и C, --- это unix-way. Он дает средства, но не определяет политику. Ты делаешь то, что нужно и настраиваешь так, как хочешь. Жаба --- это windows-way. Он мусорщика ты в принципе не избавишься. И не перепишешь его. Никак.

PS: Питон --- это unix-way! Сборщик мусора можно отключить. :-)

TheChampion
А ты пробовал это все проделать?
Кнут - оно конечно хорошо. Стратегий выделения памяти - воз и маленькая тележка, но вот применить это все дело к С++ - уже тяжелее.


Цитата:

С. Майерс, Эффективное использование C++, Еще более эффективное использование C++, совет где-то 10.

Видимо ты плохо читал пункты 3 и 4
Ведь операторы new надо переопределять для всех нужных классов. Универсального решения (как в случае с мусорщиком) нет. Не знаю как у тебя, у меня в небольших проектах количество классов может быть более 50.
Кроме того, для того, чтобы реализовать эффективное управление памятью, надо еще и правильно или унаследовать или ушаблонить каждый класс.

Цитата:

operator new[]() еще никто не отменял. У того же Шилдта в примере все распределяется Проверял!

Плюс еще один оператор для переопределения (вернее два) Проще через векторы работать.

Цитата:

C++, как и C, --- это unix-way. Он дает средства, но не определяет политику. Ты делаешь то, что нужно и настраиваешь так, как хочешь. Жаба --- это windows-way. Он мусорщика ты в принципе не избавишься. И не перепишешь его. Никак.

Чет мне не нравятся Unix-way vs Windows-way сравнения. Извини, но не корректно это. С++ есть и там и там, Java есть и там и там. При этом Java на UNIX работает лучше
А мне оно надо - от мусорщика избавляться. По тому как описана его работа в том же Рихтере - так пусть он себе трудится.
Да и вообще, в Microsoft есть подразделение, которое называется Microsoft Research. В нем явно не профаны трудятся, я думаю, они не плохо знают как должен работать мусорщик. Гораздо лучше всех здесь присутствующих. Оно реализовано. Алгоритм меня устраивает.
Чего еще нужно человеку "чтобы встретить старость"?
Еще раз повторюсь. При программировании на С# (и на Java, видимо, тоже) надо учитывать просто как работает этот сборщик. Поэтому, если надо освободить ресурс, лучше это сделать явно. Кстати, ИМХО, это и правильнее будет. Ну для другого эти языки делались. В них как раз и закладывалось отсутствие головогрения по поводу освобождения указателей.
Конечно, если играет внутре все, хочется собственную ОС забабахать - тогда Java не подойдет.

Mickey_from_nsk

Цитата:

А ты пробовал это все проделать?

Да. Ты же в курсе, что у нас не два operator new, а 4. :-)

Цитата:

При этом Java на UNIX работает лучше

Например? Диалог Open Window в виндах отображает верхний каталог в виде .., на Tru64 UNIX --- нет :-)

Цитата:

Извини, но не корректно это. С++ есть и там и там, Java есть и там и там.

Можешь ли ты на жабе делать все? Переопределять операторы, определять шаблоны, те же распределители памяти? Еще раз: C++ предоставляет средства, не определяя политику. Хочешь используй, хочешь нет. А насчет UNIX... Сколько строчек на жабе занимает вывод в консоль "здравствуй, мир"? :-)

PS: А в Питоне можно писать как в ОО-стиле, так и старом добром C++-стиле. Например:

Код: #! /usr/bin/python

print "Hello, World!"

TheChampion

Цитата:

Да. Ты же в курсе, что у нас не два operator new, а 4.

Ага, и даже в курсе, что delete тож переопределять надо.


Цитата:

Например? Диалог Open Window в виндах отображает верхний каталог в виде .., на Tru64 UNIX --- нет

Это ты про какой диалог? В каких виндах? В какой программе? Или ты про Java? Если да - я совершенно не в курсе.


Цитата:

Можешь ли ты на жабе делать все? Переопределять операторы, определять шаблоны, те же распределители памяти? Еще раз: C++ предоставляет средства, не определяя политику. Хочешь используй, хочешь нет.

В таком случае ассемблер еще круче . Еще раз, Java я не знаю. Немного изучал. То что изучал - понравилось. Сделано с т.з. архитектуры более закончено чем .NET, а уж тем более чем C++. Правда, иногда не хватает множественного наследования (в работе с C#).

Цитата:

А насчет UNIX... Сколько строчек на жабе занимает вывод в консоль "здравствуй, мир"?

Может посчитаем строчки для С++? А для Перла? А для SmallTalk? А для еще целой кучи языков?
Не та это прога чтобы строчки считать.
Вот давай может посчитаем строчки какого нибудь прикладного сервиса (только многопоточного и сетевого). На 100% Java и .NET будут в выигрыше.
Так мы какие программы то пишем?
Кстати, по крайней мере в С# и С++ количество строчек примерно одинаково.

Кстати,
Цитата:

PS: А в Питоне можно писать как в ОО-стиле, так и старом добром C++-стиле. Например:

#! /usr/bin/python

print "Hello, World!"

Не совсем С++, а скорее С стиль.

Mickey_from_nsk

Цитата:

В таком случае ассемблер еще круче

Меня терзают смутные сомнения, что я могу переопределять MOV и INT :-)


Цитата:

Может посчитаем строчки для С++?

Код: #include <iostream>

int main(void)
{
std::cout << "Hello, World!" << std::endl;
return 0;
}

Цитата:

Судя по сообщениям Xarde, в жабе тоже счастья нет.

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


Цитата:

Можешь ли ты на жабе делать все? Переопределять операторы, определять шаблоны

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


Цитата:

Правда, иногда не хватает множественного наследования (в работе с C#)

По идее, множественное наследование должно требоваться крайне редко. Если проектировка верная. В жабе пару раз сталкивался с ситуациями, когда хотелось унаследовать от двух объектов, но в конце концов разрулил за счёт интерфейсов. В шарпе явно та же ситуация.


Цитата:

Вот давай может посчитаем строчки какого нибудь прикладного сервиса (только многопоточного и сетевого). На 100% Java и .NET будут в выигрыше.

Не знаю, как насчёт количества строчек, но потоки в яве - это не самое приятное дело.

Лично мне шарп и ява понравились тем, что отказались от хэдеров. Меньше головной боли при большом количестве файлов. Ещё они мне понравились пакетированной структурой. Пространства имён в С++ - это совсем не то. Сборщик мусора расслабляет, но в принципе, мешает редко (когда есть гора объектов и хочется их удалить и нет возможности сделать это явно... ужас, какие слова извергаются из глоток ). В общем-то, успех явы и шарпа понять несложно - упрощённо, приятно, красиво. Всё-таки, новое поколение в развитии языков и платформ.

Xarde

Цитата:

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

"Так чем же она хороша?"

Цитата:

"Так чем же она хороша?"

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

Xarde

Цитата:

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

Например?

Цитата:

Меня терзают смутные сомнения, что я могу переопределять MOV и INT

Возьми макроассемблер

Цитата:

Итого 7 строчек включая пустые. Ваш ход, товарищ гроссмейстер. В Питоне 3 строчки.

Код:
using System;

namespace test
{
public class test
{
public static void Main(string [] argc)
{
Console.WriteLine("Hello, world");
}
}
}

Mickey_from_nsk

Цитата:

Займемся RegExами? Или базами данных?

Давайте. Как насчет Oracle C++ Call Interface?


Цитата:

А это не честно. Говорилось про многопоточье. Кстати, не поделишься им для виндов?

Есть сишный

Код: HANDLE CreateThread(
LPSECURITY_ATTRIBUTES lpThreadAttributes,
DWORD dwStackSize,
LPTHREAD_START_ROUTINE lpStartAddress,
LPVOID lpParameter,
DWORD dwCreationFlags,
LPDWORD lpThreadId
);

Цитата:

Давайте. Как насчет Oracle C++ Call Interface?

Ну коль пошла такая пьянка... А чтобы не к ораклу?

Про fork или я отстал от жизни или одно из двух... Когда мы учили программирование в юниксе, там четко говорилось, что для МНОГОПОТОЧНЫХ приложений надо работать через threads-библиотеку, типа pthread. А fork предназначен для порождения ЗАДАЧ. Уж между ними разницу я пока понимаю. Хотя, возможно, что в современных Юниксах это уже объединили.

По поводу шаблонов, есессно, дженерики не предоставляют тех возможностей, которыми богаты шаблоны в C++. Читая Александреску я понял, что язык С++ я не знаю.

Кстати, мне немного не хватает в C# typedef-ов и макросов.


Цитата:

Я же говорил: boost. Еще Qt. А в ISO14882:2008 будут и они, и сборка мусора

А вот когда они будут... Наверно году в 2008 Тогда и C# разовьется...
Кстати, а будут там фенечки, связанные с анонимными функциями? И вообще, где бы почитать, что там будет? Кстати, а какие компиляторы будут поддерживать этот стандарт?

Если не ошибаюсь, Буст до сих пор не все поддерживают...

Mickey_from_nsk
A Brief Look at C++0x: http://www.artima.com/cppsource/cpp0x.html

XDiaBLo
Специально для тебя C++ Applications: http://www.research.att.com/~bs/applications.html

Винда на C++ написана :-) BeOS. Про ядро Линукса еще не выяснил, но вот KDE и GNOME на нем, родном!

TheChampion
Почитал, интересно...
Кстати, где-то я уже читал, что, вроде собираются туда лямбда функции вносить...
Есть одно но... Это все только СОБИРАЮТСЯ делать, я из статьи полугодичной давности понял, что дел там еще не меряно. А C# и Java уже есть... Причем с похожей функциональностью.
При этом, в C# 2.0 предлагаемый функционал уже есть (кроме отключения GC) а библиотеки СУЩЕСТВЕННО богаче чем в С++.
А в конечном итоге, мне нужнее библиотеки, а не шаблоны.

Цитата:

Это про C#?

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


Цитата:

Ну, опять же, про Java не знаю, но в C# №2 есть такая весчь как дженерики.

В жабе те же самые generic'и


Цитата:

Кстати, мне немного не хватает в C# typedef-ов и макросов.

Поддерживаю. Бывает сидишь и думаешь - "были бы тут typedef(или define), всё бы куда лучше и проще вышло".

Mickey_from_nsk

Цитата:

При этом, в C# 2.0 предлагаемый функционал уже есть (кроме отключения GC) а библиотеки СУЩЕСТВЕННО богаче чем в С++.
А в конечном итоге, мне нужнее библиотеки, а не шаблоны.

Дело в том, что все это давно написано. Просто находится в разных библиотеках. Все-таки C++ не проприетарный, у него множество разработчиков. Отсюда множество разных библиотек, ничем не уступающих java/c#. Лично мне Qt нравится за их правильные Layout Controls. В жабе это же было геморройно (дизайнера не было, писал кодом, года 2 назад). Вот в новой версии все соберут и нанесут ответный удар :-)) А то всякие там M$ и Sun идеи тырят, вот у них потырят :-)

PS: про базы данных напишу вечером ;-)

PPS: просвети насчет анонимных функций и с чем их едят.

TheChampion
Да вощем, C# тоже уже не сильно проприетарный... Ну ладно, замнем для ясности.
Просто, имея .NET SDK я сразу имею все нужные мне либы (кроме грида, но и его, вроде в 2.0 уже добавили - не проверял).
Qt в свое время пробовали - не очень понравилась их идея предкомпиляции. Там чего-то не срослось и забили на это (ну это везде бывает, может поразбирались бы и тож его полюбили).

Анонимные функции - это такая щтучка, которую можно объявить в теле другой функции и сразу назначить (типа callback) на событие. Очень удобно по части запуска новых потоков - немного напоминает fork, только вместо анализа возвращаемого pid делаешь функцию обработки клиента.
В следствие этого стало возможным удобнее делать разные вкустности - обработка event-ов, асинхронных событий и т.д.
Если не ошибаюсь, это немного похоже на lambda-функции из буста. Ну очень отдаленно, но похоже.
Код пока не привожу - мало с этим разбирался. Не получается пока перейти на вторую версию.

Кстати, а в Java эта венечка есть?

Цитата:

В жабе это же было геморройно (дизайнера не было, писал кодом, года 2 назад)

Поверь мне, дизайнер в жабе - не выход. Нарисуешь - всё ок. Запустишь - нормально. Изменил лукэнфил или запустил на другой машине - вполне можешь получить совсем не то, что рисовал. Да и гибкости в дизайнерах мало. В общем, интерфейс на жабе лучше писать ручками. Причём, ровными - и без того проблемы бывают.


Цитата:

Кстати, а в Java эта венечка есть?

Конечно, есть. Шарп же с явы слизывали.

И, возвращаясь к дженерикам,

Цитата:

Ага, особенно прелестно выглядит обявление шаблона как наследника (!!!) некоего интерфейса )

Чет этой иронии я не понял... Чем плохо? Шаблон не может подписаться на реализацию определенных методов?
Разве в С++ такое невозможно?

Цитата:

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

Ну тут что считать компиляцией. В .NET в отличие от С++ все (практически) компилируется во время исполнения. Так что компоновка по любому динамическая.

Цитата:

Кстати, что насчет алгоритмов? Ну там перебор, подсчет, суммирование, копирование, разделение, сортировка? Время операций в контейнере гарантировано?

Вот в C++ все просто: параметр шаблона должен предоставлять определенный интерфейс, только и всего! Описывать интерфейс не надо, компилятор в достаточной мере интеллектуален, чтобы вычислить интерфейс на основе вызовов И, самое главное, параметры шаблона могут не наследовать, они вообще могут не быть классами.

А чем алгоритмы в дженериках отличаются от алгоритмов в шаблонах?

Вот в С++ не совсем все просто. Программист должен сам отследить, выполняет ли его класс определенный интерфейс для удовлетворения шаблону. Иначе на компиляции поимеет много нехорошего чтива от компилятора. При этом ему придется долго вникать, читая между строчек, что же он напортачил.
Вот насчет интеллектуальности компилятора - да. Не могу точно сказать, можно ли в .NET делать вещи, которые делает С++, но С++ компилятор - на редкость интеллектуальная машина. Видел сравнения процессора шаблонов с интерпретатором языков типа SCHEMA.

Насчет инстанциирования шаблонов и дженериков - не вижу разницы между ними.


Цитата:

Кстати, вот тут (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/csharp_generics.asp) приведен пример с функцией Find(), которая не будет работать в силу вызванного из нее operator==(). Оказывается, чтобы перегружать operator==() надо наследовать класс от IComparable, и для сравнения вызывать функцию-член CompareTo()... И эти люди говорят, что C++ сложен и неудобен!

Чтобы это понять, надо поработать с .NET. Там все объектное, все на ссылках (или указателях - как угодно). В C# вообще не рекомендуется (во избежание...) переопределять оператор ==. Там он означает равенство указателей, а не содержимого.
Я уже писал, что садясь за С# надо немного перестроить сознание. И получится совсем не плохо.

Xarde
По поводу освобождения памяти "когда вздумается". Надо бы различать непосредственно освобождение памяти и очистку объекта (закрытие дескрипторов, flush и т.д.) Поскольку в C++ управление памятью - задача программиста, там обычно эти задачи совмещаются. В языках типа .NET, Java эти задачи принципиально разные.

Если ты, например в C#, не реализуешь интерфейс Idisposable в классе, ты рискуешь потерять объект не закрыв при этом чего-нибудь.
В этом ничего страшного нет, в С++ это все гораздо страшнее. Просто это факт. Поэтому, при программировании в С# рекомендуется (причем усиленно) явно закрывать и диспозить объекты. В частности для этого в C# есть оператор using (своего рода аналог smart pointer).
Если не ошибаюсь, в Java тоже есть подобные соглашения.
А по поводу излишнего расхода памяти и невозможности ее во-время за собой убрать, то я не вполне уверен, что это сильно нужно. Отложенное освобождение памяти более эффективно, поскольку проводится сразу целым блоком.
При этом, если уж действительно не втерпеж освободить ее (ну там огромная картинка оказалась нафиг не нужна), можно явно вызвать Garbage Collector. Он все и очистит.

TheChampion

Цитата:

XDiaBLo
Специально для тебя C++ Applications: http://www.research.att.com/~bs/applications.html

Зачем оно мне? Нужные мне программы я завсегда найду, и на чём они написаны мне глубоко безразлично, лишь бы работали хорошо :) А что больше всего радует, так это если программа без перекомпиляции работает в любой ОС. Очень радует кстати в этом плане ещё и ФриБСД, там я думаю WINE и ему подобные вполне работают, и виндовые приложения многие запускать можно, а линуксовые программы даже без эмуляторов и перекомпиляций по большей части работают. Хочу поставить дома на второй комп, который без дела пока стоит: FreeBSD, WINE и Java, и посмотреть, на эти чудеса, поэкспериментировать с установкой программ :) А .NET под FreeBSD есть какой-нибудь, хотя бы полукривой? Тоже чтоб посмотреть