Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Неужели Дельфи настолько убог !!!
|
|||
|---|---|---|---|
|
#18+
Берите, учите и работайте на ассемблере, на нем можно абсолютно сделать все, и РСУБД Вам не нужны, SQL тоже учить придеться, все можно прекрасно сделать на этом замечательном абсолютно универсальном средстве. Тем более Вы такой универсал - и сетевое соединение настроите и БД спроектируете и клиента напишите и драйвер свой, если понадобится :) А вот утрировать не стОит. Тем более не понял вашего сарказма. М.б. от недостатка аргументов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2003, 15:19 |
|
||
|
Неужели Дельфи настолько убог !!!
|
|||
|---|---|---|---|
|
#18+
Ну разве что от "достатка" Ваших аргументов :) Наверное я что то пропустил в мире развития информационных технологий - с каких это пор к ПО выдвигается требование, чтобы оно охватывало все различные аспекты автоматизации и специалист был и кузнецом и жнецом и т.д. Каждый инструмент для своей цели, тот же PB идеально лепит клиентов, не надо на нем чего то еще делать, для этой цели существуют другие ПО и другие специалисты, другой области и куча стандартов взаимодействия между различными ПО. А от утопий универсального ПО и всезнающих специалистов лучше избавляться, IMHO это самая противная и вредная для профессии программиста болезнь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2003, 17:00 |
|
||
|
Неужели Дельфи настолько убог !!!
|
|||
|---|---|---|---|
|
#18+
2 f_w_p >Ну если освоение ТРЕХ инстументов вместо одного и последующее колупание с их совместным ипользованием вы называете минимизацией усилий и времени, то я пас. Во-первых 2 из того, что Вы называете инструментами, на самом деле являются языками программирования. Их знание (C/C++ точно, о фортране можно поспорить) является правилом хорошего тона для любого программиста. Как и знание Паскаля. Во-вторых я их знаю в необходимом объеме. Люди, с которыми я работаю абсолютно все тоже знают C/C++, а некоторые и фортран. Но без фортрана можно обойтись, так что дополнительные усилия тратить не нужно. В-третьих наличие только одного универсального средства (дельфей) само по себе не гарантирует, что задача решается оптималльным, в смысле затрат труда, способом. Скорее всего наоборот: как известно универсализм ВСЕГДА достигается за счет потери других качеств, так что в какой-то момент заплатить придется. Это как сторонники фокспро, выучившие один инструмент, пытаются им решать абсолютно все задачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2003, 01:42 |
|
||
|
Неужели Дельфи настолько убог !!!
|
|||
|---|---|---|---|
|
#18+
--Но без фортрана можно обойтись, так что дополнительные усилия тратить не нужно. в добавку. есть ряд считалок для моделирования, которые являются стандартом и написаны они на фортране. Я уже молчу, что оптимизаторы, под фортран самые лучшие. А для приложений, которые могут считать трехмерные матрицы со стороной 10 тыс. элементов по нескольку дней, даже выйгрыш в один день является критичным при стоимости консалтинга тысячи баксов в день. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2003, 20:07 |
|
||
|
Неужели Дельфи настолько убог !!!
|
|||
|---|---|---|---|
|
#18+
2 Lepsik Я согласен, с фортраном лучше чем без него, мне фортран нравится. Просто те библиотеки алгоритмов, которые мы используем идут в фортранном и в сишном виде. Как я понимаю из-за популярности C многие изначально фортрановские библиотеки были переписаны на C. Поэтому я и сказал, что без фортрана в принципе можно обойтись. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2003, 01:18 |
|
||
|
Неужели Дельфи настолько убог !!!
|
|||
|---|---|---|---|
|
#18+
фортран определенно был неплох в свое время, малость и я на нем успел поколупать. но то, что сейчас делает оптимизаторы С++ компиляторов, особенно в случае использования такого дела как inline-functions , фортрану и не снилось. особенно нехило оптимизирует именно под пень Intel C++ компилятор. Спорить ни с кем не хочу - любой желающий может просмотреть ассемблерные распечатки получающихся бинарных кодов. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2003, 03:18 |
|
||
|
Неужели Дельфи настолько убог !!!
|
|||
|---|---|---|---|
|
#18+
а что будет с kylix после интеграции с .net, в некоторых книжках по делфи упор делается что делфи-куликс хорошо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2003, 14:25 |
|
||
|
Неужели Дельфи настолько убог !!!
|
|||
|---|---|---|---|
|
#18+
В-третьих наличие только одного универсального средства (дельфей) само по себе не гарантирует, что задача решается оптималльным, в смысле затрат труда, способом. Скорее всего наоборот: как известно универсализм ВСЕГДА достигается за счет потери других качеств, так что в какой-то момент заплатить придется. Это утверждение верно и в обратную сторону. И м.б. в большей степени. Это как сторонники фокспро, выучившие один инструмент, пытаются им решать абсолютно все задачи А и не утверждаю, что Delphi годится для решения всех задач. Просто Delphi позволяет решать гораздо более широкий круг задач, чем PB или VFP. Причем эффективно! но то, что сейчас делает оптимизаторы С++ компиляторов, особенно в случае использования такого дела как inline-functions, фортрану и не снилось. особенно нехило оптимизирует именно под пень Intel C++ компилятор. Спорить ни с кем не хочу - любой желающий может просмотреть ассемблерные распечатки получающихся бинарных кодов. :) Тем ни менее для чисто расчетных задач Fortran лучше. Даже эффективнее чем C++. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2003, 08:37 |
|
||
|
Неужели Дельфи настолько убог !!!
|
|||
|---|---|---|---|
|
#18+
--vdimas --фортран определенно был неплох в свое время сейчас он еще лучше. 1. поддержка COM 2. поддержка мультипроцессорных маших на уровне кода (чего нету в C/C++) --но то, что сейчас делает оптимизаторы С++ компиляторов, особенно в случае использования такого дела как inline-functions, фортрану и не снилось это у тебя ИМХО от незнания. Хороший оптимизатор к Фортран всегда написать проще, потому как его синтаксис его реализован - один в один команды ассемблера. навороты C++ (типа перегрузка операторов, указатели) всегда оставляют почву для двухсмысленностей для оптимизатора, поэтому гарантировать всегда корректную оптимизацию уже поэтому нельзя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2003, 19:05 |
|
||
|
Неужели Дельфи настолько убог !!!
|
|||
|---|---|---|---|
|
#18+
2 Lepsik О чем, спор, вообще? О Formula Translation??? Откуда перегрузки? Каких операторов-маператоров?? на голых формулах С++ показывает себя чудесно. Я же просил - прогони через ассемблерный листинг фортран-компилятора сложную формулу и покажи результаты. А я те покажу на Intel C++ результаты. Тогда и продолжим обсуждение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2003, 00:50 |
|
||
|
Неужели Дельфи настолько убог !!!
|
|||
|---|---|---|---|
|
#18+
2 f_w_p > А и не утверждаю, что Delphi годится для решения всех задач. Просто Delphi позволяет решать гораздо более широкий круг задач, чем PB или VFP. А я с этим не спорю. Мое утверждение состояло в том, что вместо того, чтоб использовать один инструмент, может быть (но не обязательно) гораздо экономнее будет использовать несколько, которые относительно хорошо друг с другом совмещаются. Вопрос только в том, достаточно ли проект большой, чтоб окупить использование разных средств. Простые проекты конечно же лучше строить одним средством. Но там, где есть необходимость решения систем уравнений, я бы даже не задумывался. К тому же уже есть куча готовых фортран библиотек в исходниках, т.е. затрат труда почти ноль. А паскаль-библиотек на эту тему я встречал гораздо меньше, т.е. писать скорее всего нужно будет самому. >Причем эффективно! Все познается в сравнении. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2003, 02:03 |
|
||
|
Неужели Дельфи настолько убог !!!
|
|||
|---|---|---|---|
|
#18+
2 Lepsik >это у тебя ИМХО от незнания. Хороший оптимизатор к Фортран всегда >написать проще, потому как его синтаксис его реализован - один в один >команды ассемблера. это у тебя ИМХО от незнания. Фортран на разных процессорных платформах примерно одинаковый, а ассемблеры абсолютно разные, поэтому синтаксис Фортрана не может быть один в один с командами аасемблера ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2003, 03:47 |
|
||
|
Неужели Дельфи настолько убог !!!
|
|||
|---|---|---|---|
|
#18+
Все познается в сравнении. Согласен. М.б. мы туповаты, но вот работать с комплексными числами в Delphi получается как-то коряво. Приходится C++ привлекать:-( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2003, 08:09 |
|
||
|
Неужели Дельфи настолько убог !!!
|
|||
|---|---|---|---|
|
#18+
f_w_p писал:Согласен. М.б. мы туповаты, но вот работать с комплексными числами в Delphi получается как-то коряво. Приходится C++ привлекать:-( а по какому поводу грусть? а если я скажу, что точно так же с матрицами и векторами тоже весьма удобно на С++. :) Вроде бы такая ерунда - шаблоны, перезагрузка операторов и инлайн ф-ции, а столько удобств. Use & enjoy. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2003, 19:36 |
|
||
|
Неужели Дельфи настолько убог !!!
|
|||
|---|---|---|---|
|
#18+
после делфи, с++ как дар божий :-) тащщу все свои проекты на делфи, а сам с тоской думаю, как бы их дод си переделать... ладно, переделаю, жив если буду :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2003, 20:38 |
|
||
|
Неужели Дельфи настолько убог !!!
|
|||
|---|---|---|---|
|
#18+
2 Тоже Guest >это у тебя ИМХО от незнания. Фортран на разных процессорных платформах примерно одинаковый, а ассемблеры абсолютно разные, поэтому синтаксис Фортрана не может быть один в один с командами аасемблера Ошибочка. Из того, что ассемблеры абсолютно разные не следует, что они вообще не имеют общего подмножества команд. 2 vdimas >Вроде бы такая ерунда - шаблоны, перезагрузка операторов и инлайн ф-ции, а столько удобств. 1) Много удобств - много возможностей сделать ошибку. C/C++ излишне гибок для арифметических алгоритмов, чтоб приспособить его к таким вычислениям нужно в начале написать целую библиотеку классов/темплетов. 2) Оптимизатор для C писать сложнее, чем для фортрана. Достаточно посмотреть на оператор цикла: компилятор даже не может знать, какая переменная является переменной цикла, ее может не быть вообще. В C++ ситуация еще хуже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2003, 21:20 |
|
||
|
Неужели Дельфи настолько убог !!!
|
|||
|---|---|---|---|
|
#18+
2Guest это у тебя ИМХО от незнания я вообще-то писал компиляторы, в том числе по Си в том числе под многопроцессорные машины еще в 1989. семантика фортрана делает написание компилятора под него на ассемблер сравнительно легким делом в отличии от C/С++ . --поэтому синтаксис Фортрана не может быть один в один с командами аасемблера на уровне мнемоник один в один на любом ассемблере почти все базовые команды, кроме встроенных функций. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2003, 00:52 |
|
||
|
Неужели Дельфи настолько убог !!!
|
|||
|---|---|---|---|
|
#18+
c127 писал:1) Много удобств - много возможностей сделать ошибку. C/C++ излишне гибок для арифметических алгоритмов, чтоб приспособить его к таким вычислениям нужно в начале написать целую библиотеку классов/темплетов. это "в начале" уже давно позади ты хоть представляешь, сколько математических библиотек для С++ существует в мире. Даже не хочу давать ссылки, стоит копнуть любой поисковик, и тебя завалит этим. Ведь удобно же матрицами и векторами оперировать именно так: M1=(M2 + M3 / M4 * V5)+10. т.е. имея перезагрузку операторов, в зависимости от типа операндов выбирается соотв. ф-ия, т.е. соотв. перегруженный оператор. Т.е. при наличии ОТЛАЖЕННОЙ билиотеки, пользователю этой библиотеки гораздо труднее совершить ошибку, чем где бы то ни было (в приведеном примере, чтобы допустить ошибку, надо еще постараться ). Это отмечают все, кто плотно сидит на плюсах. с127 писал:2) Оптимизатор для C писать сложнее, чем для фортрана. Достаточно посмотреть на оператор цикла: компилятор даже не может знать, какая переменная является переменной цикла, ее может не быть вообще. В C++ ситуация еще хуже. Да, сложнее. Только на это пусть сетуют разработчики С++ компиляторов. А нам-то чего вздыхать??? Я же говорю, давай сравнивать ассемблерные распечатки скомпилированных аналогичных формул на С++ и Фортране. Сразу станет видно, who is who. (я уже сравнивал, Intel C++ дает обычно чуть ли не вдвое более короткий код для I386 и выше на одинаковых формулах) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2003, 02:06 |
|
||
|
Неужели Дельфи настолько убог !!!
|
|||
|---|---|---|---|
|
#18+
2c127 и Lepsik >Ошибочка. Из того, что ассемблеры абсолютно разные не следует, что они вообще не имеют общего подмножества команд. >на уровне мнемоник один в один на любом ассемблере почти все >базовые команды, кроме встроенных функций. Тут может быть только один ответ - Значится, команды пересылки (mov), сложения (add), умножения (mul), перехода (jmp) не являются базовыми, потому как мнемоники у них разные (если вообще есть). Какие же тогда являются? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2003, 05:34 |
|
||
|
Неужели Дельфи настолько убог !!!
|
|||
|---|---|---|---|
|
#18+
2 Тоже Guest >Тут может быть только один ответ - Значится, команды пересылки (mov), сложения (add), умножения (mul), перехода (jmp) не являются базовыми, потому как мнемоники у них разные (если вообще есть). Какие же тогда являются? Ну да, а компилятор переводит фортран-команды в мнемоники, а потом подает файл с мнемониками на вход линкеру. Могучий у тебя линкер однако. 2 vdimas >это "в начале" уже давно позади ты хоть представляешь, сколько математических библиотек для С++ существует в мире. Даже не хочу давать ссылки, стоит копнуть любой поисковик, и тебя завалит этим. Ты веришь в их эффективность? Я вот не очень. Мы как-то тут работали с одной C++ библиотекой, поставлялась в исходниках, причем создатели сразу заявили, что заботились в первую очередь об эффективности, поэтому не использовали STL, виртуальные функции и пр. Так вот когда взяли аналогичную C библиотеку разница оказалась больше чем в 100 раз в пользу С. Конечно можно заявить, что они просто не умели пользоваться C++, может это даже так и есть, но ты же призываешь использовать точно такие-же написанные кем-то библиотеки. >Ведь удобно же матрицами и векторами оперировать именно так: M1=(M2 + M3 / M4 * V5)+10. Удобно, согласен, но не намного проще, чем написать call mul(c,a,b,m,n) ..... call add(c,ax,bx,m,n) Это удобство ИМХО не окупает заплаченной за него цены. Кстати насчет "+ 10" это ты к чему число собрался прибавлять, не к матрице ли или вектору? И потом за каждым M4*M5 стоит куча C++ кода, а не ассемблера, а производительность C++ сомнительна. >Да, сложнее. Только на это пусть сетуют разработчики С++ компиляторов. А нам-то чего вздыхать??? Так мы же используем результат их труда, они же не боги, им сложнее - значит у нас будет медленнее работать. >Я же говорю, давай сравнивать ассемблерные распечатки скомпилированных аналогичных формул на С++ и Фортране. Сразу станет видно, who is who. (я уже сравнивал, Intel C++ дает обычно чуть ли не вдвое более короткий код для I386 и выше на одинаковых формулах) Во первых размер кода ничего не говорит о его производительности, во-вторых Intel - архитектура для домохозяек, она так задумывалась, так и получилось, нужно брать что-нибудь более профессиональное. Параллельные фортраны есть, а о параллельных C я что-то не слышал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2003, 02:48 |
|
||
|
Неужели Дельфи настолько убог !!!
|
|||
|---|---|---|---|
|
#18+
2 c127 >Ну да, а компилятор переводит фортран-команды в мнемоники, а потом >подает файл с мнемониками на вход линкеру. Могучий у тебя линкер однако. Причем здесь компилятор и линкер? Читай внимательно. Lepsik написал: >на уровне мнемоник один в один на любом ассемблере почти все >базовые команды, кроме встроенных функций. Я ответил: >Значится, команды пересылки (mov), сложения (add), умножения (mul), >перехода (jmp) не являются базовыми, потому как мнемоники у них разные >(если вообще есть). Где здесь сказано про компилятор и линкер? В данном случае, разговор как раз о мнемонике идет. Мнемоника отображает набор процессорных команд. И различается она, потому что сами наборы команд на разных процессорах разные. В качестве примера насчет "синтаксис Фортарана реализован - один в один команды ассемблера" - команды умножения на момент возникновения и развития Фортрана существовали далеко не на всех процессорах; на тех, где не было, умножение реализовывалось через сложение. Исходя из "синтаксис Фортрана реализован - один в один команды ассемблера" умножение в Фортане делается тоже через сложение - я, честно говоря, не помню, как в Фортране делается умножение, но думаю, что всяко разно не так . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2003, 06:06 |
|
||
|
Неужели Дельфи настолько убог !!!
|
|||
|---|---|---|---|
|
#18+
2 Тоже Guest >Причем здесь компилятор и линкер? Читай внимательно. Lepsik написал: >>на уровне мнемоник один в один на любом ассемблере почти все ... >Где здесь сказано про компилятор и линкер? В данном случае, разговор как раз о мнемонике идет. Не совсем так, перечитай себя раннего. Вот твое утверждение вроде бы доказывающее что Lepsik не прав: Тоже Guest>это у тебя ИМХО от незнания. Фортран на разных процессорных платформах примерно одинаковый, а ассемблеры абсолютно разные, поэтому синтаксис Фортрана не может быть один в один с командами аасемблера Как тут видно, разговор изначально шел как раз не о мнемониках, а об ассемблерах и незачем приплетать мнемоники, они к делу вообще не относятся. Компилятор не переводит исходный текст в мнемоники. Единственное, что я сказал, это что твое утверждение доказательством дремучести Lepsik-а не является. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2003, 06:50 |
|
||
|
Неужели Дельфи настолько убог !!!
|
|||
|---|---|---|---|
|
#18+
c127 писал:Ты веришь в их эффективность? Я вот не очень. Мы как-то тут работали с одной C++ библиотекой, поставлялась в исходниках, причем создатели сразу заявили, что заботились в первую очередь об эффективности, поэтому не использовали STL, виртуальные функции и пр. Так вот когда взяли аналогичную C библиотеку разница оказалась больше чем в 100 раз в пользу С. Конечно можно заявить, что они просто не умели пользоваться C++, может это даже так и есть, но ты же призываешь использовать точно такие-же написанные кем-то библиотеки. Ну все, хана! :) Дай мне, плиз, ту С-библиотеку, и я покажу, как из нее сдеалть С++ библиотеку с не меньшей, а (наверняка!) даже большей эффективностью и простотой использования. Апелировать мне чьими-то кривыми руками, да еще в плане математических билиотек (которых на С и С++ многие тысячи, а я услышал сравнение двух), IMHO не стоит. Я сквозь все топики вижу твое предпочтение в пользу С по отношению к С++. Ни из-за этого ли "молока" ты дуешь на воду? с127 писал:> Ведь удобно же матрицами и векторами оперировать именно так: M1=(M2 + M3 / M4 * V5)+10. Удобно, согласен, но не намного проще, чем написать call mul(c,a,b,m,n) ..... call add(c,ax,bx,m,n) угу, итого: у меня 1 строчка, у тебя 4, и причем совершенно неочевидно, что происходит. Пробежавшись быстро глазами по твоему варианту, стразу и не скажешь. И опять же - формула ерундовая. Я тебе и в 10 раз более сложную в одну строку распишу и будет наглядно и понятно, как на бумаге, а твоих там уже около 60-ти строк будет? автор писал:Это удобство ИМХО не окупает заплаченной за него цены. абсолютно никакой цены. переопределенный оператор - это ТАКАЯ ЖЕ точно функция, как и любая другая. Чудес не бывает. Если у кого-то что-то работает медленнее, так это значит только одно: оно НАПИСАНО так, чтобы работать медленнее. Алгоритмы ли, память ли, злоупотребление указателями или виртуальными ф-иями, не важно, оно просто хуже написано. И кончайте вы эти суеверия, это зависит только от рук, а не от вида ф-ии: обыкновенная, либо перегруженный оператор. автор писал:Кстати насчет "+ 10" это ты к чему число собрался прибавлять, не к матрице ли или вектору? Именно, показал перезагрузку сигнатуры оператора "плюс" для разных комбинаций операндов. Будет скомпилирован вариант, выполняющий прибавление скаляра к матрице. автор писал:И потом за каждым M4*M5 стоит куча C++ кода, а не ассемблера, а производительность C++ сомнительна. Очень прошу посмотреть на ассемблерный вход и выход из процедуры высокого уровня на С. (на С++ аналогично). Нехило тратиться машинных тактов, не правда ли? Сделав частоиспользуемые небольшие по размерам ф-ии инлайновыми, можно существенно повысить эффективность. Именно это я и имею в виду, когда предлагал взять вашу С библиотеку, и сделать из нее еще более эфективную С++ библиотеку. автор писал: >Да, сложнее. Только на это пусть сетуют разработчики С++ компиляторов. А нам-то чего вздыхать??? Так мы же используем результат их труда, они же не боги, им сложнее - значит у нас будет медленнее работать. Пошел детский лепет. Ты хоть представляешь, сколько денег вкладывается в разработку компилятора С++, а сколько в Фортран. Боги - не боги... Это бизнес, это деньги... Код, получаемый современными компиляторами С++ действительно один из самых лучших и эффективных. (это медицинский факт) Не надо голословия, я уже просил. Я каждый день несколько часов в сутки это вижу, вижу, какие фокусы с оптимизацией он выкидывает. фортран и Дельфи и VB просто курят, и будут курить и дальше, т.к. в С++ непрерывно вкладываются ср-ва. автор писал:Параллельные фортраны есть, а о параллельных C я что-то не слышал. Что-то я не слышал о стандарте параллельного Фортрана. Если кто-то разработал этот новый стандарт - то и флаг ему в руки. С++ имеет достаточно инструментов, чтобы реализовать ПРОИЗВОЛЬНУЮ стратегию синхронизации потоков исполнения, исходя из нужд каждой конкретной задачи. Где гарантия, что способ синхронизации, "зашитый" в имплементацию параллельного Фортрана, удовлетворит меня как разработчика? Так не долго и на "Logo" скатиться. :) С++, кстати, не имеет даже встроенного типа string с определеными над ней операциями. Зато имеет тонну библиотек, реализующих класс string путем различных стратегий, выбирай да пользуй, исходя из конкретных условий. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2003, 09:43 |
|
||
|
Неужели Дельфи настолько убог !!!
|
|||
|---|---|---|---|
|
#18+
Самое главное, расставляю точки над i. >Я сквозь все топики вижу твое предпочтение в пользу С по отношению к С++. Мне глубоко начхать на преимущества кого-то над кем-то. Меня заботит выбор оптимального средства в смысле сбережения моего труда. Сейчас я из этих соображений пишу на C++. >Ну все, хана! :) >Дай мне, плиз, ту С-библиотеку, и я покажу, как из нее сдеалть С++ библиотеку с не меньшей, а (наверняка!) даже большей эффективностью и простотой использования. Да пожалуйста: http://users.i.com.ua/~tchingiz/tools/HTK-3.2.1.win32.tar.gz Там есть исходники и ссылка на оригинальный источник. Мы тут с чингизом с нетерпением ожидаем C++ вариант. Чингиз даже предлагает в случае твоего успеха выставить тебе 2 бутылки пива. Время пошло. >Апелировать мне чьими-то кривыми руками, да еще в плане математических билиотек (которых на С и С++ многие тысячи, а я услышал сравнение двух), IMHO не стоит. Я тебе привел контрпример. Он является доказательством того факта, что ситуация совершенно реальная, в отличие от твоих теоретически рассуждений. Кроме того в области, покрываемой HTK таких библиотек во всем интернете было найдено как раз две. Многие тысячи - это из области сновидений. И потом ты можешь поручиться, что руки, написавшие одну выбранную тобой библиотеку из многих тысяч, прямые? Или ты собираешься весь код сам инспектировать? >угу, итого: у меня 1 строчка, у тебя 4, и причем совершенно неочевидно, что происходит. Пробежавшись быстро глазами по твоему варианту, стразу и не скажешь. И опять же - формула ерундовая. Я тебе и в 10 раз более сложную в одну строку распишу и будет наглядно и понятно, как на бумаге, а твоих там уже около 60-ти строк будет? Еще хуже, у меня получилось даже не четыре, а больше. Только дело в том, что не бывает почти таких формул в реальной жизни. Возьми любой учебник по вычметодам и посмотри, там такого почти нет. А ради тех исключений, которые есть, не стоит городить зоопарк классов. Вот это и имел в виду, когда говорил, что цель себя не окупает. А насчет неочевидно что происходит, так это у тебя не очевидно. Вот что такое, например M2, матрица, вектор, скаляр? Сразу не ответишь, нужно лезть по коду, а в сложном случае вообще не разберешься. Возьми для примера MATLAB, он умеет строить на выходе якобы читаемый C++ код примерно в твоем стиле. Разобраться просто невозможно. В фортран программе разобраться относительно несложно, кстати как и в C. >Именно, показал перезагрузку сигнатуры оператора "плюс" для разных комбинаций операндов. Будет скомпилирован вариант, выполняющий прибавление скаляра к матрице. А я тебе показал источник ошибок. В математике нет операции прибавления скаляра к матрице. И если кто-то по глупости напишет такую операцию, то ты ее в сложном тексте в жизни не найдешь. Это обратная сторона простоты записи: тяжело понять что там происходит. >Ты хоть представляешь, сколько денег вкладывается в разработку компилятора С++, а сколько в Фортран. А вот и пример насчет денег. 1996 год, большая фирма мелкософт, денег навалом, компилятор C/C++ - одно из приоритетных направлений. Маленькая фирма Watcom, денег мало. А компилятор C/C++ лучше (гораздо более быстрый код, к тому же многоплатформенный). И до сих пор мелкософт не догнал, хоть Watcom и не поддерживает навороты последних интелов. Вывод: денеги для создания эффективного компилятороа мало что значат. >Боги - не боги... Это бизнес, это деньги... Какие дньги, что ты несешь. Да не нужен никому сейчас супер эффективный код. Подумаешь, на 20%-100% медленне, кого это сейчас беспокоит. Есть гораздо более эффективное вложение денег, например в маркетинг, как это и делает мелкософт. Вот где деньги, а MS компилятор (оптимизатор) уже лет 5 как не меняется, а то и больше. >Код, получаемый современными компиляторами С++ действительно один из самых лучших и эффективных. (это медицинский факт) Не надо голословия, я уже просил. Вот это хороший, аргументированный ответ. >Я каждый день несколько часов в сутки это вижу, вижу, какие фокусы с оптимизацией он выкидывает. Может нужно бы еще посмотреть на фортран? Просто чтоб было с чем сравнивать. >Что-то я не слышал о стандарте параллельного Фортрана. Ты о многом не слышал. Это компилятор строит код для многопроцессорных платформ, типа 256 параллельных процессоров, а фортран тот же, может добавлена пара директив компилятору. Для C (C++ лучше не вспоминать) ты такое врядли сделаешь, из за тех же циклов, например. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2003, 03:51 |
|
||
|
Неужели Дельфи настолько убог !!!
|
|||
|---|---|---|---|
|
#18+
2c127 Еще раз говорю, внимательно читай Lepsik: >на уровне мнемоник один в один на любом ассемблере почти все >базовые команды, кроме встроенных функций. Я: >Значится, команды пересылки (mov), сложения (add), умножения (mul), >перехода (jmp) не являются базовыми, потому как мнемоники у них разные >(если вообще есть). Какие же тогда являются? Ты: >Ну да, а компилятор переводит фортран-команды в мнемоники, а потом >подает файл с мнемониками на вход линкеру. Могучий у тебя линкер однако. Lepsik говорит о мнемонике, я говорю о мнемонике, а ты почему-то о компиляции и линковании >Не совсем так, перечитай себя раннего. >Как тут видно, разговор изначально шел как раз не о мнемониках, а об >ассемблерах и незачем приплетать мнемоники, они к делу вообще не >относятся. Перечитал (смотри выше). И что? Кроме твоих сообщений, где тут разговор о том, во что переводит исходный текст компилятор или как работает линкер? Да был разговор о ассемблере и его мнемонике, он продолжается, но разговора о компиляторе и линковании не было. Хотя чувствую, что начнется, потому как твое утверждение >Компилятор не переводит исходный текст в мнемоники. является спорным. Скорее должно быть так, "В большинстве случаев компилятор не переводит исходный текст в мнемоники." Сразу поясняю на конкретном примере - старые борландовские сишные компиляторы в ряде случаев при компиляции генерировали ассемблерные файлы, а не объектный код >Единственное, что я сказал, это что твое утверждение доказательством >дремучести Lepsik-а не является. А что, есть такие, кто видит в моих словах доказательство дремучести Lepsik-а? Для таких (если такие найдутся): ни одно из моих утверждений не является доказательством дремучести ни Lepsika-а, ни c127, ни кого-нибудь другого ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2003, 04:16 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=32333641&tid=1554235]: |
0ms |
get settings: |
9ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
35ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
99ms |
get tp. blocked users: |
2ms |
| others: | 287ms |
| total: | 471ms |

| 0 / 0 |
