Может вопрос не по теме но имеет ли смысл углубленно изучать книгу по defphi 7 если там рассматриваются "устаревшие" технологии типа BDE или начать изучать платформу .net и писать все под .net?

книги вообще не имеет смысла изучать - пустая трата времени

Ну BDE уже изучать не обязательно, ИМХО.
ДотНЕТ имеет смысл изучать, если ты на нём собираешься писать.

> den303  (14.04.2008 13:40:02)  [2]

На ДотНЕТ не выйдет, это не язык.

> Anatoly Podgoretsky ©   (14.04.08 13:46) [3]


IL?

> oxffff ©   (14.04.08 14:20) [4]

это часть технологии

> IL?

Нет, это тоже отдельный язык, правда промежуточный.
.NET это не язык, а технология, в которую входит как минимум 22 языка, сейчас наверно больше.

> .NET это не язык, а технология, в которую входит как минимум
> 22 языка, сейчас наверно больше.


Скорее 22 языка поддерживают компиляцию в CLR. Который есть скелет .Net.

А какой именно смысл несет в себе технология .NET, что это, internet, www.domain.net, или чтото еще... ?

Что в этой технологии такого хорошего. ?

> Anatoly Podgoretsky ©   (14.04.08 14:58) [6]


В .NET язык один который понимает CLR. Это IL.
Все остальные - это высокуровневые обертки.

> oxffff ©   (14.04.08 15:11) [9]

Так вы договоритесь сначала с tesseract, подеритесь, а потом я подойду, толи вас разнимать, то ли ветку закрыватью На всякий случай, твой ответ правильный.

> Что в этой технологии такого хорошего. ?

Это managed code и возможность наследования от системы, а не от от твоих или других посторонних объектов. Второе не менее важно, чем первое.

> На всякий случай, твой ответ правильный.


Я и не спорю.


> а технология, в которую входит как минимум 22 языка,


Я это слегка переосмыслил.

.Net просто FrameWork, с некоторым шансом кросплатформенности (см mono-project). Ничего особо такого нового я в нём для себя не вижу.

> Anatoly Podgoretsky ©   (14.04.08 13:46) [3]

Дык а ни я, ни Костик не использовали термин "язык" :o)

> tesseract  (14.04.2008 16:09:12)  [12]

На данном этапе можно считать и так, ну не выполнили они свое обещание на основе .NET обошлись фреймворком, силенок не хватило, а ведь монстры.

> den303  (14.04.2008 16:28:13)  [13]

Ну я использовал, а что?

> силенок не хватило, а ведь монстры.


Задача-то весьма непростая.

С другой стороны JAVA для стральных машинок делалась - и кстати довольно активно используеться по своему предназначению ( например HTTP очень тяжко самому на ASM-E писать ). .Net  интересен имеено как Java -Beans - кучка .Net сборок очень даже неплохой вариант.

>  и кстати довольно активно используеться по своему предназначению


* Как FrameWork  для программирования малой автоматизации.

> .Net просто FrameWork, с некоторым шансом кросплатформенности
> (см mono-project). Ничего особо такого нового я в нём для
> себя не вижу.

Не пишешь серьёзно, вот и не видишь.

Я когда только Overview из SDK прочитал, сразу увидел несколько вещей, которые трудно или невозможно сделать в Дельфи.

А на кроссплатформенность чихать.

> Я когда только Overview из SDK прочитал, сразу увидел несколько
> вещей, которые трудно или невозможно сделать в Дельфи.


А пример не привидете?

P.S.

Я например прочитал ECMA 335 и Expert .NET 2.0 IL Assembler.
Не говоря уже о Рихтере (который увы менее конкретен чем вышеуказанные).

>  которые трудно или невозможно сделать в Дельфи.


Пример в студию.

Книгу вообще изучать нет смысла.
Есть смысл что-то изучать по книге.
Если книга хорошая, разумеется.
Я, например, в свое время изучал язык Modula-2 по книге.
Очень хорошей. Хотя на этом языке я не программировал. И даже и не собирался на нем программировать.
Но изучение мне помогло понять, что такое абстракция и реализация и в дальнейшем лучше ориентироваться в некоторых вещах при программировании на том же Delphi.
А вообще Delphi7(6) до сих пор прекрасный инструмент для быстрого написания приложений для Win32. И я бы в любом случае его освоил. Хотя бы в общих чертах (как создавать классы и использовать их на практике для решения конкретных задач).
Даже если бы собирался всю жизнь программировать на .NET.
Так как в Delphi все это сделано удобно и помещается в один исполняемый файл, который можно запустить под любым Windows-ом, независимо от того стоит там какой-нибудь фреймворк или нет и какой он там версии.

> kaif ©   (15.04.08 02:57) [21]

ну Библию, например, изучают :)

Согласно

http://www.bitwisemag.com/2/CodeGear-Delphi-JBuilder-and

The focus of Delphi has varied somewhat in recent years. Not so long ago, it was being strongly targeted for .NET development to the extent that it even had a .NET VCL (Visual Component Library) which was broadly compatible with the Win32 VCL, thus easing the development and migration of applications between Win32 and .NET. The existing and forthcoming versions still have support for .NET but this is being rather downplayed these days. The current version, for example, only targets .NET 2.0 whereas Microsoft’s own compilers are now working with .NET 3.5. At any rate, it seems that CodeGear has concluded that the Win32 platform is alive and well and, having been largely deserted by Microsoft itself (with the end of the ‘classic’ VB product line, Microsoft’s only Win32 programming language is its rather ‘non-visual’ C++) presents a large development ‘niche’ which Delphi can fill nicely.

New features in Delphi ’Tiburon’ will include enhanced client-server development and a "totally rewritten" VCL which will be unicode enabled.

“There’s still a lot of native development going on,” Jason Vokes insists, “So that’s where we are playing to our strengths.”

I make no secret of the fact that Delphi is my preferred Win32 language/IDE/compiler. So I await developments with interest...

Жаль что

The next major version is code-named Tiburon and is scheduled for release in the ‘second half’ of 2008.

Ранее говорили, что в первой половине.
Надеюсь это только на пользу пойдет.

> oxffff ©   (14.04.08 20:26) [19]
> tesseract ©   (14.04.08 20:31) [20]
> Пример в студию.
На делфи очень трудно программировать формулы, оперирующие комплексными значениями. Приходится переводить формулу в последовательность обращений к подпрограммам либо писать для этих целей препроцессор. Математику-вычислителю могут понадобиться не только комплексные числа. Бывают задачи точного обращения целочисленных матриц - там требуется рациональная арифметика. Или взять аналитические методы небесной механики - там требуется вычислять формулы составленные из рядов Пуассона.

Я не знаю, в каком состоянии сейчас наше образование, знаю, что в некоторых из них учат делфи. Не знаю, что будут делать выпускники этих институтов, если их попросят рассчитать геометрию антенны. Как они будут считать функции Ханкеля? Конечно, они перейдут на си++, тем более, что на этом языке имеется много наработок.

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


Мы mathcad  использовали.


> На делфи очень трудно программировать формулы, оперирующие
> комплексными значениями.


Гм тут не знаю. Не программировал. Не хватает конечно типов numeric и тд.

На делфи очень трудно программировать формулы, оперирующие комплексными значениями.

Вы имеете ввиду перегрузку операторов?
Так ее уже ввели.
А если Delphi 7, тогда если не нравится писать вызовы методов, процедур вместо + -  пожалуйста зарегистрируйте наследник Tcustomvariant, и переопределите методы Unary, binary и cast операций.
Матрицы, шматрицы, ряды и т.д.

Более того вы можете даже определить позднее связывание для произвольных типов без общего родителя и опять же variant c IDispatch (используя эту технику вы можете определить свое подмножество языка и
писать как угодно).
Матрицы, шматрицы, ряды и т.д.

var a:variant;
begin

a:=CreateMegaType(2,3);
a:=a.MEGAFUN_OP(2,3)+a.MEGAFUN_OP(2,3).Transform(3,5);

P.S. Было бы желание.

> Я не знаю, в каком состоянии сейчас наше образование, знаю,
>  что в некоторых из них учат делфи. Не знаю, что будут делать
> выпускники этих институтов, если их попросят рассчитать
> геометрию антенны. Как они будут считать функции Ханкеля?
>  Конечно, они перейдут на си++, тем более, что на этом языке
> имеется много наработок.


То есть, наработки на delphi тебе не попались, ты не искал, нафиг не нужны (нужное подчеркнуть)

<offtopic>
Народ, а какое вообще отношение имеет перегрузка операторов к вопросу о .NET? :) Вот он - стиль местного коммьюнити. Сцепиться по какому-нибудь побочному вопросу и уйти в дебри, вместо того, что бы топик обсуждать :)
</offtopic>

По теме: по-любому .NET изучить стоит, хотя бы и теоретически.

TInvokeableVariantType и вперед

> По теме: по-любому .NET изучить стоит, хотя бы и теоретически.


Так мы же написали что прочитали ECMA 335 и .NET ASM 2.0.
Использовали и С# и напрямую IL и ILDASM пользовались. и JETBrains.

P.S. Ну не лежит душа к нему. Хоть тресни.
Delphi нравится.

a:=CreateMegaType(2,3);
a:=a.MEGAFUN_OP(2,3)+a.MEGAFUN_OP(2,3).Transform(3,5);
Интересно. А как это расшифровать? Типа:


А что значит регистрировать наследника? Регистрируется COM-интерфейс? Насколько при этом трудоемок вызов функций и передача параметров?

см TComplexVariantType
пример

http://www.delphisources.ru/pages/faq/base/user_variants.html

Если не нравится динамическая variant обертка, нужна скорость перегрузка запись операторов  в  помощь.

> А что значит регистрировать наследника? Регистрируется COM-
> интерфейс?


ClassHelper регистрируеться. Перегрузка операторов как в с++ - штучка полезная.

> ClassHelper регистрируеться.

Не знаю что это такое. Попробую спросить по-другому. Для того, чтобы сложить два комплексных числа сколько потребуется операций процессора.

> P.S. Ну не лежит душа к нему. Хоть тресни.
> Delphi нравится.

Душа - это дело такое, к профессиональной деятельности касательства не имеющая. Вот у меня щас душа лежит к Лиспу и Прологу, а на работе - С++.
Вешаться что ли? :)

> oxffff

Спасибо за ссылки. Попробую разобраться на досуге.

> Вешаться что ли? :)


Зачем?
Главное знать как это работает. :)

P.S. У вас хороший багаж.

А я вот тут на днях прикрутил хранимую процедуру к SQL2005. К 64-х битному. На .net-е задача решается. На Delphi - если только под тем же .net-ом.

А вообще, если ориентироваться на разработку под .net с использованием всех возможностей библиотеки (включая WinForms), то лучше уходить под VisualStudio.

vuk ©   (15.04.08 12:11) [40]


> А вообще, если ориентироваться на разработку под .net с
> использованием всех возможностей библиотеки (включая WinForms),
>  то лучше уходить под VisualStudio.


и зачем в хранимке winforms ? :)

to Игорь Шевченко ©   (15.04.08 12:12) [41]:
>и зачем в хранимке winforms ? :)
А я что, сказал, что оно в хранимке? Вроде ж нет... Тогда откуда ты это взял? :)

> То есть, наработки на delphi тебе не попались, ты не искал,
>  нафиг не нужны (нужное подчеркнуть)

Почему "то есть". Я всего лишь написал, что на си++ много наработок. За те несколько лет, что существует перегрузка операций в делфи, возможно, и здесь появились какие-то наработки. Но по комплексным вычислениям их гораздо больше на си++ и фортране.

vuk ©   (15.04.08 12:15) [42]

Да это я синтезировал :)

palva ©   (15.04.08 12:20) [43]

Я извиняюсь, в фортране и в чистом С нету перегрузки операторов, в чистом С даже встроенного типа COMPLEX нету, как в Фортране. Однако ж математики на С понаписано немало. Я к чему - я к тому, что и на паскале хватает математики понаписаной, для которой перегрузка операторов нафиг не сдалась.

> На Delphi - если только под тем же .net-ом.

Ну почему же - Extended Stored Procedures вроде можно (теже dll), но с вами согласен clr приятнее. Как-то надо было по расписанию импортировать удаленные данные, не из базы и не сервисы, быстро и удобно. :)

to b z   (15.04.08 12:31) [45]:
>Extended Stored Procedures вроде можно
Под SQL2000 они именно и использовались. Но, если не ошибаюсь, под SQL2005 они считаются obsolete. К тому же подпихивать 64-битному процессу 32-битную .dll как-то не хорошо, что ли. :)

> Зачем?
> Главное знать как это работает. :)

Да-а-а... а вот некоторые (пальцем не буду показывать), считают, что программисту надо знать только сопромат, циклы и ветвления... :)


> P.S. У вас хороший багаж.

Спасибо за комплемент :)

> Я извиняюсь, в фортране и в чистом С нету перегрузки операторов

Речь ведь шла о расчете антен, а это уравнения матфизики в комплексной области, т. е. требуется комплексная арифметика. Будучи студентами (1971) мы использовали для этого фортран. Паскаля тогда не было, был алгол. Но он тоже был малоподходящ из-за отсутствия комплексной арифметики. Поэтому наработки тех лет накапливались на фортране. В новых разработках стали использовать си++, популярные пакеты тоже стали переводить на си++. На си тоже много понаписано, но там где не требуется перегрузки. Код си легко сочетается с кодом си++, и проблем при подключении не возникает. А вот делфи... Если бы в делфи вовремя появилась перегрузка операций, то, возможно, в то время вычислительные методы охотно портировали бы на делфи. Теперь этим занимаются в основном студенты в курсовых проектах. Препод прекрасно знает, что делфи-реализацию какого-то численного метода не найти - серьезные люди этим не занимаются. Вот он и дает такие задания студенту. А студент постоянно задает вопросы в "Начинающих" где найти симплекс-метод на делфи - только обязательно на делфи. Или "помогите перевести с си на делфи" - тоже очень популярный вопрос. Найти реализацию на си - проблем нет. А вот чтобы ублажить препода и дать ему код на делфи, приходится потрудиться.

palva ©   (15.04.08 13:24) [48]


> Поэтому наработки тех лет накапливались на фортране.


Да, я в курсе. У меня даже книжки были со сборниками алгоритмов на фортране.


> В новых разработках стали использовать си++, популярные
> пакеты тоже стали переводить на си++. На си тоже много понаписано,
>  но там где не требуется перегрузки


давным-давно много математических пакетов было переведено с фортрана на С. Еще когда не было С++


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


Причем тут перегрузка операторов ?

> давным-давно много математических пакетов было переведено с фортрана на С. Еще когда не было С++
Когда не было си++ то единственным преимуществом си перед паскалем было то, что структура языка была лучше приспособлена к процессору и позволяла создать более эффективный, лучше оптимизирующий вычисления компилятор.

> Причем тут перегрузка операторов ?
При том, что она сделала бы удобным использование паскаля для инженерных вычислений, требующих комплексную арифметику.

palva ©   (15.04.08 14:49) [50]

Я о другом - я о том, что математику переводили на С, в котором не было перегрузки операторов. И ничего, никто не умер ни в процессе перевода, ни в процессе пользования.


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


Какая нафиг разница для компилятора, переводить
double a,b;
...
a = b + foo(a,b);

или

var
 a, b: Double;
begin
...
 a := b + Foo(a,b);
end;

?

> Какая нафиг разница для компилятора, переводить...

В данном примере, возможно, и нет разницы.
У меня возникает стойкое ощущение, что вы в чем-то со мной не согласны. Но вот в чем - понять не могу.

palva ©   (15.04.08 15:16) [52]

Дело не в несогласии, Аллах с ним, с несогласием. Дело в утверждении, что паскаль и Delphi не пригодны для математических алгоритмов. Вот тут у меня противоположное мнение.

Теперь понятно.