LINUX.ORG.RU

Что отличает юниора от более продвинутого

 , скиллы


3

7

Начнем с такого вопроса: существует ли вообще такое понятие как «разработчик на C++ среднего уровня». Все знают, что есть junior и senior, но o промежуточном варианте я как-то не слышал.

Но, допустим, мы рассмотрим некий средний уровень. Что по-вашему должен уже знать/уметь миддл, чего может еще не знать юниор? Интересует только то, что непосредственно связано с языком, знания общего плана - это отдельная тема.

★★★★★

Ответ на: комментарий от anonymous

Насколько я знаю, там всё ещё прилично кода от khtml, который C++98.

Но eao197 его забракует, ибо они не используют исключения, как и firefox, Qt, llvm и прочие.

RazrFalcon ★★★★★
()
Ответ на: комментарий от anonymous

Я в стандарт лезу уточнять преимущественно сишные грабли (типа undefined << при переполнении для знаковых типов или определена ли операция nullptr - 0 (для C - нет, к слову)). А плюсовые проблемы чаще всего ограничиваются разбором трёхэтажных ошибок компилятора на шаблоны.

Но, может, у других иная история.

dzidzitop ★★
()
Последнее исправление: dzidzitop (всего исправлений: 1)
Ответ на: комментарий от dzidzitop

сомнительно, с учётом многочисленных неочевидных undefined behaviour со всеми типами, операциями, и их всевозможными комбинациями.

Нет сомнений :-) цепепе в десятки раз сложнее, чем чистый C :-) Писать на цепепе, да ещё и соблюдая «хороший стиль» - это очень и очень трудоёмкий процесс :-) В цепепе предприняли попытку стандартизировать код на C за счёт стандартной библиотеке, но, похоже, ничего хорошего из этого не вышло :-) Всё равно пишут все кто во что горазд :-) Но сначала, надо изучить тонны литературы, словить тонны UB, провести много-много бессонных ночей, обдумывая не какие-то там практические вопросы, а вопросы аж эффективности процессорного времени и памяти, чтобы «не тормозило», и лишь потом уже попробовать реализовать задуманное на цепепе :-) А когда не получается (а это происходит), то рефакторить прекрасную объектную модель и всякие прочие шаблоны (обобщённый код! (r)) :-) Но это же не страшно, правда? :-)

anonymous
()
Ответ на: комментарий от RazrFalcon

Но eao197 его забракует, ибо они не используют исключения, как и firefox, Qt, llvm и прочие.

У Google, конечно же, упоротые code guideline. Но у Mozilla гораздо хуже. Не удивительно, что Firefox скатился в УГ, а Mozilla ищет выхода в переходе на Rust.

Использование/не использование исключений — это тонкий вопрос. Есть области, в которых исключения не используются и это правильно.

Но в большинстве случаев они не используются просто по историческим причинам или, еще проще, по дурости. В таких случаях на современном C++ писать сложно.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Теперь добавим сюда элемент реальности и забабахаем свой класс / структуру данных. При условии, что у нас нет boost::shared_ptr (ибо стандарт-то третий), как будем обходиться без указателей?

UVV ★★★★★
()
Ответ на: комментарий от BitSum

отказываться от технологий глупо

Сначала ты писал, что IDE исключает факторы человечности. Я оспариваю именно это абсолютное заявление примером, в котором эта автоматизация мешает другим разработчикам, отнимая их время.

Плюс организационные моменты. Даже с тем же CMake чрезвычайно трудно сделать IDE, которая подхватит любой проект. Нужно проект начинать в IDE. И принудить всех использовать одно и то же IDE.

Почему-то у тех пользователей IDE, с которыми я сталкивался, альтернативное понимание стандартов. Они имеют тенденцию оспаривать стиль кодирования, если их любимое IDE не умеет форматировать так, как принято. Не знаю, почему так случается. Возможно, я просто не вижу тех, кто пользуется своими IDE корректно.

i-rinat ★★★★★
()
Ответ на: комментарий от eao197

Использование/не использование исключений — это тонкий вопрос. Есть области, в которых исключения не используются и это правильно.
Но в большинстве случаев они не используются просто по историческим причинам или, еще проще, по дурости. В таких случаях на современном C++ писать сложно

Тут согласен. Но грань, когда можно обойтись обработкой ошибки и кидать исключение, очень тонка.

UVV ★★★★★
()
Ответ на: комментарий от UVV

Дядя, ты чего сказать-то хотел? У нормальных разработчиков свои умные указатели на подсчете ссылок и аналоги auto_ptr были еще до появления boost-а. Внутри эти умных указателей, естественно, голые указатели были. А снаружи — нет.

Это еще одна иллюстрация того, что C++ минимизирует необходимость работы с указателями.

К чему здесь «забабахаем свой класс / структуру данных» вообще не понятно. Свои структуры и классы в C++ со времен 1985-го года и первого C++ного компилятора можно было делать.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

К чему здесь «забабахаем свой класс / структуру данных» вообще не понятно. Свои структуры и классы в C++ со времен 1985-го года и первого C++ного компилятора можно было делать.

Хранить в контейнере по значению будешь?

UVV ★★★★★
()
Ответ на: комментарий от anonymous

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

А ты не знаешь, как там фирма «упорный столб» поживает? :-)

anonymous
()
Ответ на: комментарий от eao197

В большинстве случаев — да.

В с++03? Мы же всё ещё о нём, где нет move ctor, emplace_back и мы не полагаемся на rvo и copy elision компилятора.

UVV ★★★★★
()
Ответ на: комментарий от UVV

В с++03?

Конечно.

Мы же всё ещё о нём, где нет move ctor, emplace_back и мы не полагаемся на rvo и copy elision компилятора.

И что? Не имея всего этого мы должны тупо идти в heap даже не сверившись с показаниями профайлера?

eao197 ★★★★★
()
Ответ на: комментарий от UVV

у нас нет boost::shared_ptr (ибо стандарт-то третий)

boost::shared_ptr как раз таки в третьем и есть, поговаривают что он работает даже в 98м

anonymous
()
Ответ на: комментарий от lovesan

Ахах, тады я синьёр, со стажем в пару месяцев, чо ))

deep-purple ★★★★★
()
Ответ на: комментарий от eao197

И что? Не имея всего этого мы должны тупо идти в heap даже не сверившись с показаниями профайлера?

Я б сказал, что в 90% случаях, когда речь о чём-то больше, чем int, не стоило хранить по значению. Начиная с 11-го же, у нас есть уже много оптимизаций и есть над чем поразмыслить.

UVV ★★★★★
()
Ответ на: комментарий от UVV

Я б сказал, что в 90% случаях, когда речь о чём-то больше, чем int, не стоило хранить по значению

сочувствую твоим коллегам, разгребающим твой говнокод

anonymous
()
Ответ на: комментарий от eao197

И что? Не имея всего этого мы должны тупо идти в heap даже не сверившись с показаниями профайлера?

Конечно же нет! :-) Сначала нужно провести анализы и исследования :-) На это уйдёт всего пару ночей :-) А может быть даже и одна! :-) Потом уже можно будет принять решение как хранить объекты в векторе :-) Ах, как приятно в цепепе так разрабатывать ПО :-)

anonymous
()
Ответ на: комментарий от UVV

безусловно есть, но речь то шла об std, а не о boost'e

так ты же написал невменяемое сообщение, что boost::shared_ptr отсутствует в третьем стандарте

anonymous
()
Ответ на: комментарий от anonymous

Конечно же нет! :-) Сначала нужно провести анализы и исследования :-) На это уйдёт всего пару ночей :-) А может быть даже и одна! :-) Потом уже можно будет принять решение как хранить объекты в векторе :-) Ах, как приятно в цепепе так разрабатывать ПО :-)

так ты не умеешь этого делать, а то что тебе приятно в тайне от мамки теребонькать перед монитором на порнхаб - это не есть «приятно в цепепе так разрабатывать ПО», это другое

anonymous
()
Ответ на: комментарий от UVV

Я б сказал, что в 90% случаях, когда речь о чём-то больше, чем int, не стоило хранить по значению

Я б сказал, что вам хоть раз следовало бы провести сравнение стоимости размещения объектов разных размеров в хипе и в простейшем std::vector по значению. Да еще с учетом дополнительных расходов, связанных с тем, что появляется дополнительный уровень косвенности и дополнительное выравнивание данных в памяти.

Ну а потом уже рассуждать про различия junior-а от middle. Ну и вообще о том, как следует программировать на C++.

eao197 ★★★★★
()
Ответ на: комментарий от UVV

Найди мне, пожалуйста, тут boost::shared_ptr

зачем? ты так и не объяснил смысл своего неадекватного сообщения. хотя можешь этого не делать, ты же гей

anonymous
()
Ответ на: комментарий от eao197

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

К примеру в моём GUI на Qt к svgcleaner я использую исключения, ибо мне нужно возвращать разные типы ошибок, и в плюсах это по-нормальному никак не сделаешь (нету аналога sum types, как у раста). Но там программка в 1к строк, и отследить исключения просто. В любом большом проекте это выливается в боль, ибо непонятно когда и какая функция стрельнет исключение и прога упадёт. Про многопоточность, rethrow вообще молчу.

Была бы альтернатива checked exceptions - было бы проще.

RazrFalcon ★★★★★
()
Ответ на: комментарий от i-rinat

Даже с тем же CMake чрезвычайно трудно сделать IDE, которая подхватит любой проект.

1. Это проблема кривого cmake, а не IDE.

2. В новых версиях они такие добавили возможность интеграции с IDE. Вон в QtC уже есть подвижки в эту сторону.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

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

ты не умеешь программировать :-) это ты в каждой теме доказываешь :-)

К примеру в моём GUI на Qt к svgcleaner я использую исключения, ибо мне нужно возвращать разные типы ошибок, и в плюсах это по-нормальному никак не сделаешь (нету аналога sum types, как у раста). Но там программка в 1к строк, и отследить исключения просто. В любом большом проекте это выливается в боль, ибо непонятно когда и какая функция стрельнет исключение и прога упадёт. Про многопоточность, rethrow вообще молчу.

скорее всего раст ты знаешь также как C++ :-) тоесть никак :-)

anonymous
()
Ответ на: комментарий от eao197

Я б сказал, что вам хоть раз следовало бы провести сравнение стоимости размещения объектов разных размеров в хипе и в простейшем std::vector по значению. Да еще с учетом дополнительных расходов, связанных с тем, что появляется дополнительный уровень косвенности и дополнительное выравнивание данных в памяти.

Ну хорошо, с 90% я, конечно перегнул. Я подразумевал, что если есть коллекция классов с виртуальными функциями, то без указателей тут никуда.

Ну а потом уже рассуждать про различия junior-а от middle. Ну и вообще о том, как следует программировать на C++.

Ну тебе же ничего не мешает рассуждать =)

UVV ★★★★★
()
Ответ на: комментарий от RazrFalcon

Сколько я не пытался использовать исключения - это всегда боль.

Вопрос в том, как их пытаются использовать.

В любом большом проекте это выливается в боль, ибо непонятно когда и какая функция стрельнет исключение и прога упадёт. Про многопоточность, rethrow вообще молчу.

Это явный симптом, что исключения используются как-то не так.

Была бы альтернатива checked exceptions - было бы проще.

В C++ нет checked exceptions.

eao197 ★★★★★
()
Ответ на: комментарий от UVV

Почему именно int? 4 байта? Откуда это? Я натыкался на тезис, что все структуры до 64 байт проще хранить по значению.

Но, насколько я знаю, это всё равно упрётся в тип процессора и его кеш. То есть в большинстве случаев, на неподконтрольном оборудовании, ощутимой разницы не будет.

RazrFalcon ★★★★★
()
Ответ на: комментарий от anonymous

зачем? ты так и не объяснил смысл своего неадекватного сообщения. хотя можешь этого не делать, ты же гей

Конечно. А почему ты это упоминаешь? Тебе некомфортно от этого?

UVV ★★★★★
()
Ответ на: комментарий от i-rinat

да ну ладно, компилятор сразу расскажет что такой функции банально нет. а дальше дело техники: скопировал название да вставил: сам ведь описаться можешь запросто. Я бы даже может не проверял по буквам предварительно, описки случаются, и как по мне так проще скопировать, чем выяснять.

AndreyKl ★★★★★
()

Количество пройденных граблей в своей области.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от RazrFalcon

Почему именно int? 4 байта
все структуры до 64 байт проще хранить по значению.
тип процессора и его кеш

и это гавно еще рассуждает о языках программирования)

anonymous
()
Ответ на: комментарий от UVV

Я подразумевал, что если есть коллекция классов с виртуальными функциями, то без указателей тут никуда.

Э... Полагаю, вы хотели сказать про коллекцию полиморфных объектов. Это несколько не то, что «классы с виртуальными функциями».

Ну тебе же ничего не мешает рассуждать =)

Если бы на LOR-е про C++ и о том, как на нем программировать, рассказывал бы Антон Полухин, к примеру, я бы спокойно молчал бы себе и учился у умных людей. Но в его отсутствие уж лучше я, чем вы или RazrFalcon.

eao197 ★★★★★
()
Последнее исправление: eao197 (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

Просто я подумал, что у тебя припасено достаточно аргументов. Хотя о чём это я, мы же на ЛОРе..

UVV ★★★★★
()
Ответ на: комментарий от anonymous

так ты не умеешь этого делать, а то что тебе приятно в тайне от мамки теребонькать перед монитором на порнхаб - это не есть «приятно в цепепе так разрабатывать ПО», это другое

Вот видишь к чему приводят фантазии, когда днями и ночами на уме лишь цепепе? :-) Понятное дело, что цепепе может заменить даже теребоньканье, но это не ко мне :-) Лол :-)

anonymous
()
Ответ на: комментарий от anonymous

скорее всего раст ты знаешь также как C++ :-) тоесть никак :-)

Смайликов недостаточно :-) Замени ещё «C++» на «цепепе» :-)

anonymous
()
Ответ на: комментарий от eao197

Э... Полагаю, вы хотели сказать про коллекцию полиморфных объектов. Это несколько не то, что «классы с виртуальными функциями».

Можно разницу между этими понятиями. Ну так, в ознакомительных целях.

Но в его отсутствие уж лучше я, чем вы или RarzFalcon

Это у тебя миссия такая? Нести правильный с++ в массы?

UVV ★★★★★
()
Ответ на: комментарий от anonymous

Вот это самомнение :-)

Где-то в Гомели крыша треснула

UVV ★★★★★
()
Ответ на: комментарий от UVV

Это у тебя миссия такая? Нести правильный с++ в массы?

по факту eao197 один из немногочисленных людей на ЛОРе кто действительно знает C++

anonymous
()
Ответ на: комментарий от eao197

Это явный симптом, что исключения используются как-то не так.

А как они должны использоваться? Где есть хорошее описание?

Вот простой пример:

void func1()
{ 
    func2(); // кидает один тип исключения
    func3(); // кидает другой тип исключения
}

...

try {
    func1();
} catch (const exception1& e) {
    // stuff
} catch (const exception2& e) {
    // stuff
} catch (...) {
    // ???
}

Теперь мы добавляем func4 с exception3 и прога падает где-то «неверху». Компилятор это никак не проверяет и всё работа/ответственность на программисте, который должен помнить что и где вызывается. В rust это решается через pattern matching, который проверяется на этапе компиляции.

В C++ нет checked exceptions.

Поэтому и боль.

RazrFalcon ★★★★★
()
Ответ на: комментарий от anonymous

по факту eao197 один из немногочисленных людей на ЛОРе кто действительно знает C++

Думается, что цепепе действительно не знает никто, включая Страуструпа :-)

anonymous
()

Интересует только то, что непосредственно связано с языком

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

no-such-file ★★★★★
()
Ответ на: комментарий от RazrFalcon

Теперь мы добавляем func4 с exception3 и прога падает где-то «неверху». Компилятор это никак не проверяет и всё работа/ответственность на программисте, который должен помнить что и где вызывается. В rust это решается через pattern matching, который проверяется на этапе компиляции.

я ж говорю что ты идиот :-) в цепепе есть catch(...) и базовые классы :-)

anonymous
()
Ответ на: комментарий от anonymous

Думается, что цепепе действительно не знает никто, включая Страуструпа :-)

по себе людей не суди, не все дебилы-птушники как ты

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.