Delphi vs. C++

← →
Акуличев Дмитрий (2004-09-06 19:40) [160]

> Ермак © (06.09.04 19:31) [156]
> Народ, а все таки: ЧТО ТАКОЕ ОБЕРОН?

http://www.oberon.ethz.ch/

← →
jack128 © (2004-09-06 19:41) [161]

Ozone © (06.09.04 13:04) [67]
GrayFace © (06.09.04 18:37) [140]
Ребят, вы смайлики замечаете?? Я вообще эту ссылку на форуме Юмор на rsdn подобрал..

Ермак © (06.09.04 19:31) [156]
Язык Вирта. на Королевстве огромный флейм ему посвещен..

> Суслик ©
на счет времени жизни интерфейсов..

TSimpleIntfObject = class(TObject, IUnknown)
protected
{ IUnknown }
function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
function _AddRef: Integer; stdcall;
function _Release: Integer; stdcall;
end;

function TSimpleIntfObject._AddRef: Integer;
begin
Result := -1;
end;

function TSimpleIntfObject._Release: Integer;
begin
Result := -1;
end;

function TSimpleIntfObject.QueryInterface(const IID: TGUID;
out Obj): HResult;
const
E_NOINTERFACE = HResult($80004002);
begin
if GetInterface(IID, Obj) then Result := 0 else Result := E_NOINTERFACE;
end;

var
obj: TSimpleIntfObject;
intf: IUnknown;
begin
obj := TSimpleIntfObject;
obj.GetInterface(IUnknown, intf);
end; // интерфейс помер, а объект живет..

← →
GrayFace © (2004-09-06 19:44) [162]

Игорь Шевченко © (06.09.04 16:05) [107]
> Да и без макроподстановок в Дельфи как без рук.
Эт еще нафига ?
Для return, например. Без него тяжко.

Суслик © (06.09.04 16:11) [109]
А также то, что ты идеалист.
Это точно.

Игорь Шевченко © (06.09.04 16:32) [115]
А с самого начала писать проект так, чтобы не наступать на грабли, не проще ли ? И в компиляторе ничего менять не надо...
Не все программисты идеальны. Не все ХОРОШИЕ программисты идеальны - и у них бывают ошибки в проектировке.

Григорьев Антон © (06.09.04 16:51) [118]
Не выворачивай все наизнанку. Delphi создавался для того, чтобы программисты вообще не думали. В нем просто меньше возможностей объектного программирования, поэтому в нем сложна переделка программ. Но, по уму, в C++ желательно проектировать не меньше.

Игорь Шевченко © (06.09.04 18:40) [141]
Что именно ужасного в указателях в паскале ?
К ним ничего нельзя прибавить. Единственный способ - inc, но в выражениях он не работает.

Verg © (06.09.04 19:05) [145]
На моей памяти это 3 случай после DiamondShark и ветки на Дремучих о взломанности этого сайта. Рулят такие обсуждения, ИМХО, даже не знаю, почему.

Акуличев Дмитрий (06.09.04 19:17) [148]
Во-первых, ответ уже содержится в этой ветке, во-вторых, я предлагал словарик почитать.
Я ветку читал. Ответ нету. Все твои слова на эту тему - это че-то типа "это так и если вы утверждаете обратное (хаха), то это так, как я сказал".
Модуль -- единица инкапсуляции. Нэймспейс -- нет.
И что? Ну не удобно же все лепить в один модуль. Namespace - ед. инкапсуляции, модуль - частный случай Namesapace.

>Это абсолютно кю.
> Геморрой начинается там, где кончается понимание.

Интерфейсов по-нормальному зделана в Java - там это вообще не сущьность, а как-бы класс объекта, но без методов. COM-интерфейсы для таких нужд мало пригодны, а множественное наследование - очень даже.

А вот переопределение операций -- действительно геморрой.
Так, как это сделано в C++ - да, согласен.

Ермак © (06.09.04 19:25) [152]
Ой ли? Никто не заставляет человека это использовать, но в некоторых случаях это очень удобно.
А если юзеру приспичит одному объекту присвоить другой по значению?

← →
vuk © (2004-09-06 19:48) [163]

to Суслик:
Зря так на Акуличева. Он может немного и резко высказался, но во всем прав.

to GrayFace © (06.09.04 19:44) [162]:
>Namespace - ед. инкапсуляции, модуль - частный случай
>Namesapace.
В C++ Namespace - не единица инкапсуляции, а средство борьбы с конфликтами имен в больших программных комплексах. Придумано исключительно из-за отсутствия модульности, т.к. при наличии этой самой модульности пространства имен в понимании C++ нафиг не нужны.

← →
Суслик © (2004-09-06 19:48) [164]

> GrayFace © (06.09.04 19:44) [162]

> Что именно ужасного в указателях в паскале ?
> К ним ничего нельзя прибавить. Единственный способ - inc,
> но в выражениях он не работает.

Ты не прав - приобразуй к integter и прибавляй, затем к pointer

pointer(Integer(p) + 1)

← →
GrayFace © (2004-09-06 19:49) [165]

> Но, по уму, в C++ желательно проектировать не меньше.

В смысле, предварительно.

> а множественное наследование - очень даже.

ИМХО, множественное наследование - это круто. Зря его заменили интерфейсы. Но все мои слова о C++ - это очень ИМХО... я на нем не програмировал, но от отца наслышан.

← →
Ермак © (2004-09-06 19:50) [166]

>А если юзеру приспичит одному объекту присвоить другой по значению?

А запретить кто мешает? Приватным-то переопределнием операции?

← →
GrayFace © (2004-09-06 19:52) [167]

Суслик © (06.09.04 19:48) [164]
Ты не прав - приобразуй к integter и прибавляй, затем к pointer

pointer(Integer(p) + 1)

Так и приходится. Но это как begin end - хлам, загромождающий программу. Уменьшает читабильность(begin end кому-то читабильность, может, и увеличивает), заставляет писать море лишних слов.

← →
vuk © (2004-09-06 19:58) [168]

to GrayFace © (06.09.04 19:52) [167]:
>Так и приходится.
Пишите PChar вместо Pointer и будет Вам щщщщастье.

← →
Суслик © (2004-09-06 19:59) [169]

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

← →
GrayFace © (2004-09-06 20:00) [170]

vuk © (06.09.04 19:58) [168]
Спасибо. Буду использовать. Вот только к PInt все-равно ничего не прибавить.

← →
Суслик © (2004-09-06 20:00) [171]

Я вообще первый раз участвую в ХОЛИ ВОР.

Они всегда так заканчиваются?

← →
vuk © (2004-09-06 20:01) [172]

to Суслик © (06.09.04 19:59) [169]:
>Его манера высказываться не располагает
>меня к нормальной беседе.
Можно манеру игнорировать, но следить за смыслом. :o) А со смыслом там все OK. И по времени жизни интерфейсов - тоже.

← →
GrayFace © (2004-09-06 20:01) [173]

vuk © (06.09.04 19:48) [163]
Зря так на Акуличева. Он может немного и резко высказался, но во всем прав.
8-0

← →
Суслик © (2004-09-06 20:01) [174]

> GrayFace © (06.09.04 20:00) [170]

Может и не надо ничего прибавлять?
Средства в дельфи есть, а т.к. согласись операция не настолько частая, то их (средств) вполне достаточно. ИМХО.

← →
Sergey Kaminski © (2004-09-06 20:02) [175]

>> Они всегда так заканчиваются?

Да, они начинаются и заканчиваются всегда одинаково. Все расходятся по углам, надувшись. И так до следующего раза.

← →
Суслик © (2004-09-06 20:03) [176]

> vuk © (06.09.04 20:01) [172]

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

← →
Суслик © (2004-09-06 20:04) [177]

> Sergey Kaminski © (06.09.04 20:02) [175]

> Да, они начинаются и заканчиваются всегда одинаково. Все
> расходятся по углам, надувшись. И так до следующего раза.

Жаль...
Я бы очень хотел пообщаться с вменяемым человеком на предмет обсуждения Дельфи и Си.

← →
GrayFace © (2004-09-06 20:04) [178]

Суслик © (06.09.04 20:01) [174]
Нет. Это неудобство, ничем не обоснованное. Я люблю работать с указателями, тем более, это очень сильно увеличивает скорость.

← →
uny (2004-09-06 20:05) [179]

ну а кто виноват - впечатлительный или его препод?

← →
Суслик © (2004-09-06 20:06) [180]

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

← →
Акуличев Дмитрий (2004-09-06 20:08) [181]

> GrayFace © (06.09.04 19:52) [167]
> Суслик © (06.09.04 19:48) [164]
> Ты не прав - приобразуй к integter и прибавляй, затем к
> pointer
>
> pointer(Integer(p) + 1)
>
> Так и приходится. Но это как begin end - хлам, загромождающий
> программу. Уменьшает читабильность(begin end кому-то читабильность,
> может, и увеличивает), заставляет писать море лишних слов.

А с чего это вдруг у тебя в программе такие операции появляются?

← →
Суслик © (2004-09-06 20:08) [182]

> GrayFace © (06.09.04 20:04) [178]

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

И даже не имхо.

← →
Ермак © (2004-09-06 20:11) [183]

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

← →
jack128 © (2004-09-06 20:13) [184]

Суслик © (06.09.04 20:08) [182]
Если ты пользуешься ansi строками, дин массивами и штатным манагером памяти обсолютно для всех целей, то о скорости говорить не приходится. Выигрышь в прибавлении чисел к поинтерам будет мал.

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

← →
Ермак © (2004-09-06 20:15) [185]

>>А с чего это вдруг у тебя в программе такие операции появляются?

А почему бы им не появляться? В коде, который должен быстро работать с тесктом, только ламер будет работать со стрингами, в другом случае - постоянно гоняешь PChar(string), и наоборот. И pointer++ -- - на каждом шагу.

← →
Суслик © (2004-09-06 20:15) [186]

> Ермак © (06.09.04 20:11) [183]
> Игнорировать?
>
> Вообще-то такие места, натипа, удушу и т.п. обычно модерами
> вырезаются. Тогда можно их игнорировать сколько угодно...

Хе...

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

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

← →
vuk © (2004-09-06 20:18) [187]

to Суслик © (06.09.04 20:06) [180]:
>К тебе сложно придаться - мало говоришь.
Ну дык. Золотое правило: молчи - за умного сойдешь. Вот я и стараюсь. :o)

>Но может когда нить найду и сразу в карьер
You"re welcome! :o)

← →
Суслик © (2004-09-06 20:18) [188]

> jack128 © (06.09.04 20:13) [184]

Ты попробуй помучать дома штатный манагер:
1) создавать/удалять строки случайной длинны
2) созадвать/удалять блоки по 123 (например) байт.

Попробуй тоже самое написать для виртуальной памяти. Разница будет. Как по скорости, так и по оптимальности хранения. На каждый блок ты сможешь тратить менее 4 байт, как в штатном манагере.

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

Если работаем с кусками больше чем пол-мега, надо использовать виндовские функции для резервирования страниц памяти. А иногда - mapped-files.

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

Ермак © (06.09.04 20:18) [189]
Если работаем с кусками больше чем пол-мега, надо использовать виндовские функции для резервирования страниц памяти

я же вроде говорил про виртуальную память?
Ты имеешь в виду другие страницы? Это что?

← →
Акуличев Дмитрий (2004-09-06 20:22) [192]

> Ермак © (06.09.04 20:15) [185]
> >>А с чего это вдруг у тебя в программе такие операции появляются?
>
> А почему бы им не появляться? В коде, который должен быстро
> работать с тесктом, только ламер будет работать со стрингами,
> в другом случае - постоянно гоняешь PChar(string), и наоборот.
> И pointer++ -- - на каждом шагу.

А для PChar как раз реализована адресная арифметика, работает и P+123, и inc(P), и P[i].

Меня больше необходимость этого для других типов интересует.

Суслик © (06.09.04 20:18) [188]
Ты попробуй помучать дома штатный манагер:

Я сейчас дома ;-). Я отметил твой комментарий, просто сейчас лень :-) , но как нибудь поэксперементирую.

> Меня больше необходимость этого для других типов интересует.

например ответить на вопрос на интервью при приеме на работу :))
видел такие вопросы.

я же вроде говорил про виртуальную память?
Ты имеешь в виду другие страницы? Это что?

Я про то же самое. Не боись. Со времен ВИн95 у Микрософта фантазия иссякла. Нет бы еще какую нибудь супер-витруальную забабахать! "На вашем компьютере нет оперативной памяти. Включаем программную эмуляцию!"

> jack128 © (06.09.04 20:23) [193]
> Я сейчас дома ;-). Я отметил твой комментарий, просто сейчас
> лень :-) , но как нибудь поэксперементирую.

уверен, тебя впечатлит штатный манагер. Но также впечатлит, тот факт, что в случае потребности некторые задачи можно ускорить очень сильно. И что самое главное задачи не будут зависеть от контекста (я имею в виду тот факт, что стоки, массивы, объекты также используют штатный манагер).

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

GrayFace © (06.09.04 19:44) [162]

> > Да и без макроподстановок в Дельфи как без рук.
> Эт еще нафига ?
> Для return, например. Без него тяжко.

Переведи пожалуйста свою глубокую мысль на понятный язык, можно на С++, можно на Delphi (это такой намек на пример в студию...)

> Не все программисты идеальны. Не все ХОРОШИЕ программисты
> идеальны - и у них бывают ошибки в проектировке.

Некоторые программисты отличаются еще чтением документации и изучением опыта других программистов. Оно рулез и источник знаний.

> Что именно ужасного в указателях в паскале ?
> К ним ничего нельзя прибавить. Единственный способ - inc,
> но в выражениях он не работает.

Ты будешь удивлен, но я опять попрошу проиллюстрировать глубокую мысль примером...

> Интерфейсов по-нормальному зделана в Java - там это вообще
> не сущьность, а как-бы класс объекта, но без методов. COM-интерфейсы
> для таких нужд мало пригодны, а множественное наследование
> - очень даже.

Опять же, поясни.

GrayFace © (06.09.04 19:49) [165]

> ИМХО, множественное наследование - это круто. Зря его заменили
> интерфейсы. Но все мои слова о C++ - это очень ИМХО... я
> на нем не програмировал, но от отца наслышан.

Я снимаю свои предыдущие просьбы. Для того, чтобы принимать участие в дискуссии, предмет дискуссии необходимо знать.
В ШКОЛУ!

Суслик © (06.09.04 20:03) [176]

> на счет времени жизни интерфейсов..

возьми объект, реализующий 2 интерфейса.

> Я что-то переключился на бучевствое определение интерфейса.
> Бывает...

В студию определение.

GrayFace © (06.09.04 20:04) [178]

> Я люблю работать с указателями, тем более, это очень сильно
> увеличивает скорость.

Чтобы перестать говорить чушь, открой окно CPU и посмотри генерируемый код.

Удалено модератором
Примечание: Offtopic

В коде, который должен быстро работать с тесктом, только ламер будет работать со стрингами

Я не стал бы заходить так далеко и называть брата "толстым" (с)

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