Почему шарп не хочешь?
Потому что не хочу заниматься тупыми задачами.
Я как-то сходил на собеседование. Меня там минут 30 спрашивали о какой-то ерунде, не спросив ни слова про C#. Я вышел оттуда и пока шёл до метро, понял какие там уебки работают и решил найти работу на плюсах.
Яндекс можешь попробовать, или прошерсти геймдев конторки.
>А то на hh вакансий почти нет.
Я по тегу с++ вижу 577 вакансий. Уверен, что хотя бы 100 из них могут рассмотреть кандидата-джуна.
>А то на hh вакансий почти нет.
Я по тегу с++ вижу 577 вакансий. Уверен, что хотя бы 100 из них могут рассмотреть кандидата-джуна.
Дело скорее всего в конкретной конторе. На шарпе пишут ту же пиркладную и системную шнягу что и на крестах.
>Поэтому хочу спросить, куда вообще в ДС можно устроиться на работу С++ джуниором/стажером? А то на hh вакансий почти нет.
Как-то ты вяло ищешь. Буквально неделю назад висела вакансия о наборе крестоджунов в контору, занимающуюся безопасностью.
Что спрашивали в сопроводительном письме:
ООП, VirtualTables, тонкости полиморфизма, шаблоны (которые template, а не проектирования) все вопросы не помню.
>И что вообще должен знать джуниор?
Из вопросов на собеседовании на должность дзява-макаки (что помню):
- реализация строк в дзява;
- тонкости ООП;
- сикель-запросы;
- устройство словарей;
- алгоритмы и структуры данных.
На должности питониста:
- типы данных в питоне и как вообще устроена динамическая типизация;
- мутабельность-иммутабельность;
- устройство словарей;
- декораторы.
Это я то, что вспомнил, написал.
>Что я должен вообще знать?
Всего понемногу.
>И что мне дальше делать?
Учиться, обмазываться быдлокодом, писать на крестах, искать стажировку хоть за корку сыра.
Как-то ты вяло ищешь. Буквально неделю назад висела вакансия о наборе крестоджунов в контору, занимающуюся безопасностью.
Что спрашивали в сопроводительном письме:
ООП, VirtualTables, тонкости полиморфизма, шаблоны (которые template, а не проектирования) все вопросы не помню.
>И что вообще должен знать джуниор?
Из вопросов на собеседовании на должность дзява-макаки (что помню):
- реализация строк в дзява;
- тонкости ООП;
- сикель-запросы;
- устройство словарей;
- алгоритмы и структуры данных.
На должности питониста:
- типы данных в питоне и как вообще устроена динамическая типизация;
- мутабельность-иммутабельность;
- устройство словарей;
- декораторы.
Это я то, что вспомнил, написал.
>Что я должен вообще знать?
Всего понемногу.
>И что мне дальше делать?
Учиться, обмазываться быдлокодом, писать на крестах, искать стажировку хоть за корку сыра.
В Яндекс пробовал с месяц назад. Мне прислали какой-то файл с заданиями и сказали закодить. Я сделал одно задание где-то часов за 8 и забил на остальные, так как был занят. Не знаю сколько у них там кулдаун, но может напишу как-нибудь позже.
А насчёт геймдев контор я даже не знаю. Мне просто разослать письма, вроде "вот моё резюме, у вас случайно нет подходящей вакансии?" ?
Скажи навскидку хоть одну нормальную геймдев контору?
роботы нет на крестах дурачек
беги
беги
>Пишет слово 'работа' как 'робота'
>Удивляется почему нет работы
Дети Нивала норм вроде должны быть для джуна. Мобильных всяких должно быть несколько, я их не знаю.
Да, можешь прямо так и слать, особенно в большие конторы - они могут постоянно нанимать людей. Зайди на сайт, посмотри раздел вакансий, может найдешь что-то более-менее подходящее, тогда указывай в письме, что туда подаешься. Составь хорошее резюме, без ошибок, серьезное. Письмо тоже пиши в деловом стиле: кто ты такой, почему пишешь (твой интерес), почему им это может быть интересно. Коротко и вежливо, детали - в резюме.
В Яндексе кулдаун год вроде, говорил кто-то на форумах.
Поссал в рот малолетнему грамарнаци
На лиспе есть?
нету роботы на крестах
тебе сказали дяди
послушайся потом пожалеешь
лучше освой сишечку алгоритмы типо база будет
а потом суйся туда где хайп сейчас
>За корку сыра
>А то на hh вакансий почти нет.
Этого не может быть. Там дохуя работы для джунов. Другое дело, что ты на джуна не совсем тянешь. Я на плюсах даже в своих ебенях нашел работу без опыта в свое время. Если бы не нашел, перебрался бы в ДС.
Керниган-Ритчи - это си. Годнота, но в освоении плюсов это тебе поможет только косвенно.
Шилдт по крестам - это щит. Он дает С++ не с того конца. Страуструпп - для профи. Кури праймер Липпмана 5ю(!) редакцию.
http://dl.e-book-free.com/2013/07/c_primer_5th_edition.pdf
Не знаешь английского - учи английский.
Тебе нужен не просто С++, а С++11. Его уже сейчас требуют в половине вакансий, а пока ты его освоишь на нужном уровне, он будет уже нормой.
Как освоишь 11ю редакцию, принимайся за boost. Плюсы без буста - четверть плюсов.
Еще как и любому другому кодеру, тебе нужно будет знать SQL, системы контроля версий и алгоритмы и структуры данных (Кормен, например). Плюс какой-нибудь скриптовый язык: например, шелл или пайтон.
>Этого не может быть. Там дохуя работы для джунов. Другое дело, что ты на джуна не совсем тянешь.
define джун
как блять можно на джуна не тянуть? все ебанулись...
>Я на плюсах даже в своих ебенях нашел работу без опыта в свое время.
ZASHQUAR
>Тебе нужен не просто С++, а С++11. Его уже сейчас требуют в половине вакансий, а пока ты его освоишь на нужном уровне, он будет уже нормой.
потому что не знают, что ещё требовать. кроме хипстоты в C++11 нету нихуя, а вся хипстота и так в бусте была. inb4 в C++14 добавят haskell
>Как освоишь 11ю редакцию, принимайся за boost. Плюсы без буста - четверть плюсов.
кстати, легко можно обходиться и без него
>Еще как и любому другому кодеру, тебе нужно будет знать SQL, системы контроля версий и алгоритмы и структуры данных (Кормен, например). Плюс какой-нибудь скриптовый язык: например, шелл или пайтон.
больше похоже на требования для мидла
>как блять можно на джуна не тянуть?
Не нужно долго искать на hh.ru, чтобы понять, что джун != нет опыта и знаний. Подавляющее большинство джуниор-вакансий подразумевают хорошее(!) знание плюсов, чего у ОПа нет, либо знание алгоритмов и структур данных, либо опыт до года.
Да, конечно, понятие джуниора растяжимое. При этом многие компании его трактуют так, что ОПа назвать джуном не получается.
>ZASHQUAR
Ты это чего?
>кроме хипстоты в C++11 нету нихуя
Конечно нету
>а вся хипстота и так в бусте была
Ну это ты вообще загнул. В бусте чуть больше, чем все проф. разработчики. А хипстоте в принципе плюсы не интересны. Они не модные и сложные.
Буст для хипстоты, ага.
>кстати, легко можно обходиться и без него
И ебашить говнокод, изобретать велосипеды, писать неподдерживаемые программы. Мы же говорим не о лабораторных работах, а о серьезных, коммерциализируемых приложениях и сервисах.
Буквально недавно я рассматривал две вакансии. Одна - разработка демонов, вторая сервисов под виндой, и в обеих требовался буст, при чем на высоком уровне. Если уж такие низкоуровневые вещи пишут с бустом, то ситуация с прикладной бизнес-разработкой, думаю, ясна без дополнительных объяснений.
>больше похоже на требования для мидла
Я и не говорил, что это для джуна. Просто разметил горизонты ОПу, чтобы не занимался хуетой.
Короче, ты диванный. Поэтому просто съеби.
>кроме хипстоты в C++11 нету нихуя
Ну пиздец же.
auto
{} для перечисления элементов при инициализации строк и векторов
std::istream снятие eofbit флага при unget , а не простановка фэйла
Ну и так далее. Много вещей сделали хоть и по мелочи, но они напрашивались уже очень давно.
А также:
лямбды!
<thread>
foreach как core фича
rvalue референсы
= delete;
final, override
const_expr
Кто скажет, что НИНУЖНО может смело идти пидорасить легаси проекты
Но за что я прям готов расцеловать комитет, так это за нормальные функции перевода между строками и числами. Это какой позор был для стандартной библиотеки годами.
Чем atoi плох?
Или ты про обратный перевод? Стрингстрим - да, довольно неповоротливая штука для этого. Но имхо проблемы это не решает.
Вот чего не хватает плюсам, так это создания форматных строк. Принтф уже отжил свое. Надеюсь, вскоре добавят boost::format в стандарт.
А как же делегированные конструкторы и отлов исключений в списке инициализации конструкторов?
А как же decltype?
Как же обертка над указателями на функции std::function?
11й стандарт сильно продвинул С++.
Есть ли вообще смысл в этих ваших крестах? Практичнее работать сфере пиздонов/джав/ruby/сисярпов, имхо
Что можно утащить из буста для игрового движка к примеру, если потоки и таймеры уже есть? lexical_cast прикольный, но не из-за одного его же?
А вот насчёт С++11 не понял, что там учить надо. Там же всё тривиально, достаточно статью на английской википедии поскроллить.
Братиш, зачем ты этот мертвый яп учишь?
Я тоже :C
Почему мы такие?
>>как блять можно на джуна не тянуть?
>hh.ru
>Подавляющее большинство джуниор-вакансий подразумевают хорошее(!) знание плюсов, чего у ОПа нет, либо знание алгоритмов и структур данных, либо опыт до года.
я чота на hh.ru ни разу ничего нормального не находил
с хорошими знаниями вообще не вижу смысла идти на джуна, т.е. на небольшую зарплату
>>>работа в ебенях
>>ZASHQUAR
>Ты это чего?
обычно смысл там работать только чуть-чуть опыта понахвататься, дальше лучше уезжать или искать дистанционную работу, уровень всего там обычно низкий, а если и высокий, то уровень зарплат всё равно низкий
>>а вся хипстота и так в бусте была
>хипстоте в принципе плюсы не интересны.
имел в виду хипстерские штучки. ололо а вот тута вставляем лямбдочку внутри foreach с std::function, ... пара умных указателей.. блять ну и замороченая хуета получилась же
>>кстати, легко можно обходиться и без него
>И ебашить говнокод
посмотри на плюсовые проекты, хотя бы на opensource, сколько из них зависят от буста, это будут не все, а только примерно половина
использование буста не гарантирует тебе от говнокода (libtorrent как пример)
>Буквально недавно я рассматривал две вакансии. Одна - разработка демонов, вторая сервисов под виндой, и в обеих требовался буст, при чем на высоком уровне. Если уж такие низкоуровневые вещи пишут с бустом, то ситуация с прикладной бизнес-разработкой, думаю, ясна без дополнительных объяснений.
на hh наверное рассматривал? лол
я только имел в виду, что не надо усложнять там, где можно не усложнять, можно хорошо писать и с бустом, и без него, просто надо понимать, когда он нужен, а когда нет
>Короче, ты диванный.
ну почти, 6 лет в индустрии
>auto
ловите пидараса!
съеби в свой ruby тренд
Иди еще один тайпдеф напиши.
>Принтф уже отжил свое.
Всегда хотелось спросить, эту функцию правомерно использовать в "чистом" C++? Я всегда думал, она принадлежит стандартной библиотеке C.
>но не из-за одного его же?
Во-первых, почему бы и нет.
Во-вторых, можно утащить либы для логгинга, ТДД, риджекс, некоторые алгоритмы и предикаты, которых нет в std, json может пригодиться, сериализация. Не думаю, что имеет смысл продолжать этот список.
Справедливости ради стоит добавить, что потоки и таймеры были взяты из буста.
>имел в виду хипстерские штучки. ололо а вот тута вставляем лямбдочку внутри foreach с std::function, ... пара умных указателей.. блять ну и замороченая хуета получилась же
>лямбда, std::function, умные указатели
>хипстерские штучки
>6 лет в индустрии
Ты наверное каждый раз, когда нужно сделать некоторую обработку вектора, ебашишь цикл с обходом и проверкой условий, когда это делается в одну, максимум две строчки с лямбдой и подходящим алгоритмом из STL. И получается гораздо более читаемо.
Еще скажи, что move семантика это для хипстоты.
Видел я такой код и не раз от "опытных" девелоперов. Работают уже по 10 лет, и пишут говнокод на уровне процедура из 100+ строк, которую абслютно невозможно поддерживать: любое добавление нового функционала приводит к новым костылям.
>я только имел в виду, что не надо усложнять там, где можно не усложнять
я только имел в виду, что не надо писать заново то, что можно заново не писать.
Лучше не стоит. Если очень хочется и по каким-то причинам не можется подключить boost::format, то не мешай ее с cin/cout. Либо iostream, либо cstdio.
Я звял filesystem, format и lexical_cast, теперь любой файл компилируется 10 секунд. Придётся это терпеть.
Как тебе это удается? Я работаю в проекте с кодом на 10+Гб, и файл средних размеров компилится секунды 3-4. А у нас далеко не только boost.
Попробуй делать файлы с кодом поменьше, реже вноси изменения в заголовочные файлы, упрости параметры компиляции, прогрейди комп в конце концов.
Так или иначе, производительность программ требует жертв. Как минимум на этапе компиляции.
Ну у меня пентиум 4, так-то без буста за 5 секунд компилось.
>пентиум 4
Ну а чего ты еще хотел. Не думаю, что если бы ты все это сам написал, компилилось бы быстрее, не говоря уже о потраченном времени.
Другими словами, на написание своего filesystem и format ты потратишь больше времени, чем на сумму дельт по времени компиляции.
> кококо все есть в стл, программисты не нужны
ясно
понятно
>Я обожаю велосипеды
Да пожалуйста. Ты только близко к проектам в продакшене не подходи, ок?
мамке своей подойди поуказывай, ok?
в каком месте я предлагал велосипеды? понятно же, что если можно пользоваться алгоритмами из stl - то и нужно
К чему тогда ты это ляпнул?
ну смотри, есть вот функции
http://en.cppreference.com/w/cpp/algorithm
хотим мы найти максимальный и минимальный элемент в векторе - тут уже надо c++11 и minmax_element, отдельно min_element и max_element как было раньше - это снижение скорости в два раза
а теперь, если нам надо для всех элементов этого списка дополнительно проверить серию предикатов, то в общем случае ничего эффективнее обычного цикла не может быть, зачем тут for_each с лямбдой? что он упрощает?
если нам надо эффективно найти min_element, max_element и проверить все наши предикаты - то лучше всего будет работать простой цикл с проверкой всех этих условий, попутно найдём min и max
это понятно, что если нам эту поебень надо будет несколько раз проверять и возможно для разных типов данных то можно сделать шаблончик, но тут речь уже о другом
Чего, я даже не знаю, чем руби отличается от перла. auto нужно, чтоб не городить быдлокод
И нахуя ты это все написал? Где тут про то, что я типа говорю
>все есть в стл, программисты не нужны
И даже, если не обращать внимания на то, что ты отвечаешь на какой-то другой вопрос, что за хуету ты тут написал?
>хотим мы найти максимальный и минимальный элемент в векторе - тут уже надо c++11 и minmax_element, отдельно min_element и max_element как было раньше - это снижение скорости в два раза
Зачем это?
И с хуяли ты так уверен, что в два раза? Да, массив обходим один раз, но условий то проверять в два раза больше.
>а теперь, если нам надо для всех элементов этого списка дополнительно проверить серию предикатов, то в общем случае ничего эффективнее обычного цикла не может быть, зачем тут for_each с лямбдой? что он упрощает?
А это что? Ты думаешь, что если ввели какую-то фичу, то ее куда не воткни, везде будет эффективно? Это плюсы, тут нужны мозги.
Или может быть, фор_ич - единственное место применения лямбды?
>если нам надо для всех элементов этого списка дополнительно проверить серию предикатов
Вот тут ты мне взорвал мозг. Расскажи плз, уж не с минмаксом ли ты решил фор_ич применить? Ты реально собрался обходить все смежные элементы вектора(!), извлекать на каждом шаге(!) минимальный и максимальный элементы из тьюпла и пересохранять их в каких-то еще других переменных, в случае, если они соответственно меньше или больше? Так?
>если нам надо эффективно найти min_element, max_element и проверить все наши предикаты - то лучше всего будет работать простой цикл с проверкой всех этих условий, попутно найдём min и max
Давай рассмотрим случай не твоей курсовой работы по упорядочиванию массива целых, а обход объектов некоторого нетривиального класса. Если мы не хотим засорять пространство имен лишними предикатами, будет удобно и более читаемо выделить условия в лямбды. И внутри твоего цикла запускать уже их. Так мы будем уверены, что проверка отделена от самих условий, и что если ты что-то поменяешь в условиях, тебе не нужно лезть в цикл, и наоборот.
Но не в этом сила лямбды. Лямбда очень полезна для кастомизации алгоритмов STL. Лямбда позволяет быстро, безболезненно и прямо на месте применять эти алгоритмы для объектов пользовательских классов, если для них соответствующие проверки не определены. Лямбда позволяет использовать эти алгоритмы с участием "левых" переменных, используя захват переменных.
>так уверен, что в два раза
не в 2, в среднем в 1.5, если быть точным
где я про смежные элементы писал, ты наркоман? я всего лишь имел в виду что-то вроде посчитать минимум, максимум, отрицательные значения - вывести красным, от 40000 до 100000 - зелёным и так далее, всё за один проход, ибо элементов овердохуя (либо элементов немного но пересчитывать всю эту парашу необходимо тысячи раз в секунду)
насчёт засорения пространства имён - есть много способов от него уйти: private функции-члены, static функции и т.д.
насчет лямбд - в общем понятно, что ты имеешь в виду - это от стиля кода больше зависит будет ли лучше читаться, как ты пишешь, или с отдельными функциями
Если ты хочешь делать несколько проверок элементов массива за один проход (то есть разбитие на несколько обходов для тебя действительно(!) критично), то правильно будет максимально отделить друг от друга эти проверки внутри твоего цикла, так чтобы, если ты убрал или поменял одну из них, цикл гарантированно продолжал работать.
И что бы ты не говорил про стили кода, три ровненьких вызова соответствующих проверок с говорящими названиями будут читабельнее трех блоков кода, которые в этом случае придется дополнять комментариями. Все это становится особенно уместным, когда мы работаем с пользовательскими типами (а ведь это основной случай).
>private функции-члены, static функции и т.д.
Чтобы были private функции, нужно городить класс. Заводить класс только для того, чтобы функцию не было видно? Когда есть лямбда?
Статик функции будут засорять как минимум пространство имен того модуля, где они объявлены. А зачем, если соответствующая функция содержит 1-2 строчки и нужна только в одном(!) месте - в некоторой другой функции.
При использовании безымянных пространств имен аналогичная проблема.
Пойми, STL не просто так делали. Ее алгоритмы хорошо отлажены, гарантировано работают, и что еще очень важно - работают эффективно. Ведь ты в своих самодельных велосипедах наверняка забудешь в нужном месте использовать move-семантику и прочее. И весь твой выигрыш в эффективности от одного прохода пойдет по пизде.
И, возвращаясь к читабельности, алгоритмы STL в отличие от велосипедов, знают все уважающие себя разрабы, что ускоряет понимание твоего кода другими людьми. А алгоритмы STL не мыслимы без лямбды.
>спрашивали о какой-то ерунде, не спросив ни слова про C#
Например?
>куда вообще в ДС можно устроиться на работу С++ джуниором/стажером?
Крупные компании типа яндекса касперского.
Геймдев.
В первых надо писать квиксорт на бумажке, решать задачки с топкодера и стандартные вопросы по плюсам типа "виртуальный деструктор".
Во вторых могут и ничего не спросить кроме поболтать и прислать образец кода, могут тоже самое что в первых.
И да, если на шарпике 70к это человек который может положить в базу данных и не уронить ее, то на плюсах он должен действительно чтото знать.
Няша, ты можешь назвать несколько таких стандартных вопросов по крест ам?
ещё один воннаби джуниор
>Ведь ты в своих самодельных велосипедах наверняка забудешь в нужном месте использовать move-семантику и прочее. И весь твой выигрыш в эффективности от одного прохода пойдет по пизде.
в случае когда нужно скорости никто не мешает хранить в контейнере указатели вместо объектов, работать будет быстрее чем move-хуянтика
>если на шарпике 70к это человек который может положить в базу данных и не уронить ее, то на плюсах он должен действительно чтото знать.
но на c++ это будет уже и не 70к, а больше
Завалил собеседование на кресты, задавайте свои ответы.
1) В чем разница между free, delete и delete[]
2) Функция void test() { test(); } - что будет если её позвать и почему
3) В чем разница между list, vector и setи в каком случе стоит юзать каждый из этих контейнеров.
4) В чем разница между unordered_map и map
5) Задача: есть папка, в которой лежит куча документов, внутри документов есть девятизначные телефонные номера. Нужно собрать все уникальные номера. Как будете решать такую задачу?
6) Обясните на пальцах основные этапы компиляции кода
7) Cache miss - для вас это о чем-нибудь говорит?
Мимо нанимаю джуниворов
Что спрашивали?
Какие были задания и тд?
Ну я собеседовался на сетевого разработчика, а в сетях я не особо шарю. Ну по самому языку особо вопросов сложных небыло, ну там про виртуалный деструктор спросили, умные указатели, зачем нужны weak-поинтеры, про многопоточность, вот был вопрос который меня в тупик поставил:
из-за чего вы можете заподозрить участок кода в дедлоке, какие у вас критерии? Ну я тут особо ничего не ответил.
Вот когда про сети спрашивали - вот тут мой пукан извергал огонь как ракетоноситель: Как устроен HTTP, SSL, как устанавливается сессия TCP. Далее более прикладные вопросы: Как работает какой-нибудь кодек сжатия видео, какие характеристики аудиопотока. Ну короче я всем этим никогда не занимался и не интересовался особо, поэтому завалился на них.
Тестовым заданием до собеседования было - прием-передача файла через сокеты, да так чтоб сервером принять не только файл но и его имя. Ну это просто достаточно, это я дома быстро написал.
Пойду теперь жавамакакой собеседоваться, лол.
>1) В чем разница между free, delete и delete[]
фри это из C и освобождает после маллока, делете/делете[] из C++ и освобождает после new, [] это для массивов.
>2) Функция void test() { test(); } - что будет если её позвать и почему
Стак оверфлоу ексепшен
>3) В чем разница между list, vector и set
Лист это связный список, вектор - обёрнутый массив, сет - содержит только уникальные элементы. Использовать лучше вектор, если нужна уникальность - сет.
>4) В чем разница между unordered_map и map
Понятия не имею
>5) Задача: есть папка, в которой лежит куча документов, внутри документов есть девятизначные телефонные номера. Нужно собрать все уникальные номера. Как будете решать такую задачу?
Парсить регексом
>6) Обясните на пальцах основные этапы компиляции кода
Обработка препроцессором, трансляция в объектные файлы и слепление в ексешник.
>7) Cache miss - для вас это о чем-нибудь говорит?
Ни о чём не говорит
мимо-джяваблядок-самоучка-17лвл
>Парсить регексом
Ну и истории. Парсить и всё что ли?
>Весь пост состоит из пздеца вместо ответов
>Доебался только до регекспов
Странный ты.
New/delete вызывает конструктор/деструктор
Malloc/free соотвественно нет
На мой взгляд, программера в человеке выдает инстинкт глядеть в обе стороны, при переходе через дорогу с односторонним движением. Этакая предусмотрительность.
Вопрос нашего друга-hr'а был не только про парсинг. Задача комплексная. Парсинг регекспами, по-моему, не тот аспект, которым стоило ограничиваться. Особенно учитывая, что номера могут быть в совершенно поехавших и отличающихся друг от друга форматах.
Кодю больше 10 лет, из них 5 — за деньги
1) free не бросит исключениt. также делит вызывает деструктор объекта. делит[] - для массивов объектов
2) stack overflow, т.к. глубина рекурсии бесконечна - адреса возврата забьют весь стек
3) в листе нет рандом аксесс - только перебирать с начала или с конца, в векторе есть, по индексу, в сете по самому значению. лист там, где надо много переставлять элементы, т.к. ссылки переставлять быстрее, чем содержание; вектор в 90% случаев, где обычно массив, а сет в 5 задаче
4) без гугла хз ладно-ладно, я понял, пойду контейнеры учить
5) другие цифровые последовательности в них могут быть? номера могут содержать +-()? хотя вопрос наверное о другом, каждую найденную последовательность будем пихать в std::set<std::string>
6) препроцессор подставляет вместо #include содержимое того, что заинклюжено, подставляет макросы-дефайны. потом компилятор обнаруживает ошибки типа незакрытых скобок и пилит из текста объектный код, по одному объектному файлу на один файл исходного кода. потом линкер объединяет эти объектные файлы, по пути прикручивая объектный код из других библиотек, если он используется в программе.
7) не говорит
Вангую - тебе 25.
>могут быть в совершенно поехавших и отличающихся друг от друга форматах.
То, что может быть, в условиях задачи неплохо бы оговаривать сразу же. Потому что иначе можно доебаться до любого ответа в стиле "а у нас каждая цифра номера представлена буквой китайского алфавита, ваше решение не работает"
Ни на один из вопросов, заданных тут по-хорошему кратко, одной строкой, ответить нельзя.
В точку.
>в условиях задачи неплохо бы оговаривать сразу же
Как-то раз препод нам рассказал байку про то, как на заводе спирт воровали из цистерны. С этим люто боролись, опечатывали вентили, но кражи всё равно продолжались. Стабильно по 10л каждый раз. Вопрос: как рабочим это удавалось?
Препод сказал, что математики\программеры не могут решить эту задачу, потому что начинают задавать вопросы, уточнять что-либо. Инженеры, в свою очередь, справляются, потому что сразу ищут решение, а не упарываются дополнительными условиями.
На собеседовании, мне кажется, важен именно подход. Ты можешь заебать вопросами про кодировку документов, а можешь быстренько накидать алгоритм, коснуться структур данных, пояснить за тонкие места.
Инженеры ищут решения конкретных задач, зная условия. Точно также, как работяги (или кто там был) знали чего они хотят (спиздить спирт), сколько (10л) и какие препятствия у них на пути (опечатанные вентили и прочее).
Пытаться решать задачу, сходу покрывая все возможные варианты, мне кажется путь не слишком разумный, тем более все все равно не покроешь, потому что можешь о каких-то моментах не знать. Гораздо проще задать 2 вопроса:
1) Задан ли формат входных данных.
2) Если нет, могу ли я сам его задать
Популярная байка у преподов, Решение Синяки на дно цистерны перед заливкой опускали пустые вёдра. простое, но в группе только один байтоёб догадался и та не сразу, репу чесал, чертил в тетрадке чёто, мы ещё все с него проигрывали.
Хули ты тогда сети не задрочил перед собеседованием. Такую возможность проебать. Теперь будешь создавать фабрики фабрик.
Хули ты тогда сети не задрочил перед собеседованием. Такую возможность проебать. Теперь будешь создавать фабрики фабрик.
>Это решение
Как они, блядь, ведра опускали, если вентили опечатаны?
Они что, получается, имеют прямой доступ к цистерне? Тогда проще будет спирт сразу транспортировать в желудках алкашей.
Не знаю, как там на заводе все устроено, но если абстрагироваться, то надо запретить прямой доступ, или ввести независимые проверки на каждом этапе.
Ебу что ли? Может они блять мутанты X и могут проходить сквозь стены. В группе только байтоёб один догадался, а препод выслушал его, одобрительно покивал и сказал что бы мы равнялись на него.
Он неправильно условие описал. Там у цистерны два люка - сверху для залива и снизу для слива. В цистерну наливают, запечатывают, цистерна перемещается, открывают нижний люк, сливают - хуяк - а там на 10л меньше. Водила обратно едет пустой, поэтому люк сверху открыт. По пути он останавливается и забирает ведро со дна цистерны.
>Он неправильно условие описал. Там у цистерны два люка - сверху для залива и снизу для слива. В цистерну наливают, запечатывают, цистерна перемещается, открывают нижний люк, сливают - хуяк - а там на 10л меньше. Водила обратно едет пустой, поэтому люк сверху открыт. По пути он останавливается и забирает ведро со дна цистерны.
Ну что, милок, соснул?
Я так понимаю, эта задача из серии - почему люки круглые, как мячиками для пинг-понга измерить диаметр ануса и т.д.
>как мячиками для пинг-понга измерить диаметр ануса
И как?
Тебе так сразу и скажи. Этого знания достоин только истинный байтоёб.
Хочу спросить мнение местных ребят насчёт работы С++ джуниором.
Я вот раньше неплохо знал С#(есть сертификат от MS), писал немного на джаве, но сейчас решил хорошо выучить С++ и устроиться на работу.
Поэтому хочу спросить, куда вообще в ДС можно устроиться на работу С++ джуниором/стажером? А то на hh вакансий почти нет. Может быть есть какие-то большие компании, которые проводят стажировки или что-то еще?(Типа net-cracker'a, epama, только для С++)
И что вообще должен знать джуниор? Ну прочел я сначала Кернигана&Ричи, потом шилда по С++, немного в книжке Страуструпа смотрел. Что я должен вообще знать? И что мне дальше делать?