Здравствуйте, wraithik, Вы писали:
W>А если дальше было написано: f2(x), которая куданить да засунула X. То же деструктор убьет X?
f2 не может никуда засунуть x.
Она может засунуть только указатель/ссылку или копию x.
W>Вообще то на С++ (как и у Дельфи) утечку памяти можно получить очень легко. Вот с этим как раз и борится шарп, ява и им подобные.
При использовании смартпоинтеров на С++ получить утечку памяти сильно труднее чем на дельфе.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, gandjustas, Вы писали:
W>>А что С++ гоняет через стек значения всех полей объекта? Не знал. G>Да, гоняет.
И не просто гоняет, а конструкторы копирования с деструкторами дергает.
Правда тяжелые объекты как правило таскают внутри какихнибудь смартпоинтеров которые только и делают что счетчиком ссылок щелкают.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, kuj, Вы писали:
kuj>Язык остался строго типизированным,
Понятие строгой типизации вобще какоето не понятное.
Язык может иметь статическую типизацию(хаскель), динамическую (смаллтолк) или ту или иную форму смешанной (когда преобладает либо та либо другая например C# в основном статически типизированный но там тожно делать придения типав от базового типа к потомку в рантайме).
Еще языки бывают типобезопасными (систему типов обойти нельзя например хаскль) и не типобезопасными (система типов обходится на раз например С/С++).
kuj>но получил многие элементы динамических языков:
Ваще бред.
kuj>type inference,
К динамической типизации отношения не имеет.
kuj>closures,
К динамической типизации отношения не имеет.
kuj>duck typing
К динамической типизации отношения не имеет.
kuj>(производная от dynamic typing: var something = new ClassA(...); ),
var вобщето недоделанный type inference
kuj>eval,
Ты про System.Reflection.Emit?
kuj>Такой .NET язык как Boo пошел еще дальше и взял такие элементы динамических языков как: syntactic macros (в отличии от макросов в C++, макросы в Boo имеют больше черт, характерных макросам в динамических языках — они модифицируют compiler pipeline) и generators.
На немерле посмотри да.
kuj>Полноценным динамическим языком в мире .NET на основе DLR станет IronRuby.
Вот уж что должно умереть это полноценные динамически типизированные языки ибо тормозной багодром по определению. И не лечится.
Короче иди поучи чтонибудь про системы типов.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Языки могут быть классифицированы как системы со статической типизацией и языки с динамической типизацией. Статически-типизированные языки могут быть в дальнейшем подразделены на языки с обязательной декларацией, где каждая переменная и объявление функции имеет обязательное объявление типа, и языки с выводимыми типами. Иногда динамически-типизированные языки называются латентно типизированными.
WH>Короче иди поучи чтонибудь про системы типов.
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Здравствуйте, Don Reba, Вы писали:
DR>>А QIP даже не поддерживает Юникод. О каком качестве можно говорить?
ДГ>Юзал 2005-й. Глюкалово то ещё.
Про QIP и юникод скажу так: есть Infium, попробуйте его.
а насчет глюкалова и всего прочего — посидите на стандартной шестой асе
на каком часу Вы взвоете?
а писана она на сях насколько я понимаю
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, kuj, Вы писали:
kuj>>Здравствуйте, DOOM, Вы писали:
kuj>>Это не субъективизм, а реалии жизни. Вместо того, чтоб сделать нормальный строго типизированный язык, взяли самую худшую черту динамического языка и прилепили ее в виде специального типа Variant. DOO>В результате это существенно упростило некоторые задачи, что и позволило стать дельфи языком для непрограммистов. Значит с рыночной точки зрения решение было правильным
Ну ты пошутил. Языки с динамической типизацией гораздо более требовательны к квалификации программиста, чем языки со статической типизацией.
Более того, для программы на динамически типизируемом языке необходимо максимальное покрытие тестами для доказательства что она ВООБЩЕ РАБОТАЕТ.
Делфи никогда не станет языком для "непрограммистов" именно потому, что надо достаточно много знать и за многим следить чтобы программа заработала.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, ironwit, Вы писали:
kuj>Еще один читатель. Вас что нужно носом тыкать? Или подобная невнимательность характерна для всех дельфятников?
ткни. а то от тебя кроме грубостей и слива ничего нет.
Здравствуйте, kuj, Вы писали:
kuj>Языки могут быть классифицированы как системы со статической типизацией и языки с динамической типизацией.
Вобще говоря чистых представителей динамически типизированных и в особенности статически типизированных языков (ML с некоторыми потомками. Что еще?) не так много.
В основном преобладают смешенные. C#, жаба, С++...
kuj>Статически-типизированные языки могут быть в дальнейшем подразделены на языки с обязательной декларацией, где каждая переменная и объявление функции имеет обязательное объявление типа, и языки с выводимыми типами.
Тут вобще граница весьма размыта.
Например С++ выводит типы шаблонов функций. В новом стандарте бедет изменено значение ключевого слова auto.
Да и в C# появился var.
Но сравнивать их с какимнибудь хаскелем или хотябы немерлом в плане вывода типов.
kuj>Иногда динамически-типизированные языки называются латентно типизированными. http://en.wikipedia.org/wiki/Latent_typing
WH>>Короче иди поучи чтонибудь про системы типов. kuj>Начни с себя.
Я в отличии от некоторых не путаю вывод типов и динамическую типизацию.
А еще я знаю что утиная типизация бывает вполне себе статической.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
M>>Все мои знания по ООП говорят мне, что оба раза мы создали COM-объект, унаследовавшись от базового COM-интерфейса. То, что второй объект не имеет методов, доступных из других COM-обхектов (в частности, они не используют стандартные COM-типы), никак этому факту не противоречит
kuj>Это верно с одним но — оба интерфейса автоматически наследуют все методы родительского интерфейса IUnknown: AddRef, Release, QueryInterface.
Ну это естественно. С COM я ооочень долго не работал поэтому просто не помнил, что там в этих интерфейсах было
G>Ну ты пошутил. Языки с динамической типизацией гораздо более требовательны к квалификации программиста, чем языки со статической типизацией.
Зато, как ни странно, гораздо менее требовательны к квалификации непрограммиста. Доказано это уже давно — еще начиная с бэйсика.
G>Делфи никогда не станет языком для "непрограммистов".
Тот факт, что он им являлся лет дак дцать мы во внимание принимать, конечно, не будем.
Здравствуйте, hattab, Вы писали:
H>>>>>Семантика для работы с интерфейсными классами и с обычными может быть одинаковой (см. TComponent). Но все это тонкости дающие большую гибкость. И необъяснимые глюки это может вызвать только там, где программист работает сам незная с чем (или не до конца понимая механизм). G>>>>В C# люди работают, не зная с чем, и баги не возникают почему-то. H>>> уморил. G>>Может тебе и смешно, а я уже успел почуствовать насколько меньше люди ошибатся с использованием C# и Java, по сравнению с темже Delphi G>>Причем среднее всермя обучения C# гораздо меньше чем для Delphi
H>Да-да. Я это уже слышал и не раз. За короткий срок невозможно научиться грамотно программировать на чем-бы то нибыло. Я соглашусь, что двоечнику после Delphi-AccessViolation'ов будет легче под .Net/Java. Однако создавать качественного продукта он не сможет. Пердульки бухгалтерские его удел. Максимум.
Мне очень нравиться "пердульки бухгалтерские". Откуда такое пренебрежение к основным деженжым вещам? Ведь большиство действительно серьезных программ пишется для бизнеса являются "бухлагтерскими пердульками" И там качество специалиста определяет разницу в сотни тысячи долларов. Мне аж даже интересно стало, что вы считаете достойным делом программиста, если убрать "пердульки бухглатерские".
G>>>>Я ловил сотни ошибоки из-затого что люди забывали/не_знали_что_надо вызывать Free. В Управляемых средах вообще таких проблем нет. Придирки вполе по делу. Вы просто не понимаете, потому что не работали с этим. H>>>Если люди чего-то там не знали/забывали, это характеризует только их, но не инструмент. Если выражаться простым языком: не можешь срать -- не мучай жопу. В управляемых средах, таки, есть место ручной очистке (пусть даже семантически скрываемой) для объектов владеющих ресурсами. Что начнется, когда человек, который работает не зная с чем (с твоих же слов), будет следовать навязываемой идеологии... G>>Какой-то бред, в чем смысл вашего высказывания?
H>Ты теряешь не только нить...
Я тоже потерял нить, наверное кто то плохо свои мысли формулирует? Я, например их не понимаю, наверное не дозрел еще.
H>>>>>Какая разница кто-кого догоняет или откуда заимствуются те или иные фичи? Ты тут о минусах говорил, я же тебе на плюсы указываю. G>>>>Эти плюсы не перекрывают минусы. А в других языках и платформах минусов поменьше. H>>>В других платформах есть тормоза неизвестно откуда появляющиеся, но теория их существование отрицает G>>Что дороже покупка в два раза более мощногокомпьютера или в два раза больше времени работы программиста?
H>Поменять парк бухгалтерских машинок из-за одного криворукого идиота? Мы пойдем другим путем.
Если требуется расширение функциональности, то за это надо платить, в том числе и сменой парка бухгалтерских машин. Вопрос окупится или нет, если новый функционал позволит выполнять те же оперции меньшим количеством операторов?
H>>>Мы тут, что С++ обсуждаем или Java? Ты сказал, что в Delphi чего-то нет. Я тебе говорю, что есть (может оно и в семерке уже было, я не помню). G>>Перечитай первые посты. Идет сравнение Delphi c другими популярными сейчас языками и платформами.
H>Уж не знаю, как ты, а я твои безосновательные выпады парирую.
G>>Если вам так нарвится делфи, то откройте ветк в которой опишите чем вам так нравится программировать на Delphi. Желательно в КУ.
H>Мне оно надо? У меня фетиша-то нету, в отличии от...
А как же Дельфи, разве в данном контексте не фетишь?
G>>ЗЫ Можем вспонить web. какие у делфи возможности создания web-приложений? Правильно — никаких!!!! Это удар ниже пояса.
H>Хотя Delphi и не среда для веб-разработчика, но имеется WebSnap, Intraweb, WebServices. Ты некомпетентен.
Ты не компетентен, спрашивается про WEB разработкe, а не слова где встречается WEB.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Да-да. Я это уже слышал и не раз. За короткий срок невозможно научиться грамотно программировать на чем-бы то нибыло. Я соглашусь, что двоечнику после Delphi-AccessViolation'ов будет легче под .Net/Java. Однако создавать качественного продукта он не сможет. Пердульки бухгалтерские его удел. Максимум. G>>Что в твоем понимании качественный продукт? G>>Я видел бухгалтерскую программу на C#, клон программы на Delphi. На шарпе она быстрее работала, была более стабильна и стоила в 2 раза дешевле.
H>Я тоже могу рассказать, что видел Ты мне поверишь? Читать здесь
H>>>Поменять парк бухгалтерских машинок из-за одного криворукого идиота? Мы пойдем другим путем. G>>Ты не путай, для коробочного продукта примерные параметры по быстродействию известны заранее и продукт не выпустят если не программа не пройдет по этим параметрам. Для ПО, разрабатываемого на заказ бывает выгоднее поменять железо, чем оплачивать работу десятка программистов. G>>Тем боее саме серьезные потери производительности происходят в основном не по вине платформы, а вследствие неправльного выблора/реализации алгоритмов.
H>Давай не будем углубляться в эту тему. В вопросе о цене владения перевес будет явно не на стороне .Net (но мне эту тему развивать не сильно интересно)
Конечно не на стороне .NET, цена владениа у Delphi окажется выше.
Здравствуйте, DOOM, Вы писали: DOO>Популярная библиотека Gtk является чисто сишной — на одних struct'ах построена и ничего, народ пользуется.
Но в Gtk+ реализован объектно-ориентированный поход, только классы там реализованы по-сишному: на структурах/указателях/макросах. А в биндингах Gtk+ к ОО-языкам — все это оборачивается в классы соответствующего языка.
M>>Все мои знания по ООП говорят мне, что оба раза мы создали COM-объект, унаследовавшись от базового COM-интерфейса. То, что второй объект не имеет методов, доступных из других COM-обхектов (в частности, они не используют стандартные COM-типы), никак этому факту не противоречит
H>У интерфейсов нет понятий видимости или невидимости методов. Интерфейс рассматривается только в целом. Тот факт, что второй интерфейс не совместим с типами COM, делает его не COM интерфейсом.
Тот факт, то второй интерфейс не совместим с типами COM означает обычно только то, что у программиста руки кривые.
При этом второй класс магическим образом становится COM-объектом как только в него добавляются функции с соответствующими сигнатурами?
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, _d_m_, Вы писали:
H>>>Delphi не обязывает программиста иметь конфигурационные файлы, от которых будет зависеть работоспособность приложения. Вот и вся разница.
___>>Не понял разницы. ДотНет программы тоже не обязывают. А даже если бы обязывали: "также как считать, что пользователи могут залить клавиатуру кофе недостатком клавиатуры."
H>В смысле не обязывают? А эти конфиги упоминаемые тут для настройки ремотинга? Для пользователей любящих кофе давно есть клавы-"непромокайки" , и даже буки такие есть (видимо производитель счел, таки, недостатком )
Ээээ ты просто не в курсе, действительно не обязывают. Как хранить и использовать это секцальное дело программиста, может использовать конфиги стандартные, может свой велосипед изобрести, может для каждого компа в коде все прошить.
