Конференция "Прочее" » Тесты на знание Delphi
 
  • antonn © (23.11.08 21:10) [20]
    потому что Архангельский забыл точечки (aka дополнительный код) поставить? :)
  • Григорьев Антон © (23.11.08 21:19) [21]

    > antonn ©   (23.11.08 21:10) [20]
    > потому что Архангельский забыл точечки (aka дополнительный
    > код) поставить? :)

    Забыл или не забыл - это уже не суть важно. Главное, что по этой схеме уже не один человек пытался нити реализовывать, и надо что-то делать, чтобы таких людей было меньше :) К тому же, если я правильно понял Игоря, там речь идёт именно о готовых примерах программ, в которых написан точно такой код без всяких добавлений.
  • antonn © (23.11.08 21:21) [22]
    хотел много чего написать по поводу примеров Архангельского и "статьи" Игоря, но не буду, уже высказывался, да и оффтопик :)
  • Дмитрий С (23.11.08 22:05) [23]
    Хорошие тесты
    +1 в карму :)
  • TUser © (23.11.08 22:45) [24]
    Тесты хорошие, правда код из вопросов первой части (другие не смотрел) из серии нарочно не придумаешь. Так не только никто не будет писать, так писать прямо противопоказано для клеток головного мозга. Хотя для проверки знаний основ языка оно может и норально.
  • Loginov Dmitry © (23.11.08 23:14) [25]
    Спасибо за тест! Хоть нашелся повод размяться под конец выходный :)

    Оказалось, 13 из 13 не так-то просто набрать. В связи с этим замечания )))

    - по 4-му вопросу (базовые св-ва Delphi):

    Если необходимо передать несколько флагов, как это можно сделать?



    можно 2-мя способами. А разрешается выбрать только один.

    - по 6-му вопросу.


    -Динамические массивы не могут быть параметрами-переменными
    -Здесь A – не динамический массив, а открытый, поэтому использовать SetLength нельзя



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

    - по 9-му вопросу. Пришлось открыть справку, чтобы убедиться, что
    {$WRITEABLECONST ON}

    является синонимом
    {$J+}

    . Может стоит все-таки заменить на
    {$J+}

    , либо в коментарии указать оба варианта?
  • Loginov Dmitry © (23.11.08 23:36) [26]
    Вопросы в разделе "Классы" попроще. Мне кажется, в п. 4 перед строкой
    Obj.IntProp := ...

    не помешал бы намек в виде
    Edit1.Text := 1.5;

    (при этом придется правильный ответ также скорректировать)))
  • Anatoly Podgoretsky © (23.11.08 23:47) [27]
    > Loginov Dmitry  (23.11.2008 23:14:25)  [25]

    > можно 2-мя способами. А разрешается выбрать только один.

    Приведи второй.
  • Дмитрий С (24.11.08 00:05) [28]

    > Anatoly Podgoretsky ©   (23.11.08 23:47) [27]

    Можно ORами, можно +ами.


    > -Динамические массивы не могут быть параметрами-переменными
    > -Здесь A – не динамический массив, а открытый, поэтому использовать
    > SetLength нельзя
    >
    >
    > из-за очивидности ответа на этот вопрос, может показаться,
    >  что оба варианта правильны. На мой взгляд, формулировку
    > можно бы как-то и упростить, иначе, все поголовно тут из-
    > за подобной формулировки начнут спотыкаться :)
    >

    Так динамический массив можно определить в качестве var параметра, поэтому "-Динамические массивы не могут быть параметрами-переменными" уже неверно
  • Anatoly Podgoretsky © (24.11.08 00:12) [29]
    > Дмитрий С  (24.11.2008 0:05:28)  [28]

    Ошибаешься, видимо из-за нечеткого понимания двоичных операций, это не одно и тоже, результаты могут как отличаться, так и совпадать. Просто пример, пусть есть две константы A=1 и B=3

    A or B = 3
    A + B = 4

    Второй вариант неверный, для битовых операций.
  • Loginov Dmitry © (24.11.08 00:13) [30]
    По разделу VCL. Обратил внимание на следующее описания (не стану говорить, почему оно привлекло внимание:)


    В некоторых случаях всё не так очевидно. Если бы мы попытались аналогичным образом присвоить значение свойству Label1.Caption, программа запустилась бы, хотя присвоенное в конструкторе значение было бы проигнорировано. Это происходит потому, что в некоторых случаях код VCL проверяет Self на равенство nil, и если ссылка оказывается нулевой, просто ничего не делает.



    на самом деле, многое чего делает, а проверка "Self <> nil" происходит после множества вызовов функций, и в данном случае принимается решение о возможности вызова
    WindowProc(Message)

    .
    Что-то не туда понесло на ночь глядя ))))
  • Loginov Dmitry © (24.11.08 00:15) [31]
    >
    > это не одно и тоже, результаты могут как отличаться, так
    > и совпадать


    Там конкретный случай дан с MessageBox(). Вроде каких-либо проблем с "+" замечено не было ))
  • Дмитрий С (24.11.08 00:17) [32]

    > Anatoly Podgoretsky ©   (24.11.08 00:12) [29]

    Да понимаю я:) В некоторых случаях "+"ы  дадут нужный эффект, например, когда все константы - степени двойки и повторов нет.
  • Loginov Dmitry © (24.11.08 00:33) [33]
    Раздел "Использование DLL".

    Все внимание уделяется модулю ShareMem (SimpleShareMem), хотя есть прекрасная и взаимоисключающая альтернатива - галочка "build with runtime packages", которая пока еще вполне доступна при сборке DLL :)
  • тимохов (24.11.08 00:52) [34]
    прошел первый тест.
    в последнем ошибся - не использовался за последние 12 лет ни разу вещественные числа - терпеть их не могу :) использую свой любимый Decimal, vartype 14.

    тест хорош, честно.
    на мой взгляд без двусмысленностей.

    молодцы!
  • Loginov Dmitry © (24.11.08 01:10) [35]
    Раздел "Нити (threads)"

    Как работает метод TThread.Synchronize?
     > Решает проблемы с синхронизацией неизвестным науке способом

    Супер! =)

    По вопросу 5, касающегося использование TTimer в дополнительном потоке.

    В описании сказано, что
    Сказанное выше не означает, что TTimer нельзя использовать в неглавной нити.



    Скажу по секрету: TTimer нельзя использовать в неглавной нити!!!!

    Это опасно!

    Если мы заглянет в TTimer.Create, то увидем вызов
    FWindowHandle := Classes.AllocateHWnd(WndProc);



    В функции Classes.AllocateHWnd последней строкой мы видим вызов:

     if Assigned(Method) then
       SetWindowLong(Result, GWL_WNDPROC, Longint(MakeObjectInstance(Method)));



    Теперь посмотрим на реализацию функции MakeObjectInstance(). В ней используются глобальные объекты, которые никакой синхронизацией не защищены. Что получится, если теже TTimer одновременно будут созданы в 2х потоках? Убъем всю VCL! На 1-ядерных процессорах это очень большая редкость, зато на многоядерных - запросто. Кстати, библиотека IBx, идущая по умолчанию с Delphi 7, обладала той же болезнью. Ее просто опасно (!) было эксплуатировать в многопоточных приложениях. Возможно, что для кого-то это новость.
  • тимохов (24.11.08 01:20) [36]
    а вот про нитки не согласен.

    вопрос 9. createthread пользовался, пользуюсь и буду пользоваться. думаю, что нужно "правильно" заменить на "наименее трудозатратно". или вообще перефразировать - чем createthread хуже beginthread? ну и там, варианты ответов.

    вопрос 8. облажался с waitfor - забыл, что он гад умный...

    вопрос 4. Очень не согласен с тем, что terminatethread является некорректным способом закрытия потока. он является опасным и крайней мерой, но это способ, закрывающий поток. опять же - найдите мне способ прервать ADO запрос в доп. потоке? возможно, что когда я искал этот способ 3 года назад я был слаб, чтобы его найти, но ничего кроме закрытия потока я не нашел. я так и не воспользовался terminatethread для решения данной задачи (пусть висит запрос в фоне, фиг с ним), но иного способа я не вижу.

    Опять же утвержение "данная нить не может быть остановлена корректно". А если в DoSomthing есть возможность возбудить исключение, тогда что? Исключения перестали быть корректными?

    В общем хватит критики. Совет. Перепишите вопрос таким образом, чтобы не было двусмысленностей. Например, "Какие из перечисленных способов закрывают поток и какие из них являются предпочтительными в *большинстве* случаев":
    1. waitfor
    2. terminate
    3. waitfor и terminatethread.
    4. terminatethread как крайняя мера.
    5. terminatethread как общепринятый способ завершения потоков.
    6. никак.

    я не автор вопросов, потому может не сильно правильно говорю, но вопрос 4 двусмысленный. это плохо.
  • Германн © (24.11.08 01:25) [37]
    Даже без очков прекрасно видно откуда у этой Квинтаны растут ноги :)
    Очевидно ЮЗ решил, что несправедливо будет если "тесты Юрия Зотова" будут доступны только Riply. (Кстати, а фотку-то она ЮЗ выслала, как обещала? :).
    Ну а то что в этом благородном проекте возможно приняли участие и некоторые другие уважаемые рыцари и маги королевства, так и им спасибо огромное!
  • Loginov Dmitry © (24.11.08 01:25) [38]
    > чем createthread хуже beginthread? ну и там, варианты ответов.


    IsMultiThread? :)
  • Loginov Dmitry © (24.11.08 01:29) [39]
    > Очень не согласен с тем, что terminatethread является некорректным
    > способом закрытия потока. он является опасным и крайней
    > мерой, но это способ, закрывающий поток


    Некорректный, поскольку варварски прерывает выполнение потока, после этого в отдельных случаях возможны любые глюки в программе. Кроме того, при использовании terminatethread стэк потока остается, а это целый мегабайт утекшей памяти (а то и больше, если были какие-либо динамические массивы или строки)!
 
Конференция "Прочее" » Тесты на знание Delphi
Есть новые Нет новых   [134446   +39][b:0.001][p:0.003]