Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, AlexK, Вы писали:
AK>>скоро это будет выглядить приблизительно так: надо тормоза — пиши на НЕТ... увольте... не хочу так жить... S> Ну да Native компиляторы доживают свой век или уйдут в Linux, т.к. там уже на конкретной машине под камень и операционку компилируют, а не толко программы. S> Живи по старому....
Опять промащечка... Линуха в основном то и живут на языках интерпретаторах: Perl, PHP ... че та там еще было...
пол оски на скриптах написано. а вторая половина пережиток прошлого, которое все бояться трогать... Линух мертв — в нем только остатки былой силы. Пока не будет крупной корпорации, которая не начнет постоянно поддержиать Линух, разгребет все его тоны мусора, то смысла в такой оске нету. Линух — "отстойник" мыслей. А вот приживуться ли...
А то что НЕТ под каждый проц свой код генерит, так это вранье все... не успели они эту фичу в полном объеме сделать. Только на мемори менедмент их и хватило... один для сервера, другой для клиента... Native compiler стране нужен!, но в связи с дифицитом рук которые будут писать софт, появляються языки на освоение которых требует все меньше времени и понимания основ... Вот и получаеться что программинг пытаються свести до уровня домо-хозяйки... Но программист это же гордое название человека!, который не спит ночами и стараеться все сделать для клиента...
Делфи как раз и была попытка сделать упрощенный вариант программинга в целом... согласен оно заняло достойную нишу и туда перекачивало не мало толковых людей... подстегнуло отросль компайлеров и языков програмирования к развитию... только теперь приходит очередь нового поколения — НЕТ фреймворка. а что вот делать с программерами старой закалки?
Только макрософты их переплюнули на много больше, мало того что написали либу отдаленно напоминающую vcl, но и дали возможность старым программерам не меняя языка делать свое дело... вот только реализация подкачала... пока там больше багов чем может себе позволить комерческий софт.
Вот и пытаються заткнуть недостаток качества автоматами затыкания дыр... постоянные проверки... метаданные... ексепшены... проверка типов... но это же порождает торомоза с которыми тяжело смириться; это же раждает "программеров" без понимания того что оно делат внутри...
Хочу жить по старому, да уже не смогу... вот так и рождаються сказки про злолотой век программинга и т.п. чушь.
AK>>они своей надежностью воспитают еще одно поколение псведо-программеров, который будет считать что умение кинуть на формочку кнопку — делает его прогарммером... S> Хехе уже давно воспитаны на Васиках и 1С.
основное слово еще одно
AK>>с++ — путь к силе духа! и ясности ума! S> Программирование это не профессия, а Смысл Жизни!!!!
Да прибудет с тобой сила...
Здравствуйте, AlexK, Вы писали:
AK>А то что НЕТ под каждый проц свой код генерит, так это вранье все... не успели они эту фичу в полном объеме сделать.
Для ARM, MIPS и SH3/SH4 под Windows CE уже сделали. Просто у них приоритеты другие.
Здравствуйте, desperado_gmbh, Вы писали:
_>Здравствуйте, AlexK, Вы писали:
AK>>А то что НЕТ под каждый проц свой код генерит, так это вранье все... не успели они эту фичу в полном объеме сделать.
_>Для ARM, MIPS и SH3/SH4 под Windows CE уже сделали. Просто у них приоритеты другие.
так по ихним рекламам тебя в зависимости от проца на машине (где Винды стоят) по разному натив код генериться должен... а то что они начали на другие процы все перегонять — опять спасибо надо сказать с++ за кросплатформенность... (почти полную)
Здравствуйте, AlexK, Вы писали:
AK>так по ихним рекламам тебя в зависимости от проца на машине (где Винды стоят) по разному натив код генериться должен...
Кстати, у VC++ есть ключи, указывающие, под какой процессор генерить. Сильно ли они меняют код для типового исходника на С++ (меньше Pentium-1 не рассматриваем)?
AK>а то что они начали на другие процы все перегонять — опять спасибо надо сказать с++ за кросплатформенность... (почти полную)
Для раскрутки, естественно, кроссплатформенные плюсы очень даже помогают. Только вот в .net compact framework native-бинарников (которые не все и переносятся, часть — кодогенератор под конкретный процессор) — 300-550K (в зависимости от платформы) mscoree и 80-150K какой-то переходник к AGL. Остальные полтора мега на разных платформах совпадают с точностью до бита.
[skip]
WH>>>Какие проблемы с надежностью С++ шаблонов мне ктонибудь обьяснит наконец? S>> Да втом, что шаблон он и в африке "Шаблон". WH>ГДЕ ПРОБЛЕМЫ С НАДЕЖНОСТЬЮ?
Нет никаких проблем у шаблонов с надёжностью. Да Вы это лучше меня знаете Похоже некоторые Ваши оппоненты не до конца представляют себе, что такое шаблон...
Любая сложная технология неотличима от волшебства. (Артур Кларк)
AK>Делфи как раз и была попытка сделать упрощенный вариант программинга в целом... согласен оно заняло достойную нишу и туда перекачивало не мало толковых людей... подстегнуло отросль компайлеров и языков програмирования к развитию... только теперь приходит очередь нового поколения — НЕТ фреймворка. а что вот делать с программерами старой закалки?
Я сам вроде не мальчик, но и по старому жить не хочется. Тяга к знаниям остается.
AK>Только макрософты их переплюнули на много больше, мало того что написали либу отдаленно напоминающую vcl, но и дали возможность старым программерам не меняя языка делать свое дело... вот только реализация подкачала... пока там больше багов чем может себе позволить комерческий софт.
Не долго сказка сказывается, да долго.. Идеи заложенные в Net для меня лично грандиозны и очень перспективны. По сложности и по количеству нововведений намного превышает все Native языки. Этакий симбиоз транслятора и компилятора. JIT компиляторы должны развиваться, в этом заинтересованы все производители CPU впервую очередь Intel (какой самый быстрый компилятор С++???). Долой х86, даешь многоядерные процессоры со стековой архитектурой и распределенными вычислениями.
А на С++ не одни профи кодируют, а как везде. А начем программировать побольшому счету по барабану,главное что и было бы интересно, а не муторно.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, desperado_gmbh, Вы писали:
_>Здравствуйте, AlexK, Вы писали:
AK>>так по ихним рекламам тебя в зависимости от проца на машине (где Винды стоят) по разному натив код генериться должен...
_>Кстати, у VC++ есть ключи, указывающие, под какой процессор генерить. Сильно ли они меняют код для типового исходника на С++ (меньше Pentium-1 не рассматриваем)?
а тут и мерять нечего... а вот если от Интела компайлер взять то там разница чувствуеться...
AK>>а то что они начали на другие процы все перегонять — опять спасибо надо сказать с++ за кросплатформенность... (почти полную)
_>Для раскрутки, естественно, кроссплатформенные плюсы очень даже помогают. Только вот в .net compact framework native-бинарников (которые не все и переносятся, часть — кодогенератор под конкретный процессор) — 300-550K (в зависимости от платформы) mscoree и 80-150K какой-то переходник к AGL. Остальные полтора мега на разных платформах совпадают с точностью до бита.
а кто спорит... но замечу от кросплатформенности софт круче не становился.. .а только наоборот терял пару пунктов в скорости и возможностях.. а сделать что-то стандартное на всех желание хорошое, но толку мало... нахрена калькулятору Windows CE? (но это грубая анология...) хотя приблизительно так дело и будет обстоять... переносимость NET пока что точно такой же миф как и переносимость Java в начале своего пути. мы получим мощное по возможностям средство для всех платформ, но оно будет одинаково тормозить на всех платформах. или как у Sun получиться что работает Java на машинах только собственного производства...
да кстатит смотрел я тот код что макрасофты юзают, так вот ни каким там оптимайзом на платформу и не пахнет... сначало ядро компайлиться которое c# компайлить могет, а потом на осное с# исходников генеряться остальные либы... довольно мрачно выглядит...потому как оптимизационный алгоритм компилятора с# связан по рукам и ногам, как раз изи крос-проц-платформенности... могут юзаться только общии команды для всех процов... в результате код практически не оптимизирован, а дальше все ложиться на проц... конечно основные части кода макрософт не паблишила, но я сомневаюсь что в не опубликованных исходниках один гиниальный код и остался...
вот наконец-то разработки конвееров пентуимовых и пашут по полной... прогноз переходов... и т.д. и т.п. Кто читал обзоры на Петиуму, тот должен помнить что там как раз и была основная фича — расчет на исполнение не оптимизированного кода старых процесоров.. вот там то пентиум на все 100 и вкалывал...
_>А разве есть другой серьезный компилятор, скажем, C++, в котором нет аналогичного менеджера? sbheap.c из VC, например, весит больше ста килобайт. И в любом случае выделение в стеке дешевле.
Ну кто же с этим спорит. Но не зря же в Net GC внедрили, но оставили структуры — объекты, для полного использования стека. sbheap.c посмотрю, спасибо.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AlexK, Вы писали:
AK>нахрена калькулятору Windows CE? (но это грубая анология...)
Ты видел навороченные калькуляторы типа HP49? Язык там напоминал аналитик с "Мир-2", программы (включая игрушки) писались как на нем, так и в машинных кодах. Сейчас его на сайте нет, видимо, хэндхелды убили этот рынок. Даже на телефоне .NET Compact Framework или J2ME дают удобство и гибкость, захотел — скачал новый калькулятор или icq-клиента.
AK>потому как оптимизационный алгоритм компилятора с# связан по рукам и ногам, как раз изи крос-проц-платформенности... могут юзаться только общии команды для всех процов... в результате код практически не оптимизирован, а дальше все ложиться на проц...
После компилятора c# получается код на IL, ассебмлере для виртуальной объектно-ориентированной стековой машины, не похожей ни на один из target-процессоров. Его оптимизация — задача джита. Даже с учетом его невылизанности результаты неплохие, я уже кидал ссылку на managed Q2. 85% от чисто сишного кода и 70% от сишного кода с ассемблерными вставками (это в software rendering, с акселерацией разница еще меньше) — неплохой результат для версии 1.1.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, mihailik, Вы писали:
M>>Кроме того, все объекты сугубо by ref. Никаких объектов на стеке или ещё где ни попало.
L>А как по твоему передаются параметры? По воздуху?
(Вот, из курса ВМКашных лекций по ЯП)
Вообще говоря, существует пять способов передачи параметров:
1) По значению (IN);
2) По результату (OUT);
3) По значению результата;
4) По ссылке;
5) По имени;
Механизм передачи параметра по значению достаточно прост — для подпрограммы выделяется некоторая область памяти (стек), в который копируется значение фактического параметра, которое в свою очередь и используется процедурой.
По результату — также выделяется область памяти для формального параметра, который копируется в фактический параметр после завершения процедуры.
По значению результата, не сложно догадаться, — перед началом выполнения подпрограммы происходит копирование фактического параметра в формальный, а при выходе -из формального в фактический.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, mihailik, Вы писали:
M>>Кроме того, все объекты сугубо by ref. Никаких объектов на стеке или ещё где ни попало.
L>А как по твоему передаются параметры? По воздуху?
Часть через Регистры. А вот с FPU Борланд подкачал. А объектов на стеке действительно нет, только ссылки на них.
и солнце б утром не вставало, когда бы не было меня
M>>В Дельфи объекты нельзя распределить в какой-то особенной памяти, кроме как в стандартной куче. Да я и не вижу необходимости.
WH>Ты нет а вот те кто придумывал COM почемуто видят.
Те, кто придумывал COM, сейчас стараются его как можно скорее забыть.
M>>А стандартные типы не имеют никакой деструктивной логики, которую нужно было бы вызывать. WH>А варианты? А строки их к стати тоже нужно в COM аллокатором размещать если вернуть хочешь.
Ну, разве что строки. O.K., напишем отдельный классик для строк. Пока ничего серьёзного.
M>>Дурной тон? Понимаю. WH>А в дельфе try/create/finally/free, try/create/finally/free, try/create/finally/free,.... WH>В то время как в С++ new, new, new, new,... WH>Разницу замечаем или еще нет?
Замечаем разницу, но я пример приводил
В том же C++ не всегда можно забить на время жизни.
M>>Если нужно из чужой dll'ки вызвать пару-трёшку функций в определённом порядке, на C++ принято тратить полчаса на враппер? Даже если известно наверняка, что никогда и никому больше этот враппер не понадобится?
WH>Вот мне недавно надо было просканить папку и вернуть файлы удвалетворяющие маске.
Это всё хорошо. Ручной труд — он ведь облагораживает
M>>Слава богу, что в Дельфи с тоном посвободнее.
WH>Ага вот только народ (из другой конторы) который писал OPC сервер на дельфе потратил много больше времени на разработку ибо за меня работал компилятор, а они все делали ручками.
Ну что я тебе могу сказать про этот народ и этот сервер. Я ни того ни другого не знаю
M>>Ну вот. А то кто-то говорит, что в C++ мало ручной работы. Пишете там всякие помощники по поводу и без повода, и нас, бедных Дельфистов агитируете. Доколе!
WH>Именно по этому и мало ручной работы ибо я пишу логику один раз, а ты каждый раз при использовании.
Иногда этот "каждый раз" означает в точности "один раз".
Но в остальном тенденция, конечно, полезная. Если меру знать
M>>Чтобы засечь этот "раз в год", я должен думать об этой возможности каждую секунду. Где же экономия?
WH>Тебе знакомо такое слово "проектирование"? То о чем ты сейчас говоришь относится именно туда. Если архитектура хреновая то отгребещь по полной в любом случае, а когда нормальная то на С++ работы много меньше.
Если архитектура нормальная для C++, то на C++ работы меньше. Если архитектура нормальная для Дельфи — соотвественно.
M>>Прямой доступ, конечно, разрешён. WH>Вот и закончилась безопасность.
В .NET тоже разрешён прямой доступ.
M>>Но всё-таки не так явно и беззастенчиво, как в C++. WH>Но есть следовательно в один рад с жабой и .НЕТ ставить нельзя.
Да ладно. В один ряд нельзя, в другой можно. Я ж не говорю, что Дельфи — это Java. Но нахожу много общих черт.
M>>Никакой явной адресной арифметики, обращения к указателям в стиле массивов и пр. В C++ это ещё в наследство от обычного C осталось. А в Дельфи наоборот, палки в колёса суют, если хочешь с укзателями работать. WH>Если кому захочется он всеравно сделает...
Точно так же, как и в .NET. Да и даже в Java — никто не мешает написать внешний объект, который будет обращаться к памяти напрямую. А в классах Java его использовать.
M>>Кроме того, все объекты сугубо by ref. WH>Ну и нахрена это надо?
Для однообразности и простоты. Все объекты ведут себя с памятью одинаково. Мозги не парятся.
M>>Никаких объектов на стеке или ещё где ни попало. WH>Вот и приходится городить try/finally постоянно.
Не постоянно. В Дельфи тоже есть способ уйти от ручного вызова деструкторов к подсчёту ссылок. Интерфейсы всегда работают по учёту ссылок.
M>>Операторы, слава богу, не перегружаются. WH>Это еще почему?
А вот чтобы приколисты вроде Страуструпа не выдумывали разных новых значений оператора сдвига. Сдвиг — он в Дельфи всегда сдвиг.
M>>Никаких конструкторов копирования, неявных преобразований и множественного наследования. WH>В том то и засада что не всегда объект можно просто скопировать.
А все объекты byref, то есть ничего и не копируется. Чтобы сделать копию, нужно как и в .NET вызвать какой-нибудь Clone.
M>>Шаблоны тоже разум не затмевают. WH>Ага. И использование полиморвных контейнеров ведет к чистоте, простоте и надежности
Тут ты прав. Действительно удобно.
M>>Короче говоря, возможности поурезаны, но нам-то это и нужно. WH>При написании ГУИ к БД согласен, а вот на счет всего остального.
Ты что, предлагаешь и в браузерах скрипты на C++ писать? Или ты какое-то конкретное "остальное" имеешь ввиду?
WH>А кому нужен инструмент налогающий кучу ответственности и не дающий ни каких инструментов контроля тому примая дорога на дельфе работать.
Тебе, как большому знатоку Дельфи, это виднее. Где уж мне неучу с тобой спорить.
Свойства.
Позднее связывание.
AD>Функциональность С++: AD>1. Переменные * AD>2. Типы * AD>3. функции *
Почему в Дельфи Процедуры и функции, причём даже "в т.ч. вложенные" не удостоились звезды, а в C++ простые функции удостоились?
AD>4. Классы *
Почему в Дельфи Классы не удостоились звезды, а в C++ удостоились?
AD>5. Абстакция, наследование, полиморфизм * AD>6. Перегрузка операторов * AD>7. Нормальная(!) перегрузка функций *
В Дельфи, значит, ненормальная?
Кстати, в твоём списке её не было.
AD>8. Множественное наследование * AD>9. Понятие "объект класса" *
Что такое за понятие?
AD>10. Поименованные области * AD>11. Шаблоны и STL:
Ну да, а для Дельфи есть VirtualTreeView — очень удобный компонент. Если уж пошли библиотеки сравнивать.
AD> — типизированные контейнеры и массивы *
В Дельфи, вроде бы отстутсвуют. В Дельфи все массивы, кажется, нетипизированные
M>>RTTI (aka Reflection) WH>Рефлекшен в дельфе... Бедные мои тапочки... Ну не надо сравнивать бумажный самолетик с истребителем пятого поколения.
Почему не надо сравнивать?
RTTI решает те же проблемы, что и Reflection. Сериализация и ремотинг. Конечно, RTTI похилее Reflection'а, ну и что? Работает, функции выполняет.
M>>Свойства WH>О да это величайшая АРХИТЕКТУРНАЯ особенность. К стати VC++ поддерживает свойства в качестве расширения.
Свойства — это важная архитектурная особенность. Языки, в которых поддерживаются свойства являются компонент-ориентированными. Ну вот не могу сказать почему так выходит, а реальность такова.
M>>Упор на простоту синтаксиса WH>Или убогость? Так чтобы [censured] поняли?
А я не вижу ничего хорошего в том, что C++ не понимают люди без образования.
M>>Значительная часть преимуществ как Делфи, так и C# коренится в этих трёх пунктах. WH>Особенно два последних.... величайшие преймущества.
Если тебе непонятны эти преимущества, возможно они тебе и не нужны. Мало ли у кого какая отрасль работы. А мне вот нужно, чтобы мой код был понятен [censured]'ам, и свойство-ориентированность тоже удобна.
M>>А, так ты Flush в try/finally делаешь? M>>А шуму-то было, мол, в C++ try/finally не нужен никогда.
WH>Что такое исключение? Это ФАТАЛЬНЫЙ сбой в алгоритме. Следовательно алгоритм не отработал. WH>Вопрос нафига записывать мусор если надо просто сообщить о провале и подчистить ресурсы?
А вот надо. Лог вести, или ещё какие предсмертные действия совершить.
M>>А при чём здесь объём памяти? В C# всё прозрачно расписано, когда и в каких случаях стоит вызывать Dispose. Если не следуешь советам, сам виноват. WH>А при том что когда памяти мало GC убивает объекты до того как будут сожраны ВСЕ ресурсы, а когда много...
WH>Вся проблема в том что вызов РЕКОМЕНДАТЕЛЕН те если ты его забыл сделать то ни кто тебе ни чего не скажет. А как показывает практика 90% ошибок происходит именно из-за забывчивости.
Ну и кто по твоему должен что сказать? Или для всех локальных объектов Dispose делать?
