Здравствуйте, AVC, Вы писали:
AVC>Ага-ага, начинаю понимать. AVC>А для векторов длины 4 мы напишем еще один оператор:
float operator * (Vector4d &a, Vector4d &b)
и т.д. AVC>И так для каждой новой размерности. AVC>Вот здорово! Как просто-то!
Неа! Мы напишем шаблон и не будем забивать голову посторонними предметами.
AVC>Вот только я опять не понял:
"А если я захочу передать такую матрицу в некую функцию в качестве параметра?"
AVC>Намек: функция уже написана, откомпилирована и покоится себе в какой-нибудь DLL.
Ответный намёк: в твоей программе используются 4 вида матриц: плотные, разреженные, треугольные и диагональные. А алгоритм откомпилирован и покоится себе в каком-то модуле.
Что ты будешь делать?
— копи-пастом нарожаешь алгоритмы для всех видов
— или же сделаешь интерфейс матрицы (при этом, вот досада, все эти встроенные ARRAY OF ARRAY уже наружу торчать не будут) и пусть алгоритм работает через интерфейс
Здравствуйте, Cyberax, Вы писали:
C>А какие проблемы? Инстанцированные темплейты — вполне обычные классы. Я C>вот, например, спокойно передаю std::map'ы нехилых по сложности C>темплейтных объектов между DLLками. И ничего, все работает.
До тех пор, пока не будешь иметь дело с Dinkumware STL
AVC пишет:
> C>Эээ, нет. Когда пытаются продемонстировать суперфичи _языка_ Оберон, то > C>С++-ники показывают еще более мощные аналогичные фичи _библиотек_. > И в чем разница? Почему "эээ, нет"?
Сравни сложность изменения/замены бибилиотеки (ну захотелось мне другой
способ представления матриц использовать) и сложность модификации языка.
>list<int> data(istream_iterator<int>(dataFile), istream_iterator<int>()); > > А уж про сообщения об ошибках, которые "вываливают" большинство > Си++ных компиляторов я вообще молчу.
Вполне нормальные сообщения. Правда длииииинные.
> Хотя, на самом деле это показывает реальную меру "мощи" Си++.
Это мера _практичности_ языка С++. При его разработке не старались
добавить языковую поддержку как можно большего числа фич (типа
множеств), а пытались дать достаточно средств, что можно было комфортно
реализовать как максимальное число фич.
А вот Вирт решил: "Так, нам нужен GC, множества и многомерные массивы
непосредственно в языке. Остальное нам в языке не нужно.".
Кодт пишет:
> C>А какие проблемы? Инстанцированные темплейты — вполне обычные классы. Я > C>вот, например, спокойно передаю std::map'ы нехилых по сложности > C>темплейтных объектов между DLLками. И ничего, все работает. > До тех пор, пока не будешь иметь дело с Dinkumware STL
Здравствуйте, AVC, Вы писали:
AVC>Ага-ага, начинаю понимать. AVC>А для векторов длины 4 мы напишем еще один оператор:
float operator * (Vector4d &a, Vector4d &b)
и т.д. AVC>И так для каждой новой размерности.
Ну зачем. Если ты настаиваешь, я могу тебе написать оператор скалярного умножения для любых векторов. AVC>Вот здорово! Как просто-то!
Именно. На обероне-то вообще ты это никак не опишешь. Только в рантайме будешь трапы трапать. AVC>Вот только я опять не понял:
"А если я захочу передать такую матрицу в некую функцию в качестве параметра?"
AVC>Намек: функция уже написана, откомпилирована и покоится себе в какой-нибудь DLL.
Опять от одной коровы двенадцать поросят? "Как мне передать int в функцию, которая принимает string?"
Если хочется передавать матрицу через границу compile unit, то можно отнаследовать ее от соответствующего интерфейса. Таким образом, статический контроль размерностей будет жить там, где есть эта информация, а где нету — там будет жить динамический контроль.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, GlebZ, Вы писали:
K_O>>Теперь понятно, спасибо. K_O>>Была бы возможность, я бы сейчас поставил языку С++ много минусов. GZ>Ну вот, еще один человек не любит С++. А ведь с такой конструкцие встретиться практически невозможно.
Ну вот встретилась же.
Такая конструкция может возникнуть при объявлении переменной любого типа, у которого в конструктор можно передать параметры.
На самом деле, обычно (по крайней мере, у меня), таких ситуаций не возникает, потому что 99% переменных объявлены либо в классе, либо в методе, где объявление функции недопустимо, а потому это и "не выглядит, как объявление функции".
Но вот в случае с глобальными переменными ситуация меняется.
Здравствуйте, Cyberax, Вы писали:
C>Сравни сложность изменения/замены бибилиотеки (ну захотелось мне другой C>способ представления матриц использовать) и сложность модификации языка.
Вот и пекут обероны, как блины. Здесь многопоточность встроим, там матричную алгебру или ещё какую фичу...
Здравствуйте, Kh_Oleg, Вы писали:
K_O>Здравствуйте, GlebZ, Вы писали:
K_O>>>Теперь понятно, спасибо. K_O>>>Была бы возможность, я бы сейчас поставил языку С++ много минусов. GZ>>Ну вот, еще один человек не любит С++. А ведь с такой конструкцие встретиться практически невозможно. K_O>Ну вот встретилась же. K_O>Такая конструкция может возникнуть при объявлении переменной любого типа, у которого в конструктор можно передать параметры.
И у которой параметры могут интерпретироваться как типы. А вот такое делать уже значительно сложнее.
K_O>На самом деле, обычно (по крайней мере, у меня), таких ситуаций не возникает, потому что 99% переменных объявлены либо в классе, либо в методе, где объявление функции недопустимо, а потому это и "не выглядит, как объявление функции". K_O>Но вот в случае с глобальными переменными ситуация меняется.
Почти нет. Хотя действительно глобальные переменные практически не используются. Разве что статики.
Kh_Oleg,
> На самом деле, обычно (по крайней мере, у меня), таких ситуаций не возникает, потому что 99% переменных объявлены либо в классе, либо в методе, где объявление функции недопустимо, а потому это и "не выглядит, как объявление функции". > Но вот в случае с глобальными переменными ситуация меняется.
Я позволю себе подкатить бочку еще немного в направлении C++: в функциях (в т.ч. и в функциях-членах) объявлять функции можно
#include <list>
#include <iterator>
using namespace std;
int main()
{
list<int> data(istream_iterator<int>(dataFile), istream_iterator<int>()); // те же пирогиreturn data.empty(); // oops... "нельзя применить точку к функции"
}
Это пришло еще из C, где объявление функции внутри другой функции означало, что функция определена в окружающей области видимости. И, таки да, с этим можно встретиться в реальной жизни: http://rsdn.ru/Forum/Message.aspx?mid=453121
Здравствуйте, Кодт, Вы писали:
К>Вот и пекут обероны, как блины. Здесь многопоточность встроим, там матричную алгебру или ещё какую фичу...
Гм. А разные версии шаблонных библиотек разве не именно так пекут?
Многопоточность встроена в Активный Оберон (там, кстати, на уровне ОС еще и многопроцессорность).
Я же держусь поближе к стандартному Оберону-2, и рассматриваю его возможности в качестве основного языка для встроенных систем определенного масштаба.
А матричную алгебру я не предлагал встроить в язык, а имел в виду обычный обероновский модуль. (Если используется динамический загрузчик, то это аналог DLL, но с полным контролем типов.)
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Сергей Губанов пишет:
> КЕ>Эээ, а если написать INCL(s2, 4000000000), то будет поднят бит № > четыре миллиарда? > Нет, не будет. Хотя сам язык этого не запрещает. Все дело в реализации. > Реализация BlackBox 1.5 дает следующее: > MIN(SET) = 0 > MAX(SET) = 31 > (MIN, MAX — стандартные процедуры-функции)
AVC пишет:
> К>Вот и пекут обероны, как блины. Здесь многопоточность встроим, там > матричную алгебру или ещё какую фичу... > Гм. А разные версии шаблонных библиотек разве не именно так пекут? > Многопоточность встроена в Активный Оберон (там, кстати, на уровне ОС > еще и многопроцессорность). > Я же держусь поближе к стандартному Оберону-2, и рассматриваю его > возможности в качестве основного языка для встроенных систем > определенного масштаба. > А матричную алгебру я не предлагал встроить в язык, а имел в виду > обычный обероновский модуль. (Если используется динамический > загрузчик, то это аналог DLL, но с полным контролем типов.)
Обероновской библиотеке придется экспортировать полиморфные интерфейсы,
такого статического контроля как в С++ — не будет.
Здравствуйте, AVC, Вы писали:
К>>Вот и пекут обероны, как блины. Здесь многопоточность встроим, там матричную алгебру или ещё какую фичу...
AVC>Гм. А разные версии шаблонных библиотек разве не именно так пекут?
На STL есть спецификация в Стандарте. В пределах спецификации обеспечивается взаимозаменяемость версий.
А другие библиотеки — это не "разные версии", а всё же разные библиотеки. Которые можно использовать одновременно.
Здравствуйте, Cyberax, Вы писали:
C>AVC пишет:
>> C>Эээ, нет. Когда пытаются продемонстировать суперфичи _языка_ Оберон, то >> C>С++-ники показывают еще более мощные аналогичные фичи _библиотек_. >> И в чем разница? Почему "эээ, нет"? C>Сравни сложность изменения/замены бибилиотеки (ну захотелось мне другой C>способ представления матриц использовать) и сложность модификации языка.
Во-первых, так и не понял в чем разница. Я сказал, что берутся библиотеки Си++ против "голого" языка Оберон. (Я считаю, что это абсурдное сравнение.) Вы повторяете то же самое, но как будто со мной спорите. Мне это непонятно.
У меня и раньше создавалось впечатление, что Вы полагаете, что библиотеки возможны только в Си++. Но это же явное заблуждение.
А теперь сравним сложность замены библиотек в Си++ (особенно если Вы используете библиотеки шаблонов) и Обероне.
В Си++ Вам придется перекомпилировать все проекты (в мире ), использующие данную библиотеку. О скорости компиляции (с текстовыми хэдерами) и линковки множества файлов можно даже не говорить. А в Обероне Вы просто не заметите замены библиотеки. Вам не придется перекомпилировать проект.
Так что же сложнее?
C>Вполне нормальные сообщения. Правда длииииинные.
И не читwrertytfjygh::<jhi>ljhljkhlkjgабельные.
>> Хотя, на самом деле это показывает реальную меру "мощи" Си++.
C>Это мера _практичности_ языка С++. При его разработке не старались C>добавить языковую поддержку как можно большего числа фич (типа C>множеств), а пытались дать достаточно средств, что можно было комфортно C>реализовать как максимальное число фич.
Насчет комфортности — я уже приводил примеры "комфортных" текстов на Си++. Честные книги о программировании на плюсах полны текстов вроде:
Ты туда не ходи, ты сюда ходи. Там снег башка попадет...
(c) "Джентльмены удачи"
C>А вот Вирт решил: "Так, нам нужен GC, множества и многомерные массивы C>непосредственно в языке. Остальное нам в языке не нужно.".
И ведь этого хватает!
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали:
AVC>А теперь сравним сложность замены библиотек в Си++ (особенно если Вы используете библиотеки шаблонов) и Обероне. AVC>В Си++ Вам придется перекомпилировать все проекты (в мире ), использующие данную библиотеку. О скорости компиляции (с текстовыми хэдерами) и линковки множества файлов можно даже не говорить. А в Обероне Вы просто не заметите замены библиотеки. Вам не придется перекомпилировать проект. AVC>Так что же сложнее?
Передёргивание.
Если интерфейсная часть не поменялась, достаточно заменить .lib / .out / .so / .dll или как там называются загружаемые модули в конкретной системе.
А если в обероновском модуле расковырять интерфейсную часть, то тоже всё придётся пересобирать.
Здравствуйте, Кодт, Вы писали:
AVC>>В Си++ Вам придется перекомпилировать все проекты (в мире ), использующие данную библиотеку. О скорости компиляции (с текстовыми хэдерами) и линковки множества файлов можно даже не говорить. А в Обероне Вы просто не заметите замены библиотеки. Вам не придется перекомпилировать проект. AVC>>Так что же сложнее? К>Передёргивание.
В чем именно?
К>Если интерфейсная часть не поменялась, достаточно заменить .lib / .out / .so / .dll или как там называются загружаемые модули в конкретной системе.
И в случае замены шаблона?
К>А если в обероновском модуле расковырять интерфейсную часть, то тоже всё придётся пересобирать.
Так ведь Cyberax говорил не о замене интерфейса библиотеки, а о замене реализации.
Придираетесь, батенька!
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали:
AVC>Так ведь Cyberax говорил не о замене интерфейса библиотеки, а о замене реализации. AVC>Придираетесь, батенька!
Прекрасно. Берём любой обероновский модуль, пишем на С++ эквивалентную систему типов, которая встречается в интерфейсе (те же динамические массивы). Дальше, поскольку шаблонов в интерфейсе нет, вытаскиваем реализацию в отдельный .cpp.
Потом вносим изменения в обероновский и в С++ный код. И обнаруживаем, что головная боль для клиента — практически одинаковая (заменить объектный файл).
С++, помимо этого, предоставляет дополнительные возможности, за которые (если они востребованы) нужно дополнительно платить.
Здравствуйте, Кодт, Вы писали:
К>Прекрасно. Берём любой обероновский модуль, пишем на С++ эквивалентную систему типов, которая встречается в интерфейсе (те же динамические массивы). K>Дальше, поскольку шаблонов в интерфейсе нет, вытаскиваем реализацию в отдельный .cpp.
Что я и говорил : шаблоны плохо сочетаются с динамической линковкой.
К>Потом вносим изменения в обероновский и в С++ный код. И обнаруживаем, что головная боль для клиента — практически одинаковая (заменить объектный файл).
Если речь идет о DLL, то да.
Хотя создание DLL на Си++ требует дополнительных пырханий и модификации исходника (__dllspec и т.д.).
К>С++, помимо этого, предоставляет дополнительные возможности, за которые (если они востребованы) нужно дополнительно платить.
Так ведь и платим! Вон уже сколько гигабайт требуется на винте.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Перекуём баги на фичи!
: шаблоны плохо сочетаются с динамической линковкой.