Delphi vs. C++

← →
pasha_golub © (2004-09-10 12:34) [520]

Суслик © (10.09.04 12:02) [519]
А может это само собой размуеющееся? Ну, вроде как строки базовый тип всегда был. Щас конечно реализация посложней, но все-таки.

Я вот никогда не задумывался, потокобезопасны ли строки. Всегда считал, что да.

← →
DiamondShark © (2004-09-10 12:41) [521]

> где в доке сказано про потокобезопасность строк?

Нигде. Это требуется для приближения поведения строк к поведению атомарных типов.

← →
Суслик © (2004-09-10 12:45) [522]

> [521] DiamondShark © (10.09.04 12:41)

> Нигде. Это требуется для приближения поведения строк к поведению
> атомарных типов.

Спасибо за ответ.
Четкий и понятный.
Всегда бы так.
------------
Похоже динамические массивы тоже потокобезопасные :)))
------------
Век живи - век учись.

← →
panov © (2004-09-10 12:52) [523]

>Суслик © (10.09.04 12:02) [519]

где в доке сказано про потокобезопасность строк?

А с чего бы им быть потокобезопасными?

← →
Суслик © (2004-09-10 12:55) [524]

> [523] panov © (10.09.04 12:52)

> А с чего бы им быть потокобезопасными?

Об этом сказал Акуличев.
Судя по всему строки действитель потокобезопасные.
По крайней мере об этом говорит анализ _LStrAsg и _LStrClr.

Я, как я честно сказал этого не знал. Вот и мучает вопрос - где и как я мог это пропустить. Пока в доке не нашел.

Тот же Акуличев говорит, что факт потокобезопасности строк нигде не указан.

← →
panov © (2004-09-10 12:56) [525]

>Суслик © (10.09.04 12:55) [524]

В Delphi работа со строками не потокобезопасна.

← →
Суслик © (2004-09-10 12:59) [526]

> panov © (10.09.04 12:56) [525]
В Delphi работа со строками не потокобезопасна.

Разве?
Во блин, кому верить? :))
Здесь два варианта, либо вы заблуждаетесь, либо нет.

В первом варианте меня убеждает анализ кода некоторых функций вида _LStrXXX. В пользу второго - я тоже так всегда считал.

Так где правда?

← →
DiamondShark © (2004-09-10 13:01) [527]

> В Delphi работа со строками не потокобезопасна.

И сразу пример.

← →
Cobalt © (2004-09-10 13:05) [528]

Суслик, может ты всё-таки ответишь, пока они там решают - потокобезопасны строки или нет, на мой вопрос? Cobalt © [504]

← →
DiamondShark © (2004-09-10 13:07) [529]

> Так где правда?

Как известно, в вине.

var
S: string; // глобальная;

function Thread1(Param: pointer): integer;
begin
S := "aaa";
end;

function Thread2(Param: pointer): integer;
begin
S := "bbb";
end;

Результат неопределён (сравни с поведением того же integer).

В этом смысле они не безопасны.

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

В этом смысле я подразумевал безопасность.

← →
Суслик © (2004-09-10 13:08) [530]

> Cobalt © (10.09.04 13:05) [528]

я не спец с сях. Там я ламер и ламерю обычно дома - просто компилю разные кусочки.

за синтаксис прошу прощения - плохо помню

class a { private a; }; { a*i; i = new a; // это в vsc++ даст ошибку компиляции }

что будет со стековыми переменным т.е.

{ a i; }

не знаю не проверял.

← →
pasha_golub © (2004-09-10 13:08) [531]

DiamondShark © (10.09.04 13:07) [529]
Согласен с утверждением.

← →
Ihor Osov'yak © (2004-09-10 13:31) [532]

>Любое убеждение, отличное от убеждений Игоря Шевченко - ламерское. Но и я с этим как-то живу...

Хм... Иронию ироните?
Кстати, лично мне не припоминается, чтобы в вопросах, имеющих отношение к программингу, Шевченко давал ошибочную информацию и придерживался своей точки зрения, после того, когда конкретно и аргументировано укажут на неточности (было раз или два по мелочам или ньюансам)...
В "хвилосовско-нравственно-политических" вопросах все очень субьективно, посему этой темы не затрагиваем.

← →
panov © (2004-09-10 13:52) [533]

Пример? Пожалуйста.
type TMyTestThread1=class(TThread) protected procedure Execute;override; end; TMyTestThread2=class(TThread) protected procedure Execute;override; end; s1,s2: String; impementation procedure TMyTestThread1.Execute; begin FreeOnTerminate := True; try s2 := s1; move(s1[1],s2[1],Length(s1)); except MessageBox(0,"Error","Error",MB_OK); end end; procedure TMyTestThread2.Execute; begin FreeOnTerminate := True; Sleep(1); s2 := ""; end; procedure TForm1.Button2Click(Sender: TObject); var t1: TMyTestThread1; t2: TMyTestThread2; begin s1 := StringOfChar("a",100000000); s2 := StringOfChar("b",100000000); t1 := TMyTestThread1.Create(False); t2 := TMyTestThread2.Create(False);

← →
Ihor Osov'yak © (2004-09-10 14:01) [534]

2 [533] panov © (10.09.04 13:52)

э, батенька, дык Вы шарлатанством занимаетесь.. По вашей логике ничто не есть потокобезопасным....

← →
panov © (2004-09-10 14:05) [535]

>Ihor Osov"yak © (10.09.04 14:01) [534]

э, батенька, дык Вы шарлатанством занимаетесь.. По вашей логике ничто не есть потокобезопасным....

Тогда определимся, что считать потокобезопасным кодом?

В контексте предыдущих обсуждений нужно немного видоизменить формулировку вопроса - "Что такое потокобезопасный код?"

← →
GRAND25 © (2004-09-10 14:07) [536]

> Хм... Иронию ироните?

Ыгы! Ыроним! :)

> В "хвилосовско-нравственно-политических" вопросах все очень
> субьективно, посему этой темы не затрагиваем.

Конечно субъективно! Субъективно в соответствии с мнением И.Шевченко :)

← →
panov © (2004-09-10 14:07) [537]

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

← →
Суслик © (2004-09-10 14:11) [538]

> Тогда определимся, что считать потокобезопасным кодом?

Давайте рассмотрим вопрос потокобезопасности пока только для строк.

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

Естесно, что такая потокобезопасность возможна только в случае использования штатных фукнций дельфи. Т.е. никаким move здесь не место!

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

← →
DiamondShark © (2004-09-10 14:13) [539]

> panov © (10.09.04 13:52) [533]

Грязный хак.

← →
Суслик © (2004-09-10 14:15) [540]

> [537] panov © (10.09.04 14:07)
> Работа со строками, как и с другими объектами, не может
> быть потокобезопасной, так как всегда возможны коллизии
> при одновременном использовании.

Вы, безсуловно, правы.
Но я бы назвал указанные вами колизии логическими ошибками.

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

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

А вот логические ошибки - они везде возможны, даже в атомарных типах.

← →
Ihor Osov'yak © (2004-09-10 14:18) [541]

2 [535] panov © (10.09.04 14:05)

Вам уже ответили - 538, 540

← →
DiamondShark © (2004-09-10 14:28) [542]

> panov © (10.09.04 14:07) [537]

Коллизии коллизиям рознь.
Есть коллизии типа "потеря значения", а есть коллизии управления внутренним представлением объектов.

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

← →
Суслик © (2004-09-10 14:31) [543]

Эх!
Здорово, хоть понимание достигнуто.

> [542] DiamondShark © (10.09.04 14:28)

Ты мне все же скажи - дин. массивы тоже потокобезопасные? Смотрел их?

У меня слабое знание asm, поэтому достоверно понять самому сложно. Вернее понять можно, не знаю верить себе или нет :)

← →
DiamondShark © (2004-09-10 14:44) [544]

> Суслик © (10.09.04 14:31) [543]

Я детально не разбирался.
На первый беглый взгляд -- вроде бы очень на строки похоже.

← →
pasha_golub © (2004-09-10 15:54) [545]

По моему, ИМХУ, строки = дин. массивы

← →
Суслик © (2004-09-10 15:56) [546]

> [545] pasha_golub © (10.09.04 15:54)
> По моему, ИМХУ, строки = дин. массивы

Это в каком смысле? Реализация у них разная, да и семантика разная.

← →
jack128 © (2004-09-10 16:10) [547]

Суслик © (10.09.04 15:56) [546]
Реализация у них разная
с чего это вдруг?? Длина, счетчик ссылок - все как у строк..

← →
Суслик © (2004-09-10 16:15) [548]

> [547] jack128 © (10.09.04 16:10)

Строки копируются, у массиво копируется только ссылка. У строк тоже копируется ссылка, но при первом изменеии одной из строк происходит создание копии. Т.о. на оригинал не влияет. У массивов, если не ошибаюсь, копирование происходит только при изменении размеров массива. Если же менять элемент массива, то изменение в копии скажутся и на оригинале.

Над строками больше автоматической работы проводится компилером, как по мне. А так схожесть есть.

Суслик © (10.09.04 16:15) [548]
но при первом изменеии одной из строк происходит создание копии.

Угу. Но у массивов создания копии не происходит.. Их поведение ещё проще строки..

> Угу. Но у массивов создания копии не происходит.. Их поведение
> ещё проще строки..

Если я не ошибаюсь не совсем так.
Копирование массива происходит при изменении размера.

Я точно не помню. Если интересно, сам посмотри.

Я недели две назад перешёл на си++.
Ничего, работать хоть и муторно, но можно.
Главная награда в конце - скорость работы приложения.
Я правда это относительно игр, и DirectX.

А вот оконные стандартные вещи, где скорость не главное - лучше на Старом, добром Delphi ваять. :))

ИМХО.

← →
имя (2004-09-10 18:01) [553]

Удалено модератором

← →
имя (2004-09-10 18:12) [554]

Удалено модератором

← →
имя (2004-09-10 18:17) [555]

Удалено модератором

>>Megabyte-Ceercop © (10.09.04 17:12) [552]

C++ к скорости никакого отношения не имеет. Это заслуга конкретного компилятора.

>Главная награда в конце - скорость работы приложения.

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

← →
имя (2004-09-10 18:29) [557]

Удалено модератором

> Ничего, работать хоть и муторно, но можно.

Стоит ли так себя мучить?

Игорь Шевченко © (07.09.04 22:04) [336]
Вот мне интересно - как ты себе предстваляешь одновременно наличие переменной Result и оператора return (допустим, он появился в Delphi).
А в чем проблема? Так, как я это написал в макросе. А можно так: Return - выход с возвращением Result, Return 3 или Return(3) - выход с возвращением 3.

>> Там это заменяет множественное наследование
> Где это - там ?

В Java.

>> В общем, вам тоже в школу надо.
> Не потрудится ли достопоченный дон объяснить, почему
> именно мне надо в школу ? :)

Учить, учить и еще раз учиь :) Цитата, кстати, неверная - у меня в конце смайлик был.

<font color=red><strike>имя</strike></font> (08.09.04 7:57) [343]
<font color=red><strike>имя</strike></font> (08.09.04 10:41) [345]
Зачем удалили?

0d08h (08.09.04 11:11) [352]
А между кем и кем была Holy War пару десятков лет назад?

Danilka © (08.09.04 11:39) [371]
Обычные задачи - Delphi; там, где нужна хитрая структура объектов - C++, как кто-то сказал. (Это не есть мое мнение)

Суслик © (08.09.04 14:46) [427]
Была бы недокументированная - не в жизь не пользовался бы - никогда так не делаю.
И сообщениями, начинающимися с CM (CM_MouseLeave и т.д.) тоже не пользуешься? Они тоже недокументированы.

Суслик © (08.09.04 16:10) [459]
Дмитрий, это эмоции :))
А правда где-то рядом.
Да. В следующем предложении. :) Между прочим, move - не чем не лучше обычного копирования в цикле по 4 байта. А на малых объемах хуже во много раз.
jack128 © (08.09.04 16:29) [463]
>Суслик © (08.09.04 15:43) [452]
>Кусочек из interface части
> Хе. А вот в пятерке это все под имплментейшен сидит..

В семерке - тоже, кажется. Т.к. компиллятор ее не видит.

jack128 © (08.09.04 16:29) [463]
Вариант 1 лучше во всем, включая скорость. Смысл в move есть только когда копируюется много структур с размером, не кратным 4.

> AFAIR, чувствительность к регистру можно отключить в опциях.
А че такое AFAIR?

Так тут идёт сравнения языка С++ с компилятором Дельфи? Неправильно это. Лечше сравнивать С++ с объект паскалем, тогда могу пример привести из Фрипаскаля. Результат функции при выходе можно назначить как:

Function:=X;
Exit;
или
Result:=X;
Exit;
или
Exit(X);

Delphi vs. C++ Найти похожие ветки