[Delphi] Передача экземпляра класса в качестве параметра
пустой - это in
out - это out
var - это in/out
const - это тоже самое что пустой, только внутри изменять нельзя
out - это out
var - это in/out
const - это тоже самое что пустой, только внутри изменять нельзя
без квалификатора:
в процедуру передаётся _весь_ объект, и при этом происходит его копирование (особенно тут надо быть осторожными со строками и массивами!) Обрати внимание, что все библиотечные функции для работы со строками оформлены через var/const. нет ни одной такой:
с квалификаторами var,const в процедуру передаётся только ссылка на объект
в терминах С++ это примерно эквивалентно
и
квалификаторы out,in введены для связки с виндовыми технологиями COM
procedure P(a:MyType);
в процедуру передаётся _весь_ объект, и при этом происходит его копирование (особенно тут надо быть осторожными со строками и массивами!) Обрати внимание, что все библиотечные функции для работы со строками оформлены через var/const. нет ни одной такой:
function BlaBla(s:string):blabla;
с квалификаторами var,const в процедуру передаётся только ссылка на объект
в терминах С++ это примерно эквивалентно
void P(MyType &a); // для var
и
void P(const MyType &a); // для const
квалификаторы out,in введены для связки с виндовыми технологиями COM
поправка:
для классов квалификаторы смысла особого не имеют, ибо экземпляры - всегда указатели.
для классов квалификаторы смысла особого не имеют, ибо экземпляры - всегда указатели.
и при этом происходит его копированиеПиздец.
А вроде бы нормальным языком выглядит...
int func(MyType p)
копирование p происходит?
function func(MyType $p) {}Копирование не происходит. Данные копируются - только если явно клонируешь объект.
зато у тебя язык интерпретируемый, с нечёткой типизацией и ГК.
холивары "мой любимый язык" vs Delphi иди в отдельный тред разводить
холивары "мой любимый язык" vs Delphi иди в отдельный тред разводить
с нечёткой типизациейАга, согласен - огромный минус, было бы здорово, если бы в 6 они сделали все типы жёсткими. Или добавили бы перегрузку операторов для пользовательских классов.
и ГК.Ты про GC? А чем это плохо?
копирование (особенно тут надо быть осторожными со строками и массивами!)дык что копируется то?
внутренность копируется?
и с массивами как, внутренность копируется?
Опытным путем пришел к такому набору фактов
1)В run-time все 4 случая ведут себя одинаково
2)Удалось добиться различного поведения во время компиляции (т.е. нашел такой код, который компилится без var , и не компилится с ним)
3)Delphi генерит разный код для всех случаев
1)В run-time все 4 случая ведут себя одинаково
2)Удалось добиться различного поведения во время компиляции (т.е. нашел такой код, который компилится без var , и не компилится с ним)
3)Delphi генерит разный код для всех случаев
Копирования классов так просто не добиться, это нетривиальная задача
Для копирования классов даже придумали виртуальный класс TPersistent, в котором надо перекрыть метод
procedure AssignTo(Dest: TPersistent); virtual;
Для копирования классов даже придумали виртуальный класс TPersistent, в котором надо перекрыть метод
procedure AssignTo(Dest: TPersistent); virtual;
1)В run-time все 4 случая ведут себя одинаковочто-то сомневаюсь
const в рантайме скорей всего не работает
а вот in и out должны четко разделяться
вот тебе пример:
// global vars
B : TMyClass;
C : TMyClass;
// procedure MyProc(ляляля A: TMyClass)
if A = nil then
MessageBox('m1')
else
MessageBox('m2');
A := C;
// основная прога
B := (инициализация B)
C := (инициализация C)
A := B;
MyProc(A);
if A = B then
MessageBox('t1')
else
MessageBox('t2');
по моим соображениям должно получиться вот так
в пустом случае
m2 t1
в случае out
m1 t2
в случае var
m2 t2
в случае const не откомпилится
Для классов:
{$APPTYPE CONSOLE}
uses SysUtils;
type
TMyClass = class
end;
procedure Cast1(X:TMyClass);
begin
WriteLn(Format('%p',[@X];
end;
procedure Cast2(var X:TMyClass);
begin
WriteLn(Format('%p',[@X];
end;
procedure Cast3(const X:TMyClass);
begin
WriteLn(Format('%p',[@X];
end;
var
C: TMyClass;
begin
C:=TMyClass.Create;
Cast1(C);
Cast2(C);
Cast3(C);
C.Free;
end.
Пиздец.Незнание синтаксиса языка - не повод говорить "пиздец".
А вроде бы нормальным языком выглядит...
То, что дельфи по умолчанию копирует объекты - пиздец независимо от знания/незнания чего-либо.
Действительно,
procedure Cast1(X:TMyClass);
и
procedure Cast2(var X:TMyClass)
выводят различные данные. Как это интерпретировать? Происходит ли копирование экземпляра объекта? совсем ничего не понимаю.
procedure Cast1(X:TMyClass);
и
procedure Cast2(var X:TMyClass)
выводят различные данные. Как это интерпретировать? Происходит ли копирование экземпляра объекта? совсем ничего не понимаю.
нашел в справке по дельфи:
Every class (and therefore every component) is really a pointer. The compiler automatically dereferences class pointers for you, so most of the time you do not need to think about this. The status of classes as pointers becomes important when you pass a class as a parameter. In general, you should pass classes by value rather than by reference. The reason is that classes are already pointers, which are references; passing a class by reference amounts to passing a reference to a reference.
Только непонятен физический смысл "указатель на указатель на класс"
Every class (and therefore every component) is really a pointer. The compiler automatically dereferences class pointers for you, so most of the time you do not need to think about this. The status of classes as pointers becomes important when you pass a class as a parameter. In general, you should pass classes by value rather than by reference. The reason is that classes are already pointers, which are references; passing a class by reference amounts to passing a reference to a reference.
Только непонятен физический смысл "указатель на указатель на класс"
То, что дельфи по умолчанию копирует объекты - пиздец независимо от знания/незнания чего-либо.Предлагаю тебе убить Никласа Вирта, воспользовавшись "поясом шахида", а все учебники по паскалю сжечь.
Детко, насчет "по умолчанию" ты, как всегда, ляпнул не подумав.
Вся проблема в том, что это именно явно.
Стандарт паскаля гласит: при объявлении
procedure proc(x: xtype);
для аргумента функции создается локальная копия объекта. А чтоб передать только ссылку (с возможностью изменить внешний объект нужно написать:
procedure proc(var x: xtype);
Но тебе, конечно, незнание всего этого не помешает идти к успеху, потому что это не для пацанов. :]
и с массивами как, внутренность копируется?В паскале - да.
Детко, насчет "по умолчанию" ты, как всегда, ляпнул не подумав.Ты невнимательно прочитал мой пост.
Вся проблема в том, что это именно явно.
В php5 всегда по умолчанию передаётся исходный объект, и ничего не копируется; если хочешь скопировать - тебе явно надо клонировать объект.
А в дельфи, в случае с параметрами функций - по умолчанию передаётся копия, а если ты хочешь, чтобы передан был сам объект - придётся явно это указывать.
ЗЫ: Я так и не понял, если у меня в одном объекте есть свойство - другой объект, то, когда я получу копию первого объекта, её свойством будет второй объект, или его копия?
знаешь, сравнивать php и pascal это во-первых странно, во-вторых это неуважение к Вирту.
сравнивать php и pascal это во-первых странноЭто почему?
Или ты хочешь сказать что-то о том, что php типа веб-ориентированный?
В паскале - да.тогда пенартур прав
это пиздец!
знаешь, сравнивать php и pascal это во-первых странно, во-вторых это неуважение к Вирту.да причем тут неуважение?
все языки так действуют, почему вдруг паскаль по-другому?
кстати, а есть еще языки с таким паскалевским поведением?
> все языки так действуют, почему вдруг паскаль по-другому?
C/C++ ведет себя также как паскаль
C/C++ ведет себя также как паскаль
C/C++ ведет себя также как паскальты опух?
насколько я понимаю, надо различать в данном случае "объект" и "экземпляр класса"
в Дельфи есть 2 ключевых слова - object и class.
первое оставлено для совместимости с паскалем и экземпляры такого объекта всегда будут копироваться, если не переданы явно по ссылке.
экземпляры же класса всегда расположены в динамической памяти, поэтому переменная
x:TObject есть указатель, как его не передавай, сам объект скопирован не будет. Чтобы передать копию объекта, его нужно явно скопировать.
Совместимость со старыми версиями нельзя однозначно назвать недостатком языка.
Хотите "нормальную" передачу объектов - используйте ключевое слово class
и не используйте устаревший object .
в Дельфи есть 2 ключевых слова - object и class.
первое оставлено для совместимости с паскалем и экземпляры такого объекта всегда будут копироваться, если не переданы явно по ссылке.
экземпляры же класса всегда расположены в динамической памяти, поэтому переменная
x:TObject есть указатель, как его не передавай, сам объект скопирован не будет. Чтобы передать копию объекта, его нужно явно скопировать.
Совместимость со старыми версиями нельзя однозначно назвать недостатком языка.
Хотите "нормальную" передачу объектов - используйте ключевое слово class
и не используйте устаревший object .
учитывая что в первом посте речь была про классы, а не объекты
получается, что ты согласился, что я прав и
получается, что ты согласился, что я прав и
почти согласен.
меня терзают смутные сомнения, что при передаче как out все равно исходный класс будет передан внутрь по ссылке и nil никогда не будет получен. Хотя я могу ошибаться с этим.
Как доберусь до Дельфи - проверю.
при отсутствии квалификатора не будет копирования экземпляра класса
меня терзают смутные сомнения, что при передаче как out все равно исходный класс будет передан внутрь по ссылке и nil никогда не будет получен. Хотя я могу ошибаться с этим.
Как доберусь до Дельфи - проверю.
при отсутствии квалификатора не будет копирования экземпляра класса
И что по твоему выдаст такой код?
class Q
{
public: int i;
};
void F(Q q)
{
q.i = 1;
}
void main
{
Q q;
std::cout << q.i << std::endl;
F(q);
std::cout << q.i << std::endl;
}
тогда пенартур правПросто вы оба привыкли измерять вселенную от двери до окна своей конуры.
это пиздец!
И что по твоему выдаст такой код?этот пирмер не подходит для С
и потом, я речь вел про
void f(int a[1]) {
a[0] = 1;
}
int main {
int a[1];
a[0] = 3;
printf("%d", a[0]);
f(a);
printf("%d", a[0]);
}
офф
ты на вижуалбасике что ли пишешь? функции с большой буквы именуешь ...
Просто вы оба привыкли измерять вселенную от двери до окна своей конуры.в отношении себя не соглашусь
тогда пенартур прав
это пиздец!
Просто в C массивы это не объекты. Передавай структуру, а не массив.
Или напиши на C++, используя не массив, а std::vector.
Или напиши на C++, используя не массив, а std::vector.
оффУ тебя в голове реальная проблема, чувак!
ты на вижуалбасике что ли пишешь? функции с большой буквы именуешь ...
У тебя в голове реальная проблема, чувак!Сорри, не сдержался! Но ты же написал полный бред!
Сорри, не сдержался! Но ты же написал полный бред!просто ненавижу вижуалбасик
что тут бредового?
думаю не я один его ненавижу
просто ненавижу вижуалбасикА как с этим связаны имена функций с большой буквы?
что тут бредового?
думаю не я один его ненавижу
насколько я понимаю, надо различать в данном случае "объект" и "экземпляр класса"это одно и то же по определению:
Определение:
Объектом называется экземпляр класса
А как с этим связаны имена функций с большой буквы?ну там это принято
В твоём примере тоже нормального языка не видно. В нормальном языке это бы выглядело так:
def func (p):
<что-то делаем>
далее я объяснил что в дельфи есть два вида объектов: старые (object) и новые (class)
экземпляры старых по традиции называют объектами, а новых наверно стоит называть экземплярами классов.
Смысл понятен?
экземпляры старых по традиции называют объектами, а новых наверно стоит называть экземплярами классов.
Смысл понятен?
То есть, в дельфи есть два разных типа классов - один называется "класс", а другой - "объект".
И у объектов этих классов (в дельфи они называются "экземпляр класса" и "экземпляр объекта") - вот такое разное поведение, что первые не копируются, а вторые копируются.
Так?
Ну и нахрен тогда нужна такая совместимость? Это всё равно, что совместимость вида "вот раньше строки назывались массивами - так что, мы старые строки будем называть массивами, новые строки - строками, а массивы - пчёлами".
И у объектов этих классов (в дельфи они называются "экземпляр класса" и "экземпляр объекта") - вот такое разное поведение, что первые не копируются, а вторые копируются.
Так?
Ну и нахрен тогда нужна такая совместимость? Это всё равно, что совместимость вида "вот раньше строки назывались массивами - так что, мы старые строки будем называть массивами, новые строки - строками, а массивы - пчёлами".
В нормальном языке это бы выглядело так:Тебя так сильно волнует то, что там, где в одном языке фигурные скобки - в другом begin и end? Вынужден тебя разочаровать - это всё мелочи, вопросы наименования, и к обсуждаемому тут вопросу отношения не имеют. Всё равно как если бы тут обсуждали различия между русским и китайским языками, а ты бы сказал "тот русский, на котором вы тут пишете - отстойный русский, правильный язык - не Verdana, а Times New Roman".
Итак, какой все таки ответ на вопрос:
Происходит ли копирование класса вместе со всем содержимым при вызове процедуры:
Происходит ли копирование класса вместе со всем содержимым при вызове процедуры:
procedure MyProc(var A: TMyClass)?
Братцы! Я допер наконец до ответа на первоначалльный вопрос.
Это гениально! Все мы тут ходили вокруг да около, но правильного ответа не было.
Напишу в понедельник развернутый ответ на свой вопрос, а сейчас опаздываю на самолет и ухожу в оффлайн до понедельника
Всем привет!
Это гениально! Все мы тут ходили вокруг да около, но правильного ответа не было.
Напишу в понедельник развернутый ответ на свой вопрос, а сейчас опаздываю на самолет и ухожу в оффлайн до понедельника
Всем привет!
Нет, не происходит. Если при параметре написано 'var', в процедуру передается только ссылка на фактический параметр; в отличие от C++, ссылка по типу совпадает с тем, на что ссылается.
В ответ на:
C/C++ ведет себя также как паскаль
ты опух?
#include <stdio.h>
void func (int p)
{
printf("%p\n",&p);
}
int main(void)
{
int k;
printf("%p\n",&k);
func(k);
return 0;
}
что напечатает?
А тут?
#include <iostream>
using namespace std;
void func1 (int p)
{
cout << &p << endl;
}
void func2 (int& p)
{
cout << &p << endl;
}
int main(void)
{
int k=200;
cout << &k << endl;
func1(k);
func2(k);
return 0;
}
В php вообще пиздец с передачей параметров.
Например:
выведет 1, а
выведет 100.
И прежде чем говорить, что в Delphi пиздец, объясни ка почему так происходит.
Например:
$v = array(1);
function Bar($foo)
{
$foo[0] = 100;
}
Bar($v);
print $v[0];
выведет 1, а
$v = array(1);
foreach ($v as &$item) {
$i = $item;
}
function Bar($foo)
{
$foo[0] = 100;
}
Bar($v);
print $v[0];
выведет 100.
И прежде чем говорить, что в Delphi пиздец, объясни ка почему так происходит.
И прежде чем говорить, что в Delphi пиздец, объясни ка почему так происходит.Потому что php в некоторых случаях (например, этом) - тоже говно.
А вообще, насколько я понимаю, то, что записывается как "foreach($arr as &$val)" - реально означает что-то вроде "foreach(&$arr as $val)" (в то время, как "foreach($arr as $val)" означает "foreach(clone $arr as $val)").
В результате - ткое ощущение, что после foreach-а с &, $arr становится уже не массивом, а указателем на массив (хотя в php и нет указателей и, соответственно, твоей функцией приходит не массив, а указатель на массив. А может, после foreach-а его элементы вместо старых значений становятся указателями на старые элементы...
Потому что php в некоторых случаях (например, этом) - тоже говно.мдяяя
пхп еще больший пиздец чем дельфи
ты ваще про что?
я твои посты не понимаю
если ты споришь с пенартуром то отвечай на его посты, если споришь со мной то изволь мои посты читать:
опять меня скажет что у меня не все дома,
но я выражу тебе респект, что ты int main пишешь, а не как некторые...
я твои посты не понимаю
если ты споришь с пенартуром то отвечай на его посты, если споришь со мной то изволь мои посты читать:
и потом, я речь вел проp.s.
опять меня скажет что у меня не все дома,
но я выражу тебе респект, что ты int main пишешь, а не как некторые...
уже сказал про массивы. см. vector или структуры.
//
int main — привычка уже. ибо приходится писать переносимый на три-четыре платформы код.
ладно, тему закрывать можно.
#include <iostream>
using namespace std;
typedef int Arr[10];
void func (Arr p)
{
cout << &p << endl;
}
int main(void)
{
Arr k;
cout << &k << endl;
func(k);
return 0;
}
//
int main — привычка уже. ибо приходится писать переносимый на три-четыре платформы код.
ладно, тему закрывать можно.
ладно, тему закрывать можно.нее
ждем понедельника
что-то родить хотел
кстати
когда я писал на с++, я никогда не использовал (эээ как это назвать?) прямое построение объектов
всегда использовал new
а вы енто используете в реальном коде?
также я и передачу с & не использовал, считал что это будет токо путаницу вносить
Просто надо не писать foreach($arr as &$val). Реально это практически не нужно, единственный плюс - выигрыш в скорости на огромных массивах, но это не такая уж и частая задача в php.
Просто надо не писать foreach($arr as &$val).почему ты не можешь также ответить на всякие конструкции в дельфи?
просто не надо так писать и все дела
Я сказал, что в php не надо использовать такой синтаксис для foreach.
А ты что предлагаешь, не писать функции, которые в качестве аргументов принимают объекты?
Или что ты там понимаешь под "так писать"?
А ты что предлагаешь, не писать функции, которые в качестве аргументов принимают объекты?
Или что ты там понимаешь под "так писать"?
А ты что предлагаешь, не писать функции, которые в качестве аргументов принимают объекты?да
тебе про это уже говорили, прямые объекты это рудимент
а классы передаются по ссылке и с ними все ок
классы передаются по ссылкеПовторю ещё раз - ну и жесть же в вашем дельфи с наименованиями!
Лучше бы никакой обратной совместимости не было.
А как тебе такой код?
выведет 100
а
Выведет 1.
В PHP с передачей параметров всё очень запутанно.
function Bar($foo)
{
$foo[0] = 100;
}
function Foo( &$k ) {
$k = 10;
}
$v = array(1);
Foo( v[0] );
Bar($v);
print $v[0];
выведет 100
а
function Bar($foo)
{
$foo[0] = 100;
}
function Foo( &$k ) {
$k = 10;
}
$v = array(1);
Foo( v[0] );
$t = $v[0];
unset( $t );
Bar($v);
print $v[0];
Выведет 1.
В PHP с передачей параметров всё очень запутанно.
У меня
слава богу, выдаёт 10.
Тебя обманули. Или, возможно, ты используешь мегажопный php4.
<?php
function Bar($foo)
{
$foo[0] = 100;
}
function Foo(&$k) {
$k = 10;
}
$v = array(1);
Foo($v[0]);
Bar($v);
echo $v[0].PHP_EOL;
?>
слава богу, выдаёт 10.
Тебя обманули. Или, возможно, ты используешь мегажопный php4.
М.б. я не очень хорошо помню все тонкости, но что-то такое запутанное там было...
Напишу в понедельник развернутый ответ на свой вопроссорри, напишу завтра, щас нет времени
в процедуру передаётся _весь_ объект, и при этом происходит его копирование(особенно тут надо быть осторожными со строками и массивами!) Обративнимание, что все библиотечные функции для работы со строками оформленычерез var/const. нет ни одной такой:Что за чушь? Все объекты в Delphi - ссылки. (как ссылка в С++). Строка тоже не копируются если нет реального изменения. Даже если ты присваиваешь одну строку другой, она не копирутеся, а всего лишь увеличивает количество ссылок. Так что const можно не писать. const - всего лищь модификатор доступа. var и out делают тоже самое что и передача указателя в С++ (не ссылки!). out - чисто декларативный квалификатор. Везде, где есть out можно обойтись и var. Но с out понятнее, что что-то возвращается.
под "объектом" понимается любая сущность.
например:
Подчеркну, что так дело обстоит не только со строками.
с массивами, строками внутри структур, массивами в структурах etc всё намного хуже.
потому что (если я не разработчик TOtherType) нет например гарантии что в TOtherType нет массивов или строк внутри.
const существенно помогает компилятору оптимизировать код.
никогда не задумывался, зачем даже в C пишут:
?
кроме того, со строками - это некоторые ухищрения компилятора. для массивов copy-on-write уже не работает
например:
procedure foo(x:string);
begin
x[3]:='b'; // можно
WriteLn(x);
end;
procedure bar(const x:string);
begin
x[3]:='b'; // нельзя ибо const
WriteLn(x);
end;
procedure toor(var x:string);
begin
x[3]:='b'; // можно
WriteLn(x);
end;
var baz:string;
begin
foo('foobar'); // Можно передавать: и чему происходит присваивание x[3]:='b' ?
bar('foobar'); // Можно передавать
toor('foobar'); // Нельзя передавать.
baz:='foobar';
foo(baz);
WriteLn(baz);
toor(baz);
WriteLn(baz);
end.
Подчеркну, что так дело обстоит не только со строками.
type
TMyType = record
X: TOtherType;
Y: array of Integer;
S: string;
...
end;
с массивами, строками внутри структур, массивами в структурах etc всё намного хуже.
потому что (если я не разработчик TOtherType) нет например гарантии что в TOtherType нет массивов или строк внутри.
const существенно помогает компилятору оптимизировать код.
никогда не задумывался, зачем даже в C пишут:
int printf(const char * fmt, ...);
?
кроме того, со строками - это некоторые ухищрения компилятора. для массивов copy-on-write уже не работает
Любая переменная объектного типа
- это в действительности 4-х-байтовый указатель, который содержит адрес объекта (экземпляра класса). Компилятор невидимо от нас автоматически преобразует этот указатель в класс, так что мы можем спокойно обращаться к его методам и свойствам. Например, при вызове
AInstance.Method1 компилятор проделывает кучу вещей - получает указатель на экземпляр класса, получает указатель на VMT класса TMyClass, в нем ищет указатель на Method1, только поток вызывает этот метод.
При передаче экземпляра класса в качестве параметра функции в действительности передается 4 байта, в которых записан адрес объекта.
При этом:
procedure MyProc(A: TMyClass) - выделяет дополнительные 4 байта и копирует в них содержимое, записанное в указателе A (а там записан адрес объекта) и передает их в качестве аргумента процедуры. (это в общем случае, хотя возможно компилятор использует какую-либо оптимизацию)
procedure MyProc(const A: TMyClass) - компилятор для доступа к объекту использует 4 байта, записанные в А. Память не выделяется
procedure MyProc(var A: TMyClass) - аналогично первому варианту
procedure MyProc(out A: TMyClass) - аналогично первому варианту
Содержимое объектов нигде не копируются, копируются только 4 байта - указатели (кроме const)
При операции присвоения A := B копируются 4 байта, которые указывают на объект. При сравнении if A = B проверяются, указывают ли они на одну область памяти.
var
AInstance: TMyClass
- это в действительности 4-х-байтовый указатель, который содержит адрес объекта (экземпляра класса). Компилятор невидимо от нас автоматически преобразует этот указатель в класс, так что мы можем спокойно обращаться к его методам и свойствам. Например, при вызове
AInstance.Method1 компилятор проделывает кучу вещей - получает указатель на экземпляр класса, получает указатель на VMT класса TMyClass, в нем ищет указатель на Method1, только поток вызывает этот метод.
При передаче экземпляра класса в качестве параметра функции в действительности передается 4 байта, в которых записан адрес объекта.
При этом:
procedure MyProc(A: TMyClass) - выделяет дополнительные 4 байта и копирует в них содержимое, записанное в указателе A (а там записан адрес объекта) и передает их в качестве аргумента процедуры. (это в общем случае, хотя возможно компилятор использует какую-либо оптимизацию)
procedure MyProc(const A: TMyClass) - компилятор для доступа к объекту использует 4 байта, записанные в А. Память не выделяется
procedure MyProc(var A: TMyClass) - аналогично первому варианту
procedure MyProc(out A: TMyClass) - аналогично первому варианту
Содержимое объектов нигде не копируются, копируются только 4 байта - указатели (кроме const)
При операции присвоения A := B копируются 4 байта, которые указывают на объект. При сравнении if A = B проверяются, указывают ли они на одну область памяти.
То есть, в дельфи есть два разных типа классов - один называется "класс", а другой - "объект".Да, есть class и есть object
И у объектов этих классов (в дельфи они называются "экземпляр класса" и "экземпляр объекта") - вот такое разное поведение, что первые не копируются, а вторые копируются.Поведение разное, но словосочетание "экземпляр объекта" не является ни общеупотребительным, ни официальным, я использовал его только чтобы как-то поразному
Так?
назвать эти 2 вещи (class и object)
Ну и нахрен тогда нужна такая совместимость? ...Совместимость нужна для совместимости.
Если следовать твоей логике, то нужно из С убрать все *printf и *scanf
так как есть нормальные потоки.
Если следовать твоей логике, то нужно из С убрать все *printf и *scanfТы имел в виду C++?
Во-первых, *printf и *scanf очень удобны, независимо от совместимости.
Во-вторых, C++ срёт на совместимость - C-программы не являются ведь валидными C++-программами?
да, сорри, я имел ввиду С++
но, даже если С++ не совместим с С это же не означает, что другие языки не должны быть совместимы со старыми версиями
PS я лично не имею ничего против функций *scanf/printf, просто взял для примера
но, даже если С++ не совместим с С это же не означает, что другие языки не должны быть совместимы со старыми версиями
PS я лично не имею ничего против функций *scanf/printf, просто взял для примера
это же не означает, что другие языки не должны быть совместимы со старыми версиямиТакой ценой - не должны.
Что ты подразумеваешь под "такой ценой"?
Никто же не заставляет использовать устаревший синтаксис, он просто есть. Можно просто забыть про него и все. Зато когда понадобится использовать какую-нить старую прогу на 7 паскале, гемороя все ж будет меньше (хотя все равно будет)
Никто же не заставляет использовать устаревший синтаксис, он просто есть. Можно просто забыть про него и все. Зато когда понадобится использовать какую-нить старую прогу на 7 паскале, гемороя все ж будет меньше (хотя все равно будет)
Что ты подразумеваешь под "такой ценой"?Проблема в том, что в устаревшем синтаксисе есть понятия, которые в этом устаревшем синтаксисе означают совсем не то, что в нормальном мире; и что существование этих понятий с таким значением даёт дикую путаницу тем, кто пишет на дельфи.
Никто же не заставляет использовать устаревший синтаксис, он просто есть
Зато можно использовать прогу на 7 паскале, которую и без этого можно было бы скомпилировать компилятором паскаля.
если ты читаешь учебник по дельфи, там про поддержку старого синтаксиса скорее всего ничего не будет сказано - чтобы узнать про это надо будет специально искать. и можно использовать нормальные классы, которые ведут себя как "нормальные" в твоем понимании и при этом ничего не знать про старинные объекты.
если же вдруг хочешь перенести какой-нибудь текст из досовского паскаля под винду, чтоб например решить проблему с нехваткой памяти, то в синтаксисе ничего менять не придется.
проблемы конечно будут с библиотеками graph,crt и иже с ними, но это уже не синтаксис.
если же вдруг хочешь перенести какой-нибудь текст из досовского паскаля под винду, чтоб например решить проблему с нехваткой памяти, то в синтаксисе ничего менять не придется.
проблемы конечно будут с библиотеками graph,crt и иже с ними, но это уже не синтаксис.
А почему тебя не возмущает, что в PHP4/5 не удалили magic_qutes и автозаполнение переменных в глобальной зоне видимости из значениями хэша $_REQUEST? Это ведь вещи пострашнее, чем какиая-то альтернативная реализация классов.
почему тебя не возмущает, что в PHP4/5 не удалили magic_qutes и автозаполнение переменных в глобальной зоне видимости из значениями хэшаВ PHP4 они были включены по умолчанию, насколько я помню. Вообще, PHP4 - говно, можешь называть его паскалем.
В PHP5 (это вроде первой версии дельфи) - осталась возможность включить старое поведение (пока не включишь явно в php.ini, никакого старого поведения нет).
В PHP6 возможности включить старое поведение нет.
А двенадцатилетняя дельфи до сих пор заботится о такое ужасной совместимости с паскалем. Сколько ещё времени они с собой эту обратную совместимость таскать будут? Пока обратной совместимости не будет больше, чем основного функционала?
а сколько еще будут тянуть обратную совместимость с процессорами 8086?
они давно никому не нужны и вообще это г... давайте резко поменяем архитектуру
чтоб вообще ничего старинного 32-16 разрядного запустить нельзя было
они давно никому не нужны и вообще это г... давайте резко поменяем архитектуру
чтоб вообще ничего старинного 32-16 разрядного запустить нельзя было
а сколько еще будут тянуть обратную совместимость с процессорами 8086?говори конкретнее
общие слова тут неуместны
это я не к тому чтоб убрать совместимость процессоров.
это я к тому, что совместимость, особенно ненавязчивая, всегда полезна
вот сижу я на 64 разрядной машине, а винда обычная, 32-разрядная, и ничего, работает.
можно и дос поставить если надо.
это я к тому, что совместимость, особенно ненавязчивая, всегда полезна
вот сижу я на 64 разрядной машине, а винда обычная, 32-разрядная, и ничего, работает.
можно и дос поставить если надо.
вот сижу я на 64 разрядной машине, а винда обычная, 32-разрядная, и ничего, работает.А я говорю, что совместимость надо резко убрать?
можно и дос поставить если надо.А вот не надо. Зачем тебе дос? Есть dosbox, есть vmware на худой конец - зачем тебе реальный дос? Если для работы со старым железом - то и подключается это железо наверняка через такие интерфейсы, о которых на новых 64битных компах давно забыли.
мне дос и не надо. но может оказаться, что он нужен. и в этом случае, гораздо лучше
если он работает без дополнительных плясок с бубном и без объяснения и доказательства, что "на самом деле он тебе не нужен"
например: я отлаживаю асмовскую прогу с новым набором инструкций, которая должна работать на операционке для детекторов движения (самописной и без обширного девелоперского софта соответственно). прога требует хороших ресурсов (виртуальная машина отпадает). она работает с девайсами, созданными той же организацией.
используется набор инструкций, не поддерживаемый виртуальной машиной.
в реализации виртуальной машины могут быть глюки, о которых я не знаю.
(кстати такое я наблюдал - таймер шел вдвое быстрее или медленнее, что-то в этом роде,
при обращении к нему через биос виртуальной машины)
по-моему достаточно причин, чтобы иногда использовать именно дос
если он работает без дополнительных плясок с бубном и без объяснения и доказательства, что "на самом деле он тебе не нужен"
например: я отлаживаю асмовскую прогу с новым набором инструкций, которая должна работать на операционке для детекторов движения (самописной и без обширного девелоперского софта соответственно). прога требует хороших ресурсов (виртуальная машина отпадает). она работает с девайсами, созданными той же организацией.
используется набор инструкций, не поддерживаемый виртуальной машиной.
в реализации виртуальной машины могут быть глюки, о которых я не знаю.
(кстати такое я наблюдал - таймер шел вдвое быстрее или медленнее, что-то в этом роде,
при обращении к нему через биос виртуальной машины)
по-моему достаточно причин, чтобы иногда использовать именно дос
мне дос и не надо. но может оказаться, что он нужен.И ради того, чтобы, если какой-нибудь вдруг решит, что он хочет дос - тащить с собой всю эту совместимость и тратить на неё кучу ресурсов?
Во-первых, на эту совместимость тратятся ресурсы разработчиков - надо всё время помнить о том, что нельзя ничего удалить, из-за этого возникает огромная куча проблем.
Во-вторых, на эту совместимость тратятся ресурсы готового продукта, в котором вместо "получили X - сделали Y" будет "получили X, прошлись по всем ста известным языкам в поисках того языка, на котором X, поняли, что означает X в данном случае в данном режиме, сделали Y"
Если тебе нужен мощный комп - используй мощный комп с современными инструкциями. Если тебе нужен дос для того, чтобы поработать с древней железкой - старый комп ощутимо тормозить не будет. Если тебе нужен дос чисто посмотреть - никто ради этого не должен возиться и таскать с собой всю эту обратную совместимость.
Было бы здорово, если бы наконец-то выкинули всю эту помойку под названием x86 и внесли в массы что-то новое, которое будет заниматься своим делом, а не поддержкой устаревших костылей. При условии, конечно, что ядра ОС и компиляторы будут работать с новыми инструкциями (а программы можно и перекомпилировать, если они написаны на языке программирования, а не на ассемблере).
вот сижу я на 64 разрядной машине, а винда обычная, 32-разрядная, и ничего, работает.с чего ты взял что это не случайно получилось?
где конкретный пример старой команды которая не нужна в новом процессорре, а оставлена для совестимости?
и уж тем более которая сбивает с толку
И ради того, чтобы, если какой-нибудь вдруг решит, что он хочет дос - тащить с собой всю эту совместимость и тратить на неё кучу ресурсов?во-первых, прошу без личных выпадов
Во-первых, на эту совместимость тратятся ресурсы разработчиков - надо всё время помнить о том, что нельзя ничего удалить, из-за этого возникает огромная куча проблем.
Во-вторых, на эту совместимость тратятся ресурсы готового продукта, в котором вместо "получили X - сделали Y" будет "получили X, прошлись по всем ста известным языкам в поисках того языка, на котором X, поняли, что означает X в данном случае в данном режиме, сделали Y"
во-вторых, надо различать совместимость вообще и разумную совместимость
если какая-то примочка может понадобиться множеству людей, причем ее отсутствие
сильно затруднит им жизнь, а ее реализация не слишком напряжна для разработчика, то
почему бы ее не сделать?
с другой стороны, глупо ухудшать характеристики продукта только из-за совместимости.
в случае дельфи, наличие возможности использовать старый синтаксис ничем не мешает
разработчику. а вот если бы в целях совместимости программа была бы 16-разрядной
и с ограничением в 64к на переменную или на сегмент - это было бы уже не нормально
реальный режим работы процессора в целом. без него во многих случаях уже можно было бы
обойтись. тем не менее он до сих пор существует и проц стартует именно в нем.
однако это очень полезно для совместимости и это оставляют от модели к модели процессора
обойтись. тем не менее он до сих пор существует и проц стартует именно в нем.
однако это очень полезно для совместимости и это оставляют от модели к модели процессора
То есть, в дельфи есть два разных типа классов - один называется "класс", а другой - "объект".
И у объектов этих классов (в дельфи они называются "экземпляр класса" и "экземпляр объекта") - вот такое разное поведение, что первые не копируются, а вторые копируются.
Так?
Не так. Далее весь диалог исходит из этого неверного утверждения и превращается в бред
Не так.как это не так если выяснили что так?
с чем конкретно ты не согласен?
То есть, в дельфи есть два разных типа классов - один называется "класс", а другой - "объект".
ерунда какая-то
приведи пример кода, чтобы там были "два типа классов" - "класс" и "объект". Я не понимаю, что это такое.
В Delphi со времен Turbo Pascal with objects осталось ключевое слово object для определения классов так, как оно было в этом самом Turbo Pascal. И еще добавили class для "новых" классов.
ерунда какая-тоа прочитать весь тред с самого начала сложно?
приведи пример кода, чтобы там были "два типа классов" - "класс" и "объект". Я не понимаю, что это такое.
вот тебе пример:
typeу Foo и Bar будет разное поведение при передаче параметром в процедуру
TFoo = object
Length : Integer;
procedure Proc;
end;
TBar = class
Length : Integer;
procedure Proc;
end;
var
Foo : TFoo;
Bar : TBar;
TFoo = objectжесть, не знал про это. Имхо, этим почти никто не пользуется
Length : Integer;
procedure Proc;
end;
жесть, не знал про это. Имхо, этим почти никто не пользуетсяеще раз говорю тебе: прочитай все сообщения выше
писали же, что эта конструкция перешла в дельфи из паскаля, нафига они оставили эту совместимость не понятно
В Delphi со времен Turbo Pascal with objects осталось ключевое слово object для определения классов так, как оно было в этом самом Turbo Pascal. И еще добавили class для "новых" классов.По моему, в Дельфи просто объектные типы данных называют классами, а их экземпляры — объектами.
Оставить комментарий
Corrector
Есть ли разница между следующими объявлениями процедур?procedure MyProc(A: TMyClass)
procedure MyProc(const A: TMyClass)
procedure MyProc(var A: TMyClass)
procedure MyProc(out A: TMyClass)
Если есть, то на каком примере можно показать, что программа ведет себя по разному?