Pull to refresh

Comments 183

Если правильный ответ не 100, пожалуй, я не буду заниматься программированием :)
Ну, не стоит так категорично… 4 взрослых гуру c++ дали неправильный ответ… это никак не должно затрагивать ваши способности к программированию.
Может быть стоит и категорично.

Не знать про триграфы — это допустимо (я вот тоже про них не знал, правда я и не Си-программист). Но не знать, что выводов тут 1+10x10 — это не здорово :)
Да пропустил просто одну строчку, первую… Это на внимание.
Вы пропустили строчку после
int i = 10;
Но не в ней проблема :)
жесть) вот я ее и пропустил)
пока не закончится диапазон числа int
хотя если учесть что забыл я С++ и 0 означает false
тогда 111 :)
мда 101 всетаки :)
Поддерживаю, я конечно не проверял в компиляторах, но нормальный компилятор С++ должен выдать фразу 101 раз.
Тоже так подумал.
UFO just landed and posted this here
Мне тоже сначала показалось что 91, хотя сюда по ответам, таки 101.
Нет меня чет сглючило, там сто пудов 101.
Хм, а как же ще? Мне сперва показалось что там стоит while(--i), тогда бы получилось 91, а так других вариантов кроме 101 не вижу. Очень хочется услышать правильный ответ.
Обязательно услышите, немного терпения
Что-то я опять за сомневался в своем ответе. Таки по логике 91. Только сейчас начал понимать, почему в питоне подобные финты запрещены, они сильно вводят в заблуждение.
Если очень хочется, почему бы не откомпилировать и не запустить?
Обоснование:
Сначала вычисляется логическое выражение в скобках, т. е. во время первой итерации i=9, пока i не равно нулю, пройдёт 9 итераций по 10 выводов «Hello world» прибавляем первый вывод, получаем 91.
Во время первой итерации i=10 (так как используется не --i, а i--)
Обоснование: 1 строка при запуске + 10x10 строк в циклах («while (0)» не запустится ;) )
к сожалению не правильный ответ. Но, поверьте, это самое распространенное рассуждение ;)
int main(int argc, char* argv[])
{
int i = 10,k=0;
std::cout<<"Hello World!"<<++k<<std::endl;
// Сколько раз???
while(i--)
{
// Сколько раз будет вызвана эта строка???/
for(int j=0; j<10; j++)
std::cout<<"Hello World!"<<++k<<std::endl;
}
return 0;
}

первая строка «Hello World!1», последняя «Hello World!101». В чем прикол?
я уверен, что не у всех так :)
ArchLinux, gnu g++
Windows, DevCPP (Mingw port of GCC)
ок, видимо gcc (в чем я не сомневался) молодец ;)
Можно поинтересоваться каким компилятором вы пользовались при проверке?
101 — мозговым компилятором
там ведь интерпретатор!
кстати, префиксная и постфиксная декриментация — разные вещи ;) мб ваш компилятор считает i-- префиксным, и тогда выходит 91
Это i-- префиксный? Какой тогда --i? :)
мб = может быть. Разные авторы компиляторов, разные стандарты, разные ошибки, в конце концов.

P.S.:
i = 10; x = --i // i = 9; x = 9 постфиксное декриментирование
i = 10; x = i-- // i = 9; x = 10 постфиксное декриментирование
твою налево — первый префиксный (вот и у меня косяк случился — почему у компиляторов не может их быть, их же люди делали)
Первое префиксное. Сначала декремент, потом вычисление.

* уменьшаем i
* присваиваем x = результат

Второе постфиксное:

*присваеваем x = результат (который ещё 10)
*уменьшаем i
>Второе постфиксное:
>*присваеваем x = результат (который ещё 10)
>*уменьшаем i

Это не так. Порядок операций декремента и присваивавния будет как в первом случае, вот только результат будет другим. Т. е.
• уменьшаем i
• присваеваем x = результат (который ещё 10)

Вопрос на засыпку: всегда ли можно заменить вызов функции «statement(i++);» на «statement(i); ++i;»?
Ламерам, ставящим минус, предлагается для начала Саттера хоть почитать, что ли.

А ещё лучше написать свой тестовый класс-обёртку над int. Определить оператор присваивания и постинкремент с обычной семантикой, которые печатают лог в консоль. И выяснить, что присваивание раньше инкремента вызвано никак не будет.

Это здесь вы мне сейчас минус ставите, вместо того, чтобы разобраться с вопросом. А попадёте мне на собеседование — я вам минусы буду ставить.
10 раз по 10 итераций, плюс одна в начале.
Значит фишка во while и постфиксном декременте. 9 по 10 раз плюс одна в начале, 91.
Здесь не будет разницы между --i и i--, мы все равно выполняемся по конечному результату, насколько я понимаю.
Если не трудно, обоснуйте свой ответ комментарием к своему ответу (сумбурно как то, но думаю вы поняли ;)
А зацикливания не будет?
while(i--) когда нибудь вернет false?
Вернет, декремент же
Ясною Странно как то, нелогично.
Вот чую я что: for(int j=0; j<10; j++) даст не 10, а 11 итераций почему-то.
Данная конструкция выполнит ровно 10 итераций (от 0 до 9 включительно)
Сорри, больше не буду =(
Пред-условие i-- т. е. на 1-м же этапе уже i=9…
ваше условие бы выполнялось, если был не пост-декремент, а пре-декремент (--i)
не значит, я же прошу обосновать…
while(i--) будет выполняться пока i истинно и будет 9 циклов. Так как
1. постфиксная запись декримента
2. когла i будет равен 0 тогда условие будет ложным и цикл не выполнится 10-й раз.
блин) обратный отсчет начинается с 10 не учел) тогда 9+1

итого 101
Тогда должно быть --i. C++ в этом плане хитрая штука.
ну тут while(i--) будет выполняться пока i истинно и будет 9 циклов. Хотя тут сомнения может даже и 81 раз покажет.
#include int main(int argc, char* argv[])
{
int i = 10, k = 0;
//std::cout<<"Hello World!"<<std::endl;
k++;

// Сколько раз???
while(i--)
{
// Сколько раз будет вызвана эта строка???/
for(int j=0; j<10; j++)
//std::cout<<"Hello World!"<<std::endl;
k++;
}

std::cout << k << std::endl;
return 0;
}

Выводит на экран 101. В общем-то, как и ожидалось :).
извиняюсь, кусок кода съел парсер :(. На первой строчке #include <iostream>, а потом уже int, конечно же :)
Если честно — то это уже тест реализации компиляторов с plus plus — раз начали такую простую задачу исполнять компиляторами.
А вот автора приведшего такой код я завалил бы на собеседовании — так как постинкремент/декремент себя ведет это понятно, а что считается ИСТИНОЙ или ЛОЖЬЮ — это уже гораздо большой вопрос к его разработчикам.
Не совсем понял про «что считается ИСТИНОЙ или ЛОЖЬЮ». Если можно на примере представленного кода.
Что в данном случае не так?
то что многим и мне в том числе не нравиться в с++ — приравнивание 0(нуль) к false (ложь)
Согласен, в том же c# нужно использовать именно оператор сравнения, а такая коснтрукция просто не пройдет…

PS А по-поводу «завалил бы на собеседовании» не совсем ясно ;)
Ну прет некоторых. «Вот я бы у себя на кафедре тебе 4 не поставил». Или «вот при приеме на работу, я бы тебя завалили интеллектом, просто потому что настроение плохое» Этакое невзначайное показательное проявление власти и интеллекта в одном невзрачном предложении, не обращайте внимания) Задачка клевая, еще на втором курсе препод на нее ловил, лучшие умы матерились и плевались )
Ну конечно же такая конструкция пройдёт, надо только написать ее немного более явно:

while (Convert.ToBoolean(i--))
{

}
А вот в контору, где человек, проводящий собеседование, не знает что в цпп считается истиной, а что ложью, я бы не пошёл. Открою вам страшную цпп-шную тайну — от компилятора это не зависит.
Идея заключается в том, что в ряде систем (не в Си ПП) действительно приняты другие значения int для истины и ложи. Банальный пример — MS Access, где истина — это 0, а ложь — -1.
Если я устраиваюсь на должность плюсового программиста, то мне дела нет до того безумства, которое придумали разработчики акцесса. Аффтар комментария написал, что он бы завалил претендента на этом и что это якобы зависит от разработчкиков компилятора конкретно цпп. Вот я и говорю, в контору, где такие профаны проводят технические собеседования идти явно не стОит. :)
Простите, а мне нет безумства до того дела, как в том или инном компиляторе, или фреймворке реализуеться булевские типы. Я программирую и под Windows и под Mac OS X, так коды ошибок и их формирование различаеться рказительно. Я бы предпочел писать человеческий while или for, вместо того, безобразия, что написано в примере.
Нежелание учиться и читать документацию не говорит о вас ничего хорошего как о специалисте. Это не особенность компилятора или платформы. Это спецификация языка. Инвариант во всех возможных реализациях.
Что касается «человеческого»… Меня удивляют люди, способные написать пол-страницы бессмысленного текста только потому, что не осилили учебник дальше второй страницы. _Это_ в си и сипипи — идиоматическое выражение. Выросло поколение программистов, которые этого не знают? Вот если бы я проводил собеседования по кандидатам на сипипи, то точно завалил бы человека, не знающего и не понимающего этого. А! «Пхп-программисты»? :)
Про нежелание учиться вы взяли с потолка, я говорю, что я не обязан знать, что к примеру E_FILE_NOT_FOUND — 0x80041003. Такие элементарные вещи я знаю, а про триграф прочел два года назад у Саттера, однако дело не в этом. Если бы я проводил собеседование по С++, я бы точно не стал валить человека из-за такой чуши, потому что я не самоутверждаюсь, когда задаю вопросы. Цель — узнать уровень человека, его натуру, природу, область знаний, присутствие аналитического мышления, а всякие элементарные вещички — забываються в процессе их не использования. Их мозг попросту вычеркивает, когда каждый день вы пихаете в голову огромное количество материала, который необходимо освоить по работе. А о тех, кто пытается завалить человека на таком элементарном действии я могу подумать только одно «Видимо более толкого ничего спросить не может». Лично я предпочитаю услышать на собеседовании вопрос «Какие методы перехвата API функций вы знаете», чем «Отстортируйте пожалуйста массив методом вставки»…
В Obj C например вообще нет булевского типа, его реализует самостоятельно, тем не менее Obj C — это надмножество над языком С (хотя в нем булевского типа тоже нет...). Человек, который является не только узкоспециализированным специалистом (я считаю, что человек всегда обязан постигать что-то новое, иначе он остановиться в развитии и начнет деградировать), всегда может забыть что-то элементарное или спутать его с чем-то. А код, подобный тому, что дан в примере, я всегда рефакторю, когда вижу…
Ну и последнее, что я хотел сказать. Да, каюсь, я не помню такие вещи из стандарта языка, как частичная инстанциация шаблонов, и вообще многое о шаблонах, и не помню многое из книги Александреску, просто потому, что я НЕ ИСПОЛЬЗОВАЛ это уже как два года. Однако два года назад все эти вещи отскакивали у меня от языка, и по знаниям плюсов, и всяких заковыристых штучек я мог бы дать фору любому Сеньйору. Однако это вовсе не говорит о том, что раньше я был лучшим программистом, скорее наоборот.

Вот потому всякие штуки касательно языка, особенности, мелочи, и прочие Exceptional вещи стоит спрашивать у джуниоров, просто потому, что более у них нечего спросить, опыта у них нет, и оценить их как специалистов — очень сложно. Человек, которые поработал в отрасли професионально, просто не допускает вещей, который могут приводить ко всяким Undefined Behaviour и прочим прелестям, просто потому, что эта привычка выработалась на интуитивном уровне. Из своего богатого опыта багфиксинга в С++ проектах, могу сказать, что баги из-за элементарных ошибок — это ну 10%, и их очень легко обнаружить, или пофиксить во время рефакторинга или Code Review. А вот кривое проектирование, или обильное использование тех же шаблонов — это действительно Pain In the ass, и отлаживать это очень сложно.

Есть конечно же фанбои языка, которые в 40 лет способны помнить такие вещички, что сам Саттер позавидует, но я видимо не из таких, и меня больше интересуют прикладные направления.
Мне кажется, спор изначально шел об актуальности писать


while (i--)


а не


while (i-- != 0)


Так вот это человек должен знать и через 2, и через 5 лет. Это азы, основа, идея языка. Именно это обеспечивает легкость кода, которая в С максимальна и прекрасна.
А по поводу триграфов и соотношения умения к знанию мелочей Вы, безусловно, правы.
>А код, подобный тому, что дан в примере, я всегда рефакторю, когда вижу…

Интересно, на что?
На
while ( i != 0) {
i = i — 1; // а вдруг вы позабудете как работает оператор декремента

?
Вы взаправду считаете, что этот проще для понимания? А вдруг вы позабудете что делает операция "!="? Ведь всегда можно забыть что-то элементарное, ага? А вдруг вы позабудите, как работает оператор while? Тогда как?
start_of_loop_345:
if ( i
Я предпочитаю для быстроты понимания for, так как он четко отображает границы цикла, и при применении префиксного декримента (--i) по скорости работы не уступает while. Ну а чтобы позабыть как работают операторы — это не знаю, нужно лет 10 не программировать, так как по-сути операторы одни и те же во всех языках, но различаются семантикой.
Сожрался кусок…
start_of_loop_345:
if ( i <= 0 ) {
goto end_of_loop_345;
}
i = i-1;

goto start_of_loop_345;
end_of_loop_345:

:) Тоже прикольно, только зачем тогда вообще изучать языки высокого уровня?
>я не обязан знать, что к примеру E_FILE_NOT_FOUND — 0x80041003
Угу. На то они и константы, чтобы не запоминать их численное значение. Но речь совсем не об этом.

>а про триграф
А речь не про триграфы. Это забавный анахронизм. В номальных компиляторах по умолчанию уже отключён.

>Лично я предпочитаю услышать на собеседовании вопрос «Какие методы перехвата API функций вы знаете»
По-моему, как раз этот вопрос ни чем не отличается от вопроса, — «каково численное значение константы E_FILE_NOT_FOUND». Тупая зубрёжка апи. Где здесь натура человека, природа, область знаний, аналитическое мышление? Где?

>чем «Отстортируйте пожалуйста массив методом вставки»
Ну, вот этот вопрос, конечно, слишком простой, но он, хотя бы, чуть-чуть про аналитическое мышление :). Немного интереснее вопрос, — «напишите бинарный поиск», — почти все далают ошибки.
> Тупая зубрёжка апи. Где здесь натура человека, природа, область знаний, аналитическое мышление? Где?

Я c вами не согласен. Этот вопрос отображает опыт человека, хоть как-то, а подобные задачки типа сортировки или поиска делением пополам все когда-то решали будучи в институте, т. е. если это нужно будет, и если человек этого не знает, то алгоритм гуглиться в течении 5 минут, и применяется к конкретной ситуации. Конечно, кто-то может возразить, что это не правильно, но я считаю, что лучше уметь правильно применить существующий алгоритм, чем по памяти сделать неправильно :)
Так ведь и методы перехвата гуглятся на раз. Тут речь о другом — поскольку почти все далают ошибку в поиске пополам, это повод узнать как человек будет искать и исправлять ошибку. Либо как доказывать что его алгоритм реализован правильно. Вот вам и природа, натура и мышление. А какую информацию о человеке вы получите от перечисления тупо заученых методов? Что человек их тупо заучил?
Как о человеке — да никакую, но я я говорил о другом, что сам предпочитаю получать такие вопросы на собеседовании ;) О психологии человека точнее может сказать HR, а я как человек воспринимаю другого человека по моторике, невербальном общении и характеристикам его речи.

К слову сказать, почему-то все компании взяли за правило при приеме на работу, давать распечатаные тесты с БреинБенча advanced level, и потом проводить техническое собеседование по конкретным прикладным направлениям…

Если речь зашла о бинарном поиске, какую же ошибку все допускают в сравнительно простом алгоритма, если не секрет?
Попробуйте написать бинарный поиск, узнаете какую ошибку делют :). Лучше на бумажке сначала, а потом прогоните юнит-тесты. С пересчётом границ, разумеется, ошибки. Что ведёт либо к зацикливанию, либо к пропуску значений — смотря в какую сторону ошиблись. Утверждают, что реализация двоичного поиска не содержащая ошибок исторически появилась лет через пять — десять, после публикации алгоритма :). Сам по себе факт ошибки в этом алгоритме, конечно, большой полезной информации не несёт, интересна, как я уже написал, реакция.
На самом деле, мне ближе всего однажды описаный здесь на хабре подход к техническим собеседованиям — всё что нужно понять — может ли человек программировать или нет. В концептуальном смысле. А на этот вопрос, как раз несложные алгоритмические задачки позволяют получить ответ. Если да, то всякие там тонкости апи конкретных платформ — это дело десяток и двадцатое, — зачем это учить, если это всё есть в справочнике и в гугле. Это для начинающих. А для «продолжающих»,… ну, не знаю, опыт описан в резюме. Пять лет назад (два года, год, даже пол-года назад) я работал с иными вещами, нежели сейчас. Спросить меня про апи и библиотеки тех времён разработки — ничего на отвечу.
С этим не поспоришь, но обсуждения вилки зарплат, без детального собеседования по прикладным направлениям — не возможно :)
Запустил в 2008 студии, прифигел.
Расскажите в чём прикол, или я что-то не заметил? %)
А что выдала 2008 студия, если не секрет? :)
секрет ))) надо уповать на собственный мозг
Секрет :)
А вот в гсс, всё нормально работает, как и должно быть — 101.
Что за задача такая, если решение зависит от компилятора?
Ну такая вот задачка… как же её еще назвать?
Спасибо за задачку. Супер, блин!!!
Если бы такой баг где-нибудь в проекте зарылся стоило бы вешаться %)
101

люблю c++, а в особенности озадачивать подобными алгоритмами преподов =)
Мне кажется, что студенту лучше учиться, нежели под*бать препода. Преподаватели тоже люди, и могут чего-то не знать
UFO just landed and posted this here
потерпите, правильный ответ требует небольшой подготовки материала…
Данный код как оказалось, ведет себя иначе (читай нормально) при компилировании с GCC
за меня думает интерпретатор/компилятор
gcc-4.2.4 (linux) — 101
mingw gcc port (windows) — 101
msvc 2005 — 11
Хотя если не просто перенести код из примера, а переписать ручками 1 в 1 и в msvc получилось 101.
Смутило вот это при компиляции «Warning 1 warning C4010: single-line comment contains line-continuation character c:\Documents and Settings\Koric\Мои документы\Visual Studio 2005\Projects\Test\Test\main.cpp 12
»
ну это собственно оно и есть…
тогда могу предположить, что причина в комментарии
" // Сколько раз будет вызвана эта строка???/",
в конце которого содержится символ перевода строки.

Таким образом строчка с for тоже будет куском строчного (!) комментария => цикл for выполняться не будет => 1 вывод + 10 итераций while

А препроцессор gcc вырезает все комментарии до компиляции
Совершенно верно, именно и дело в комментарии, так как там используется триграф ??/
Вот кстати это очень интересно — вырезает ли компилятор комментарии до компиляции или он просто игнорирует триграфы?
кстати не вырезает gcc комментарии… он явно предупреждает пользователя что мол, используются триграфы и я их отключил…

g++ app.cpp
app.cpp:26:73: warning: trigraph ??/ ignored, use -trigraphs to enable
система Arch Linux, компилятор GCC 4.3.2
При явном указании стандарта -std=c++98 таки меняет ??/ на \, и даёт соответственно 2 ворнинга
some.cc:11:78: warning: trigraph ??/ converted to \
some.cc:11:7: warning: multi-line comment

Вот это поворот событий, такого меньше всего ожидал. Это выдуманная ситуация или реально такой баг попался?
Такого, слава богу, не попадалось… Тем не менее, ситуация вполне может произойти, например, в качестве злой шутки…
Для того, чтобы таких злых шуток не было нужно использовать -Wtrigraphs -Werror… Как у нас и сделано :-)
а вот это реальный баг из той же серии
insomniacgames.com/tech/articles/0807/ahairtearingoutbug.php
А, понял. А разве там можно их оставлять?
Мда. Выходит, Майкрософту — можно.
msvc 2008 — 11

Ну раз уж ответы пошли.
В пятницу, да вечером… Жестокий человек…
Я правильно понял, что весь прикол вот здесь?
"// Сколько раз будет вызвана эта строка???/"
В последнем слеше?
11 раз получилось со слешем и 101 без :)
именно так (пост обновил, ответ там)
Ну и да, ответ будет разным в зависимости от компилятора (101 либо 21)


откуда 21? должно же быть 11 вроде
Да, не 21 а 11… пока печатал, задумался, моя вина ;)
во первый почему 21?
101 (1 + 10*10) и 11 (1 + 10)
Опечатался, 11 конечно…
В режиме соответствия стандарту GCC включает поддержку триграфов.
Вот вот, скорее бы новый стандарт приняли…
UFO just landed and posted this here
А я веб-разработчик, коих многие считают «недопрограммистами», но, судя по комментариям, кхе-кхе… даже не знаю что сказать )
))) «вот такое вот хреновое лето»
+1, — базис кодера, диплом кодера, а сам админ.
я вот тоже читаю комментарии и удивляюсь. Здесь программистких навыков-то и не нужно, обычная логика, будь-то си++ или псевдокод.
Вот если честно, 111 может получиться только из-за невнимательности, как у меня :) Я посчитал, 101. триграф кстати заметил, о них читал в свое время у Саттера. А потом сам себе злой буратино думаю «Постойте, но что будет на последней итерации, когда будет 1? Правильно, он сначала пройдет в цикл, а потом сделает декремент!» и вот тут-то логика дала сбой. В общем с подколом задачка.
И при этом VS не раскрашивает код соответственно поддерживаемой функции?

Надо будет преподавателю, который Си предпочитает, показать, вдруг не знает, интересно как он выглядит в заблуждении=)
Спасибо за интересный миниурок.
а как бы вы выглядели на его месте? я думаю точно так же — не ловко.
Хорошая идея. Ему, видимо, также будет интересно, как вы выглядете во время сдачи сессии.
Хорошая задачка. По сути наглядно, на пальцах показавшая, как можно глупыми вкраплениями изуродовать мощный промышленный язык, сделав его неподконтрольным даже для сильных разработчиков. Грустно. Да.
В Паскале эта проблема решена аккуратнее. Вместо квадратных скобок, к примеру, можно писать "(." и ".)", но это распознается на уровне токенов, а не заменяется где попало.
Про триграфы знал из «Дизайн и эволюция C++»,

Отвечу на вопрос:
// Сколько раз будет вызвана эта строка???/

Ответ — нисколько, строчка с комментариями игнорируется программой, а вот следующая строчка…
сидел и вмыкал всё утро, как народ 101 получает, или 11, ппц какой-то
потом уже увидел, что ещё раз вывод строки вначале
Он как раз, чтобы отвлечь внимание от более существенной вещи — триграфа :).
$ g++ 1.cpp
1.cpp:11:47: warning: trigraph ??/ ignored, use -trigraphs to enable
Это о сказках про «несовместимость».
Автору спасибо (в карму) за триграфы. Добавлю пожалуй в избранное.
101 конечно. 2 цикла по 10 и 1 раз в начале. посчитал моском.

удивлен до крайности что столько комментов…
А вот Visual c++ с вами не согласен)
>А вот Visual c++ с вами не согласен)
то это проблема мс-кого компилятора.
10 на 10, и плюс 1. всегда буит 101 )
«Таким образом следующая за триграфом ??/ строка будет добавлена к комментарию (действие „\“ обратного слеша)».
Вот Visual C++ и хавает следующую строку с циклом. И получается 11. Не думаю, что это большая проблема.
Фиг с ними с триграфами, но чтобы столько сразу людей на хабре (!) не знало самых основ языка C…
Хочется прям грубо спросить, ребята, что вы тут делаете со своими 100, 91 и прочими бесконечными циклами?
Вы откуда, из 1С?
Стыдно.

Задачку (вариант без триграфов, т. к. у меня java и суть не в этом) запомню на будущее для собеседований. Кто не решит, того можно смело гнать сцаными тряпками и дальше не разговаривать ;)
Не согласен, иногда даже в простой задачке по перестановке символов в строке местами, из-за волнения можно сделать промашку и пустить цикл на лишнюю итерацию. Однако из этого ничего не следует. На собеседовании в мою текущую компанию, я так и ступил, однако меня взяли. И не из-за того, что брать некого было, а из-за того, что по результатам собеседования (на котором были 6(!) человек, не более 4 одновременно), я показал свои знания и то, что подобная хрень со строками — мало играет роли :)
А вы может толкового человека будете гнать. Ну что ж, удачи вам ;)
Насчёт нервов — согласен.
Ну хорошо, у меня есть ещё одна задачка для проверки на вшивость, которая пока не подводила.
Будем юзать их в тандеме ;)
Такую задачу на java перенести можно только с корректировкой, Так как while(i--) выдаст ошибку при компиляции — целочисленный тип к логическому привести нельзя
UFO just landed and posted this here
Мне даже ответить нечего вам, я не HR.
Я бы и уволился, если бы мой ответ был 90 или ещё какой-то бред в этом роде — без триграфов это задача на тупость, не более.
Слушайте, вы хабракатом просто так вот зарезали девяносто далматинцев?!
Поясните, каким образом?
Очень просто =) Когда я прочитала текст до хабраката — были живы все 101 (хоть и было понятно, что будь так, этого топика бы не было), после осталось только одиннадцать и ассоциации с далматинцами стали неактуальны :)
Не сколько. Забыли include;)
Я поправлю ради вас ;)
Еще есть похожая штука — диграфы. Они полезны, если надо сделать код с хитростями подобно вышеприведенному ( например " i = 42<:p:>; " ). В отличие от триграфов, gcc даже предупреждения не выдает. Я погорел однажды на инстанцировании шаблона классом из глобального пространства имен, написав примерно так: Myclass<::poi> q;
UFO just landed and posted this here
Триграфы удобно использовать в соревнованиях типаIOCCC. Код сразу же теряет привычную читабельность.
Sign up to leave a comment.

Articles