Как в С++ правильно работать с функциями?!

← →
default © (2006-09-07 13:16) [40]

Cyrax © (07.09.06 11:21) [37]
> А o.intfield не получится ?

да, не получится

> Ведь при упаковке создаётся объект и у етого объекта должно
> быть поле с числом 7...

да, но оно не доступно без распаковки(ты пойми, что в переменной типа object может храниться ссылка на экземпляр абсолютно любого типа, о каком o.intfield может идти речь?)

> Выходит, при упаковке/распаковке происходит не перемещение,
> а копирование. Это же УЖАС !!! Нарушается целостность данных
> !!!
> Кто нибудь может вразумительно объяснить ?

ничего не нарушается, всё нормально, разве что код выдаёт несколько неестественный по виду кода результат

вот что я думаю
когда мы работаем с размерными типами изменение какого-либо экземпляра размерного типа не сказываются на чём-либо другом, это для нас понятно и естественно
не удивляемся же мы коду
int x = 5;
int y = x;
y = 7; // x = 5!
предположим такое
StructType st; // выделение в стеке памяти под переменную
st.intfield = 7; // инициализация перед использованием переменной
object o = st; // boxing
StructType v = (StructType) o; // предположим здесь не
//создаётся копия в стеке, а имеем доступ
// через переменную v к запакованному размерному типу ссылка
// на который хранится в переменной o
v.intfield = 22; // вносим изменения, здесь нарушение единообразия
//происходит, изменение размерного экз-ра типа сказывается на
//упакованном экз-ре размерном типе
Console.WriteLine(((StructType) o).intfield); // выведется 22

поэтому то, что в C# unboxing всегда действует в купе с копированием, для меня разумно, единообразие штука необычайно полезная

> И вообще, что в C# является значением ссылки (например,
> object o) - адрес объекта в куче ? Если так, то чем это
> не указатель ?

уже объяснил Alkid
> Имеется ввиду доступ к полю intfield в примере ?
> (кстати, не читать - это значит неправильно ?)

да
правильно, только я подумал лучше на примере показать о чем речь, а то забыл из поста убрать

← →
Cyrax © (2006-09-07 22:58) [41]

...всё папалядку... (уже становится интелесней...)

guav © (06.09.06 12:52) [17]
var
I: Integer;
P: ^Integer;
begin
P := @I;
ShowMessageFmt("P points at %P", [P]);
Inc(P);
ShowMessageFmt("P points at %P", [P]);
end;

А вот с указателем на объект такого ни за что не провернёшь...

> Alkid © (07.09.06 10:44) [34]
> Хм. А какие навороты там друг с другом пересекаются?

Довольно забавный пример... Но сначала хочу немного поправиться: хотел сказать, не навороты должны друг с другом пересекаться, а навороты с уже имеющейся функциональностью (кстати, многим может показаться, что я ретируюсь)...
Так вот. Возьмём всем известные константные поля и ... readonly-поля. Кто работал с C#, знает, что это. Функциональность их весьма схожа... И даже очень схожа.
(кстати, знаешь, чем они отличаются ?)

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

...из всего этого делаем вывод: поскольку для новичков важнее огородить себя от возможных собственных ошибок, а для опытных программистов на первом месте стоит гибкость и эффективность, то C# более предпочтителен именно для новичков...

> Не совсем. А что если в какой-либо реализации .NET или Java ссылка - это
не указатель, а, например, индекс в таблице объектов? То есть реализация абстракции "ссылка" - это далеко не всегда обязательно указатель.

И я тоже согласен...

Alkid © (07.09.06 11:26) [38]
> А это принципиально неизвестно. Может быть указатель, может быть не
> указатель, программе на C# это должно быть фиолетово

Это программе фиолетово, а нам - нет...

И вообще, значение ссылки - это объект.

Это верно, например, для C#. Но не для С++ или Java... если не говорить об абстракциях...

Сдаётся мне, что reference в C++ и reference в Java/C# - это слишком разные вещи, что бы бросать их в одну кучу. Взять хотя бы то, что в C++ ссылки указывают всё время своей жизни на одно и то же, а в Java/C# могут менять объект, на котороый указывают и могут указывать на null.

Не думаю. Это всё потому, что то, что Microsoft называет объектами ссылочного типа, не что иное, как указатели.

Приведу пример кода:

using System;
class CValue
{ public int val;
public CValue(int x) {val = x;}
}
class Example_1
{public static void Main()
{ CValue p1 = new CValue(1);
CValue p2 = p1;
Console.WriteLine(”p1 = {0}, p2 = {1}”, p1.val, p2.val);
p2.val = 2;
Console.WriteLine(”p1 = {0}, p2 = {1}”, p1.val, p2.val);
}
}
Результат:
p1 = 1, p2 = 1
p1 = 2, p2 = 2

> vvcom © (07.09.06 12:30) [39]
>> Чушь. Однозначно.
>> Значением ссылки являются данные, а указателя - адрес данных...
> Да, да. Неверно выразился...
Ну не так прям э... совсем, чтоб уж очень это, но так... может ыы, разве что чуть-чуть...

...но также четко представляю, то в процедуру (смотрим асм) передается на самом деле указатель. А уже интерпретация этого value (адрес или данные) лежит на совести шамана-компилятора.

Так это очевидно. Иначе, если бы передавались сами данные, то это была бы уже передача по значению, а не по ссылке...
Да и вообще, любая переменная имеет дело с адресом - ей же надо как-то менять значение. Но мы же не называем переменную указателем, чётко понимаем между ними различия...

>default © (07.09.06 13:16) [40]
>> А o.intfield не получится ?
>да, не получится

Ещё один досадный фокус Microsoft"а...

да, но оно не доступно без распаковки(ты пойми, что в переменной типа object может храниться ссылка на экземпляр абсолютно любого типа, о каком o.intfield может идти речь?)

Почему ссылка ? Упаковка ведь происходит из заранее известной структуры... Т.е. почему бы не создать объект с полем именно intfield именно целого типа ?

ничего не нарушается, всё нормально, разве что код выдаёт несколько неестественный по виду кода результат

А вот насчёт целостности данных неубедительно...

вот что я думаю
когда мы работаем с размерными типами изменение какого-либо экземпляра размерного типа не сказываются на чём-либо другом...

Дырка в рассуждениях:
StructType v = (StructType) o; // предположим здесь не...
Здесь объектом-целью является значимый тип, а такое присваивание всегда приводит к копированию правой части (возможно, после преобразования) в левую...

Я предлагаю такое объяснение.
Если у нас будет две ссылки на один и тот же объект в куче и одну из ссылок (говорим обычно "объект") мы распакуем, то у нас из одного объекта получится две сущности - объект в куче и переменная или структура в стеке, которые мы сможем менять независимо... Допустим, что при упаковке/распаковке происходит не копирование объектов, а перемещение. В этом случае, если мы проведём распаковку одной из этих двух ссылок, то объект в куче уничтожится (а в стеке будет создан его значимый аналог). Тогда другая ссылка будет ссылаться на несуществующий объект в куче.
Но такого Microsoft допустить не может, поскольку она намеренно разделила указатели и ссылки (хотя Microsoft"овская ссылка, а точнее объект ссылочного типа, это тоже указатель), не желая, в частности, связываться с проблемой "указателя на несуществующий объект".

Таким образом, выделяю 2 два довода:
1. Microsoft недолюбливает указатели
2. (Самый, на мой взгляд, жизнеспособный.) Операция упаковки/распаковки часто выполняется неявно. В любом случае эта операция не претендует на роль деструктора объекта, чтобы его уничтожать в куче...

>> И вообще, что в C# является значением ссылки (например,
>> object o) - адрес объекта в куче ? Если так, то чем это
>> не указатель ?
>уже объяснил Alkid

Я тоже (см. далеко назад)... :)

__________________________________________________________
"Никогда мне не понять "программистов" предпочитающих
платить производительностью за НЕЖЕЛАНИЕ понять указатели...
...да любой уважающий себя программер должен понимать указатели."

Блин, голова разболелась...

← →
Cyrax © (2006-09-07 23:17) [42]

...а впереди ещё исключения...

← →
default © (2006-09-07 23:23) [43]

ты тут не уходи щас я тебе настряпаю чего-нибудь

← →
Cyrax © (2006-09-07 23:26) [44]

Быстрее тряпай, спать охота...

← →
guav © (2006-09-07 23:26) [45]

>> guav © (06.09.06 12:52) [17]
> А вот с указателем на объект такого ни за что не провернёшь...

Правда ? Не хочу проверять но если это так то... меня это даже радует.
Объекты выделяются в куче и по отдельности (можно переопределить выделение, но это никогда не применяется, по кр мере я не встречал такое). А так как в этом случае они лягут в кучу непредвиденным образом, нечего пытаться искать что-либо определённое вроде объекта.
Т.е. инкрементировать указатель на объект - глупая идея.

← →
Cyrax © (2006-09-07 23:29) [46]

Блин, я не соображаю...

Где default ???

← →
Cyrax © (2006-09-07 23:30) [47]

Все сюда...

...только каждый за себя...

← →
Cyrax © (2006-09-07 23:31) [48]

А где ketmar ?

← →
Cyrax © (2006-09-07 23:32) [49]

DEFAULT !!! Ты где ?

← →
Cyrax © (2006-09-07 23:44) [50]

Default, можешь обмазговывать всё спокойно. Я пошёл в out...

з.ы. Напиши что нибудь интересное, чтобы долго думать пришлось... :)

← →
default © (2006-09-07 23:44) [51]

> Почему ссылка ? Упаковка ведь происходит из заранее известной
> структуры... Т.е. почему бы не создать объект с полем именно
> intfield именно целого типа ?

ссылка потому как object тип ссылочный(переменные его типа ссылаются на данные, а не являются ими)
на счёт последнего вопроса, так он и создаётся " объект с полем именно
intfield именно целого типа", но не доступен по уже пояснённой причине

> А вот насчёт целостности данных неубедительно...

поясни что ты понимаешь под нарушением целостности в данном случае
> Дырка в рассуждениях:
> StructType v = (StructType) o; // предположим здесь не..
> .
> Здесь объектом-целью является значимый тип, а такое присваивание
> всегда приводит к копированию правой части (возможно, после
> преобразования) в левую...

я же написал --> предположим
всегда в C#, собственно unboxing это получение доступа к экземпляру упакованному размерного типа(никакого копирования нет)
вот в языке C# собственно unboxing всегда идёт вместе с копированием
у Рихтера можно про это прочесть, например

> "Никогда мне не понять "программистов" предпочитающих
> платить производительностью за НЕЖЕЛАНИЕ понять указатели.
> ..
> ...да любой уважающий себя программер должен понимать указатели.
> "

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

← →
Cyrax © (2006-09-07 23:45) [52]

guav, может всё-таки попробуешь ?..

← →
guav © (2006-09-07 23:46) [53]

> guav, может всё-таки попробуешь ?..

"

← →
Cyrax © (2006-09-07 23:47) [54]

Всё-таки успел стряпать...
НО:
Я ЩАС НЕ СООБРАЖАЮ ...

← →
Cyrax © (2006-09-07 23:48) [55]

guav, это чё за козяблик на экране ?

← →
guav © (2006-09-07 23:49) [56]

> guav, может всё-таки попробуешь ?..

"а шо його пробовать, сало як сало"

нет, действительно что я сейчас могу попробовать.
инкрементировать ссылку на объект ? Если не работает то хорошо, если работает, то зря, но я бы всё равно до такого никода не додумался.

← →
Cyrax © (2006-09-07 23:54) [57]

Всё, в out...

з.ы. ...пишем компиляторы, оси, декомпиляторы...

← →
default © (2006-09-07 23:58) [58]

Cyrax © (07.09.06 23:54) [57]
вот здесь
http://rsdn.ru/?forum/?group=net
раздел "Асимметрия boxing/unboxing" прочитай потом, там немного

← →
Cyrax © (2006-09-08 08:17) [59]

default © (07.09.06 23:58) [58]
раздел "Асимметрия boxing/unboxing" прочитай потом, там немного

Чё-то буквы полетели... не видать их совсем...

← →
Cyrax © (2006-09-08 20:11) [60]

Куда девались alkid и vvcom ?
(см. [41])

← →
Cyrax © (2006-09-08 23:07) [61]

Вот что я придумал.
И ссылка, и указатель содержат адрес... Возникает вопрос, почему мы получаем значение ссылки без разыменования ? Возможный ответ: ссылка отличается от указателя тем, что её разыменование при выполнении кода происходит автоматически (но не неявно, поскольку неявные преобразования всегда можно выполнить явно, что не скажешь о ссылке) и поэтому значение ссылки нельзя изменить после инициализации (происходит разыменование и вместо адреса получаем значение, которому пытаемся присвоить адрес). Если так, то на низком уровне ссылка представлена как указатель, а на уровне поведения в программе - как ссылка в том понимании, которое нам навязывают многие авторы: ссылка - это синоним переменной, т.е. фактически ничем от переменной не отличается. И это подтверждается использованием ссылок в программе - работаем в точности как с переменной... Получается, что ссылка - это нечто среднее между указателем и переменной (об абстракциях по прежнему не говорим...).
И если эта "теория" верна, то если кто рассерчал, прошу сильно не выражаться... :)
А что по поводу ссылок в C#, то скорее всего это те же ссылки, что и в C++. Но с единственным отличием: значение ссылки можно изменить, но только в процессе упаковки/распаковки...

А вот теперь насчёт упаковки/распаковки в C#. Берём объект (ссылку) obj1 в куче, распаковываем - получаем сущность в стеке. Затем её снова упаковываем в кучу. Теперь что здесь происходит. В куче создаётся новый объект obj2 или же упаковываемая сущность замещает obj1 в куче. Если создаётся новый, то происходит утечка памяти (у нас, конечно же есть сборщик, но это не повод к таким действиям). Если же происходит замещение, то напрашивается на наличие связи между объектом obj1, оставшимся в куче, и вновь упаковываемой сущностью. Но раз есть такая связь, то почему бы не синхронизировать сущности в стеке и куче ?

guav © (07.09.06 23:26) [45]
Правда ? Не хочу проверять но если это так то... меня это даже радует.
Объекты выделяются в куче и по отдельности (можно переопределить выделение, но это никогда не применяется, по кр мере я не встречал такое). А так как в этом случае они лягут в кучу непредвиденным образом, нечего пытаться искать что-либо определённое вроде объекта.
Т.е. инкрементировать указатель на объект - глупая идея.

Да?.. А в C++ это активно и эффективно применяется...

default © (07.09.06 23:44) [51]
>> Почему ссылка ? Упаковка ведь происходит из заранее известной
>> структуры... Т.е. почему бы не создать объект с полем именно
>>intfield именно целого типа ?
>ссылка потому как object тип ссылочный(переменные его типа ссылаются на
>данные, а не являются ими)
>на счёт последнего вопроса, так он и создаётся " объект с полем именно
>intfield именно целого типа", но не доступен по уже пояснённой причине

Если со ссылкой типа object не связывается никакой информации об объекте, на который он ссылается, то как тогда происходит его распаковка, а точнее - во что происходит?
А если связывается, то моя идея остаётся в силе...

поясни что ты понимаешь под нарушением целостности в данном случае

Это когда две ссылки ссылаются на один объект в куче и при распаковке одной из ссылок в стек мы из одной сущности (объекта в куче) получаем две сущности: значимого типа и ссылочного. Причём изменение одной из них никак не влияет на другую. Аналогия с БД: одна и та же информация хранится в двух местах...
И я не думаю, что операция распаковки/упаковки - это операция создания новой сущности... А если так, то наблюдается нарушение целостности данных...

всегда в C#, собственно unboxing это получение доступа к экземпляру упакованному размерного типа(никакого копирования нет)
вот в языке C# собственно unboxing всегда идёт вместе с копированием
у Рихтера можно про это прочесть, например

Ошибка ? Идёт с копированием, или нет...

default, не найду раздел "Асимметрия boxing/unboxing"...

← →
default © (2006-09-09 00:24) [62]

Cyrax © (08.09.06 23:07) [61]

> Если со ссылкой типа object не связывается никакой информации
> об объекте, на который он ссылается, то как тогда происходит
> его распаковка, а точнее - во что происходит?
> А если связывается, то моя идея остаётся в силе...

на платформе .NET твоя идея осуществима поскольку в управляемых модулях хранится полная информацию о типах, членах и тд
(метаданные) и с помощью механизма отражения можно узнать всё об экземпляре типа на который указывает ссылка, менять его поля, вызывать методы и тд
и тогда компилятор при встрече вызовов типа o.IntField = 7;(o имеет тип object для определённости) мог бы генерировать код который "шерстит" информацию об экземпляре типа на который храниться ссылка в o, проверяет тем самым доступна-ли требуемая функциональность и если да - использует её(в данном примере, изменить поле IntField если экземпляр типа на который храниться ссылка в o имеет такое поле, вызывающий код имеет права на доступ к полю и тд)
НО! единственное и очень критичное НО! ЭТО СЛИШКОМ МЕДЛЕННО!
именно поэтому такое не реализовано на практике
и компилятор генерирует такой код, который пользует гарантированную функциональность, то есть, например, для всех ненулевых ссылочных переменных типа object можно вызвать метод ToString() и тд
ТАК ЧТО ЕЩЁ РАЗ ПОВТОРЯЮ - ВСЁ ДЕЛО В СКОРОСТИ

> Ошибка ? Идёт с копированием, или нет...

нет, я так и думал, что подумаешь что я ошибся, предложения построил довольно заковыристо...
просто ты до этого писал
> Здесь объектом-целью является значимый тип, а такое присваивание
> всегда приводит к копированию правой части (возможно, после
> преобразования) в левую...
вот к выделенному относится моё всегда в C# чем хотел подчеркнуть, что копирование обязательно не во всех языках

> не найду раздел "Асимметрия boxing/unboxing"...

вот тебе копия
" Асимметрия boxing/unboxing Процедура, обратная boxing’у (получение значения из запакованного значения), носит название unboxing. Существенно то, что эта процедура не является противоположностью boxing’у. Дело в том, что для получения значения, лежащего внутри упаковки, в IL совершенно не нужно ни создавать новый объект, ни копировать в него значение. Достаточно получить адрес данных, лежащих внутри упаковки, и использовать этот адрес в операциях с этим значением. Так вот, в IL unboxing – это и есть операция получения адреса значения внутри упаковки, то есть это разновидность операции приведения. Unboxing не требует ни выделения памяти (хоть бы и стековой), ни копирования. Только небольшое упражнение по адресной арифметике. Поэтому эффективность unboxing’а на порядок выше, чем boxing’а. Ещё короче, boxing = new instance + копирование, а unboxing = приведение (вычисление адреса). Тут есть одна неприятность. Далеко не все языки программирования в .Net могут воспользоваться в полной мере быстротой операции unbox. Они не умеют получать прямой доступ к содержимому boxed-объекта. Поэтому компилятор каждый раз после операции unbox вставляет код копирования значения в стековую переменную. Так обстоит дело в C# и VB.Net. Для этих языков unboxing = приведение + копирование. А вот в MC++ … Но об этом чуть позже. Чтобы окончательно прояснить ситуацию, ниже приведён код на C++, который представляет в явном виде те операции, которые происходят при boxing/unboxing. Видно, что операция boxing на C++-манер сводится к выделению памяти и срабатыванию конструктора. А операция извлечения значения (unboxing) – это операция приведения к типу значения. template <typename Value> class Box { public: Box(const Value& val) { this->val = val; } operator Value&() { return val; } private: Value val; }; int _tmain(void) { int n = 12345; void* pObj= new Box<int>(n); // boxing int& pn = *(Box<int>*)pObj; // pure unboxing int n2 = *(Box<int>*)pObj; // unboxing + copy return 0; } Теперь рассмотрим типичные ситуации, в которых возникает boxing, и способы борьбы с ним. "(c) http://rsdn.ru/?forum/?group=net
про boxing/unboxing не стал ничего писать(прочитай кстати всю статью эту) и так я что-то разговорился
а завтра я выхожу в аут, и так я тут расслабился на этом форуме...
так что если отвечать не буду, знай - просто ушёл

← →
default © (2006-09-09 00:34) [63]

> единственное и очень критичное НО!

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

← →
guav © (2006-09-09 00:45) [64]

[61] Cyrax © (08.09.06 23:07)
> Да?.. А в C++ это активно и эффективно применяется...

Внимательно читай [45] там написано почему в Delphi (именно в Delphi) инкремент указателя на объект ни к чему хорошему не приведёт.

← →
Cyrax © (2006-09-09 22:34) [65]

default © (09.09.06 00:24) [62]
на платформе .NET твоя идея осуществима поскольку в управляемых модулях хранится полная информацию о типах, членах и тд
(метаданные) и с помощью механизма отражения можно узнать всё об экземпляре типа на который указывает ссылка, менять его поля, вызывать методы и тд
и тогда компилятор при встрече вызовов типа o.IntField = 7;(o имеет тип object для определённости) мог бы генерировать код...

Да и не обязательно использовать механизм отражения, и не обязательно иметь метаданные. Информация о типах данных, на которые ссылается ссылка или указывает указатель связывается со ссылкой или указателем во всех языках, где они имеются (по крайней мере, в C, C++, C#, Java, Python, Pascal и др.) точно так же как и тип переменной с именем переменной. Т.е. для доступа к целому полю объекта (o.IntField) ничего шерстить не понадобиться, а следовательно, и времени тратить (вспомним операцию разыменования...). А вот на распаковку объекта времени уйдёт намного больше, поскольку С# осуществляет распаковку путём копирования сущности-объекта в стек.
Т.е. предложенный довод, как мне кажется, ничего не объясняет...

Вот моё объяснение.
Копирование ссылок происходит именно по значению, а не по адресу ("теория" [61] + подтверждение ей ниже). Т.е. копируется значение, а не адрес - точно так же, как и переменные (value-тип в терминах .NET). Всё. Это объясняет присваивание StructType v = (StructType) o, где ни о чём кроме как о копировании структур речи идти не может.
И вообще, рассмотрение вопроса о копировании/перемещении сущностей должно происходить не применительно к "=", а к оператору приведения (а также к неявному unboxing"у)... - допишу потом (срочные дела).

Кстати, подтверждение моей "теории" ([61]):
Но это не главное. Главное в другом. Посмотрите, как описано строковое поле в составе класса. Видите звёздочку? Это значит, что переменные объектов ссылочных типов в MC++ имеют тип указателей. То, что в C# тщательно скрывается от программиста (из лучших побуждений, конечно), то в MC++ явно видно. Если это указатель, то переменная ссылочная, а если это сам объект, то, очевидно, он имеет тип-значение.
Для обращения к полям и методам используются знакомые стрелочки. Если объект вызывает свой метод или обращается к полю через стрелочку, то яснее ясного – это указатель, и, значит, это ссылочный тип, а если через точку – то это тип-значение.
AValue a;
a.n = 5;
AClass* pA = new AClass();
pA->n = 5;
Объект ссылочного типа выделяется в памяти через new. А value-тип – как обыкновенная автоматическая переменная языка C.
Короче, в MC++ все различия между ссылочными и value-типами не маскируются, а ясно видны, и контролировать то, что происходит в программе, легче. (зато писать тяжелее. – прим.ред.)

← →
default © (2006-09-09 23:49) [66]

> Cyrax © (09.09.06 22:34) [65]
> Да и не обязательно использовать механизм отражения, и не
> обязательно иметь метаданные. Информация о типах данных,
> на которые ссылается ссылка или указывает указатель связывается
> со ссылкой или указателем во всех языках, где они имеются
> (по крайней мере, в C, C++, C#, Java, Python, Pascal и др.
> ) точно так же как и тип переменной с именем переменной.
> Т.е. для доступа к целому полю объекта (o.IntField) ничего
> шерстить не понадобиться, а следовательно, и времени тратить
> (вспомним операцию разыменования...). А вот на распаковку
> объекта времени уйдёт намного больше, поскольку С# осуществляет
> распаковку путём копирования сущности-объекта в стек.
> Т.е. предложенный довод, как мне кажется, ничего не объясняет.
> ..

ты не прав
например, возьмём Delphi(раз ты сказал, что метаданные не нужны, какой же ты наивняк всё-таки а!)
и такую процедуру, её вызывает некий внешний код и передаёт ей ссылки на объекты(о конкретном типе объектов она и понятия не имеет)
procedure P(o: TObject);
begin
// ну-ка покажи-ка мне как выяснить есть ли у объекта,ссылка на которой
// находится в o, поле с именем IntFiled типа Integer и если есть - изменить
// его на 22!
end;

а про остальное даже говорить не хочется:)

> Видите звёздочку? Это значит, что переменные объектов ссылочных
> типов в MC++ имеют тип указателей.

спасибо за порцию смеха:) звёздочка это синтаксис - то есть форма
содержание его может как угодно меняться...подобные аргументы просто смешны
есть ссылочная и размерная семантика, описанная в msdn
всё остальное - нелепость

← →
Cyrax © (2006-09-10 01:30) [67]

А ты разве не в отключке ?
Или решил до победного ?.. :)

Завтра я тебе тоже интересного намолюю...

← →
Cyrax © (2006-09-11 17:44) [68]

guav, default.
Чё это такое ? Где ето самое ?

> default © (09.09.06 23:49) [66]
> ты не прав

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

>например, возьмём Delphi(...[ай-ай-ай])
>и такую процедуру, её вызывает некий внешний код и передаёт ей ссылки
>на объекты(о конкретном типе объектов она и понятия не имеет)
>procedure P(o: TObject);
>begin
> // ну-ка покажи-ка мне как выяснить есть ли у объекта,ссылка на которой
>// находится в o, поле с именем IntFiled типа Integer и если есть - изменить
>// его на 22!
>end;

Изменить на 22 можно. Но определять имя поля в данном случае, я считаю, незачем. Да и вообще, поскольку речь идёт о семействе языков C, то предпочитаю примерчик приводить на C++. Слово, конечно, оставляю за тобой, но не думаю, что ты будешь против.
Итак, будешь настаивать на Delphi ?

а про остальное даже говорить не хочется:)

А зря. Было бы над чем посмеяться... :)

спасибо за порцию смеха:)

Если хошь, могу ещё вколоть...

звёздочка это синтаксис - то есть форма
содержание его может как угодно меняться...

Ну ты прям Америку открываешь...

подобные аргументы просто смешны

Какие аргументы смешны ?
Те, что подтверждают следующие слова ? :
То, что в C# тщательно скрывается от программиста (из лучших побуждений, конечно), то в MC++ явно видно...

А ведь в приведённом фрагменте кода именно указатели и подразумевались.
(Пренебрежение контекстом иногда приводит к опрометчивым выводам...)

есть ссылочная и размерная семантика, описанная в msdn
всё остальное - нелепость

Ты это к чему ?

______________________________________________________
По поводу StructType v = (StructType) o допишу потом.
Опять времени не хватило...
______________________________________________________
з.ы. А ведь факт доказывать легче, чем опровергать обосновывающие его доводы...

Забыл мыло указать...

Кстати, судя по числам, в "завтра" уложился... :)

> То, что в C# тщательно скрывается от программиста (из лучших
> побуждений, конечно), то в MC++ явно видно...

это лабуда
ничёго ни от кого не скрывается тем более тщательно:)
в спецификации по C# чётко описана ссылочная и размерная семантика
то что ссылочные типы от размерых в коде C++ можно отличить по "." и "->"
можно лишь рассматривать в пользу наглядности кода и то, думаю, можно и на этот счёт поспорить если захотеть

> Изменить на 22 можно. Но определять имя поля в данном случае,
> я считаю, незачем. Да и вообще, поскольку речь идёт о семействе
> языков C, то предпочитаю примерчик приводить на C++. Слово,
> конечно, оставляю за тобой, но не думаю, что ты будешь
> против.
> Итак, будешь настаивать на Delphi ?

Delphi, имя поле обязательно нужно, может у объекта этих полей Integer как китайцев в китае

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

какая стадия компиляции?! я же говорил, процедура и понятия не имеет что за типы объектов могу к ней в качестве параметра пожаловать

это лабуда
ничёго ни от кого не скрывается тем более тщательно:)

Будет потом

в спецификации по C# чётко описана ссылочная и размерная семантика
то что ссылочные типы от размерых в коде C++ можно отличить по "." и "->"
можно лишь рассматривать в пользу наглядности кода и то, думаю, можно и на этот счёт поспорить если захотеть

А ведь сам намекаешь ! :)
Тоже будет.

Delphi, имя поле обязательно нужно, может у объекта этих полей Integer как китайцев в китае

А не слишком ли много требуешь? И Делфа, и имена полей.
Но не все китайцы разный сдвиг имеют :) Выходит, и не обязательно имена то определять. Достаточно сдвигов...

какая стадия компиляции?!

Уже беспокойнее стало !?!?....

я же говорил, процедура и понятия не имеет что за типы объектов могу к ней в качестве параметра пожаловать

А ето и не обязательно сразу знать. Можно попозже узнать...

______________________________________
з.ы. Спокойствие... главное спокойствие...
з.ы. Всё будет...

> А не слишком ли много требуешь? И Делфа, и имена полей.
>
> Но не все китайцы разный сдвиг имеют :) Выходит, и не обязательно
> имена то определять. Достаточно сдвигов...

ты хочешь задать сдвиг статически?
у разных типов объектов даже поле с одинаковым именем и типом может находиться по разным сдвигам...
я тебе уже говорил - это невозможно...ну нельзя в рантайм такую инфу получить в Delphi, C++ и тд, для произвольного объекта

> А ето и не обязательно сразу знать. Можно попозже узнать.
> ..

можно и попозже было бы откуда:)

ты хочешь задать сдвиг статически?
у разных типов объектов даже поле с одинаковым именем и типом может находиться по разным сдвигам...

Сначала тип определяем, а потом и сдвиг...

я тебе уже говорил - это невозможно...ну нельзя в рантайм такую инфу получить в Delphi, C++ и тд, для произвольного объекта

Сдаётся мне, что ты теряешь в этом уверенность...
Русский человек и не на такое способен... :)

можно и попозже было бы откуда:)

Не на зоне всё-таки сидишь...

> Сдаётся мне, что ты теряешь в этом уверенность...
> Русский человек и не на такое способен... :)

я таки жду кода на Delphi, с нетерпением
а надежду я не имею, потому что знаю, что это впринципе невозможно

з.ы. Всё будет...

Кстати, а почему всё-таки на делфе ?

А ты что - сразу на С# ?

Как в С++ правильно работать с функциями?! Найти похожие ветки