Здравствуйте, Кодт, Вы писали:
К>Я понял. К>Окей, замена подмассива как элемента без инвалидации ссылок на остальные элементы — невозможна либо сопряжена с маразматическими трудностями.
Вот именно. И это только одна из проблем. Именно исходя из этого я и сказал:
Это если на словах и не подумав. А если подумать, то станет понятным, что при любой реализации вложенные массивы нельзя делать единым блоком. Они ведь как минимум должны иметь возможность динамически пдменяться в рантайме.
и
Что до реализации, то массивы массивов могут быть реализованы только одним способом. Мномерные же разными, но эффективная реализация именно единым блоком памяти. Так что слова Quintanar неверны только с очень теоритической точки зрения. На практике же так оно и есть.
К>Если не вываливать все требования сразу...
Дык, это требования того что называется вложенными массивами в дотнете и Яве. Именно о непонимании отличии этих сущностей и говорил автор темы:
чем отличие массива массивов от многомерного массива и почему многомерный массив вроде бы как лучше. Сколько ни писал на Java и на C++, разницы так и не заметил
Думаю, что идея сделать массив ссылочным типом была хорошо продумана. И совершенно не странно, что во всех перспективных языках используется или она или вообще концепция саписка которому сам бог велел быть ссылочным.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Массив — это value-type, поэтому массив массивов — это одно, а массив указателей на массивы — совсем другое.
У тебя проблемы с догмами. Массив — это первоклассная сущьность нужная для манипуляции со списками. Все остальное домыслы.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Трурль, Вы писали:
VD>>Массив массивов — это массив ссылок на массивы определенного типа (в том числе и опять же массивов массивов).
Т>А что тогда "массив ссылок на массивы"?
Для этого нужно сначало определиться с понятием ссылок. В общем, случае — это будет двойная (и больше) косвенность. Но, например, та же Ява просто не поддерживает пдобного. Тема же подразумевает вложенные массивы Явы.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
СГ>>А я его могу еще более "усугубить". В языке программирования вообще все-все-все что только можно должно быть value-type. Тогда на таком языке можно будет писать программы используя динамическое распределение памяти (new) только тогда когда это действительно необходимо, а не "на каждый чих". Меньше нагрузка на сборщик мусора — быстрее работать будет.
E>Имхо, это еще одно слишком категоричное и субъективное утверждение
Мужик откровенно уперся в "единственно врную" реализацию. Эта упертость настолько сильна, что он даже плюет на понятие абстракции и разумность утверждений.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, GlebZ, Вы писали:
GZ>>В других высокоуровневых языках это называется указатель и ссылка.
СГ>Да, вот такая вот путаница у нас есть.
СГ>Есть три разных понятия СГ>1) адрес,
Под адресом обычно в С++ или С# имеется ввиду значение указателя, но не более. СГ>2) указатель [в отличие от адреса может управляться GC],
В CLI есть manager pointer и unmanaged pointer. СГ>3) ссылка.
СГ>Таблица соответствия этих понятий в разных языках: СГ>
СГ> +---------------+---------------+---------------+---------------+
СГ> | Обероны | C/C++ | С# | Java |
СГ>+-----------+---------------+---------------+---------------+---------------+
СГ>| | | | есть | |
СГ>| адрес | INTEGER | | только в | нету |
СГ>| | | | unsafe | |
СГ>+-----------+---------------+ Foo* +---------------+---------------+
СГ>| | | | | |
СГ>| указатель | POINTER TO | | class, byte[] | class |
СГ>| | | | | |
СГ>+-----------+---------------+---------------+---------------+---------------+
СГ>| | | | | |
СГ>| ссылка | VAR, IN, OUT | & | ref, out | нету |
СГ>| | | | | |
СГ>+-----------+---------------+---------------+---------------+---------------+
СГ>
Здорово нарисовано, я бы так не смог. Но немного перерисую (то что не Оберон).
+---------------+---------------+---------------+---------------+
| Обероны | C/C++ | С# | Java |
+-----------+---------------+---------------+---------------+---------------+
| | | | есть | |
| адрес | INTEGER | обычно | только в | нету |
| | | значение &Foo | unsafe | |
+-----------+---------------+---------------+---------------+---------------+
| | | | | |
| указатель | POINTER TO | Foo* | short* для | нету |
| | | | unsafe | |
+-----------+---------------+---------------+---------------+---------------+
| | | | class, byte[]| |
| ссылка | VAR, IN, OUT | Foo& | ref, out | class |
| | | | | |
+-----------+---------------+---------------+---------------+---------------+
Дополнительные пояснения:
Для С# нет разницы в ссылочных объектах как они передаются через ref или иначе. Некоторое значение есть для value объектов. Но это уже частности.
В С# указатели спрятаны от пользователя языка. Они есть на уровне CLI. И кстати как управляемые так и неуправляемые.
На уровнях компиляции, многие термины перемешиваются. Например — ссылка и указатель в C++ часто дают один и тот-же результат.
Здравствуйте, VladD2, Вы писали: VD>У тебя проблемы с догмами. Массив — это первоклассная сущьность нужная для манипуляции со списками. Все остальное домыслы.
Это-то понятно. Чтобы начать приближаться к правильному пониманию идеи X аналитическим путем, нужно столкнуться как минимум с тремя ее трактовками или проявлениями. Типа такого прогресса:
Шаг 1. Некто изучил Турбо-Паскаль 6.0.
Он знает всё про ООП. Инкапсуляция — это public/protected, наследование — object(TMyObject), а полиморфизм — это virtual.
Шаг 2. Некто увидел С++.
Теперь он узнал, что ООП бывает разным. Что наследование бывает множественным и виртуальным и что бывают какие-то друзья. В этот момент в его голову может закрасться подозрение, что ООП не эквивалентно четырем или пяти ключевым словам языка. Что наоборот — эти ключевые слова выражают некоторые идеи ООП на некотором языке. Это может стимулировать дальнейший поиск истины.
Шаг 3. Некто встретился с SmallTalk
От подозрения о существовании базовых концепций ООП некто плавно переходит к некоторому пониманию самих этих концепций.
Шаг 4. Некто сталкивается с Java, JavaScript, COM, Corba, .Net...
Понимание концепций, лежащих в основе ООП, кристаллизуется и оттачивается.
Наш уважаемый оппонент сейчас находится на шаге 1. Коварство Вирта в том, что Сергей Губанов знает всё не только про ООП. Он знает всё про программирование в целом. И модульность, и компонентность, и декларативность, да и вообще всё чудесным образом высечено на скрижалях в виде ключевых слов любимого Оберона. Ага.
У нас на главном корпусе университета религиозные фанатики в свое время написали из баллончика огромную надпись:
ВСЕ ЧТО ВАМ НУЖНО ЗНАТЬ ЕСТЬ В БИБЛИИ
Студенты-юмористы через пару недель исправили последнее слово:
ВСЕ ЧТО ВАМ НУЖНО ЗНАТЬ ЕСТЬ В БИБЛИОТЕКЕ
Искренне желаю Сергею сходить таки в библиотеку. Иначе можно пропустить очень много интересного.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
<...с перечисленным выше, в целом, согласен...> S>Шаг 4. Некто сталкивается с Java, JavaScript, COM, Corba, .Net... S>Понимание концепций, лежащих в основе ООП, кристаллизуется и оттачивается.
Особенно сильно ООП кристализовано в JavaScript, COM и Corba
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали: E>Особенно сильно ООП кристализовано в JavaScript, COM и Corba E>
А что, есть какие-то сомнения? Без JavaScript человек будет думать, что объекты непременно должны принадлежать классам. Без COM — что наследование бывает только одного типа — наследование реализации. С точки зрения теории кристалла в ООП главное — понятие объекта. При обучении на примерах нужно большое разнообразие этих примеров чтобы выкинуть из своего интуитивного понимания термина "объект" все лишнее, оставив существенное.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, eao197, Вы писали: E>>Особенно сильно ООП кристализовано в JavaScript, COM и Corba E>> S>А что, есть какие-то сомнения? Без JavaScript человек будет думать, что объекты непременно должны принадлежать классам.
Я и сейчас в этом убежден.
S> Без COM — что наследование бывает только одного типа — наследование реализации.
А что, в Java не было наследования интерфейсов?
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали: E>Я и сейчас в этом убежден.
Совершенно необязательно. В JavaScript классов нет, тем не менее объекты есть и ничуть этого не стесняются. E>А что, в Java не было наследования интерфейсов?
Ну ладно, теперь уже можно в принципе обойтись и без COM/Corba. Если столкнулся с Net/Java, конечно.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>В C# массивы есть классы, то есть reference-type, а значит в C# "вложенные массивы" есть массив ссылок на массивы. А на самом деле, массивы должны быть value-type, и таких настоящих массивов нет ни в C# ни в .NET ни в Java (зато они есть в Оберонах, Модулах, и даже в древнем Паскале, правда в Паскале они в ограниченном виде).
VD>На самом деле никто никому ничего не должен. Вложенные массивы (nested array) и уж темболеее зубчатые массивы (jagged array) — это термины из Явы и Шарпа. Собственно вопрос в теме о них и был.
Лучше Ява,Delphi, Net (не шарпом единым Net зыждется )
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, GlebZ, Вы писали:
GZ>...многие термины перемешиваются...
Вы отнесли к ссылкам также и то что в моей таблице было указателями. Объясню как я их различаю:
Ссылки VAR, IN, OUT в Оберонах (или ref, out в C#; или & в C/C++) отличаются от указателя тем, что указатель можно проверить на равенство или неравенство с другим указателем, а также с NIL в Оберонах (null в C# и Java, или 0 в С++). В то время как ссылку нельзя проверить на равенство или неравенство с NIL или другой ссылкой потому что любое обращение к ссылке автоматически ее разыменовывает и мы автоматом попадаем на ссылаемый по ней объект но никогда на собственное значение ссылки самой по себе безотносительно на кого она ссылка.
+-----------------+-----------------------------------+--------------------------------------------------+
| Тип переменной | Собственное значение | Примеры |
+-----------------+-----------------------------------+--------------------------------------------------+
| адрес | целочисленное значение | INTEGER, int |
+-----------------+-----------------------------------+--------------------------------------------------+
| указатель | = NIL, # NIL (== null, != null) | POINTER TO ..., interface ..., class ..., byte[] |
+-----------------+-----------------------------------+--------------------------------------------------+
| ссылка | собственное значение недоступно | VAR BYTE, IN REAL, OUT CHAR, ref double, out int |
+-----------------+-----------------------------------+--------------------------------------------------+
Здравствуйте, Кодт, Вы писали:
К>Да почему нельзя, очень даже можно.
К>Вариант номер раз:
[] К>В данном случае reinterpret законный, так как по Стандарту элементы массива идут встык, и можно трактовать линейный массив как массив из одинаковых массивов.
new RSDN@Home(1.1.4, 303) << new Message(); std::head::ear << "Celtic Awakening — Feast At Tintern";
Здравствуйте, VladD2, Вы писали:
Т>>А что тогда "массив ссылок на массивы"?
VD>Для этого нужно сначало определиться с понятием ссылок. В общем, случае — это будет двойная (и больше) косвенность. Но, например, та же Ява просто не поддерживает пдобного. Тема же подразумевает вложенные массивы Явы.
Ява как пример. Просто мне интересна разница между двумя сущностями. Я то работал с ними, но как они называются... Теперь я знаю терминологию.
Кстати, про диез я читал то же самое, что и про Яву (что они там многомерные). Этож вроде не так
new RSDN@Home(1.1.4, 303) << new Message(); std::head::ear << "Celtic Awakening — Feast At Tintern";
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, ansi, Вы писали:
VD>С++ фактически вообще не поддерживает массивы как первокласные сущьности. Массив в С++ — это всего лишь область памяти. Рельная работа же ведется на базе указателей и классов-оберток.
Вообще, ничто не поддерживает массивы как первоклассные сущности Везде и все есть область памяти. И ваще, это всего лишь поток зарядов 0 — 1, есть заряд — нет заряда, любит — не любит, нальет — не нальет
new RSDN@Home(1.1.4, 303) << new Message(); std::head::ear << "Celtic Awakening — The Wind Dances";
Здравствуйте, Sinclair, Вы писали:
E>>А что, в Java не было наследования интерфейсов? S>Ну ладно, теперь уже можно в принципе обойтись и без COM/Corba. Если столкнулся с Net/Java, конечно.
Без COM с его системой агрегирования — пожалуй, не обойтись.
)
Этож вроде не так
0 — 1, есть заряд — нет заряда, любит — не любит, нальет — не нальет
Перекуём баги на фичи!
