CrossKylix прекратил свое развитие

>Про ресурс "память", как я вижу, я Вас тоже убедил. Ни черта вы не убедили. Рассмотрите такой ресурс как файл. Это не просто область памяти. Если вы это не понимаете то очень жаль. Закрыть файл это не тоже самое, что delete p.

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

Что за бред. Разработал язык, пиши для него компилятор. ДотНет предоставляет нам промежуточное представление для этого - IL. А JIT сам переведет в маш. код. Или мы такие крутые, что можем супер-эффективный маш. код генерировать. Судя по GCC орда ГНУ-тых программистов не могут сделать эффективно генерировать код. Бабла и знаний не хватает. Под .НЕТ есть компиляторы, написанные одним человеком. Быстродействие генерируемых исполнимых файлов при этом выше чем у GCC. Как говорится, доверьтесь профессионалам, а не стаду тупых гнушников, возомнивших себя экспертами по генерации маш. кода. Линукс - это колосс на глиняных ногах. Вот и все.

>шаред либы в UNIX появились раньше, чем в виндах. а КОМ там не нужен, ибо unix way.

То есть вы предлагаете для каждой программы изобретать свой велосипед. Для ОО это UNO. Для остального - шиш вам. Мне насрать на unix way и всякие остальные true-way. Мне нужны приложения, которые работают одновременно с AutoCAD-ом, Оффисом и базами данных. СОМ это все позволяет. Причем из любого языка, поддерживающего СОМ (Visual C++, .NET, Visual Basic 6, Delphi, VBA, VBScript, JScript и т. д.) А в Линукс?

>Но виртуальную машину-то надо ставить! дотнет только в висту изкоробки встроен, в остальных виндах надо dotnetfx*.exe запускать.

А чтобы запускать например GCC, нужно Линукс ставить. А чтобы игруху запустить нужно DirectX ставить. А чтобы установить rpm-пакет, нужно скачивать и устанавливать кучу зависимых от него пакетов, не совместимых между дистрибутивами Линукса. Это что true-way? На хер нужен мне этот true-way?

>Но он не является прослойкой А С++ это такая же прослойка. Идите пишите на маш. кодах, если не любите прослойки.

>> Про ресурс "память", как я вижу, я Вас тоже убедил.
> Ни черта вы не убедили. Рассмотрите такой ресурс как файл. Это не просто область памяти. Если вы это не понимаете то очень жаль. Закрыть файл это не тоже самое, что delete p.
open() и close() - это системные вызовы. Напрямую с файлами программа не работает. read() берёт файл с диска и суёт его _в оперативную память_, откуда потом программа его и обрабатывает. Вообще, open() - это выделение оперативной памяти под буфер обмена с диском, а close() - освобождение этого буфера.

>> С того хрена, что язык должен иметь _свой_ личный компилятор для получения максимальной эффективности.
> Что за бред. Разработал язык, пиши для него компилятор. ДотНет предоставляет нам промежуточное представление для этого - IL. А JIT сам переведет в маш. код. Или мы такие крутые, что можем супер-эффективный маш. код генерировать.
Для КОНКРЕТНОЙ ЗАДАЧИ написание сразу машинного кода оказывается эффективнее. Другое дело, что никто не хочет тратить время на то, чтобы этим заниматься. Но бывают задачи(не быдлокодерские, потому не всем о них известно), в которых написание своего языка и своего компилятора оправдано.
В конце концов, я могу свой язык перевести в C(как например, делается для фортрана: сначала f2c, а потом gcc) и скомпилировать его любым оптимизирующим сишным компилятором. Раз Вам так не по душе gcc, то возьмём Intel C++ compiler.

> Быстродействие генерируемых исполнимых файлов при этом выше чем у GCC.
Наблюдаю постоянные скачки от общего к частному и от частного к общему. Возможно, гцц не самый лучший, но сравните производительность кода от вашего любимого JIT с производительностью кода, скомпилированного хорошим коммерческим компилятором, типа того же icc.

>> шаред либы в UNIX появились раньше, чем в виндах. а КОМ там не нужен, ибо unix way.
> То есть вы предлагаете для каждой программы изобретать свой велосипед.
Зачем велосипед? Возможностей пайпов хватает за глаза. Шаред либы тоже есть.

> Для ОО это UNO. Для остального - шиш вам.
Ещё раз говорю про DCOP.

> Мне насрать на unix way и всякие остальные true-way.
Оно и видно.

> Мне нужны приложения, которые работают одновременно с AutoCAD-ом, Оффисом и базами данных.
Я вот рулю amaroK и licq из консоли. Потому что они поддерживают DCOP. Мне не нужно писать интерфейсы для работы с COM, я просто вызываю из консоли одну подпрограмму. Это и есть unix way.

> СОМ это все позволяет. Причем из любого языка, поддерживающего СОМ (Visual C++, .NET, Visual Basic 6, Delphi, VBA, VBScript, JScript и т. д.) А в Линукс?
DCOP тоже всё это позволяет. Кстати, а программа, в которой не предусмотрена работа с COM, будет с COM-ом работать? Если в автокаде будет реализована, наряду с поддержкой COM, поддержка DCOP, я с таким же успехом буду рулить и им. В линуксе.

>> Но виртуальную машину-то надо ставить! дотнет только в висту изкоробки встроен, в остальных виндах надо dotnetfx*.exe запускать.

> А чтобы запускать например GCC, нужно Линукс ставить. А чтобы игруху запустить нужно DirectX ставить. А чтобы установить rpm-пакет, нужно скачивать и устанавливать кучу зависимых от него пакетов, не совместимых между дистрибутивами Линукса. Это что true-way? На хер нужен мне этот true-way?
Я не хочу спорить про удобство установки софта в linux и windows, так как это выходит за рамки нашей дискуссии.

>> Но он не является прослойкой
> А С++ это такая же просло
C++ - это _высокоуровневый_ язык, в отличие от MSIL.

Да и еще:

В С++ операторы new и delete очень медленные. По крайней мере в 2 раза (в некоторых случаях - до 5) медленнее, чем в DotNet.

Прочитайте LXF 06'07 интервью с создателем языка Д. Он хоть и нативный, но поддерживает сборку мусора.

Цитата:

Итак, D – это некоторое расширение C++?

У D есть много функций, привнесенных из дру- гих языков программирования, но помимо этого, его разработчики воспользовались случаем избавиться от некоторых элементов C++, которые им нрави- лись меньше всего. Например, под нож попало мно- жественное наследование. Препроцессор тоже был уничтожен, а это значит, что макросы погибли вмес- те с ним. Пропали заголовочные файлы, пространс- тва имен и ранние объявления (forward declarations). Последние оставались еще с тех времен, когда ком- пиляторы были гораздо менее умными. Ну и, конечно, появилась автоматическая сборка мусора...

Если D включает в себя сборку мусора, как он может создавать столь же быстрый код, что и C?

Ну, на самом деле современные системы сборки мусо- ра позволяют программам работать даже быстрее, чем программы с ручным управлением памятью. Да, я знаю, что это противоречит вашим интуитивным ощу- щениям, но подождите, и я все объясню. Во-первых, сборка мусора запускается только тог- да, когда памяти становится слишком мало, а это значит, что память не освобождается, пока в этом не появится необходимость. Для большинства программ может оказаться, что за время их работы сборка мусо- ра не запустится ни разу – а это большой выигрыш в производительности по сравнению с С, в котором память освобождается всегда, вне зависимости от того, нужна она сейчас для чего-нибудь еще или нет. Во-вторых, объекты C++ освобождают память с помощью вызова метода деструктора, что может силь- но замедлить работу, особенно если нужно освобо- дить несколько тысяч объектов. В-третьих, сборка мусора автоматически перегруппирует кучу, что улуч- шает производительность памяти.

страница 50.

> В С++ операторы new и delete очень медленные. По крайней мере в 2 раза (в некоторых случаях - до 5) медленнее, чем в DotNet. Переопределение operator new() и operator delete() никто не отменял.

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

Там ещё было что-то про деструктор: в Java точно, не знаю как в дотнете, есть функция finalize, которая вызывается в тот момент, когда объект удаляется из памяти. Так что там тоже можно чего угодно насовать в "деструктор".

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

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

>Наблюдаю постоянные скачки от общего к частному и от частного к общему. Возможно, гцц не самый лучший, но сравните производительность кода от вашего любимого JIT с производительностью кода, скомпилированного хорошим коммерческим компилятором, типа того же icc.

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

А какое коммерческое примененение этого компилятора?

Ты бы хоть посоветовал сравнить с Visual C++ - лучшим компиляторм для С++ в мире.

Так вот скажу по секрету: единственное, что работает в DotNet медленнее, чем VC++ - это массивы и то по понятным причинам (контроль выхода за границы).

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

>Ещё раз говорю про DCOP. А что ты мне эти рваные кеды приплел? UNO хоть кроссплатформенное.

>Я не хочу спорить про удобство установки софта в linux и windows, так как это выходит за рамки нашей дискуссии.

А! Задели за живое? А теперь господа, как выглядит установка приложений в DotNet:

просто копируем файлы на винчестер. И все. Инсталлятор нужен только как красивая обёртка. Никаких проблем с зависимостями.

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

C++ - это _высокоуровневый_ язык, в отличие от MSIL. Опять путаем сено с соломой! Вообще-то С# - это еще более высокоуровневый чем С с крестами. IL - более высокоуровневый, чем Ассемблер процессора.

>> Мне насрать на unix way и всякие остальные true-way. Оно и видно.

А потому что unix way не предложил ни одной по настоящему стоящей технологии. Все повторяем за МС и другими коммерческими гигантами.

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

О, мы признали, что менеджер памяти в С++ - гавно.

>Там ещё было что-то про деструктор: в Java точно, не знаю как в дотнете, есть функция finalize, которая вызывается в тот момент, когда объект удаляется из памяти. Так что там тоже можно чего угодно насовать в "деструктор"

Сборщик мусора в ДотНете (особенно последней версии) еще более

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

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

А в ДотНет УТЕЧКИ ПАМЯТИ НЕВОЗМОЖНЫ В ПРИНЦИПЕ.

И еще: явный вызов GC.Collect() уберёт весь мусор

http://msdn2.microsoft.com/en-US/library/system.gc(VS.80).aspx

> Ты бы хоть посоветовал сравнить с Visual C++ - лучшим компиляторм для С++ в мире.
Грязный пиар микрософта и обсирание других продуктов, ничего больше.

>> Ещё раз говорю про DCOP.
> А что ты мне эти рваные кеды приплел? UNO хоть кроссплатформенное.
а COM кроссплатформенный? Так что баш-на-баш

-----------------------------------------------------------
По вопросам языков программирования анонимус слил. Далее дискуссия продолжается на тему установки софта в linux и window$.

>> Я не хочу спорить про удобство установки софта в linux и windows, так как это выходит за рамки нашей дискуссии.
> А! Задели за живое? А теперь господа, как выглядит установка приложений в DotNet: просто копируем файлы на винчестер. И все. Инсталлятор нужен только как красивая обёртка. Никаких проблем с зависимостями.
Угу, не следует тольк забывать, что эти файлы сначала надо где-то найти, потом скачать, найти кряк, прокрячить(всё это руками0. По сравнению с этим "aptitude install megaproga" смотрится как-то серо и неинтересно :)
Да, проблем с зависимостями нет, потому что одна и та же библиотека будет копироваться в каталог каждой программы, её использующей. Потому последняя версия "неро" и занимает гиг.
Кстати, а кто будет GAC чистить? Пользователь должен запоминать, какую сборку он туда положил?

> C++ - это _высокоуровневый_ язык, в отличие от MSIL. Опять путаем сено с соломой! Вообще-то С# - это еще более высокоуровневый чем С с крестами. IL - более высокоуровневый, чем Ассемблер процессора.
Давайте распишем путь кода на c++ и c# до процессора:
c++ -> машкод (1 шаг)
c# -> MSIL -> машкод (2 шага)
Соответственно, у пути c# сделать неэффективность при трансляции можно в двух местах, а у c++ - только в одном.

>>> Мне насрать на unix way и всякие остальные true-way.
>> Оно и видно.
> А потому что unix way не предложил ни одной по настоящему стоящей технологии. Все повторяем за МС и другими коммерческими гигантами.
Это те технологии, которые каждые 5 лет меняются на новые, более хорошие? Спасибо, но unix way работает уже 35 лет без проблем.
А то, что в силу инертности мышления, трудно перетащить виндовую прогу на unix, это не проблема unix way, а проблема архитектуры виндов.

> А в ДотНет УТЕЧКИ ПАМЯТИ НЕВОЗМОЖНЫ В ПРИНЦИПЕ.

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

Вы составили своё мнение на основании знаний исключительно из источников от микрософт. Разумеется, там написано, что C# - самый лучший язык, память в дотнете не течёт, JIT работает быстро и т.д.

Я тоже когда-то верил тому, что писали в книгах по дельфи. Но потом рискнул проверить и был разочарован в своей наивности.

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

Мусорщики мне нравятся, но я привык иметь возможность переписать его под конкретную задачу, где я могу выбрать более эффективный алгоритм. Вы считаете, что микрософтский менеждер памяти идеален? А мужики-то, которые занимаются Computer Science, и не знают, потому продолжают разрабатывать алгоритмы всё лучших и лучших менеджеров памяти!

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

По вопросам языков программирования анонимус слил тупого быдлокодера gaa в унитаз!

>а COM кроссплатформенный?

А ГНУ слабо повторить? Нихрена. Кишка тонка.

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

Ну вот, мы дошли до того, что ты, быдло, воруешь программы! МС был, прав: Лялихом пользуются террористы и преступники!

>Кстати, а кто будет GAC чистить? Пользователь должен запоминать, какую сборку он туда положил?

Придурок конченный... А в Лялйихе все такие?

В GAC пишут инсталляторы. При деинсталляции сборка удаляется.

>Соответственно, у пути c# сделать неэффективность при трансляции можно в двух местах, а у c++ - только в одном.

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

GCC переводит сначала в промежуточное представление, их там даже несколько. Так вот переводе из одного представления в другое неэффективность увеличивается в 10 раз. Это по твоей "теории".

>Спасибо, но unix way работает уже 35 лет без проблем.

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

Ан нет, господа! На дворе 21 Век!

>Я тоже когда-то верил тому, что писали в книгах по дельфи.

О бля, я точно знал, что ты Делфинист. Это было видно по тупости твоих сообщений!

Вобщем ситуация с тобой ясна: бывший ниудачник-делфинист, ворующий софт у МС/Борланд не нашел работу по специальности.

Пациент: Анонимус Лорный.
Симптомы: Передёргивание фактов, оскорбление собеседников, отсутствие сколь нибудь глубоких знаний по предмету, вызывающе неверная информация.
Диагноз: Тролль.
Лечение: Невозможно.

Пациент: gaa Адрес: Нижний Новгород Симптомы: Полное незнание темы и нежелание ее изучать. Диагноз: Бывший Делфи-быдлокодер, пересевший на Сы с крестами и думающий, что это - самое лучшее в этом мире. При попытке показать что-то лучшее фыркает и бесится, бьёт себя кулаками по груди и кричит: Сы с крестами - наше фсё! Лечение: Биореактор.

ЗЫ.

Кстати неплохой скриншотик. http://dn.codegear.com/article/images/37131/03000003.png

Посмотри и на IL-код, и на машкод.

> О, мы признали, что менеджер памяти в С++ - гавно.

Если под "менеджером памяти" Вы имеете в виду "умолчательную" реализацию операторов new и delete, тогда конкретизируйте инструмент.

Иначе вы бросаете тень на уважаемую операционную систему Windows™.

Visual C++ — "лучший компиляторм для С++ в мире", как было заявлено выше — реализует эти операторы через malloc и free соответственно, которые являются "обёртками" к HeapAlloc и HeapFree, т. е. вызовам менеджера кучи Windows™.

Комитет по этике корпорации Microsoft делает Вам предупреждение и указывает на неуместность подобных высказываний. Только учитывая Вашу самоотверженную миссионерскую деятельность и праведный образ жизни, вы не будете привлечены к ответственности.

P. S. На экстренно состоявшейся пресс-конференции глава комитета по этике корпорации Microsoft William Cruel Censor III заявил:"If he don't change his mind he'll be excommunicated anyway!" (по сообщению ИТАР-ТАСС)

> А кто сказал, что я ее не использую? DotNet великолепно интегрируется с COM.

Если Com Interop - великолепная интеграция, то что тогда "костыль"? EnterpriseSevices(COM+) что ли?

> В отличие от Ява. А рынок COM исчисляется миллиардами долларов.

У Кобола и легаси-VB6 он тоже не маленький. А у Явы и поболее, кстати.

а как ты греческий пользуеш?

я могу его поставить четвёртой раскладкой в иксах?

а клава у тебя тоже греческая?