Добавить любой RSS - источник (включая журнал LiveJournal) в свою ленту друзей вы можете на странице синдикации.
Исходная информация - http://forum.sources.ru. Данный дневник сформирован из открытого RSS-источника по адресу http://forum.sources.ru/yandex.php, и дополняется в соответствии с дополнением данного источника. Он может не соответствовать содержимому оригинальной страницы. Трансляция создана автоматически по запросу читателей этой RSS ленты. По всем вопросам о работе данного сервиса обращаться со страницы контактной информации.[Обновить трансляцию]
swf: - Вы готовы работать бесплатно? - Ну если зарплата хорошая, можно и бесплатно.
- Вы в резюме написали, что имеете огромный опыт работы в стрессовых условиях, устойчивость к форс-мажорам, профессиональные навыки выхода из критических ситуаций. В какой области? - В Челябинской.
Условие. На вход алгоритма подаётся натуральное число N.
Алгоритм по нему строит новое число R следующим образом.
1) Строится двоичная запись числа N.
2) К этой записи дописываются разряды по следующему правилу:
а) если число чётное, то к двоичной записи числа в конце дописывается 1 и 0;
б) если число нечётное, то к двоичной записи числа в конце дописывается 01.
Полученная таким образом запись является двоичной записью искомого числа R. Укажите наибольшее число R меньшее 109, которое может получиться после обработки этого алгоритма (в результате работы этого алгоритма). В ответе это число запишите в десятичной системе.
Решение.
Вначале посмотрим, что происходит с числом после приписывания к нему двух цифр в десятичной системе счисления.
Пусть число N записано в десятичной системе счисления. Если мы к концу этого числа припишем две цифры xy, то умножим исходное число на 100 (10^2) и прибавим к нему число xy:
R = N * 10^2 + x * 10^1 + y * 1.
Приписывание двух цифр 01(10) в двоичной системе счисления аналогично умножению исходного числа на 4 (2^2) в десятичной с последующим прибавлением числа 1(2):
а) N – нечётное
R = N * 2^2 + 0 * 2^1 + 1 * 1 = 4N + 1.
Теперь найдём наибольшее нечётное R < 109:
R < 109; 4N < 108; N < 27; N = 25.
R = 4*25 + 1 = 101.
б) N – чётное
R = N * 2^2 + 1 * 2^1 + 0 * 1 = 4N + 2.
R < 109; 4*N < 107; N < 26,75; N = 26.
R = 4*26 + 2 = 106.
Условие. По каналу связи передаются сообщения, содержащие 6 букв:
А, Б, В, Г, Д, Е, для передачи используется неравномерный двоичный код, удовлетворяющий условию Фано. Буква А имеет код 00, буква Б код 01.
Какова наименьшая возможная сумма длин кодовых букв В, Г, Д, Е, при котором код будет допускать однозначное декодирование. Решение.
Условие Фано означает, что ни одно кодовое слово не является началом другого кодового слова. Коды, удовлетворяющие условию Фано, допускают однозначное декодирование.
Поэтому коды букв В, Г, Д, Е не могут начинаться с нуля (иначе нарушается условие Фано).
Если буквы В, Г, Д, Е закодированы тремя цифрами:
В – 100, Г – 101, Д – 110, Е – 111, то
сумма длин их кодов равна 3 * 4 = 12.
Теперь предположим, что код одной из букв (например, В) состоит из двух цифр.
Тогда Г нужно закодировать не меньше чем тремя цифрами (иначе будет нарушено условие Фано), а для кодирования Д и Е потребуется 4 цифры.
Поясним вышесказанное на примере.
Пусть код В = 10. Тогда Г кодируем как 110 или 111, для определённости, Г = 110.
Тогда коды Д и Е начинаются с 111:
Д = 1110, Е = 1111.
Итого 2 + 3 + 4 + 4 = 13.
Чтобы далеко не посылать.
Первые два load-а читают посимвольно из-за того, что не знают, сколько там данных. Это также вызывает постоянные реаллокации приёмного буфера. Вторые два load-а читают скопом весь файл, заранее сконфигурировав приёмный буфер на требуемый размер. Что-то это мне напоминает... Ах да, std::vector vs T*. Ну разве не прелесть.
Да, надо свое мутить! Хотя есть задачи и по важнее. Например "окроссплатформить" чтение/запись в файл по позиционированию по off_t для x32/64.
Я бы не стал доверять программе, написанной в нарушение Стандарта и неверно считающей оверхед. Совсем не верно. Вообще.
Чтобы далеко не посылать.
Первые два load-а читают посимвольно из-за того, что не знают, сколько там данных. Это также вызывает постоянные реаллокации приёмного буфера. Вторые два load-а читают скопом весь файл, заранее сконфигурировав приёмный буфер на требуемый размер. Что-то это мне напоминает... Ах да, std::vector vs T*. Ну разве не прелесть.
Добавлено
Быстренько налобал правильный тест. Теперь все load-ы читают посимвольно в буфер достаточного размера. Полюбуйтесь:
Дык он тоже весь на finally. Там практически ничего без SEH написать невозможно, течь будет из всех щелей контрактов. Посмотри на нормальные Плюсовые сырцы: catch редки, а если и встречаются, то внутри реализаций.
А вот в случае когда нужен скоуп владеющий ресурсом, RAII зачастую совершенно излишен.
Вот. Собственно это и есть тот критерий, который оправдано можно закостылить scope()ом... но вдруг и внезапно – скоуп может захотеть владеть разными ресурсами, в разном количестве и с разной стратегией владения. Ну и получите и распишитесь, получили такой маленький упсик. Собственно, всё равно владельцем выступает программист, а скоуп просто выступает в роли послушного исполнителя твоей воли. Ибо дашь ему неверные инструкции, он и исполнит их неверно, а давать приходится постоянно, пусть и одни и те же. В RAII инструкции даются один раз, и они всегда одинаковые. Может быть иногда и не удобно, но всегда надёжно.
Не путай с автоматическим контролем и исполнением инвариантов. Исполнение данных тобой инструкций – да, автоматическое. С этим и __attribute__((__cleanup__())) справляется. Интересно, почему его не включали в Стандарт C? Это же так удобно, по твоим словам.
Но я привожу примеры, где scope(exit) проще и понятнее и не менее безопасно, чем RAII.
Пока у тебя не получилось :)
Цитата
scope это скорее про try/catch/finally.
Можно согласиться, что defer/scope(exit) лучше finally(хотя и не сильно).
Но еще лучше using/with/try-with-resources. Тем, что не нужно каждый раз указывать действие по освобождению.
На том же уровне with*-функции. ИМХО, их сложнее "забыть" использовать плюс они реализуются без изменения языка(как и RAII), что тоже плюс.
Но RAII выигрывает и у них. Хотя бы тем, что может быть точно так же использован для полей структуры/класса.
Ты сам сказал, что если убрать совсем scope(exit), то программа станет корректной. А ведь в этом случае TTF_Quit не будт вызван вообще. Из твоих же слов следует, что вызов TTF_Quit лишний.
Я тебе это говорил в контексте правильности/неправильности такого подхода на плюсах, чтоб обратить твое внимание на GC.
Чувак по незнанию неверно оценил ситуацию, он написал:
Цитата
AFTER the scope(exit) statements
А точнее было бы написать
Цитата
AFTER exit from the function scope
scope(exit) никак не влияет на порядок вызовов деструкторов объектов на куче.
Он как раз все верно оценил, если я правильно понял что там произошло. Ты же видишь в его примере просто надпись в консоль выводится? У него вывелось:
scope exit
De
De
А произошло это из за того, что после выхода из функции - не отработал деструктор De, который написан перед scope(exit), этот деструктор отработал в тот момент, когда GC начал подчищать ресурсы, а ресурсы в его случае он начал подчищать, когда он нажал на кнопку Закрыть.
сам по себе scope(exit) - Не влияет на порядок вызовов деструкторов, я нигде не утверждал что он влияет. Но используя этот scope(exit) - можно нарваться вот на такие грабли, как у чувака, вот об этом я и написал.
Напиши scope(exit) delete(ptr) и бага не будет. По-твоему написать целую обертку гораздо проще, чем написать вот эту одну строчку, с учетом того что эта обертка будет использована ровно ОДИН раз?
Ну да, нахер юзать все эти RAII в плюсах. Вот дебилы, правда? че сложно написать delete ptr - где это нужно.
По моему, обертку писать не нужно вообще. Это ты придумал. Я предлагал юзать unique_ptr, если тебе хочется сделать вот именно так, а никак иначе.
Очередной ошибочный вывод. Нет не только в исключениях. Также разница в ранних return, в том что код освобождения ресурса пишется прямо рядом с его захватом (прямо как твой любимый unique_ptr с кастомным деструктром, только гораздо опрятнее), ну и если таких мест несколько, то освобождение ресурсов будет выполнено автоматически в порядке обратном захвату. В сяшке ничего этого нет.
В Сяшке ровно тот же механизм, только вид с боку. Когда ты юзаешь мой любимый unique_ptr, то это полноценная RAII обертка, и она лишена практически всех недостатков. Например что будет у тебя, если во время выделения ресурса произойдет исключение? Будет очищать ресурс, который не существует?
Неверно, scope(...) введен в язык для автоматического вызова кода при выходе из скоупа. А при работе с GC ресурсы обычно освобождаются самим GC. Накой там scope(...)?
На той же на кой finally в языках с GC существует. Расскажи, как ты закроешь сетевое соединение например по выходу из функции, если объект создается на куче? Да ты же бля напишешь scope(exit), ты уже приводил даже этот пример с PQExec :D
Тебя трудно понять, Киля. Ты применяешь какие-то определения, выдавая их за общепринятые и потом тебя не понимают. Видимо ты имеешь в виду конструкцию, которую в C# называют try-catch-finally. Ну так ты опять ошибся, так как finally вполне можно написать без try-catch, а именно try-finally без catch.
Ты как раз таки все понял, просто тебе видимо потроллить хочеца. Я слышал в Java его частенько называют именно так. И название идет от полной конструкции. Finally не фигурирует сам по себе. Так что ты тоже ошибся выходит, если цеплятся к словам, как ты любишь ;)
Ты привел пример, в котором RAII вполне уместен. Но я таки напишу специально для тебя все это дело в функциональном стиле без всякого RAII, но со scope(exit), дабы, так сказать, расширить твой и не только твой кругозор
Угумс, я уже видел похожее на шарпах, когда двухсотстрочная портянка оформлена в подобном виде! Очень удобно
Там это к слову очень сильно распространено. Делегаты называется.
Он ожидает что у него отработает деструктор его класса De, в котором он вызывает TTF_CloseFont, а после него scope(exit) - который вызывает TTF_Quit. Но из за того что память под класс он выделил на хипе, у него вызывается сначало scope(exit) с TTF_Quit, а после отрабатывает деструктор класса De, в котором вызывается TTF_CloseFont. Где тут лишний вызов то?
Ты сам сказал, что если убрать совсем scope(exit), то программа станет корректной. А ведь в этом случае TTF_Quit не будт вызван вообще. Из твоих же слов следует, что вызов TTF_Quit лишний.
Чувак по незнанию неверно оценил ситуацию, он написал:
Цитата
AFTER the scope(exit) statements
А точнее было бы написать
Цитата
AFTER exit from the function scope
scope(exit) никак не влияет на порядок вызовов деструкторов объектов на куче.
Вот именно. Поэтому ты без задней мысли будешь думать что ошибки у тебя нет. А в плюсах это баг априори. Соответственно ты ничего не будешь ждать, ты напишешь RAII обертку, и бага не будет.
Напиши scope(exit) delete(ptr) и бага не будет. По-твоему написать целую обертку гораздо проще, чем написать вот эту одну строчку, с учетом того что эта обертка будет использована ровно ОДИН раз?
Это же Си, там нет исключений! Если разница только в исключениях, то твоей пример ничем не отличается от сишного кода. А объяснять что подход с RAII лучше, чем Сишный нужно? Или ты и так знаешь?
Очередной ошибочный вывод. Нет не только в исключениях. Также разница в ранних return, в том что код освобождения ресурса пишется прямо рядом с его захватом (прямо как твой любимый unique_ptr с кастомным деструктром, только гораздо опрятнее), ну и если таких мест несколько, то освобождение ресурсов будет выполнено автоматически в порядке обратном захвату. В сяшке ничего этого нет.
Ну а goto делает переход, например в конец функции. Ты представляешь этот scope(exit) - как какую то супер пупер фичу, на деле - это обычный костыль, судя по всему введен в язык исключительно с целью освобождения ресурсов при работе с GC. Это единственно верное его предназначение. Но ты выдаешь его зачем то за какую то конфетку
Неверно, scope(...) введен в язык для автоматического вызова кода при выходе из скоупа. А при работе с GC ресурсы обычно освобождаются самим GC. Накой там scope(...)?
Поясняю - я имел ввиду try/catch/finally, а не finally. На всякий случай посоветую тебе, ты прежде чем отвечать на это, загугли про это и почитай что такое finally и как оно используется в языках с GC JAVA/C#. Потом уже отвечай.
Я не знаю как там в вашем D, но вообще конструкция try/catch/finally судя по всему родилась где то в Java, И вот этот finally - является не отъемлемой частью try/catch/finally, нельзя его написать без try/catch.
Тебя трудно понять, Киля. Ты применяешь какие-то определения, выдавая их за общепринятые и потом тебя не понимают. Видимо ты имеешь в виду конструкцию, которую в C# называют try-catch-finally. Ну так ты опять ошибся, так как finally вполне можно написать без try-catch, а именно try-finally без catch.
Ну посмотри на класс std::fstream - обычная RAII Обертка над FILE* дескриптором. В 10 разных местах я хочу юзать вот эти функции, ну например у меня есть 10 кнопок, и в каждом обработчике я хочу производить вот примерно такие действия, разные и в разной последовательности, допустим в обработчике одной кнопки только читаем, во второй читаем и пишем, в третьей читаем, создаем новый файл в него пишем и т.д.. Т.е. мне нужны какие то функции или что ты там сделаешь, за которыми мне потом не надо подчищать, они же сами все сделают.
Вообще не парься, у тебя не получится это сделать со scope(exit), либо получится говно какое то, в итоге ты просто напишешь RAII обертку. Что собственно и требовалось доказать.
Ты привел пример, в котором RAII вполне уместен. Но я таки напишу специально для тебя все это дело в функциональном стиле без всякого RAII, но со scope(exit), дабы, так сказать, расширить твой и не только твой кругозор :)
swf: ЕГЭ по информатике 2020, вариант Москва
Булевы алгебры логики, логические функции
Часть 1, № 2
Задание взято с сайта http://kotolis.ru/realegeinf_2020
Решение. Из второй полностью заполненной строчки таблицы истинности определяем, что переменная 3 = y = 1.
(Как мы это узнали.
w не может иметь значение 1, потому что иначе not w = 0 и всё выражение обращается в ложь.
Если z = 1, то и x = 0, и y = 0, соответственно, (x или y) тоже 0, а должно быть 1.
Если x = 1, то и y = 0, и z = 0, соответственно, тождественность y и z даёт 1, отрицание тождественности - 0.
Поэтому остаётся ровно один вариант: y = 1.)
Из третьей строчки таблицы следует, что при y = 0 значение z должно быть равно 1 (y и z должны иметь противоположные значения).
Поэтому z либо переменная 1, либо переменная 2.
Поскольку строчки в таблице не должны совпадать, а в первой строчке переменная 1 = 1, то вначале предположим, что z = переменная 2 = 1.
Получили xzyw: ?100 -> 1 (со значением true.)
Определим значение x. Так как y = 0, то x = 1, чтобы выражение (x или y) обращалось в истину.
xzyw: 1100 -> 1.
Теперь проверим, можно ли для такой последовательности переменных получить неповторяющуюся первую строчку.
Если и x = 1, и y =1, то снова получим третью строчку.
Поэтому x = 1, y = 0. Тогда z = 1 и w = 0:
xzyw: 1010 -> 1.
applegame: использовать scope(exit) в качестве иммитации RAII действительно глупо. Но бывают случаи где сия конструкция вполне уместна. Например, я писал обертку для постгресовской родной либы libpq. Она написана на сяшке (как и весь постгрескуль). Там память захватывается самой либой, а освобождается уже клинтским кодом путем вызова соответствующей функции. Это освобождение в моей обертке фигурировало буквально внутри одной функции. Я использовал там scope(exit) так как посчитал абсолютно бесполезным городить отдельный класс вместо одной сраной строчки: scope(exit) PQfree(res).
Кроме того scope(exit) можно применять не только для освобождения ресурсов. Я пихал в него временный отладочный код вроде изменения счетчиков и всяких логов.
Хотя есть задачи и по важнее. Например "окроссплатформить" чтение/запись в файл по позиционированию по off_t для x32/64. 
