Конфликт мышки и не мышки

[Лекс Айрин]

Подтверждаю... Так как я не знал, что размер лазаруса настолько большой, то он у меня занимает 14,2 МБ (14 910 464 байт) никакими внешними программами оптимизации размера не пользовался. Только сборка из самого лазаруса. Причем, с кучей левых пакетов. Т.е все остальное это отладочная инфа, которой я в принципе не пользуюсь, т.к. отладчик толком не заточен под fpc. Да и смысл ей пользоваться, если Лазарус поддерживается не мной?

[vitaly_l]

"оптимизированная ИДЕ

Да, так действительно собрался нормального размера. Ура - получилось! Но почему-то на 1 мегабайт меньше чем версия из коробки. Это видимо из-за разной оптимизации.

А я пробовал из под cmd запускать, с похожими параметрами: -O2 -g- -Xs (или около того), но он всё равно компилировал 222 Мб. Потом забил и стал прикреплять все пакеты к проекту - это даже немного удобнее. Теперь если понадобится, на форму чего-то класть, то буду знать где у него установки компиляции именно IDE. Спасибочки за познавательный ликбез.

[zub]

>>т.к. отладчик толком не заточен под fpc
Откуда такие мысли в головах? Ненадо такое постить на форумах - вводить в заблуждение читающих

>>Да и смысл ей пользоваться, если Лазарус поддерживается не мной?
Смысл очень большой - чтоб не возникало веры в "неполные" формы if-else и багованые modalresultы

[Лекс Айрин]

Откуда такие мысли в головах? Ненадо такое постить на форумах - вводить в заблуждение читающих

когда заточен толком, то не возникает ситуаций, что отладчик не видит некоторых переменных (и/или их значений)... а по форуму таких примеров туева хуча.

Смысл очень большой - чтоб не возникало веры в "неполные" формы if-else

Знаешь... это практика. Где нет вероятности косяка с полной/неполной формой условных операторов можно превосходно использовать неполную форму. Все лучше, чем при каждом чихе заворачивать все в исключения... это как то менее профессионально. И, кстати, это скорее косяк языка, а не отдельного компилятора.
А модальные окна мне проще имитировать, чем использовать стандартные возможности.
И, собственно, наличие отладчика как такового как-то расслабляет... зачем думать и разбираться, если программа сама подскажет? А я все же хочу именно понять, где я лажанулся. Возможно, потом я и буду его использовать, но вряд ли часто и с большей отдачей, чем дедовские способы.
Да и в код лазаруса действительно нет смысла лезть. Это к программе имеет смысл его подключать... или не имеет. А так, подправишь, а после обновления все правки исчезнут.

[zub]

>>что отладчик не видит некоторых переменных (и/или их значений)
Отладчик не видит вычисляемые проперти и не дружит с оптимизацией. На этом претензии к нему заканчиваются.

>>А я все же хочу именно понять, где я лажанулся.
>>Где нет вероятности косяка с полной/неполной формой
Такой вероятности нет нигде. Если бы ты использовал отладчик, то пару раз нажав F8 понял бы где накосячил - else относится не к тому if как ты планировал - забыл ; или begin-end

>>Да и в код лазаруса действительно нет смысла лезть. Это к программе имеет смысл его подключать... или не имеет. А так, подправишь, а после обновления все правки исчезнут.
Например чтоб понять как работает. или исправить баг. Но исправив надо уметь сделать патч и доступно описать ситуацию на багтрекере\форуме

[pupsik]

На этом претензии к нему заканчиваются.

вы забыли о: упс...

[Лекс Айрин]

На этом претензии к нему заканчиваются.

Мне и этого много.

Если бы ты использовал отладчик, то пару раз нажав F8 понял бы где накосячил - else относится не к тому if как ты планировал - забыл ;

В паре if/if или case/if приходится слишком часто "косячить"... так что лучше перебдеть и вставить лишнее else. Это просто особенность языка и ее никак не исправить, если не менять самого языка. Впрочем, сомневаюсь, что в любом другом языке иначе. Для этого надо изменить саму форму условного оператора, фактически, подписав все условия вручную.

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

Например чтоб понять как работает.

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

или исправить баг.

Это очень похоже на лесть. Я не настолько хорошо знаю программирование. Хотя однажды и получилось исправить ошибку, но она была настолько простой, что даже непонятно почему ее допустили.
И, кстати, для обнаружения бага не надо иметь отладчик. Скорее, время и привычку "думать как компьютер". Ну и чуть воображения для правильной расстановки отладочных операторов.

[zub]

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

Не используя отладчик серьезную ошибку не поймать.

[Лекс Айрин]

Ветвистые ифы и кэйсы - в большинстве своем говнокод. надо обходиться без них.

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

Не используя отладчик серьезную ошибку не поймать.

За все время, только час назад возникла необходимость в отладчике... Да и то, потому что компилятор пропустил код, который не должен был выполняться. Я его, конечно, переделаю, но почему не было ругани непонятно. Там переделка небольшая, но обидно.
Конечно, если серьезная ошибка возникнет, то есть смысл подключить отладчик/отладочную информацию... Но чаще всего тут как с автопроверкой -- при хорошей скорости набора она скорее мешает, чем помогает. Проще проверить потом, благо чаще ошибку исправляешь на автомате еще при самом наборе. К тому же у меня очень маленький цикл набор/компиляция /отладка.

[zub]

>>Но и обратная ситуация (макароны из вызовов мелких функций) говнокод не меньший.
ИМХО. Говнокод тут не в том как выглядит, а в монолитности. Динамическая регистрация и последующий поиск и выполнение нужной ветки - гораздо лучше.

>>За все время, только час назад возникла необходимость в отладчике...
С ростом сложности ружда будет всё чаще. поэтому смысла отнекиваться до последнего нет никакого))

[Лекс Айрин]

Динамическая регистрация и последующий поиск и выполнение нужной ветки - гораздо лучше.

Со временем, сможем и это освоить)))

С ростом сложности ружда будет всё чаще.

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

[vitaly_l]

Тут как с написанием художественных текстом -- хочешь чтобы было интересно, пиши сам.

Ну это - не показатель интересности, художественного текста. Хочешь чтобы было интересно - учи драматургию. Но и этого будет мало, зато сможешь грамотно как 99% писателей делать людям "интересно". К оставшемуся 1% - путь очень сложный.

Динамическая регистрация и последующий поиск и выполнение нужной ветки - гораздо лучше.

Можно чуть подробнее, а то мой вангинатор, краешком мозга рисует художественные картины, а вдруг они не то что, задумывалось автором текста?

[zub]

Наколенный вариант,

Код: Выделить всё

program case2map;
uses
  gmap{модуль описания TMap из fpc-stl},gutil{пара вспомогательных функций из fpc-stl};
type
  TMyKey=Integer;//Тип ключа в мапе
  TMyOnKeyProc=procedure;//Тип данных сопоставленных ключу в мапе
  TMyKeyComparer=specialize TLess<TMyKey>;//стандартный компаратор из gutil, нужен для сортировки ключей
  TMyCase2Map=class(specialize TMap<TMyKey,TMyOnKeyProc,TMyKeyComparer>)//собственно сам класс
    procedure doit(key:TMyKey);//ищем ключ, если есть - вызываем сопоставленную ему процедуру, если нет делаем чето другое
  end;
var
  MyCase:TMyCase2Map;

procedure on1proc;//выполняется для 1
begin
  writeln('on1proc');
end;

procedure on2proc;//выполняется для 2
begin
  writeln('on2proc');
end;

procedure on100proc;//выполняется для 100
begin
  writeln('on100proc');
end;

procedure TMyCase2Map.doit(key:TMyKey);
var
  proc:TMyOnKeyProc;
begin
  if TryGetValue(key,proc) then //пробуем найти ключ
    proc() //если нашли запускаем процедуру
  else
    writeln('Do Something else, key=',key) //не нашли, аналог case else
end;

begin
  MyCase:=TMyCase2Map.Create;

  MyCase.Insert(100,@on100proc); //регистрируем процедуру для 100
  MyCase.Insert(2,@on2proc);//регистрируем процедуру для 2
  MyCase.Insert(1,@on1proc);//регистрируем процедуру для 1

  MyCase.doit(1);//пробуем выполнить чтото для 1
  MyCase.doit(22);//пробуем выполнить чтото для 22
  MyCase.doit(2);//пробуем выполнить чтото для 2
  MyCase.doit(33);//пробуем выполнить чтото для 33
  MyCase.doit(100);//пробуем выполнить чтото для 100

  MyCase.Destroy;//денег нет, вы держитесь тут. хорошего настроения

  readln;
end.

on1proc
Do Something else, key=22
on2proc
Do Something else, key=33
on100proc

[vitaly_l]

if TryGetValue(key,proc) then //пробуем найти ключ

Код: Выделить всё

generic TSet<T, TCompare>=class  ....

function TSet.NFind(value:T):PNode;inline;
var x:PNode;
begin
  x:=FBase;
  while(x <> nil) do begin
    if(TCompare.c(value,x^.Data)) then x:=x^.Left
    else if(TCompare.c(x^.Data,value)) then x:=x^.Right
    else begin
      exit(x);
    end;
  end;
  exit(nil);
end;


Чё-то как-то сложно. Хотя безусловно, если там 1000 функций, то в какой-то момент, на 777 прыжке, это станет работать быстрее чем case.
В этом фишка? Или фишка, только в простоте читабельности кода программы?

[zub]

>> Хотя безусловно, если там 1000 функций
глянь результаты в соседней теме viewtopic.php?t=19485 это для 1023 "веток", такчто результаты на лице гораздо раньше
Фишка в том что тут потратится время на заполнение мапы (сортировка), но зато потом работает бинарный поиск. Также большой плюс в динамической регистрации - ветки можно добавлять из разных юнитов и юнит с мапом о них ниче может не знать. в случае с обычным кейсом его юнит должен подключать в uses все юниты с "ветками"