Вот так фокус !!!

← →
Суслик © (2007-02-28 20:15) [40]

пора переходить на дельфи2007!

← →
Ketmar © (2007-02-28 20:18) [41]

> iZEN © (28.02.07 20:13) [38]
> Нужно быть готовым ко всему! :))
да я давно готов жабу пристрелить. пусть только рядом пробежит...

← →
iZEN © (2007-02-28 20:31) [42]

> Ketmar © (28.02.07 20:18) [41]
>
> > iZEN © (28.02.07 20:13) [38]
> > Нужно быть готовым ко всему! :))
> да я давно готов жабу пристрелить. пусть только рядом пробежит.
> ..

С некоторых пор она не бегает (и уже не ползает). Она летает! :)

P.S.
Мне хочется отправить фтопку Python2.5 и XUL. Ну очень тормозно и глюкаво всё. Firefox столько памяти жрёт -- ужас.

← →
Ketmar © (2007-02-28 20:53) [43]

> iZEN © (28.02.07 20:31) [42]
> Она летает! :)
угу. с крыши на асфальт.

> Мне хочется отправить фтопку Python2.5 и XUL
на здоровье. два <autocensored>.

← →
iZEN © (2007-02-28 21:06) [44]

((Прошу прощения, не Python2.5, а Python2.4.))

← →
Игорь Шевченко © (2007-02-28 21:42) [45]

Суслик © (28.02.07 20:15) [40]

> пора переходить на дельфи2007!

Целиком и полностью поддерживаю!

← →
Юрий Зотов © (2007-02-28 21:48) [46]

> iZEN © (28.02.07 20:08) [34]

Да пусть он себе инлайнит что хочет, и куда хочет, это его личное дело.

Но когда обращение к значению константы напрямую и обращение к нему же через промежеточную переменную дают РАЗНЫЕ результаты - это стопроцентный глюк. Хоть 100 раз он заинлайнит - но он ОБЯЗАН сделать это 100 раз ОДИНАКОВО.

← →
Канадец (2007-02-28 22:22) [47]

>Юрий Зотов © (28.02.07 21:48) [46]

Кстати всё логично получается.

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

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

← →
Ketmar © (2007-02-28 23:31) [48]

> Канадец (28.02.07 22:22) [47]
если компилятор заоптимизировался до полного маразма, то это баг разработчиков, а никак не пользователей.

заинлайнил? запомни, откуда, и перекомпилируй то, что надо, коли поменяли. не можешь? глючище. жаба, короче...

← →
Petr V. Abramov © (2007-02-28 23:46) [49]

> Юрий Зотов © (28.02.07 18:23) [0]
да ладно, в Дельфе чтоль ни разу такого не было
но в общем и целом сочуствую.... терпи...

← →
Суслик © (2007-03-01 01:37) [50]

> Юрий Зотов © (28.02.07 21:48) [46]

делай полный билд, и все будет ок.

мне (в моем отсталом нетбинсе фор дот зеро) помогало.

← →
Германн © (2007-03-01 01:49) [51]

> Petr V. Abramov © (28.02.07 23:46) [49]
>
> > Юрий Зотов © (28.02.07 18:23) [0]
> да ладно, в Дельфе чтоль ни разу такого не было

А ты, Петь, можешь привести пример аналога (хотя бы приблизительного) в "Дэльфе?"
Степень "приблизительности" оценят в следущих постах :)

← →
Alex Konshin © (2007-03-01 01:54) [52]

> Ketmar © (28.02.07 23:31) [48]
>
> > Канадец (28.02.07 22:22) [47]
> если компилятор заоптимизировался до полного маразма, то
> это баг разработчиков, а никак не пользователей.
>
> заинлайнил? запомни, откуда, и перекомпилируй то, что надо,
> коли поменяли. не можешь? глючище. жаба, короче...
>

Причем тут Java?
Это глюк/feature Eclipse у которого, кстати, свой встроеный компилятор.
Кстати, а вы уже все позабыли, что в Delphi IDE перед отладкой крайне желательно перекомпилировать все из-за подобных же глюков? Или то, что позволено Delphi, не позволено Java?
Объективнее надо быть, друзья. :)

← →
Суслик © (2007-03-01 01:59) [53]

не только объективней, но и ориентированнее!!!!!

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

Вот (это мой репорт в QC)

1. Run this project

{$o+} program Project1; uses SysUtils, Windows; type TItem = record private var Dummy: array[0..1111] of Integer; public class function New(): TItem; static; public procedure Change(); end; class function TItem.New(): TItem; begin Result.Dummy[0] := 1; end; procedure TItem.Change(); begin Dummy[0] := 2; end; procedure A(const Item: TItem); begin Item.Change(); end; var kItem: TItem; kI: Integer; begin kItem := TItem.New(); kI := kItem.Dummy[0]; MessageBox(0, PChar(IntToStr(kI)), "before A() call", 0); A(kItem); kI := kItem.Dummy[0]; MessageBox(0, PChar(IntToStr(kI)), "after A() call", 0); end.

2. See the behaviour

3. Run this project again with {$o-}

4. See the *different* behaviour: you must see the different content of "after A() call"
message box.

← →
Суслик © (2007-03-01 02:00) [54]

Закрыли, кстити, репорт со словами - сам дурак

> The bug is in the test application, not the compiler. It
> iis unreasonable to expect the compiler to generate code
> that produces the same results with $o+ and $o- if the assumptions
> that you allow it to make (in this case that "procedure
> A(const Item:TItem)" does not change "Item") are incorrect
> due to a programming error.

PS
Полностью согласен с решением, кстати.

← →
DiamondShark © (2007-03-01 11:32) [55]

> Полностью согласен с решением, кстати.

А я не согласен.

Пятая дельфи в случае
type Z = record A: integer; end; procedure Q(var a: Z); begin a.A := 1; end; procedure W(const a: Z); begin Q(a); end;

Добросовестно ругалась "Constant object cannot be passed as var parameter"

От того, что в результате издевательств над синтаксисом у записей появились методы, объявление
public procedure Change();
не перестало быть в действительности
public procedure Change(var Self: TItem);

Что мешало здесь выдать точно такое же предупреждение?

Возражения рода: "А тогда бы появился гемор с вызовом методов записи откуда ни попадя!" не принимаются.
Во-первых, подобный гемор с простыми процедурами никого не напрягает, и помогает контролировать side effect.
Во-вторых, нефиг извращаться над синтаксисом, бездумно вводя абсолютно левые фичи.
А если уж извращаться, то по-чёрному. Например, ничего не мешает декларировать метод как свободный от side effect, например, так:
public const procedure Change();
что семантически эквивалентно
public procedure Change(const Self: TItem);
и всё замечательно проверяется на этапе компиляции.

Так что это не "сам дурак". Это борландцы -- негодяи и лентяи.
Испохабили язык, до конца не додумали, да ещё и отмазываются.

← →
Ketmar © (2007-03-01 11:36) [56]

самое противное то, что ребята из FPC Team ведь ломанутся реализовывать весь тот идиотизм, что напридумывали в новых дельфях...

← →
Суслик © (2007-03-01 11:39) [57]

> [55] DiamondShark © (01.03.07 11:32)

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

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

← →
Суслик © (2007-03-01 11:39) [58]

Удалено модератором
Примечание: Дубль

← →
Суслик © (2007-03-01 11:39) [59]

Удалено модератором
Примечание: Дубль

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

> [47] Канадец (28.02.07 22:22)
> А вот когда вы объявляете локальную переменную, вы изменяете
> код класса где она используется, что в свою очередь ведёт
> к перекомпиляции и к подстановке нового значения. Поэтому
> всё красиво работает.

Но в этом случае возврат к варианту без локальной переменной тоже должен начать работать правильно.
2 Юрий Зотов ©: а так тот же глюк или все ж начинает правильно работать?

Забавная мысль по поводу.
Действительно хорошо было бы явно декларировать побочный эффект методов.
Т.е., к примеру, я как разработчег какого-нибудь базового класса могу написать:

public const function GetValue: Integer; virtual; abstract;

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

Хотя, тут встаёт вопрос, что делать с полями-ссылками на объекты.
Компилятор запретит изменить саму ссылку. Но нет никакой возможности контролировать изменение экземпляра по ссылке.
:(

Дима, тут как по рукам не бей -- всё равно найдут, где сломать. головы чинить надо, а не синтаксис...

Ну и напоследок полезная ссылка на материал о модели памяти в Java:

"Теория и практика Java: Исправление модели памяти Java, Часть 1"
http://www.ibm.com/developerworks/ru/library/j-jtp02244/index.html

Недостатки оригинальной модели памяти Java

В то время, как модель памяти JMM, заданная в главе 17 спецификации Java Language Specification, была амбициозной попыткой определить единообразную, межплатформенную модель памяти, у нее есть несколько незаметных, но существенных недостатков. Семантика synchronized и volatile была довольно такой запутанной, настолько, что многие хорошо подготовленные разработчики предпочитали иногда игнорировать правила, потому что написание соответствующим образом синхронизированного кода под старой моделью памяти было затруднительно.

Старая модель памяти JMM допускала некоторые удивительные и сбивающие с толку вещи, например появление в полях final не тех величин, которые были установлены в конструкторе (что могло превратить неизменяемые объекты в изменяемые), а также неожиданные результаты при переупорядочивании операций с памятью. Это также мешало некоторым формам оптимизаций программ во время компилирования, которые в иных случаях эффективны. Если вы прочли какие-либо статьи о проблеме блокировки с двойной проверкой (см. Ресурсы), вы помните, насколько запутанной может быть операция по переупорядочиванию, и насколько незаметные, но серьезные проблемы могут проникнуть в ваш код, когда вы не выполняете синхронизацию должным образом (или активно пытаетесь избежать синхронизации). Хуже того, многие неправильно синхронизированные программы оказываются работают правильно в некоторых ситуациях, например, при при небольшой загрузке, на однопроцессорных системах, или на процессорах с более сильными моделями памяти, чем это требуется JMM.

Термин переупорядочивание используется для описания нескольких классов реальных и очевидных перераспределений операций с памятью:

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

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

"в дворницкой стоял запах гниющего навоза, распространяемого новыми валенками Тихона. Старые валенки стояли в углу и воздуха тоже не озонировали"
12 стульев

> Petr V. Abramov © (04.03.07 00:16) [66]

Согласен. Сначала разложили грабли, замаскировали их, на них наступали, а потом радостно сообщили всем о том, где они лежат, огородив это место ленточкой. Ж))

Вот так фокус !!! Найти похожие ветки