YAR под windows

← →
* © (2011-06-10 08:27) [40]

> бекэнд к LLVM не забудь -)

:-)

← →
oxffff © (2011-06-10 09:09) [41]

> бекэнд к LLVM не забудь -)

Читал лекцию в университете 3 курсу.
Предложил заняться им LLVM с последующим перетеканием в диплом.
Отказались.

← →
Kerk © (2011-06-10 12:28) [42]

Сделай потокобезопасный оператор with :)

← →
DVM © (2011-06-10 15:18) [43]

> Kerk © (10.06.11 12:28) [42]

и потокобезопасные begin и end

← →
oxffff © (2011-06-10 16:45) [44]

> Напишу чуть позже обобщенный TRUE и FALSE.

Сделано.

while GetMessage(MSG,0,0,0) do
begin
.........

← →
oxffff © (2011-06-10 16:47) [45]

> oxffff © (10.06.11 16:45) [44]
>
> > Напишу чуть позже обобщенный TRUE и FALSE.
>
>
> Сделано.

Теперь есть два логических типа boolean(1 байт) и bool(4 байта).

← →
Дмитрий С © (2011-06-11 16:37) [46]

> Сделай потокобезопасный оператор with :)

А что с ним не так?

← →
DVM © (2011-06-11 19:10) [47]

> Дмитрий С © (11.06.11 16:37) [46]

> А что с ним не так?

не потокобезопасный

← →
DiamondShark © (2011-06-12 10:40) [48]

> DVM © (11.06.11 19:10) [47]

А как должен вести себя потокобезопасный оператор with?

← →
cwl © (2011-06-12 11:07) [49]

Есть подозрение, щто имелась ввиду связка
with A
begin
...
end;

иначе - тоже не ососбо догоняю.

← →
Kerk © (2011-06-12 14:39) [50]

Он должен гарантировать блокировку доступа к A для всех остальных потоков

← →
Kerk © (2011-06-12 14:46) [51]

> cwl © (12.06.11 11:07) [49]

К слову, нет тут никакой связки. После with идет операция, begin-end всего-лишь операторные скобки.

← →
DVM © (2011-06-13 00:31) [52]

> DiamondShark © (12.06.11 10:40) [48]

> А как должен вести себя потокобезопасный оператор with?

так же как и непотокобезопасный, но потокобезопасно.

Люди, у вас совсем туго с чувством юмора что ли? Я вообще то шутил.

> Kerk © (12.06.11 14:46) [51]

> К слову, нет тут никакой связки. После with идет операция,
> begin-end всего-лишь операторные скобки.

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

← →
Kerk © (2011-06-13 01:16) [53]

> DVM © (13.06.11 00:31) [52]

Здесь как бы речь о создании нового языка идет.

← →
DVM © (2011-06-13 11:17) [54]

> Kerk © (13.06.11 01:16) [53]

> Здесь как бы речь о создании нового языка идет.
>
>

Тогда зачем приплетать With? Тем более не очень понятно, как эта конструкция должна обеспечивать потокозащищенность чего либо? Критическая секция встроенная в язык? Лучше уж сразу при объявлении типа ввести ключевое слово threadsafe, типа такого:

a: string; threadsafe;

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

← →
Kerk © (2011-06-13 13:54) [55]

> DVM © (13.06.11 11:17) [54]
> Тогда зачем приплетать With?

К тому, что я предлагаю, по смыслу этот оператор ближе всего.

> Лучше уж сразу при объявлении типа ввести ключевое слово
> threadsafe

Не лучше, это совершенно другое.

1)
var
SomeObject: TSomeObject; threadsafe;
begin
SomeObject.X := 1;
SomeObject.Y := 2;
...
end;

2)
with TSomeObject do
begin
X := 1;
Y := 2;
end;

Видишь разницу? Обрати внимание, здесь ДВА действия. И во втором случае для остальных потоков они будут атомарны.

← →
Kerk © (2011-06-13 14:00) [56]

Конструктор в обоих примерах я забыл вызвать, ну да ладно, на суть не влияет.

← →
jack128_ (2011-06-13 16:04) [57]

lock что ли дотнетовский хотите??? нафиг!

← →
DiamondShark © (2011-06-13 20:09) [58]

> jack128_ (13.06.11 16:04) [57]
> lock что ли дотнетовский хотите??? нафиг!

Почему нафиг? Хорошая же штука.

← →
jack128_ (2011-06-13 21:30) [59]

> Почему нафиг? Хорошая же штука.

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

using (Locker.Lock(myObj)) { }

по сравнению с
lock (myObj) { }

?
ИМХО ничем, значит lock не нужно было в язык встраивать.

← →
DVM © (2011-06-13 23:26) [60]

> Kerk © (13.06.11 13:54) [55]

> Видишь разницу? Обрати внимание, здесь ДВА действия. И во
> втором случае для остальных потоков они будут атомарны.

Ну для двух и более действий сделать threadsafe методы у объектов, в них и пихать все что надо. На мой взгляд with сюда не совсем подходит, что-то не то.
А лучше как jack128 говорит сделать.

← →
Дмитрий Белькевич (2011-06-14 00:16) [61]

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

Подпишусь Дмитрий С. 7,8,9.

Реализация 9:

for I := 0 to 100 do
for J := 0 to 100 do
begin
...
...
next i; continue понимать как next j
...
...
break i; // - выход с обоих циклов
end;

← →
DiamondShark © (2011-06-14 16:35) [62]

> jack128_ (13.06.11 21:30) [59]

Давай разовьём твою мысль.

Вот я у тебя заметил using. А чем

try
{
}
finally
{
((IDisposable)myObj).Dispose();
}

хуже, чем

using(myObj)
{
}
?
Ничем. Значит using в язык не надо было вводить. Без него библиотечнее.
foreach тоже не надо было вводить, потому что цикл с IEnumerator.MoveNext ничем не хуже и библиотечнее.

Не нравится вам синтаксический сахар -- базару нет, никто не принуждает. Нравится вам вместо одной строки писать шесть, можете невозбранно писать:
Monitor.Enter(myObj);
try
{
}
finally
{
Monitor.Exit(myObj);
}

Вместо
lock(myObj)
{
}

Будет вам библиотечно и благопотребно.

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

> DVM © (13.06.11 23:26) [60]
>
> > Kerk © (13.06.11 13:54) [55]
>
> > Видишь разницу? Обрати внимание, здесь ДВА действия. И во
> > втором случае для остальных потоков они будут атомарны.
>
> Ну для двух и более действий сделать threadsafe методы у
> объектов, в них и пихать все что надо.

Для этого разработчику класса придется предусматривать методы на все случаи жизни?

> Kerk © (14.06.11 16:48) [63]

> Для этого разработчику класса придется предусматривать методы
> на все случаи жизни?

Зачем? Достаточно дать возможность наследоваться от данного класса. И вызывай дальше методы предка в нужной последовательности внутри threadsafe методов потомка.

Это безумие какое-то.

> DVM © (14.06.11 16:58) [64]
> Достаточно дать возможность наследоваться от данного класса.

public abstract class Task
{
}

public MyTaskHandler : TaskHandler
{
public override void HandleTask(Task task)
{
// здесь я хочу обработать task атомарно.
}
}

public static void Main()
{
GlobalTaskManager.RegisterHandler(new MyTaskHandler());
GlobalTaskManager.Run();
}

Скажи, пожалуйста, как тут поможет возможность наследоваться?

> Дмитрий Белькевич (14.06.11 00:16) [61]

а выход из циклов while, repeat как ?

Кстати можно добавить конструкцию вроде такой:
do begin
...
end;
что по смыслу будет как
while true do
begin
...
break;
end;
или
repeat
...
until true;
смысл и необходимость которой предлагаю обсудить

> DiamondShark © (14.06.11 17:33) [66]

> Скажи, пожалуйста, как тут поможет возможность наследоваться?

Добавить в MyTaskHandler еще один "threadsafe" метод, который и будет обрабатывать атомарно твой таск и внутри HandleTask его вызвать? Нет?

> DVM © (14.06.11 17:45) [68]
> Добавить в MyTaskHandler еще один "threadsafe" метод, который
> и будет обрабатывать атомарно твой таск и внутри HandleTask
> его вызвать? Нет?

Нет.

public static class GlobalTaskManager { public static void Run() { Task task; while ((task = DequeueTask()) != null) { foreach (var handler in RegisteredHandlers) { ThreadPool.QueueUserWorkItem(x => handler.HandleTask(task)); } } } }

← →
jack128_ (2011-06-14 21:42) [70]

> Давай разовьём твою мысль.

Я и не сомневался в твоей способности довести любую мысль до абсурда.

Очевидно иногда нужно вводить синтаксический сахар.

Только нужно искать баланс между парой факторов:
1) частота использования шаблона кода. (Думаю, что ты согласишься, что using используется на пару порядков чаще, чем lock)
2) насколько сахар упрощает запись кода. мой пример с using отличается от lock на пяток символов, а замена using на try-finally на 5 строк

var temp = myObj; // myObj в теле try может измениться, нужно сохранить старое значение.
try
{
..
}
finally
{
((IDisposable)temp).Dispose();
}

Просто в крайности не нужно в крайности бросаться.

> jack128_ (14.06.11 21:42) [70]
> Я и не сомневался в твоей способности довести любую мысль до абсурда.

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

> Очевидно иногда нужно вводить синтаксический сахар.

А когда? Вот using и foreach абсолюютно точно такие же введённые в язык надстройки над библиотекой, как и lock. Но using тебе нравится, а lock -- нет.
Очевидно, что твои критерии очевидности ни разу не очевидны.

> 1) частота использования шаблона кода. (Думаю, что ты согласишься,
> что using используется на пару порядков чаще, чем lock)

Думаю, что не соглашусь. На пару порядков -- это, на секундочку, раз этак в сто. Как считали?
Приложения бывают разного типа. В десктопном windows forms приложении может вообще не быть ни одного лока. А в каком-нибудь многопоточном сервисе -- полно.
Язык у нас, вроде как, универсальный, общего применения, так что о частоте сценариев использования стоит рассуждать с осторожносьтю.

> 2) насколько сахар упрощает запись кода. мой пример с using
> отличается от lock на пяток символов, а замена using на
> try-finally на 5 строк

Для начала, твой пример с using не имеет никакого отношения к тому, как на самом деле реализован lock.
Ценность сахара не столько в количестве букафф, сколько в повышении качества кода: отсутствует возможность что-то накорявить в реализации рутинных действий.
Машина должна работать, а человек думать. Вот пусть машина и генерирует рутинный код, а человек будет думать в терминах высокоуровневых блоков, а не пытаться удержать в голове от рассыпания пучок операторов.

> Просто в крайности не нужно в крайности бросаться.

Вот твоё заявление, типа: "такой-то оператор не нужен, потому что в библиотеке всё уже есть" -- это крайность и есть крайность.

ЗЫ
Ты, вроде, дельфист? Хочешь, посчитаем, сколько в языке дельфи обёрток над библиотекой?

YAR под windows Найти похожие ветки