Re[23]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 16.02.05 15:51
Оценка:
Здравствуйте, Кодт, Вы писали:

AVC>>Справедливости ради, матричная алгебра на Обероне реализуется проще, чем на Си++.

AVC>>Причина: отсутствие в Си++ многомерных гибких массивов.
AVC>>В Обероне даже не требуются классы (записи), достаточно массивов.
AVC>>Я и обратил впервые внимание на Оберон из-за того, что там легко было обобщить методы линейной алгебры для матриц разных размерностей.
AVC>>Потом уже стало "доходить", что разница между Обероном и Си++ глубже, чем наличие или отсутствие тех или иных фич. Тогда заинтересовался всерьез.

К>В С++, благодаря шаблонам, есть возможность контролировать размеры матриц на стадии компиляции


Гм. Как бы это поделикатнее сказать...
Мне даже интересно, а где этой возможности нет?
Например:
VAR a: ARRAY 10,10 OF REAL;
И так в большинстве языков...

К>Кстати, я всё-таки не понял: ARRAY OF ARRAY (без фиксированного размера) — это прямоугольник или рваный край?


Прямоугольник.
Кирпич.
И т.д.

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

К>А если прямоугольник — то действительно, раз — и готово!

Прямоугольник.

К>Но опять же, в С++ можно сделать код, эквивалентный Обероновскому.

К>Введём только, с помощью шаблона, тип "двумерный массив".
К>
К>template<class T>
К>class array2d
К>{
К>public:
К>  int xsize() const;
К>  int ysize() const;

К>  array2d(); // 1*1
К>  array2d(int x, int y);
К>  array2d(const array2d& src);
К>  array2d& operator=(const array2d& src);

К>  T& at(int x, int y);
К>  const T& at(int x, int y) const;
К>};
К>

К>Минимально, этого достаточно. Дальше — вагон и маленькая тележка функций, таких же, как в Обероне.

Конечно.
Си++, как всегда, выгодно отличается от Оберона своей простотой.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[24]: Нужна ли Оберон-ОС защита памяти?
От: Кодт Россия  
Дата: 16.02.05 16:04
Оценка: +4
Здравствуйте, AVC, Вы писали:

К>>В С++, благодаря шаблонам, есть возможность контролировать размеры матриц на стадии компиляции


AVC>Гм. Как бы это поделикатнее сказать...

AVC>Мне даже интересно, а где этой возможности нет?
AVC>Например:
VAR a: ARRAY 10,10 OF REAL;
И так в большинстве языков...


Я имел в виду
VAR a: ARRAY 3,5 OF REAL;
    b: ARRAY 5,7 OF REAL;
    c: ARRAY 4,7 OF REAL;
    d: ARRAY 3,7 OF REAL;

d := a*b;
d := a*c; (* ошибка компиляции: несовместимые операнды *)
c := a*b; (* ошибка компиляции: несовместимые результат и приёмник *)


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

К>>А если прямоугольник — то действительно, раз — и готово!

AVC>Прямоугольник.




К>>Но опять же, в С++ можно сделать код, эквивалентный Обероновскому.

К>>Введём только, с помощью шаблона, тип "двумерный массив".
К>>Минимально, этого достаточно. Дальше — вагон и маленькая тележка функций, таких же, как в Обероне.

AVC>Конечно.

AVC>Си++, как всегда, выгодно отличается от Оберона своей простотой.

Планида у него такая. Бедность встроенных типов компенсируется мощностью пользовательских.
Перекуём баги на фичи!
Re[25]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 16.02.05 16:44
Оценка:
Здравствуйте, Кодт, Вы писали:

К>Я имел в виду

K>
К>VAR a: ARRAY 3,5 OF REAL;
К>    b: ARRAY 5,7 OF REAL;
К>    c: ARRAY 4,7 OF REAL;
К>    d: ARRAY 3,7 OF REAL;

К>d := a*b;
К>d := a*c; (* ошибка компиляции: несовместимые операнды *)
К>c := a*b; (* ошибка компиляции: несовместимые результат и приёмник *)
К>


Это хорошо.
А если я захочу передать такую матрицу в некую функцию в качестве параметра?

AVC>>Конечно.

AVC>>Си++, как всегда, выгодно отличается от Оберона своей простотой.
К>Планида у него такая. Бедность встроенных типов компенсируется мощностью пользовательских.

И простотой.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[21]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 16.02.05 16:52
Оценка:
Здравствуйте, Костя Ещенко, Вы писали:

СГ> Кстати про множества, а почему элементарный тип bool в языки C++/Java/C# все-таки ввели, а элементарный тип "множество" проигнорировали?

КЕ>Не такой уж он элементарный. В С++ есть куча шаблонов множеств для разных сценариев использования: std::bitset, boost::dynamic_bitset, std::vector<bool>, std::set и до кучи std::multiset — множество с повторениями.

Прослеживается очень интересный подход.
Когда надо проиллюстрировать величие Си++, он берется со всеми библиотеками, даже нестандартными (пока?), как boost.
Когда надо проиллюстрировать ничтожество Оберона, он берется в "голом" виде.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[22]: Нужна ли Оберон-ОС защита памяти?
От: Cyberax Марс  
Дата: 16.02.05 17:01
Оценка: :)
AVC пишет:

> СГ> Кстати про множества, а почему элементарный тип bool в языки

> C++/Java/C# все-таки ввели, а элементарный тип "множество"
> проигнорировали?
> КЕ>Не такой уж он элементарный. В С++ есть куча шаблонов множеств для
> разных сценариев использования: std::bitset, boost::dynamic_bitset,
> std::vector<bool>, std::set и до кучи std::multiset — множество с
> повторениями.
> Прослеживается очень интересный подход.
> Когда надо проиллюстрировать величие Си++, он берется со всеми
> библиотеками, даже нестандартными (пока?), как boost.
> Когда надо проиллюстрировать ничтожество Оберона, он берется в "голом"
> виде.

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

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[23]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 16.02.05 17:18
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> Прослеживается очень интересный подход.

>> Когда надо проиллюстрировать величие Си++, он берется со всеми
>> библиотеками, даже нестандартными (пока?), как boost.
>> Когда надо проиллюстрировать ничтожество Оберона, он берется в "голом"
>> виде.
C>Эээ, нет. Когда пытаются продемонстировать суперфичи _языка_ Оберон, то
C>С++-ники показывают еще более мощные аналогичные фичи _библиотек_.

И в чем разница? Почему "эээ, нет"?

C>Причем при использовании этих библиотек внешний вид кода получается еще

C>и получше обероновского.

Мягко говоря, сомнительно.
Рассмотрим хотя бы учебный пример:
list<int> data(istream_iterator<int>(dataFile), istream_iterator<int>());
А уж про сообщения об ошибках, которые "вываливают" большинство Си++ных компиляторов я вообще молчу.
ИМХО, несколько комично торжественно праздновать "победу" всей мощи Си++ных библиотек над "голым" языком, компилятор которого умещается в 50K.
Хотя, на самом деле это показывает реальную меру "мощи" Си++.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[24]: Нужна ли Оберон-ОС защита памяти?
От: Павел Кузнецов  
Дата: 16.02.05 17:36
Оценка:
AVC,

> C> Причем при использовании этих библиотек внешний вид кода получается еще и получше обероновского.


> Мягко говоря, сомнительно. Рассмотрим хотя бы учебный пример:

list<int> data(istream_iterator<int>(dataFile), istream_iterator<int>());


Интересно... А если исправить ошибки в этом коде, то как будет выглядеть эквивалентный код на Обероне?
Posted via RSDN NNTP Server 2.0 alpha
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[22]: Нужна ли Оберон-ОС защита памяти?
От: Кодт Россия  
Дата: 16.02.05 20:19
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>Прослеживается очень интересный подход.


и заметим, нездоровый...

AVC>Когда надо проиллюстрировать величие Си++, он берется со всеми библиотеками, даже нестандартными (пока?), как boost.

AVC>Когда надо проиллюстрировать ничтожество Оберона, он берется в "голом" виде.

Знаешь, почему? Потому что приверженцы Оберона всячески подчёркивают, что в самом языке достаточно фич, чтобы "было щастье". А избалованные библиотеками С++ники считают, что нет, не достаточно.
Перекуём баги на фичи!
Re[23]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 16.02.05 21:52
Оценка: 2 (2) :)
Здравствуйте, Кодт, Вы писали:

AVC>>Прослеживается очень интересный подход.

К>и заметим, нездоровый...

Вот именно...
... это я и хотел сказать. Но проявил свойственные сторонникам Оберона такт и деликатность.

AVC>>Когда надо проиллюстрировать величие Си++, он берется со всеми библиотеками, даже нестандартными (пока?), как boost.

AVC>>Когда надо проиллюстрировать ничтожество Оберона, он берется в "голом" виде.
К>Знаешь, почему? Потому что приверженцы Оберона всячески подчёркивают, что в самом языке достаточно фич, чтобы "было щастье". А избалованные библиотеками С++ники считают, что нет, не достаточно.

Если бы дело обстояло именно так, то "избалованные библиотеками С++ники" были бы правы.
(Что уже само по себе абсурдно... стоп! что это я? Спокойствие! держим себя в руках... такт и деликатность, такт и деликатность... )
Вообще-то приверженцев Оберона на RSDN раз-два и обчелся. Сергей Губанов, Трурль (изредка) и Ваш покорный слуга.
Так, мыслим... я тут хлебнул пивка, ща разберемся... Очевидно, имеются в виду мое "педалирование" отсутствия в Си++ гибких многомерных массивов и сегодняшний пассаж Сергея о множествах (на мой взгляд, не самый удачный).
Не... ну с гибкими-то массивами все ясно. В Си++ их как не было, так и нет. И, наверное, не будет, как недавно прозрачно намекнул Павел Кузнецов.
Правда, сторонники Си++ выражают такой бурный энтузиазм по поводу каждой отсутствующей в их языке фичи (я бы сказал — фундаментальной фичи )... Еще бы! повод написать новый класс!.. Может им Смоллток втихаря подсунуть?
Вообще-то интересное мнение об "Оберонщиках" здесь сформировалось! Мало того, что ребята выбрали минималистский язык (который иногда уподобляют RISC-процессору в мире CISC-ов), так они еще и ни в какую не соглашаются пользоваться библиотеками. Мол, "нет, уберите от меня ваши гадкие коды, я все сам!"
Дорогие мои (пьяная фамильярность ), неправда все это!
Вы в наших исходниках словечко IMPORT видели? Так это оно и есть — библиотеки!
А если нам вдруг мало становится чисто обероновских библиотек, то в нашем распоряжении еще библиотеки, написанные на других языках. Даю слово Метцелеру:

Now if you think of the reuse of legacy code, programs and libraries written for other languages, such as C/C++ and maybe Assembler, Pascal, Modula-2, Fortran or some other old language; or commercial libraries written for one of the popular programming languages: don’t worry, as long as whatever code you wish to use conforms to the platform standard for object modules and/or libraries (including dynamic link libraries, DLLs under Windows), you can use it with Oberon-2.

In fact, as long as the Oberon-2 compiler supports interfacing with external libraries (all of those outside of the ETH Oberon System do), it is usually enough to translate the standard .H header files, which are usually supplied with commercial libraries, into an acceptable format. The XDS compiler accepts Modula-2 style definition modules. These can be generated automatically from .H header files, for example by using the utility program H2D.EXE supplied at no cost by XDS (cf. corresponding documentation, or download it from their web site – www.excelsior-usa.com — if you don’t use their compiler).

Unfortunately, this possibility is largely ignored by many programmers. Even many computer magazines perpetuate the assumption that a program that wants to use an API written in C must also use C. According to this logic, all programs would still have to be written in machine language, as all programming languages must be translated into – or must interface with – machine language at some point, which is of course an absurd conclusion.

Скажу совсем криминальную вещь: мы бы и STL использовали. Если бы был объектник...

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[25]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 16.02.05 22:28
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

>> Мягко говоря, сомнительно. Рассмотрим хотя бы учебный пример:

>>
list<int> data(istream_iterator<int>(dataFile), istream_iterator<int>());

ПК>Интересно... А если исправить ошибки в этом коде, то как будет выглядеть эквивалентный код на Обероне?

Опаньки! неужели сам...
Павел, а где, собственно, ошибки?
Вот беру исходник
#include <list>

using namespace std;

list<int> data(istream_iterator<int>(dataFile), istream_iterator<int>());

int main()
{
    return 0;
}
и компилирую. Ошибок нет!

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[26]: Нужна ли Оберон-ОС защита памяти?
От: Павел Кузнецов  
Дата: 16.02.05 23:24
Оценка: :)
AVC,

>>>
list<int> data(istream_iterator<int>(dataFile), istream_iterator<int>());


> ПК> Интересно... А если исправить ошибки в этом коде, то как будет выглядеть эквивалентный код на Обероне?


> Опаньки! неужели сам...


Тпру Касте Оберонопочитателей напоминаю, что я ни против Оберона, ни против адептов ничего не имею ("Огонь, мы с тобой одной крови, ты и я" ), так что иронию можно перенацелить на кого-нибудь более враждебно настроенного. В данном случае мне было, действительно, интересно, как же будет выглядеть код на Обероне. Про ошибки упомянул, чтобы не написали объявление функции, а не чтобы задеть

> Павел, а где, собственно, ошибки?

> Вот беру исходник
>
#include <list>
>
> using namespace std;
>
> list<int> data(istream_iterator<int>(dataFile), istream_iterator<int>());
>
> int main()
> {
>     return 0;
> }

> и компилирую. Ошибок нет!

Т.к. AVC, хитро заложивший мину, делает невинные глаза (*), то для тех, кто от C++ пострадал в недостаточной степени, позволю прокомментировать код, приведенный выше. В данном случае мы имеем дело с одной из неприятных особенностей синтаксиса C++: вопреки очевидному желанию программиста объявить список, проинициализированный парой итераторов, вместо этого мы видим объявление функции data, возвращающей list<int>.

Итак, мне, все-таки, действительно, интересно, как бы выглядел на Обероне код, подобный следующему (считаем, что соответствующий контекст предоставлен, в т.ч. нужные #includes, определение dataFile и т.п.):
list<int> data( (istream_iterator<int>(dataFile)),  (istream_iterator<int>()) );




(*) В сознательном вредительстве его можно уличить, т.к. объявления dataFile он не предоставил
Posted via RSDN NNTP Server 2.0 alpha
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[22]: Нужна ли Оберон-ОС защита памяти?
От: Костя Ещенко Россия  
Дата: 16.02.05 23:38
Оценка:
Здравствуйте, AVC, Вы писали:

СГ>> Кстати про множества, а почему элементарный тип bool в языки C++/Java/C# все-таки ввели, а элементарный тип "множество" проигнорировали?

КЕ>>Не такой уж он элементарный. В С++ есть куча шаблонов множеств для разных сценариев использования: std::bitset, boost::dynamic_bitset, std::vector<bool>, std::set и до кучи std::multiset — множество с повторениями.

AVC>Прослеживается очень интересный подход.

AVC>Когда надо проиллюстрировать величие Си++, он берется со всеми библиотеками, даже нестандартными (пока?), как boost.

Вообще-то это был ответ на вопрос Сергея, почему проигнорировали "элементарный" тип множество. Чем ответ не устраивает и что не так с библиотеками?
Они же стандартные или типа того. Есть почти на каждом компиляторе. Их реализация не обязана находиться в исходных файлах, а может быть встроена в компилятор. С точки зрения Стандарта это стандартные типы/функции/шаблоны, почти как int.

AVC>Когда надо проиллюстрировать ничтожество Оберона, он берется в "голом" виде.

AVC>

Я не иллюстрировал, оно само
А что, в "одетом" виде у Оберона есть стандартные или нестандартные библиотеки, реализующие множества? И что, типизированные? На дженериках?
На самом деле, люди не читают газеты, они принимают их каждое утро, так же как ванну. ©Маршалл Мак-Льюэн
Re[26]: Нужна ли Оберон-ОС защита памяти?
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.02.05 05:19
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>Это хорошо.


AVC>А если я захочу передать такую матрицу в некую функцию в качестве параметра?

Вот как раз в С++ ты такую матрицу в функцию передашь легко. Там можно описывать фунции с весьма занятными ограничениями на принимаемые параметры. В частности, описываемое поведение достигается применением специальной версии оператора *, в которую принимаются исключительно матрицы подходящих размерностей.
AVC>И простотой.
Да, и простотой. Потому что в реальной жизни делается примерно так:
typedef Matrix<3, 3, float> Matrix3d;
typedef Matrix<3, 1, float> Vector3d;
typedef Matrix<1, 3, float> CoVector3d;
// определим скалярное произведение для удобства
float operator * (Vector3d &a, Vector3d &b)
{
  static const Matrix<1, 1, float> transposer = Matrix<1, 1, float>(1.0);
    return (a*transposer*b)[0][0]; // преобразует Vector3d в CoVector3d, чтобы можно было выполнить умножение
}

И все. Это делается в одном хидере, и все эти страшные наборы вложенных угловых скобок никто не видит.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[27]: Нужна ли Оберон-ОС защита памяти?
От: Kh_Oleg  
Дата: 17.02.05 09:16
Оценка: 1 (1)
Здравствуйте, Павел Кузнецов, Вы писали:

list<int> data(istream_iterator<int>(dataFile), istream_iterator<int>());

ПК>В данном случае мы имеем дело с одной из неприятных особенностей синтаксиса C++: вопреки очевидному желанию программиста объявить список, проинициализированный парой итераторов, вместо этого мы видим объявление функции data, возвращающей list<int>.

Шикарнейший язык!

ПК>list<int> data( (istream_iterator<int>(dataFile)),  (istream_iterator<int>()) );

Читал, много думал...
Почему взятие итераторов в скобки меняет смысл объявления?
Re[27]: Нужна ли Оберон-ОС защита памяти?
От: Кодт Россия  
Дата: 17.02.05 10:48
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Итак, мне, все-таки, действительно, интересно, как бы выглядел на Обероне код, подобный следующему (считаем, что соответствующий контекст предоставлен, в т.ч. нужные #includes, определение dataFile и т.п.):

ПК>
ПК>list<int> data( (istream_iterator<int>(dataFile)),  (istream_iterator<int>()) );
ПК>


ПК>

ПК>(*) В сознательном вредительстве его можно уличить, т.к. объявления dataFile он не предоставил

Предполагаю...
1) Сперва избавимся от адресной арифметики, скрытой в концепции итераторов.
Перейдём к эквивалентной концепции — диапазонов и генераторов.
Генератор — это аналог output iterator.
// над генератором определены 2 функции: read и end

template<class G>
typename generator_traits<G>::type
read(G gen);

template<class G>
bool
ends(G gen);

// конкретно, с файлом:
template<class T>
struct istream_generator
{
  istream* istr;
};
template<class T>
T read(istream_generator<T> gen)
{
  T var;
  gen.istr->read(var);
  return var;
}
template<class T>
T ends(istream_generator<T> gen)
{
  return gen.istr->eof();
}

// конструктор списка

template<class G>
list<T>::list(G gen)
{
  while(!ends(gen)) push_back(read(gen));
}

2) Заодно, по мере сил, избавимся от шаблонов, — только generics.
template<class T>
struct IGenerator
{
  virtual T read() = 0;
  virtual bool ends() const = 0;
};

template<class T>
struct istream_generator : IGenerator<T>
{
  istream* istr;
  T read() { T var; istr->read(var); return var; }
  bool ends() const { return istr->eof(); }
};

list<T>::list(IGenerator<T>* gen)
{
  while(!gen->ends()) push_back(gen->read());
}

3) А если и generics недоступны — нарожаем конкретных интерфейсов и классов.
Перекуём баги на фичи!
Re[28]: Нужна ли Оберон-ОС защита памяти?
От: Кодт Россия  
Дата: 17.02.05 10:54
Оценка:
Здравствуйте, Kh_Oleg, Вы писали:

K_O>
list<int> data(istream_iterator<int>(dataFile), istream_iterator<int>());

ПК>>В данном случае мы имеем дело с одной из неприятных особенностей синтаксиса C++: вопреки очевидному желанию программиста объявить список, проинициализированный парой итераторов, вместо этого мы видим объявление функции data, возвращающей list<int>.

K_O>Шикарнейший язык!


K_O>
ПК>list<int> data( (istream_iterator<int>(dataFile)),  (istream_iterator<int>()) );

K_O>Читал, много думал...
K_O>Почему взятие итераторов в скобки меняет смысл объявления?

Потому что есть правило "если нечто выглядит как объявление функции, это и есть объявление функции".
В данном случае,
T name(U (u), V (v)); // где T, U, V - типы; name, u, v - идентификаторы

U (u) можно трактовать как элемент объявления аргумента. Был бы там вместо u литерал или выражение — всё стало бы однозначно конструктором временного объекта типа U. А так — неоднозначность.
А вот (U(u)) уже невозможно трактовать как объявление аргумента.
Перекуём баги на фичи!
Re[27]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 17.02.05 12:29
Оценка:
Здравствуйте, Sinclair, Вы писали:

AVC>>И простотой.

S>Да, и простотой. Потому что в реальной жизни делается примерно так:
S>
S>typedef Matrix<3, 3, float> Matrix3d;
S>typedef Matrix<3, 1, float> Vector3d;
S>typedef Matrix<1, 3, float> CoVector3d;
S>// определим скалярное произведение для удобства
S>float operator * (Vector3d &a, Vector3d &b)
S>{
S>  static const Matrix<1, 1, float> transposer = Matrix<1, 1, float>(1.0);
S>    return (a*transposer*b)[0][0]; // преобразует Vector3d в CoVector3d, чтобы можно было выполнить умножение
S>}
S>

S>И все. Это делается в одном хидере, и все эти страшные наборы вложенных угловых скобок никто не видит.

Ага-ага, начинаю понимать.
А для векторов длины 4 мы напишем еще один оператор:
float operator * (Vector4d &a, Vector4d &b)
и т.д.
И так для каждой новой размерности.
Вот здорово! Как просто-то!
Вот только я опять не понял:

"А если я захочу передать такую матрицу в некую функцию в качестве параметра?"

Намек: функция уже написана, откомпилирована и покоится себе в какой-нибудь DLL.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[29]: Нужна ли Оберон-ОС защита памяти?
От: Kh_Oleg  
Дата: 17.02.05 12:55
Оценка: +2 :))
Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, Kh_Oleg, Вы писали:


K_O>>
list<int> data(istream_iterator<int>(dataFile), istream_iterator<int>());

ПК>>>В данном случае мы имеем дело с одной из неприятных особенностей синтаксиса C++: вопреки очевидному желанию программиста объявить список, проинициализированный парой итераторов, вместо этого мы видим объявление функции data, возвращающей list<int>.
K_O>>
ПК>list<int> data( (istream_iterator<int>(dataFile)),  (istream_iterator<int>()) );

K_O>>Читал, много думал...
K_O>>Почему взятие итераторов в скобки меняет смысл объявления?

К>Потому что есть правило "если нечто выглядит как объявление функции, это и есть объявление функции".

К>В данном случае,
К>
К>T name(U (u), V (v)); // где T, U, V - типы; name, u, v - идентификаторы
К>

К>U (u) можно трактовать как элемент объявления аргумента. Был бы там вместо u литерал или выражение — всё стало бы однозначно конструктором временного объекта типа U. А так — неоднозначность.
К>А вот (U(u)) уже невозможно трактовать как объявление аргумента.

Теперь понятно, спасибо.
Была бы возможность, я бы сейчас поставил языку С++ много минусов.
Re[30]: Нужна ли Оберон-ОС защита памяти?
От: GlebZ Россия  
Дата: 17.02.05 13:05
Оценка:
Здравствуйте, Kh_Oleg, Вы писали:

K_O>Теперь понятно, спасибо.

K_O>Была бы возможность, я бы сейчас поставил языку С++ много минусов.
Ну вот, еще один человек не любит С++. А ведь с такой конструкцие встретиться практически невозможно.

С уважением, Gleb.
Re[28]: Нужна ли Оберон-ОС защита памяти?
От: Cyberax Марс  
Дата: 17.02.05 13:08
Оценка:
AVC пишет:

> S>И все. Это делается в одном хидере, и все эти страшные наборы

> вложенных угловых скобок никто не видит.
> Ага-ага, начинаю понимать.
> А для векторов длины 4 мы напишем еще один оператор:

Не длины, а _размерности_. Работа с векторами разной размерности бывает
нужна очень редко (а вот 2,3,4-мерные вектора нужны часто). Кстати, при
желании можно с темплейтами сделать и вектора произвольной размерности.

>float operator * (Vector4d &a, Vector4d &b)

>
> и т.д.
> И так для каждой новой размерности.
> Вот здорово! Как просто-то!
> Вот только я опять не понял:
> "А если я захочу передать такую матрицу в некую функцию в качестве
> параметра?"
> Намек: функция уже написана, откомпилирована и покоится себе в
> какой-нибудь DLL.

А какие проблемы? Инстанцированные темплейты — вполне обычные классы. Я
вот, например, спокойно передаю std::map'ы нехилых по сложности
темплейтных объектов между DLLками. И ничего, все работает.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.