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

← →
Konstantin555 © (2006-09-06 00:05) [0]

Пишу так:

#include <iostream> #include <string> using namespace std; int main() { extern void swap(int*,int*); void swap(int* p, int* q) { int t=*p; *p=*q; *q=t; } cout<<swap(1,4); string name; cout<<"Please enter you name:\n"; getline(cin,name); cout<<"Hello, "<<name<<"!\n"; return 0; }

В результате ошибки:
error C2601: "swap" : local function definitions are illegal
error C2664: "swap" : cannot convert parameter 1 from "const int" to "int *"
Conversion from integral type to pointer type requires reinterpret_cast, C-style cast or function-style cast

КАК ИСПРАВИТЬ?!

← →
DiamondShark © (2006-09-06 00:11) [1]

> КАК ИСПРАВИТЬ?!

Перенести за пределы main
Ну нету в Ц вложенных ф-ций. Нету.
(плохой язык)

← →
Cyrax © (2006-09-06 00:24) [2]

А extern можешь убрать - он подразумевается по умолчанию...
Да и вообще, объявление можно убрать - в одном модуле обычно его не пихают с implement"ом...

DiamondShark © (06.09.06 00:11) [1]
(плохой язык)

Ты о русском или C++ ?

← →
guav © (2006-09-06 00:25) [3]

> cout<<swap(1,4);

Это что ?
Литеральные константы не указатели (кроме 0).
И вообще не lvalue чтобы получать на их ссылку и менять их местами.
и swap возвращает void, что должно пойти на cout ?

> [1] DiamondShark © (06.09.06 00:11)

> (плохой язык)

ага...

← →
Cyrax © (2006-09-06 00:29) [4]

Да и вообще, объявление можно убрать - в одном модуле обычно его не пихают с implement"ом...

...если етот implement красуется до main"a...

← →
Аноним2000 (2006-09-06 00:59) [5]

2Konstantin555
вот ентот фрагмент
> extern void swap(int*,int*); > > void swap(int* p, int* q) > { > int t=*p; > *p=*q; > *q=t; > } > > cout<<swap(1,4);
бред редкостный. просто удали его и все заработает

← →
Cyrax © (2006-09-06 01:19) [6]

guav © (06.09.06 00:25) [3]
> cout<<swap(1,4);
Это что ?
Литеральные константы не указатели (кроме 0).

1. Не литерные константы, а целые константы...
2. 0 это никакой не указатель - см. п.1

И вообще не lvalue чтобы получать на их ссылку и менять их местами.

Не ссылку, а указатель (см. функцию)...

и swap возвращает void, что должно пойти на cout ?

Ничего. Выйдет ошибка...

>> (плохой язык)
> ага...
Всё-таки о русском...

← →
Джо © (2006-09-06 01:19) [7]

> [6] Cyrax © (06.09.06 01:19)
> >> (плохой язык)
> > ага...
> Всё-таки о русском...

О говяжьем.

← →
guav © (2006-09-06 01:31) [8]

> [6] Cyrax © (06.09.06 01:19)

> 1. Не литерные константы, а целые константы...

Литералы это и есть константы
Invariant program elements are called "literals" or "constants." The terms "literal" and "constant" are used interchangeably here. Literals fall into four major categories: integer, character, floating-point, and string literals.
http://msdn2.microsoft.com/en-us/library/c70dax92.aspx

> 2. 0 это никакой не указатель - см. п.1

0 это типа nil, пустой указатель. функция с таким объявлением может принять в качестве параметров (0, 0) (хотя данная функция и приведёт к AV при выполнении)

> Не ссылку, а указатель (см. функцию)...

ну да, ошибся... привык что это синонимы.

> Ничего. Выйдет ошибка...

так и я о том же.

> >> (плохой язык)
> > ага...
> Всё-таки о русском...

кто о чём, но я о С++, в часности о http://delphimaster.net/view/15-1157465777/

← →
vidiv © (2006-09-06 02:21) [9]

Объясните, пожалуйста, смысл этой строки???

> cout<<"Please enter you name:\n";

А точнее символов <<

← →
Cyrax © (2006-09-06 09:12) [10]

Всё, дальше идём в духе :)

guav © (06.09.06 01:31) [8]
>> 1. Не литерные константы, а целые константы...
>Литералы это и есть константы

Тогда получается тавтология:
литерная константа = литерный литерал (или константная константа)...

> Литералы это и есть константы
Invariant program elements are called "literals" or "constants." The terms "literal" and "constant" are used interchangeably here. Literals fall into four major categories: integer, character, floating-point, and string literals.

Настораживает "The terms "literal" and "constant" are used interchangeably here"
В более строгом понимании константа может быть представлена, например, символьным или числовым литералом. В примере в конечном счёте используется анонимная константа...

0 это типа nil, пустой указатель

1. nil - это в pascal"е, а в C - null.
2. 0 имеет тип int. Но с помощью стандартных преобразований приводится к типу указателя.

кто о чём, но я о С++...
Сожалею... :)

...в часности о http://delphimaster.net/view/15-1157465777/

А что там такого, если не секрет ?

> vidiv © (06.09.06 02:21) [9]
> Объясните, пожалуйста, смысл этой строки???
>> cout<<"Please enter you name:\n";
>А точнее символов <<

Это оператор вывода в поток.

← →
Cyrax © (2006-09-06 11:55) [11]

Хочу сделать вот такое замечание.
В паскале то, что называют указателем, является на самом деле (по реализации) не чем иным, как сцылкой...

← →
DiamondShark © (2006-09-06 12:06) [12]

> >А точнее символов <<
>
> Это оператор вывода в поток.

Какой это оператор -- зависит от того, какой инклуд подцеплен к исходному файлу.

← →
DiamondShark © (2006-09-06 12:08) [13]

> В паскале то, что называют указателем, является на самом
> деле (по реализации) не чем иным, как сцылкой...

Всё с точностью до наоборот. УМЧ.

← →
evvcom © (2006-09-06 12:13) [14]

> [11] Cyrax © (06.09.06 11:55)
> В паскале то, что называют указателем, является на самом
> деле (по реализации) не чем иным, как сцылкой...

А в чем разница? И пишется вообще-то так: "ссылка".

← →
DiamondShark © (2006-09-06 12:18) [15]

> А в чем разница?

Ссылка -- абстрактное понятие.
Указатель -- машинно-зависимое.

← →
Cyrax © (2006-09-06 12:46) [16]

DiamondShark © (06.09.06 12:06) [12]
Какой это оператор -- зависит от того, какой инклуд подцеплен к исходному файлу.

Да, но в контексте программы это всё-таки оператор потокового вывода...
Вспомним вопрос vidiv: "Объясните смысл строки..., а точнее символов <<"...

Всё с точностью до наоборот. УМЧ.

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

Ссылка -- абстрактное понятие.
Указатель -- машинно-зависимое.

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

← →
guav © (2006-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;

> ...в часности о http://delphimaster.net/view/15-1157465777/
>
> А что там такого, если не секрет ?

Мой вопрос про сишную обработку исключений.

← →
default © (2006-09-06 12:59) [18]

штука в том, что указатель это путь к анархии в доступе к памяти:)
его значение можно менять получая доступ к памяти, возможно, непринадлежащей объекту на который исходной указывал указатель
ссылка такого не допускает, ссылка это нечто дающее возможность работать с самим объектом, а не его копией(вольное и не полное определение)
поэтому в managed коде указателей нет, есть ссылки их в большинстве случае заменяющие

← →
Alkid © (2006-09-06 13:33) [19]

> штука в том, что указатель это путь к анархии в доступе
> к памяти:)
> его значение можно менять получая доступ к памяти, возможно,
> непринадлежащей объекту на который исходной указывал указатель
> ссылка такого не допускает, ссылка это нечто дающее возможность
> работать с самим объектом, а не его копией(вольное и не
> полное определение)
> поэтому в managed коде указателей нет, есть ссылки их в
> большинстве случае заменяющие

Не совсем верно, в .NET-managed code они могут быть в unsafe-коде (C# позволяет такой делать). В его рамках и указатели есть и их арифметика и возможность нетипобезопасных приведений указателей друг к другу. В Java их и правда нет. Собственно спор "ссылки vs. указатели" - это спор обобщённости и эффективности. В каждой задаче есть своя специфика и есть свои средства решения. Где-то и на асме надо писать, где у тебя нет никаких обобщений, сплошная "машинная специфика".

← →
default © (2006-09-06 13:37) [20]

Alkid © (06.09.06 13:33) [19]
unsafe код это неуправляемый, CLR закрывает на него глаза
если таковой встретится в среде недоверяющей небезопасному коду, то такой код вообще исполнен не будет

← →
default © (2006-09-06 13:46) [21]

+[20]
пардон, я по запарке попутал управляемость с безопасностью
в безопасном коде нет указателей, а не в управляемом

← →
default © (2006-09-06 13:47) [22]

"CLR закрывает на него глаза"
в смысле, что этот код не проходит верификацию

← →
default © (2006-09-06 13:51) [23]

Alkid © (06.09.06 13:33) [19]
кстати в C# гадство есть, нельзя получать доступ к полям упакованного размерного типа, приведение к размерному типу создаёт копию
в MC++ это можно...
есть один выход - интерфейсы, но это не очень удобное
я было в один подумал, что такое возможно в unsafe коде, но хрен...:(

← →
Alkid © (2006-09-06 14:03) [24]

Упакованного - это про boxing/unboxing?

← →
default © (2006-09-06 14:50) [25]

Alkid © (06.09.06 14:03) [24]
ага

← →
Alkid © (2006-09-06 14:52) [26]

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

← →
default © (2006-09-06 15:02) [27]

Alkid © (06.09.06 14:52) [26]
а причём здесь это?
а критерии в мсдн-е есть когда стоит применять структуры вместо классов если ты об этом

← →
Cyrax © (2006-09-06 19:49) [28]

Тьфу, блин. Запутался я с этими ссылками и указателями.
Но... если подумать... Есть в паскале и ссылки, и указатели (и это разные вещи !!!). Ссылки используются только для передачи параметров в функцию/процедуру (передача по ссылке). Т.е. ссылки в программе нельзя объявлять и использовать в отличие от указателей. А вот указатели в паскале - обычное дело.

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;

Это что - фокус? Хорошо... твоя взяла... :)

Мой вопрос про сишную обработку исключений.

Тебе нужна помощь или ты хочешь показать на примере исключений преимущества С... ?

default © (06.09.06 13:51) [23]
кстати в C# гадство есть, нельзя получать доступ к полям упакованного размерного типа...

Размерный - я так понимаю значимый (value). Т.е. хочешь сказать, что, допустим, если целое упакованное взять как объект, то не сможешь получить его значение (не распаковывая)... Правильно я тебя понял ?

приведение к размерному типу создаёт копию

Объект что - остаётся в куче ?

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

← →
guav © (2006-09-06 20:28) [29]

> Тебе нужна помощь

Мне уже вроде ответили, но если есть что добавить, давай.

> ты хочешь показать на примере исключений преимущества С...
> ?

Думаю речь о преимуществах С++, а не о преимуществах С, т.к. в С нет ни деструкторов ни исключений (стандартных).
Так вот, про преимущества обработки исключений в С++ .
Хотелось бы мне увидеть там преимущества.
Неужели действительно лучше паковать каждый динамический ресурс в класс (вынося код который был бы иначе в finally в деструкторы этих классов) и следить чтобы у этого класса конструктор не вывал исключения (т.е. не выполять в конструкторе ничего кроме выделения ресурса), чем просто использовать finally (и писать код функции в порядке выполнения) и использовать надёжно-вызываемые деструкторы, не задумываяь о возможных исключениях в конструкторах.

← →
default © (2006-09-06 20:35) [30]

Cyrax © (06.09.06 19:49) [28]

> Размерный - я так понимаю значимый (value). Т.е. хочешь
> сказать, что, допустим, если целое упакованное взять как
> объект, то не сможешь получить его значение (не распаковывая).
> .. Правильно я тебя понял ?

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

StructType st;
st.intfield = 7;
object o = st;
((StructType) o).intfield = 22;
Console.WriteLine(((StructType) o).intfield); // выведется 7, а не 22

в MC++ такую проблему можно избежать
но подобные манипуляции редко, думаю, используются так что можно сильно не переживать по этому поводу:)

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

← →
default © (2006-09-06 20:37) [31]

последний абзац не читать:) забыл выкинуть

← →
Cyrax © (2006-09-06 20:47) [32]

guav © (06.09.06 20:28) [29]
Думаю речь о преимуществах С++, а не о преимуществах С

Я имел ввиду семейство языков C, ну за искл., чистого С...

Так вот, про преимущества обработки исключений в С++...

В общем, сначала гляну http://msdn2.microsoft.com/en-us/library/c70dax92.aspx... Но не щас... Запарился я на форуме - не спишь, не ешь. Так и зачахнуть можно...

P.S. Всё будет !!! ...

← →
evvcom © (2006-09-07 10:09) [33]

> [15] DiamondShark © (06.09.06 12:18)
> Ссылка -- абстрактное понятие.
> Указатель -- машинно-зависимое.

Любая реализация языка программирования написана для реальной машины/платформы, пусть даже виртуальной. Т.е. получается, что пока речь идет о теории и каких-то абстрактных языках, то оперируем термином "ссылка", как только начинаем говорить о реальном языке, то говорим "указатель"?

> [28] Cyrax © (06.09.06 19:49)
> Есть в паскале и ссылки, и указатели (и это разные вещи
> !!!). Ссылки используются только для передачи параметров
> в функцию/процедуру (передача по ссылке). Т.е. ссылки в
> программе нельзя объявлять и использовать в отличие от указателей.
> А вот указатели в паскале - обычное дело.

"Передача по ссылке" - это общепринятое выражение. А еще говорят, что если параметр передан по ссылке, то в переменной мы имеем указатель на данные. Так в чем же разница? Словоблудие и только. Мое имхо, это синонимы.

← →
Alkid © (2006-09-07 10:44) [34]

> А вообще, в C# много всяких ограничений и наворотов по сравнению
> с C++. Многие навороты в конце концов загромождают код и
> даже пересекаются друг с другом (частично дублируют свои
> функции), что не есть хорошо...
Хм. А какие навороты там друг с другом пересекаются?

> А вот по поводу ограничений, в частности отсутствие указателей
> (в безопасном коде) и шаблонов, - то это сильно урезает
> гибкость (часто и эффективность) средств разработки, доступных
> программисту.

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

← →
Alkid © (2006-09-07 10:47) [35]

> Любая реализация языка программирования написана для реальной
> машины/платформы, пусть даже виртуальной. Т.е. получается,
> что пока речь идет о теории и каких-то абстрактных языках,
> то оперируем термином "ссылка", как только начинаем говорить
> о реальном языке, то говорим "указатель"?

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

← →
evvcom © (2006-09-07 10:50) [36]

> [35] Alkid © (07.09.06 10:47)

Вот с этим согласен.

← →
Cyrax © (2006-09-07 11:21) [37]

> default © (06.09.06 20:35) [30]
StructType st;
st.intfield = 7;
object o = st;
((StructType) o).intfield = 22;
Console.WriteLine(((StructType) o).intfield); // выведется 7, а не 22

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

Здесь в [object o = st] st упаковывается в кучу, а o начинает ссылаться на st (в куче) (пока имеем 7). (StructType) o распаковывает o в стек, меняем на 22 (7 уже не должно быть). Короче жуть получается.
Выходит, при упаковке/распаковке происходит не перемещение, а копирование. Это же УЖАС !!! Нарушается целостность данных !!!
Кто нибудь может вразумительно объяснить ?

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

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

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

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

Т.е. получается, что пока речь идет о теории и каких-то абстрактных языках, то оперируем термином "ссылка", как только начинаем говорить о реальном языке, то говорим "указатель"?

Я другого мнения. Возьмём, к примеру С++ - там и указатели, и ссылки...

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

Например, в С++ предача по указателю и по ссылке - разные вещи. Да и в паскале есть и передача по указателю, и по ссылке...
Так что, ИМХО, разное всё это...

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

Чушь. Однозначно.
Значением ссылки являются данные, а указателя - адрес данных...

← →
Alkid © (2006-09-07 11:26) [38]

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

А это принципиально неизвестно. Может быть указатель, может быть не указатель, программе на C# это должно быть фиолетово. И вообще, значение ссылки - это объект.

> Я другого мнения. Возьмём, к примеру С++ - там и указатели,
> и ссылки...

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

← →
evvcom © (2006-09-07 12:30) [39]

> [37] Cyrax © (07.09.06 11:21)
> Да и в паскале есть и передача по указателю, и по ссылке...
> Так что, ИМХО, разное всё это...

А... ну да... Поднялся на небеса (в смысле с низкого уровня программирования :) ) и стал понятен смысл того, о чем ты. :)

> Чушь. Однозначно.
> Значением ссылки являются данные, а указателя - адрес данных...

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

← →
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]

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

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

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, с нетерпением
а надежду я не имею, потому что знаю, что это впринципе невозможно

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

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

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

C# ведь труднопереносим...

Кроссплатформенность

"Работать исключительно под .NET" - не означает "не быть переносимым".

То и значит, что работает исключительно под .NET.
Но мы говорим об осях, а не о подобных технологиях/платформах...

А ето ещё как ?

Ну а поддержка .NET что - прилепил соплями и всё ? :)

← →
07BB (2006-09-12 07:30) [92]

Эти холодильники отбили другие производители...

Default, мы ещё не закончили ету самую...
Твой довод всё-таки корявый...

Cyrax © (16.09.06 23:41) [94]
если ты реально хочешь сделать то о чём я прошу расскажи что ты собираешься сделать - я скажу где нарушение условия

Cyrax © (16.09.06 23:41) [94]
если ты реально хочешь сделать то о чём я прошу расскажи как ты собираешься это сделать - я скажу где нарушение условия или ошибка

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