Приветственный пост
Рады приветствовать всех на нашем канале!
Вы устали от скучного, монотонного, обезличенного контента по плюсам?
Тогда мы идем к вам!
Здесь не будет бесполезных 30 IQ постов, сгенеренных ChatGPT, накрученных подписчиков и активности.
Канал ведут два сеньора, Денис и Владимир, которые искренне хотят делится своими знаниями по С++ и создать самое уютное коммьюнити позитивных прогеров в телеге!
(ну вы поняли, да? с++, плюс плюс, плюс типа
позитивный?.. ай ладно)
Жмакай и попадешь в наш чат. Там обсуждения не привязаны к постам, можете общаться на любые темы.
ГАЙДЫ:
Мини-гайд по собеседования
Гайд по категория выражения и мув-семантике
Гайд по inline
Дальше пойдет список хэштегов, которыми вы можете пользоваться для более удобной навигации по каналу и для быстрого поиска группы постов по интересующей теме:
#algorithms
#datastructures
#cppcore
#stl
#goodoldc
#cpp11
#cpp14
#cpp17
#cpp20
#commercial
#net
#database
#hardcore
#memory
#goodpractice
#howitworks
#NONSTANDARD
#interview
#digest
#OS
#tools
#optimization
#performance
#fun
#compiler
#multitasking
#design
#exception
#guide
#задачки
#base
#quiz
#concurrency
Рады приветствовать всех на нашем канале!
Вы устали от скучного, монотонного, обезличенного контента по плюсам?
Тогда мы идем к вам!
Здесь не будет бесполезных 30 IQ постов, сгенеренных ChatGPT, накрученных подписчиков и активности.
Канал ведут два сеньора, Денис и Владимир, которые искренне хотят делится своими знаниями по С++ и создать самое уютное коммьюнити позитивных прогеров в телеге!
(ну вы поняли, да? с++, плюс плюс, плюс типа
позитивный?.. ай ладно)
Жмакай и попадешь в наш чат. Там обсуждения не привязаны к постам, можете общаться на любые темы.
ГАЙДЫ:
Мини-гайд по собеседования
Гайд по категория выражения и мув-семантике
Гайд по inline
Дальше пойдет список хэштегов, которыми вы можете пользоваться для более удобной навигации по каналу и для быстрого поиска группы постов по интересующей теме:
#algorithms
#datastructures
#cppcore
#stl
#goodoldc
#cpp11
#cpp14
#cpp17
#cpp20
#commercial
#net
#database
#hardcore
#memory
#goodpractice
#howitworks
#NONSTANDARD
#interview
#digest
#OS
#tools
#optimization
#performance
#fun
#compiler
#multitasking
#design
#exception
#guide
#задачки
#base
#quiz
#concurrency
Telegram
Грокаем C++
Мини-гайд по собеседованиям
Доброго дня, дорогие подписчики. Сегодня у нас радостный день - на канале выходит первый гайд. Не так давно мы в комментах с ребятами осуждали этот вопрос, что нужно сделать чеклист по вопросам с собесов. Собственно, сделал. Скачивайте…
Доброго дня, дорогие подписчики. Сегодня у нас радостный день - на канале выходит первый гайд. Не так давно мы в комментах с ребятами осуждали этот вопрос, что нужно сделать чеклист по вопросам с собесов. Собственно, сделал. Скачивайте…
Код ревью Ч1
Во многих IT-компаниях процедура код-ревью является обязательной. Перед добавлением новых изменений в кодовую базу команда разработчиков проверяет друг друга с целью улучшить решение. Побочным эффектом является повышение компетенций автора. Я предлагаю рассматривать эту практику именно с этой стороны и сейчас поговорим, почему именно так.
Нередко на просторах интернета можно встретить достаточно токсичные треды с обсуждением какого-либо решения... Неудивительно, что многие начинающие разработчики побаиваются код-ревью. И все же это интернет, а не реальные коллеги. Тем не менее это вызов вашим компетенциям. Рассматривайте это, как способ проверить и повысить ваши навыки коммуникации и убеждения, расширить знания программирования. Часто нет однозначно правильного решения, все варианты обладают своими плюсами и минусами. В таком случае приходится убеждать других - это все влияет на ваш профессиональный авторитет в коллективе. Это важно и для собственной самооценки, и для карьерного роста.
Эмоциональная нагрузка со временем будет уменьшаться, и даже наоборот перерасти в азарт: а слабо ли мне пройти ревью без единого исправления? Это челлендж самому себе, но его проходить реально прикольно. Желаю вам испытать это чувство собственной неотразимости! 😊
К сожалению, в некоторых компаниях пренебрегают такой процедурой. На моей практике был печальный опыт получения проекта от другой компании, где не было такой процедуры. Отсутствие проверки расхолаживает разработчиков, а качество кода не улучшается со временем. Всегда есть возможность сэкономить и запилить костыль до лучших времен, которые, возможно, никогда не настанут. Я не преувеличиваю, бывает очень сложно доказать вышестоящему руководству, что необходимо выделить время на рефакторинг. С точки зрения потребителя и бизнеса ничего не меняется, это внутренние дела вашей кухни.
Я сделал однозначный для себя вывод, что код-ревью является необходимой процедурой коммерческой разработки. Качественный код нужно публиковать как можно раньше. Да, это требует времени и сил, но развивает коллектив и позволяет поддерживать проект очень долгое время, сокращает количество ошибок и багов, упрощает жизнь программистов в долгосрочной перспективе.
В следующей части давайте поговорим, как проводить код-ревью для своих коллег. На мой взгляд есть важные моменты, я хочу быть уверен, что вы их точно будете знать.
#commercial #goodpractice
Во многих IT-компаниях процедура код-ревью является обязательной. Перед добавлением новых изменений в кодовую базу команда разработчиков проверяет друг друга с целью улучшить решение. Побочным эффектом является повышение компетенций автора. Я предлагаю рассматривать эту практику именно с этой стороны и сейчас поговорим, почему именно так.
Нередко на просторах интернета можно встретить достаточно токсичные треды с обсуждением какого-либо решения... Неудивительно, что многие начинающие разработчики побаиваются код-ревью. И все же это интернет, а не реальные коллеги. Тем не менее это вызов вашим компетенциям. Рассматривайте это, как способ проверить и повысить ваши навыки коммуникации и убеждения, расширить знания программирования. Часто нет однозначно правильного решения, все варианты обладают своими плюсами и минусами. В таком случае приходится убеждать других - это все влияет на ваш профессиональный авторитет в коллективе. Это важно и для собственной самооценки, и для карьерного роста.
Эмоциональная нагрузка со временем будет уменьшаться, и даже наоборот перерасти в азарт: а слабо ли мне пройти ревью без единого исправления? Это челлендж самому себе, но его проходить реально прикольно. Желаю вам испытать это чувство собственной неотразимости! 😊
К сожалению, в некоторых компаниях пренебрегают такой процедурой. На моей практике был печальный опыт получения проекта от другой компании, где не было такой процедуры. Отсутствие проверки расхолаживает разработчиков, а качество кода не улучшается со временем. Всегда есть возможность сэкономить и запилить костыль до лучших времен, которые, возможно, никогда не настанут. Я не преувеличиваю, бывает очень сложно доказать вышестоящему руководству, что необходимо выделить время на рефакторинг. С точки зрения потребителя и бизнеса ничего не меняется, это внутренние дела вашей кухни.
Я сделал однозначный для себя вывод, что код-ревью является необходимой процедурой коммерческой разработки. Качественный код нужно публиковать как можно раньше. Да, это требует времени и сил, но развивает коллектив и позволяет поддерживать проект очень долгое время, сокращает количество ошибок и багов, упрощает жизнь программистов в долгосрочной перспективе.
В следующей части давайте поговорим, как проводить код-ревью для своих коллег. На мой взгляд есть важные моменты, я хочу быть уверен, что вы их точно будете знать.
#commercial #goodpractice
Код ревью Ч2
Продолжаем тему код-ревью. На этот раз поговорим об этом с точки зрения проверяющего.
Эмоциональный фон сильно влияет на скорость и качество исправлений замечаний, исполнения пожеланий других разработчиков. В одном из исследований было замечено, что люди получают большее удовольствие от работы, если в компании работает лучший друг. Зачем упускать возможность получать от работы удовольствие? Мы решаем проблему, а не самоутверждаемся за счет других!
На моем текущем месте работы однажды проводили тренинг по командообразованию. Мы обсуждали разные сложности в работе, в том числе эмоциональную нагрузку на код-ревью. Нам понадобилось два полных рабочих дня, чтобы проработать все сложности... И знаете какой итог был по окончанию этого мероприятия? Не поверите, но мы договорились делать друг другу комплименты там, где нам действительно что-то понравилось 😄 Конечно, лишь немногие стали придерживаться этой рекомендации, но прошел уже почти год и мне действительно стало приятнее работать с этими единицами!
Заводите друзей среди коллег, либо общайтесь, как с другом, пока вы ими действительно не станете. Это определяет всю манеру и способы взаимодействия друг с другом! Например:
1. Терпеливость и внимательность в общении
2. Допущение вкусовых предпочтений автора кода
Конечно, это не отменяет конструктивной критики, а лишь корректирует форму преподнесения ваших замечаний. Главной целью, как я уже говорил ранее, является улучшение предоставленного решения: исправление ошибок, работа над читаемостью кода, проверка логики и т.д.
«Абсолютная корректность системы - недостижима. Каждая последняя найденная ошибка является предпоследней»
Этот закон отражает сложность нетривиальных систем, с которыми разработчики сталкиваются каждый день. Следовательно, и решение необходимо искать ошибки на самых разных уровнях. Начиная с самых простых - синтаксических, заканчивая самыми сложными - соответствия целям бизнеса. В идеале, целеустремленный разработчик будет стремиться к пониманию потребностей своих клиентов и работать над их достижением.
Вовлеченность в каждый из этих вопросов определяет профессионализм разработчика.
#commercial #goodpractice
Продолжаем тему код-ревью. На этот раз поговорим об этом с точки зрения проверяющего.
Эмоциональный фон сильно влияет на скорость и качество исправлений замечаний, исполнения пожеланий других разработчиков. В одном из исследований было замечено, что люди получают большее удовольствие от работы, если в компании работает лучший друг. Зачем упускать возможность получать от работы удовольствие? Мы решаем проблему, а не самоутверждаемся за счет других!
На моем текущем месте работы однажды проводили тренинг по командообразованию. Мы обсуждали разные сложности в работе, в том числе эмоциональную нагрузку на код-ревью. Нам понадобилось два полных рабочих дня, чтобы проработать все сложности... И знаете какой итог был по окончанию этого мероприятия? Не поверите, но мы договорились делать друг другу комплименты там, где нам действительно что-то понравилось 😄 Конечно, лишь немногие стали придерживаться этой рекомендации, но прошел уже почти год и мне действительно стало приятнее работать с этими единицами!
Заводите друзей среди коллег, либо общайтесь, как с другом, пока вы ими действительно не станете. Это определяет всю манеру и способы взаимодействия друг с другом! Например:
1. Терпеливость и внимательность в общении
2. Допущение вкусовых предпочтений автора кода
Конечно, это не отменяет конструктивной критики, а лишь корректирует форму преподнесения ваших замечаний. Главной целью, как я уже говорил ранее, является улучшение предоставленного решения: исправление ошибок, работа над читаемостью кода, проверка логики и т.д.
«Абсолютная корректность системы - недостижима. Каждая последняя найденная ошибка является предпоследней»
Этот закон отражает сложность нетривиальных систем, с которыми разработчики сталкиваются каждый день. Следовательно, и решение необходимо искать ошибки на самых разных уровнях. Начиная с самых простых - синтаксических, заканчивая самыми сложными - соответствия целям бизнеса. В идеале, целеустремленный разработчик будет стремиться к пониманию потребностей своих клиентов и работать над их достижением.
Вовлеченность в каждый из этих вопросов определяет профессионализм разработчика.
#commercial #goodpractice
Код ревью Ч3
Продолжаем тему код-ревью. Давайте теперь попробуем назвать общее требование к автору и проверяющим. Я бы выделил коллективную ответственность за эволюцию кода проекта.
Специально использую термин эволюция, т.к. ваш проект изменяется каждый день. Заказчики присылают новые требования, конкуренты развивают свои продукты, разработчики добавляют новые фишки и исправляют баги... Каждая строчка кода проходит естественный и искусственный отбор.
Выбор потребителей - это этапы естественного отбора. Если ваш продукт уступает в чем-то, то его перестают выбирать. При такой динамике количество клиентов будет недостаточно, чтобы поддерживать ПО дальше, т.е. произойдет отбор не в вашу пользу.
Ваши замечания на ревью - это этап искусственного отбора. Проверка кода - это капля в море, но именно из них и состоит весь проект. Те баги, что вы пропускаете вперед, вы же и будете исправлять! Да, иногда стоит поискать слова и аргументы, чтобы объяснить сложную суть проблемы или преимущество вашего решения, которое вы видите сейчас или в будущем.
С моей точки зрения, автор несёт большую ответственность, т.к. именно он является наиболее погруженным в контекст участником, выполняет первичное тестирование. Если смотреть с этой позиции, автор выступает еще и в роли проверяющего, а исходное решение является нулевой итерацией проверки. Ну, и следовательно, их надо найти и устранить 😃
Предполагается, что опубликованное решение работает корректно, но мы всегда должны мыслить критически - проверять это предположение и превращать его в утверждение.
Пишите вопросы! Вам ответ - нам контент!
#commercial #goodpractice
Продолжаем тему код-ревью. Давайте теперь попробуем назвать общее требование к автору и проверяющим. Я бы выделил коллективную ответственность за эволюцию кода проекта.
Специально использую термин эволюция, т.к. ваш проект изменяется каждый день. Заказчики присылают новые требования, конкуренты развивают свои продукты, разработчики добавляют новые фишки и исправляют баги... Каждая строчка кода проходит естественный и искусственный отбор.
Выбор потребителей - это этапы естественного отбора. Если ваш продукт уступает в чем-то, то его перестают выбирать. При такой динамике количество клиентов будет недостаточно, чтобы поддерживать ПО дальше, т.е. произойдет отбор не в вашу пользу.
Ваши замечания на ревью - это этап искусственного отбора. Проверка кода - это капля в море, но именно из них и состоит весь проект. Те баги, что вы пропускаете вперед, вы же и будете исправлять! Да, иногда стоит поискать слова и аргументы, чтобы объяснить сложную суть проблемы или преимущество вашего решения, которое вы видите сейчас или в будущем.
С моей точки зрения, автор несёт большую ответственность, т.к. именно он является наиболее погруженным в контекст участником, выполняет первичное тестирование. Если смотреть с этой позиции, автор выступает еще и в роли проверяющего, а исходное решение является нулевой итерацией проверки. Ну, и следовательно, их надо найти и устранить 😃
Предполагается, что опубликованное решение работает корректно, но мы всегда должны мыслить критически - проверять это предположение и превращать его в утверждение.
Пишите вопросы! Вам ответ - нам контент!
#commercial #goodpractice
Код ревью Ч4
Продолжаем тему код-ревью.
Конечно, найти все ошибки самостоятельно нельзя. Это следует из закона, который я упомянул в одном из предыдущих постов. Но можно поспособствовать себе в этом! В основном, большая часть ошибок допускается по невнимательности или неосознанности принятых решений. Мне помогают следующие рекомендации:
1. Отдыхать после работы.
Без комментариев.
2. Не публиковать код вечером.
Не думаю, что вашим коллегам будет принципиально важно увидеть код как можно скорее - вечером или утром следующего дня. А вот вам этот перерыв поможет перевести дух и взглянуть на решение свежим взглядом. Я так неоднократно находил у себя разные мелочи.
3. Спрашивайте себя почему и зачем?
Почаще спрашивайте себя, зачем вы приняли такой решение тут? Почему это работает так там? И не забывайте отвечать на эти вопросы :) Это просто влияет на вашу осознанность и погруженность в код.
3. Представить себя на месте коллег
Бывало ли у вас такое, что вы идете по очень знакомой улице, но вспоминаете свои ощущения и впечатления, как это было впервые? Попробуйте погрузиться в это ментальное состояние и попробовать посмотреть на свой код чужими глазами, абстрагировавшись от контекста. Это то, что увидят ваши коллеги. Поймут ли они то, что задумали вы?
4. Как бы сказал ваш авторитет?
Да, можно представить себя на месте вашего авторитета и подумать, что бы он сказал по поводу того или иного решения?
Надеюсь, что и для вас эти рекомендации будут полезны! 😉
#commercial #goodpractice
Продолжаем тему код-ревью.
Конечно, найти все ошибки самостоятельно нельзя. Это следует из закона, который я упомянул в одном из предыдущих постов. Но можно поспособствовать себе в этом! В основном, большая часть ошибок допускается по невнимательности или неосознанности принятых решений. Мне помогают следующие рекомендации:
1. Отдыхать после работы.
Без комментариев.
2. Не публиковать код вечером.
Не думаю, что вашим коллегам будет принципиально важно увидеть код как можно скорее - вечером или утром следующего дня. А вот вам этот перерыв поможет перевести дух и взглянуть на решение свежим взглядом. Я так неоднократно находил у себя разные мелочи.
3. Спрашивайте себя почему и зачем?
Почаще спрашивайте себя, зачем вы приняли такой решение тут? Почему это работает так там? И не забывайте отвечать на эти вопросы :) Это просто влияет на вашу осознанность и погруженность в код.
3. Представить себя на месте коллег
Бывало ли у вас такое, что вы идете по очень знакомой улице, но вспоминаете свои ощущения и впечатления, как это было впервые? Попробуйте погрузиться в это ментальное состояние и попробовать посмотреть на свой код чужими глазами, абстрагировавшись от контекста. Это то, что увидят ваши коллеги. Поймут ли они то, что задумали вы?
4. Как бы сказал ваш авторитет?
Да, можно представить себя на месте вашего авторитета и подумать, что бы он сказал по поводу того или иного решения?
Надеюсь, что и для вас эти рекомендации будут полезны! 😉
#commercial #goodpractice
STL vs stdlib
Откопаем один из популярнейших холиваров по С++, о котором вы даже могли и не слышать. Из-за того, что мы с вами не носители, то плохо понимаем ориджин терминов, которые сами используем. Ну типа всю нашу жизнь вокруг нас на туалетах написано WC и мы даже не понимаем, а что это значит на самом деле. Но продолжаем в новых заведениях помечать туалет именно этими буквами и просто принимаем это, как данность. Water closet. Так давно в Англии начали назывались маленькие приватные комнатки с подачей воды для смыва.
Так и мы с вами употребляем термин STL скорее в каком-то нашем интуитивном понимании, чем в реальном его значении. Ну вот например, в вакансиях плюсовиков в требованиях часто пишут, что необходимо знание буста и STL. Думаю, что и HR'ы и соискатели удивятся, что 99.9% плюсовиков никогда не пользовались STL....
Утверждение громкое и для кого-то может быть обидное, поэтому погнали разбираться, пока меня тухлыми помидорами не закидали.
С 1979 года, когда мастер-Бьёрн создал С с классами, пройдет почти 20 лет прежде, чем С++ будет стандартизирован в 1998 году. Процесс стандартизации шел долго и люди со временем вносили свои пропоузалы в будущий стандарт. В принципе и сейчас так делают. Так вот. Жил, был и работал в HP один русский эмигрант - Александр Степанов. У него давно были мысли по созданию обобщенной библиотеки, в которой данные и алгоритмы над ними находились бы отдельно друг от друга. Он пытался воплотить свои мысли в жизнь даже в других языках, типа Ada, потому что на тот момент С++ не обладал необходимой функциональностью. Но язык развивался, появились необходимые фичи и Александр начал думать над реализацией своих идей в С++. В конце 1993 года он рассказал о своих наработках бывшему коллеге - Эндрю Кёнингу, который на тот момент работал в ISO комитете С++. Эндрю восхитился замыслом Александра и организовал ему встречу с комитетом. Комитет тоже охал и ахал от гениальности идей и включил их в драфт страндарта С++. Но не полностью. Что-то пришлось удалить и что-то пришлось подкорректировать в сотрудничестве со Степановым. Именно так были созданы стандартные библиотеки алгоритмов, итераторов и контейнеров.
В 1995 году Александр перешел в компанию Silicon Graphics, доработал и релизнул окончательную версию своего видения STL. Ее даже вроде можно скачать тут. То есть это вообще отдельная библиотека, которую надо отдельно подключать к своему проекту. И с почти стопроцентной вероятностью, вы ей никогда не пользовались.
То есть STL никогда не была частью стандарта, хотя и сильно повлияло на него. В тексте стандарта нет ни одного упоминания STL! Но Степанов сам называл включения своей библиотеки в стандартную библиотеку как STL. И авторы многих книг по С++ называли эти включения STL. Даже Страуструп называет стандартные библиотеки алгоритмов, итераторов и контейнеров STL. Поэтому в умах закрепилась эта ассоциация и, в целом, сейчас легитимно называть так этот набор библиотек.
Но мозг людей склонен к обобщениям, поэтому под STL со временем многие начали понимать в принципе всю стандартную библотеку. Масла в огонь подливает еще, что STL можно расшифровать, как STandard Library. Да и другие части stdlib сугубо шаблонизированы. Типа тех же умных указателей или работы со случайными числами. Для многих STL стала уже симулякром в чистом виде, потому что люди забыли изначальное значение этого акронима.
Я не против использования термина STL в качестве референса к либам алгоритмов, итераторов и контейнеров. Даже для stdlib не против. Потому что не понимаю, как это может вредить программисту. Но считаю важным, чтобы люди понимали настоящий смысл слов, которые они употребляют. Используя в жизни ситулякры, мы отдаляемся от реальных вещей и переходим в мир выдуманный, нереальный. А настоящий мир будет продолжать влиять на нас по прежнему и это противоречие может вылиться в проблемы.
А к какому лагерю вы относитесь? Только stdlib и больше ничего или STL, но в правильном контексте? Напишите свои мысли в комментариях)
Stay in reality. Stay cool.
#fun #commercial #STL
Откопаем один из популярнейших холиваров по С++, о котором вы даже могли и не слышать. Из-за того, что мы с вами не носители, то плохо понимаем ориджин терминов, которые сами используем. Ну типа всю нашу жизнь вокруг нас на туалетах написано WC и мы даже не понимаем, а что это значит на самом деле. Но продолжаем в новых заведениях помечать туалет именно этими буквами и просто принимаем это, как данность. Water closet. Так давно в Англии начали назывались маленькие приватные комнатки с подачей воды для смыва.
Так и мы с вами употребляем термин STL скорее в каком-то нашем интуитивном понимании, чем в реальном его значении. Ну вот например, в вакансиях плюсовиков в требованиях часто пишут, что необходимо знание буста и STL. Думаю, что и HR'ы и соискатели удивятся, что 99.9% плюсовиков никогда не пользовались STL....
Утверждение громкое и для кого-то может быть обидное, поэтому погнали разбираться, пока меня тухлыми помидорами не закидали.
С 1979 года, когда мастер-Бьёрн создал С с классами, пройдет почти 20 лет прежде, чем С++ будет стандартизирован в 1998 году. Процесс стандартизации шел долго и люди со временем вносили свои пропоузалы в будущий стандарт. В принципе и сейчас так делают. Так вот. Жил, был и работал в HP один русский эмигрант - Александр Степанов. У него давно были мысли по созданию обобщенной библиотеки, в которой данные и алгоритмы над ними находились бы отдельно друг от друга. Он пытался воплотить свои мысли в жизнь даже в других языках, типа Ada, потому что на тот момент С++ не обладал необходимой функциональностью. Но язык развивался, появились необходимые фичи и Александр начал думать над реализацией своих идей в С++. В конце 1993 года он рассказал о своих наработках бывшему коллеге - Эндрю Кёнингу, который на тот момент работал в ISO комитете С++. Эндрю восхитился замыслом Александра и организовал ему встречу с комитетом. Комитет тоже охал и ахал от гениальности идей и включил их в драфт страндарта С++. Но не полностью. Что-то пришлось удалить и что-то пришлось подкорректировать в сотрудничестве со Степановым. Именно так были созданы стандартные библиотеки алгоритмов, итераторов и контейнеров.
В 1995 году Александр перешел в компанию Silicon Graphics, доработал и релизнул окончательную версию своего видения STL. Ее даже вроде можно скачать тут. То есть это вообще отдельная библиотека, которую надо отдельно подключать к своему проекту. И с почти стопроцентной вероятностью, вы ей никогда не пользовались.
То есть STL никогда не была частью стандарта, хотя и сильно повлияло на него. В тексте стандарта нет ни одного упоминания STL! Но Степанов сам называл включения своей библиотеки в стандартную библиотеку как STL. И авторы многих книг по С++ называли эти включения STL. Даже Страуструп называет стандартные библиотеки алгоритмов, итераторов и контейнеров STL. Поэтому в умах закрепилась эта ассоциация и, в целом, сейчас легитимно называть так этот набор библиотек.
Но мозг людей склонен к обобщениям, поэтому под STL со временем многие начали понимать в принципе всю стандартную библотеку. Масла в огонь подливает еще, что STL можно расшифровать, как STandard Library. Да и другие части stdlib сугубо шаблонизированы. Типа тех же умных указателей или работы со случайными числами. Для многих STL стала уже симулякром в чистом виде, потому что люди забыли изначальное значение этого акронима.
Я не против использования термина STL в качестве референса к либам алгоритмов, итераторов и контейнеров. Даже для stdlib не против. Потому что не понимаю, как это может вредить программисту. Но считаю важным, чтобы люди понимали настоящий смысл слов, которые они употребляют. Используя в жизни ситулякры, мы отдаляемся от реальных вещей и переходим в мир выдуманный, нереальный. А настоящий мир будет продолжать влиять на нас по прежнему и это противоречие может вылиться в проблемы.
А к какому лагерю вы относитесь? Только stdlib и больше ничего или STL, но в правильном контексте? Напишите свои мысли в комментариях)
Stay in reality. Stay cool.
#fun #commercial #STL
Что значит, что фича устрела или удалена
Новые стандарты языка приносят нам кучу разных новых способов решать наши повседневные задачи. Но не только это. Комитет стандартизации думает не только о новом, но и заботится о прошлом. Как минимум примером является обратная совместимость языка при переходе на новый стандарт. Но это не совсем правда. Бывают случаи, когда ломают обратную совместимость в некоторых моментах. Через удаление определенных фичей. Зачем это делают?
Плюсы - довольно старый язык, который пытается сохранить, до определенной степени, совместимость в еще более старым языком - С. Такая большая история говорит о том, что в языке накапливается определенное количество "багов", то есть функциональности, которая уже устарела и/или вреди пользователю. На самом деле такие "баги" выделяют очень строго, когда есть реальная опасность в их использовании. Или все члены комитета согласятся, что от нее нет толку. А комитет состоит из сотен людей, которые непрерывно дебатируют по поводу будущего языка. И если уж они наконец договорились что-то удалить, то это должно сильно встревожить разрабов и воодушевить их на переход на более безопасные альтернативы, которые уже есть в языке.
Такой процесс происходил например с std::autoptr, std::randomshuffle, ключевым словом register, триграфами и прочим.
Их всех объединяет, что для них есть более предпочтительные альтернативы или в современных реалиях они полностью утратили значимость и просто вносят сложность в язык.
Теперь разберем процесс удаления сущности из стандарта.
Для начала она объявляется устаревшей или deprecated. При попытке компиляции с новым стандартом всплывет ворнинг. А в любой нормальной компании ворнинг роняет через бедро сборку проекта. Об этом подробнее здесь рассказывали. И люди просто вынуждены провести небольшой рефакторинг и заменить устаревшую функциональность, чтобы перейти на новый стандарт. Таким образом народ минимально преобразует код, но зато теперь есть возможность использовать фишки нового стандарта, которые могут быть вполне полезными. Ну или забить и не переходить на него. Так тоже иногда делают. Но я бы не хотел работать в такой компании)
После объявления устаревшей стандарт еще какое-то время поддерживает фичу. Но через 3-5-10 лет ее удалят. И больше ее упоминания в стандарте не будет.
Fix your flaws. Stay cool.
#commercial #cppcore
Новые стандарты языка приносят нам кучу разных новых способов решать наши повседневные задачи. Но не только это. Комитет стандартизации думает не только о новом, но и заботится о прошлом. Как минимум примером является обратная совместимость языка при переходе на новый стандарт. Но это не совсем правда. Бывают случаи, когда ломают обратную совместимость в некоторых моментах. Через удаление определенных фичей. Зачем это делают?
Плюсы - довольно старый язык, который пытается сохранить, до определенной степени, совместимость в еще более старым языком - С. Такая большая история говорит о том, что в языке накапливается определенное количество "багов", то есть функциональности, которая уже устарела и/или вреди пользователю. На самом деле такие "баги" выделяют очень строго, когда есть реальная опасность в их использовании. Или все члены комитета согласятся, что от нее нет толку. А комитет состоит из сотен людей, которые непрерывно дебатируют по поводу будущего языка. И если уж они наконец договорились что-то удалить, то это должно сильно встревожить разрабов и воодушевить их на переход на более безопасные альтернативы, которые уже есть в языке.
Такой процесс происходил например с std::autoptr, std::randomshuffle, ключевым словом register, триграфами и прочим.
Их всех объединяет, что для них есть более предпочтительные альтернативы или в современных реалиях они полностью утратили значимость и просто вносят сложность в язык.
Теперь разберем процесс удаления сущности из стандарта.
Для начала она объявляется устаревшей или deprecated. При попытке компиляции с новым стандартом всплывет ворнинг. А в любой нормальной компании ворнинг роняет через бедро сборку проекта. Об этом подробнее здесь рассказывали. И люди просто вынуждены провести небольшой рефакторинг и заменить устаревшую функциональность, чтобы перейти на новый стандарт. Таким образом народ минимально преобразует код, но зато теперь есть возможность использовать фишки нового стандарта, которые могут быть вполне полезными. Ну или забить и не переходить на него. Так тоже иногда делают. Но я бы не хотел работать в такой компании)
После объявления устаревшей стандарт еще какое-то время поддерживает фичу. Но через 3-5-10 лет ее удалят. И больше ее упоминания в стандарте не будет.
Fix your flaws. Stay cool.
#commercial #cppcore
