Здравствуйте, lifrsdn, Вы писали:
L>Здравствуйте, DOOM, Вы писали:
DOO>>Тем и читабельнее. Почему-то в исходники самбы, написанной на C я могу въехать за пару тройку часов, а в среднестатистическую C++'ную программу и за пару дней не въеду. DOO>>Временные переменные при этом есть везде — но вот возможность на каждый блок объявить свою, как ни странно, сильно захламляет код.
L>Ой, то есть Вы ещё и помните, что вот эту временную переменную уже можно использовать заново, а вот эту не стоит?
Не понял замечания. Когда переменную всегда надо объявлять в одном месте, то у тебя временные переменные будут универсальны — какой-нибудь tmp, который будет каждый раз использоваться. В случае, когда переменную можно объявить где угодно, сразу начинается злоупотребление (еще и с венгерской нотацией какой-нибудь для полного счастья).
L>>>Во-вторых — оно в каких случаях нужно-то? DOO>>Что конкретно? Понять, что это перегруженный оператор? Это нужно когда читаешь/модифицируешь чужой код.
L>Писать в каких слуаях это нужно: когда нужно явно вызывать неявное приведение типов?
Ты о чем? О том примере — это было так, что ввспомнилось из смутного прошлого. В общем и целом перегрузка операторов делает код write only.
P.S. А я еще и ООП в целом не люблю
L>Ну вот сколько бы я не видел реализаций С++ везде был препроцессор. А в Дельфи? А сколько реализаций Дельфи ты видел?
DOO>>А каким основным? DOO>>Про деструкторы? Что-то есть — я просто сейчас уже точно не смогу грамотно на эту тему поспорить. DOO>>Про обязательность вызова конструктора как-то не понял, что имелось ввиду.
L>Сразу про оба отвечу:
L>
L>class ABigComplexData
L>{
L>public:
L> ABigComplexData(...){...};
L> ~ABigComplexData(){...};
L> void Go(){...};
L> ...
L>}
L>void use()
L>{
L> //тут с abcd ничего делать нельзя, его ещё нет
L> ABigComplexData abcd(...);
L> //тут он уже сконструирован
L> abcd.Go();
L> ...
L> if(...)
L> return;//деструктор вызван автоматически
L> ...
L> //тут тоже
L>}
L>
А теперь замени на ABigComplexData на ABigComplexData * — и пойми, что в Дельфи объект это всегда указатель на объект.
L>На дельфи не писал очень давно, пишу по памяти, если что поправляйте.
L>[pascal] L>class ABCD L>begin L> constructor Init(); L> destructor Done(); L> procedure Go(); L> ... L>end;
DOO>>Шаблоны — на вкус и цвет. Мне они как-то не нравились в свое время.
L>Ну хорошо, вопрос в лоб — нужен список элементов T, которые мы только что придумали. Аналог std::list<T> какой?
Tlist, потому что все классы наследники TObject. Сейчас ты мне скажешь, что мне компилятор ни фига не проверит, что в моем TList'е все объекти одного класса, но я, сильно поднатужившись, приведу тебе примеры, какую динамику это дает — просто программер на C++ с шаблонами не мыслит о своей программе как о чем-то меняющемся во время выполнения.
DOO>>Про оптимизатор на уровне Intel C++ — ну и сколько процентов народу используют этот компилятор? А у остальных тоже не такие уж выдающиеся результаты по сравнению с ним.
L>А фокус в том, что он есть. И если нужно — можно использовать. А в дельфи — нужно, не нужно, а про качественную машинную оптимизацию можно забыть.
Была старая статья здесь на сайте по сравнению скорости работы разных компиляторов — дак вот, если откроешь, то увидешь 2 факта:
1. Intel C++ не всегда рулит
2. Delphi иногда очень сильно обходит других
TEO>Кризис мозга у обоих в чистом виде. Читайте оба — Википедиа — C++, особенно раздел "История". А вот потом уже делайте различные умозаключения, только, пожалуйста, исторически и логически правильные.
Прочитал. Только утвердился в своих предположениях. Есть что-то сказать по существу?
Здравствуйте, TheEvilOne, Вы писали:
TEO>Конечно, про ROCS, видимо, ни Вы, ни Ваши "заказчики" и слыхом не слыхивали.
Во-первых, я где-то упомянул заказчиков? Вроде как нет...
А во-вторых, чем в этом случае мне поможет зубная паста? Ибо кроме нее с таким именем гуголь ничего не знает.
Здравствуйте, DOOM, Вы писали:
DOO>А теперь замени на ABigComplexData на ABigComplexData * — и пойми, что в Дельфи объект это всегда указатель на объект.
L>>Ну хорошо, вопрос в лоб — нужен список элементов T, которые мы только что придумали. Аналог std::list<T> какой? DOO>Tlist, потому что все классы наследники TObject. Сейчас ты мне скажешь, что мне компилятор ни фига не проверит, что в моем TList'е все объекти одного класса, но я, сильно поднатужившись, приведу тебе примеры, какую динамику это дает — просто программер на C++ с шаблонами не мыслит о своей программе как о чем-то меняющемся во время выполнения.
Ты не понял. Во-первых, в C++ можно и std::list< void * >, во-вторых, это дает не гибкость, а широкое поле для ошибок и проблем с приведением типов. И конечно же негативно сказывается на производительности.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, gandjustas, Вы писали:
kuj>>>.NET куда больше взяла из мира Java все-же.
G>>А язык C# взял очень много от языка Delphi.
kuj>Это шутка? Можно хотя бы пять первых пунктов?
1)Свойства
2)Делегаты и события
3)Cсылочная объектная модель (хотя этоже характерно и для Java)
4)ref и out параметры.
5)(больше вопрос платформы) Основная направленность на Windows
Здравствуйте, gandjustas, Вы писали:
kuj>>Здравствуйте, gandjustas, Вы писали:
kuj>>>>.NET куда больше взяла из мира Java все-же.
G>>>А язык C# взял очень много от языка Delphi.
kuj>>Это шутка? Можно хотя бы пять первых пунктов?
G>1)Свойства
Java get/set
G>2)Делегаты и события
Java
G>3)Cсылочная объектная модель (хотя этоже характерно и для Java)
Reference/value вообще-то. Это от Java (хотя и не совсем полностью).
G>4)ref и out параметры.
Java
G>5)(больше вопрос платформы) Основная направленность на Windows
В C# гораздо больше взято от Java, чем от Object Pascal.
Здравствуйте, hattab, Вы писали:
H>Да-да. Я это уже слышал и не раз. За короткий срок невозможно научиться грамотно программировать на чем-бы то нибыло. Я соглашусь, что двоечнику после Delphi-AccessViolation'ов будет легче под .Net/Java. Однако создавать качественного продукта он не сможет. Пердульки бухгалтерские его удел. Максимум.
...
H>Поменять парк бухгалтерских машинок из-за одного криворукого идиота? Мы пойдем другим путем.
Сопоставляя выделенное можно сделать неутешительные выводы.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, hattab, Вы писали:
MC>>>Речь не о SOAP-сервисах, а о создании веб-морд. Т.е. упрощенно — когда есть HTML-шаблоны и java/.net код, который на их основе хитро генерит динамические страницы. Ну, короче, как в php.
H>>WebSnap. Ребята, оно было еще в 6 версии. Intraweb еще круче
kuj>Хочу полноценный MVC с unit test`ами и расширяемым view-engine по типу Brail (из Castle Monorail)! Где?
Здравствуйте, sndanil, Вы писали:
S>Здравствуйте, hattab, Вы писали:
H>>>>Дженерики есть в 2007 под .Net. В 2008 обещают и для нативного кода. G>>>Мда... Это на фоне того, что появилось в C# 3.0 в 2007 году. Делфи тут оооочень сильно отстает.
H>>Уж не про LINQ ли ты говоришь Ну в 2008 или 2009 обещают анонимные методы добавить еще.
H>>Заметь, не я тут на языки наезжал не имея представления о текущем положении дел.
S>немного улыбнуло ... ты в каком году живешь, раз у тебя это уже текущее состояние дел?
Дернуть слова из контекста и поржать. Намана. А вдумчиво и с начала?
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, hattab, Вы писали:
H>>>>Ты знаешь, для меня веб-разработка, где-то очень далеко за горизонтом G>>>А зря. Дядька Фаулер еще в 2003 году сказал что если нет особых причин разрабатывать desktop клиент для корпоративного приложения, то лучше сразу заниматься веб-мордой. Web уже давно не только сайты знакомств и порнуха. Ты отстатешь от прогресса.
H>>Т.е. все не веб-девелоперы сидят в глубокой #опе прогресса... Я говорю, WebSnap был уже в 6 версии (ты говоришь сидел на 7 и не знаешь об этом?) И вообще, не сотвори себе кумира.
kuj>Что на этом WebSnap`е хоть было написано? Урлы сайтов плиз.
Если тебе интересны существующие проекты под WebSnap, самое время погрузиться в гугл. Мне оно надо?
Здравствуйте, kuj, Вы писали:
G>>1)Свойства kuj>Java get/set
Это не свойства
G>>2)Делегаты и события kuj>Java
Их в Java нет, в основном интерфейсы с одинм методом применяются
G>>3)Cсылочная объектная модель (хотя этоже характерно и для Java) kuj>Reference/value вообще-то. Это от Java (хотя и не совсем полностью).
Это для многих языков
G>>4)ref и out параметры. kuj>Java
Нет их там
G>>5)(больше вопрос платформы) Основная направленность на Windows kuj>
kuj>В C# гораздо больше взято от Java, чем от Object Pascal.
Здравствуйте, kuj, Вы писали:
kuj>Как в Delphi обстоят дела с unit test`ами? О каком scalability приложения может вообще идти речь, когда нет ни unit test`ов, ни DI/IoC?...
Здравствуйте, gandjustas, Вы писали:
G>Тем более WPF при простом рисовании окошек и двумерной графики практически не тормозит на современных компах.
При простом рисовании окошек и двумерной графике ГУЙ вообще не имеет права тормозить на современных компах.
Я так понимаю "практически не тормозит" в данном случае означает "тормозит, но еще пока терпимо"
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, DOOM, Вы писали:
L>>Ой, то есть Вы ещё и помните, что вот эту временную переменную уже можно использовать заново, а вот эту не стоит? DOO>Не понял замечания. Когда переменную всегда надо объявлять в одном месте, то у тебя временные переменные будут универсальны — какой-нибудь tmp, который будет каждый раз использоваться. В случае, когда переменную можно объявить где угодно, сразу начинается злоупотребление (еще и с венгерской нотацией какой-нибудь для полного счастья).
Ну и надо всё время проверять, что в этом месте процедуры этот tmp ещё нужен, а чуть ниже по тексту уже нет.
L>>>>Во-вторых — оно в каких случаях нужно-то? DOO>>>Что конкретно? Понять, что это перегруженный оператор? Это нужно когда читаешь/модифицируешь чужой код. L>>Писать в каких слуаях это нужно: когда нужно явно вызывать неявное приведение типов? DOO>Ты о чем? О том примере — это было так, что ввспомнилось из смутного прошлого. В общем и целом перегрузка операторов делает код write only. DOO>P.S. А я еще и ООП в целом не люблю
Ну так написать везде можно так, что потом 100 лет не расхлебаешь.
L>>Ну вот сколько бы я не видел реализаций С++ везде был препроцессор. А в Дельфи? DOO> А сколько реализаций Дельфи ты видел?
Одну. От Борланда. Вы назовёте ту, где есть препроцессор?
DOO>А теперь замени на ABigComplexData на ABigComplexData * — и пойми, что в Дельфи объект это всегда указатель на объект.
Ну и что в этом хорошего? Кстати, kuj про shared/scoped_ptr не зря вспомнил. В дельфи как их реализовать?
DOO>>>Шаблоны — на вкус и цвет. Мне они как-то не нравились в свое время. L>>Ну хорошо, вопрос в лоб — нужен список элементов T, которые мы только что придумали. Аналог std::list<T> какой? DOO>Tlist, потому что все классы наследники TObject. Сейчас ты мне скажешь, что мне компилятор ни фига не проверит, что в моем TList'е все объекти одного класса, но я, сильно поднатужившись, приведу тебе примеры, какую динамику это дает — просто программер на C++ с шаблонами не мыслит о своей программе как о чем-то меняющемся во время выполнения.
Это дает лишний уровень косвенности, хранятся-то там тогда не объекты, а указатели на них. На маленьких по размеру теряем, это ж каждый раз надо из кучи дергать по несколько байт.
Но намного важнее то, что в реальных задачах нужны списки чего-то, а не всего чего угодно. В С++ с шаблонами за этим следит компилятор и дает по рукам при попытке это нарушить. Кроме того не надо делать лишних и опасных движений, вроде приведения типов. При этом в С++ не запрещено выделить некоторую сущность и хранить список [умных] указателей на неё, приводя по мере надобности. Гибкость есть. И свобода выбора.
DOO>>>Про оптимизатор на уровне Intel C++ — ну и сколько процентов народу используют этот компилятор? А у остальных тоже не такие уж выдающиеся результаты по сравнению с ним.
L>>А фокус в том, что он есть. И если нужно — можно использовать. А в дельфи — нужно, не нужно, а про качественную машинную оптимизацию можно забыть. DOO>Была старая статья здесь на сайте по сравнению скорости работы разных компиляторов — дак вот, если откроешь, то увидешь 2 факта: DOO>1. Intel C++ не всегда рулит DOO>2. Delphi иногда очень сильно обходит других
Не спорю. Но работа с плавающей точкой, а именно это меня в своё время интересовало, у интела сделан на 5+.
DOO>Но вообще статейку не мешало б обновить...
Здравствуйте, kuj, Вы писали:
kuj>>>Хотя это и повсеместная практика на КСВ, но все-таки это не хорошо кидаться безосновательными утверждениями...
H>>Прикольная практика это ссылки просить по всякому поводу. Где же мне их помнить, истории уж полгода если не больше...
kuj>А что прикажешь делать? Верить тебе на слово про звон?
Я еще раз говорю, у меня нет идеи доказать тебе чего-то Я описал реальную ситуацию, а вопросы веры это не ко мне.
H>>Я же упомянул о сигналящем менеджере. Что еще фактору нужно? Нужно в смирительную рубашку погрузить тело бренное, чтоб не дай бог глаз вилкой не выколол... Есть инструмент контроля. О чем тут спорить еще?
kuj>Ты хоть понял о чем речь? В человеческой натуре допускать ошибки. Задача современного языка программирования создать максимально гибкий и удобный инструмент с минимальной вероятностью допустить ошибку по вине данного человеческого фактора.
Да не избавляет вас управляемость от алгоритмических граблей и утечек. Работая с инструментом надо знать, как с ним работать, а не так, как проповедовал gandjustas. Все вокруг этого вертится.
H>>Есть другие идеи улыбающиеся мне сильнее чем дженерики и дающие не меньше пользы. Ну вот честно скажу, дженерики это хорошо и привлекательно.
kuj>Не понял при чем тут другие идеи, которые тебя привлекают больше? Мне вот игра в снукер нравится больше, чем яблоки и что?
Мы говорили о плюсах и минусах, если ты забыл. Ну и дженерики, это вроде как плюс .Net/Java. Но насколько это весомый плюс, большой вопрос. Я понят?
kuj>>>Поясняю: препроцессорная реализация это костыль. Имея generics на языковом уровне я получаю все плюшки статически типизированной среды разработки: intellisense, refactoring и прочее.
H>>Все это понятно и никто не оспаривает собственно идеи дженериков Чего на этом так заостряться? Будут они у нативных дельфистов во второй половине этого года
kuj>Угу, в Вилариба еще моют, а в Вилабаджа уже празднуют.
Ну в 2007 для .Net уже есть. Успокойся. Вам нативу-то вообще противопоставить нечего