Здравствуйте, so5team, Вы писали:
S>я понял про #ifndef vs #pragma once, а вот часть про export не понял (разве что export был использован вместо extern).
S>Ключевое слово "expert" в C++ мне не ведомо.
Насколько помню, если ничего не поменялось в новом стандарте как auto, export был нужен в древних компиляторах, где часть реализации шаблонов приходилось писать в cpp файлах, а не в хедерах.
Современные компиляторы скорее всего это слово вообще игнорят, точно так же как они в один момент начали игнорить auto.
И про древние компиляторы которым export был нужен я имею в виду что-то примерно старше Моргенштерна . Кому оно нужно сейчас и правда непонятно
Здравствуйте, __kot2, Вы писали:
S>>я понял про #ifndef vs #pragma once, а вот часть про export не понял (разве что export был использован вместо extern).
S>>Ключевое слово "expert" в C++ мне не ведомо. __>Насколько помню, если ничего не поменялось в новом стандарте как auto, export был нужен в древних компиляторах, где часть реализации шаблонов приходилось писать в cpp файлах, а не в хедерах.
Ключевое слово export было введено в C++98 для того, чтобы можно было выносить код шаблонов из заголовочных файлов.
На практике эта фича была реализована всего в одном малоизвестном и нераспространенном компиляторе (вроде бы EDG) и в дикой природе применения export templates не встречалось от слова совсем.
Поддержка export templates была объявлена как deprecated в C++11, но само ключевое слово в языке осталось как зарезервированное. Попытки его использовать в стандартах C++11/14/17 приводят к предупреждениям со стороны компилятора.
__>Современные компиляторы скорее всего это слово вообще игнорят, точно так же как они в один момент начали игнорить auto. __>И про древние компиляторы которым export был нужен я имею в виду что-то примерно старше Моргенштерна . Кому оно нужно сейчас и правда непонятно
Начиная с C++20 у ключевого слова export появилась новая нагрузка: посредством export указывают сущности, которые должны экспортироваться из модулей (в C++20 в язык была добавлена система модулей).
Можно было бы предположить, что sergey2b работает над проектом уже в стандарте C++20, но тогда непонятно зачем export указывать в заголовочных файлах.
Кстати говоря, если sergey2b работает в рамках более ранних стандартов, где модулей еще нет, и перепутал export с extern, то все равно остается вопрос о том, а зачем в C++ декларации функции в заголовочных файлах помечать как extern.
Здравствуйте, sergey2b, Вы писали:
S>11 месцев все было нормально но 2 недели началась какая то ерунда
не было. ты просто похоже не видишь проблем пока они не бьют тебе по голове.
S>как вы считаете, как нормализовать ситуацию
все же это было у тебя и не один раз. делай как все делал до этого. ты же все равно не сможешь по другому.
Здравствуйте, baxton_ulf, Вы писали: _>где ж ты их таких находишь, Серега? _>если ему хватает время в твои задачи лезть, значит свои не делает. _>а вообще букай митинг с босом и все вместе разруливайте
Коллеги, я уверен, совершенно обычные, плюс минус как у всех.
Серега вот да, софт скилл на нуле или может даже в минус.
Здравствуйте, sergey2b, Вы писали:
S>как вы считаете, как нормализовать ситуацию
Выделить зоны ответственности. Если вы отвечаете за библиотеку — то обязательно прислушиваться к фидбеку её юзеров и делать соотв. изменения. Если кто-то лезит в библиотеку и возникает конфликт — то ясно давать понять, что это вы отвечаете за библиотеку и поэтому не все изменения можете принять.
Когда у всех есть свои зоны ответственности — то и работается легче и конфликтов не возникает. Другое дело, что так построить работу получается далеко не всегда и не у всех, т. к. всё сильно зависит от степени зрелости участников. Например, кто-то не готов отдавать какие-то вещи на исполнение другим людям, твёрдо настаивает на своём — в таком случае можеть быть он сам этим займется раз ему настолько виднее? Либо он знает то, чего пока что не знаете вы — в таком случае нужно внимательно прислушаться к сопроводительным аргументам и хинтам которые сопровождают такую настойчивасть. Если же их нет, а есть только твёрдое "используй Y вместо X" — то это тухлое дело, т. к. либо вы абсолютно ничего не знаете и некомпетентны, либо ваш оппонент — это обязательно приведет к конфликту и к проблемам. Поэтому правила ответственности лучше придерживаться всегда — если вы за что-то беретесь, то вы и несете за эту подсистему полную ответственность, следовательно последнее слово в принятии решений остаётся за вами.
Иначе будет так — один веселый парень посоветовал использовать технологию B вместо A, а потом весело срулил в другое вместо. При этом якорь ответственности и ворох проблем от такого решения остаётся висеть именно на вас, а не на нём. Есть даже поговорка: "пиз*еть языком — не мешки ворочать". В этой ситуации кто-то просто так пошевелил языком, а ворочать мешки получается обязаны вы. Несправедливо, не правда ли? Поэтому и нужна концепция ответственности — от принятия самого решения вплоть до достижения результатов, включая работу на поддержку.
Здравствуйте, sergey2b, Вы писали:
S>вчера этот коллега настоял что я должен переделать библиотеку которую я пишу, так как он иначе жить не может (что не правда) S>я передлал, ночью зачекинил все изменения написал начальнику письмо
S>сегодня утром получаю ведомление, что этот жн коллега переписал теже самые функции и я должен подтвердить его merge request
Здравствуйте, Aquilaware, Вы писали: A>Выделить зоны ответственности. Если вы отвечаете за библиотеку — то обязательно прислушиваться к фидбеку её юзеров и делать соотв. изменения. Если кто-то лезит в библиотеку и возникает конфликт — то ясно давать понять, что это вы отвечаете за библиотеку и поэтому не все изменения можете принять.
тут есть такой интересный неочевидный момент, что менеджер может считать отвественным за ту часть кода другого человека
Возникает такая интересная ролевая игра.
коллега — менеджеру в лично беседе. -что надо сделать для промо?
менеджер — вот если это сдать и ты готов брать ответственность, то с меня потом спросят, а я тебя похвалю
вы менеджеру — хочу таски получше.
менеджер вам — ну, вот, может поучаствовать в этом, а то боюсь не успеем
вы начинаете работать оба и чел может понять, что вы делаете работу лучше него и он вам все время пытается донести мысль, что это его корова. вы обьясняете ситуацию менеджеру, тот чешет репу, он не знает реального вклада ни вас ни коллеги, но так как тому он уже что-то пообещал, что менеджеру проще вас просто проигнорить.
на самом деле это косяк менеджера, но если вы попытаетесь на это указать, то можешь получить лейбл "не командного игрока"
рабочее решение как по мне — искать другого менеджера, то есть команду. если лень, то можно попробовать в лоб спросить кто ответственен за эту часть проекта по факту. добро пожаловать в подковерные войны, короче
S>>добавляет export ко всем деклорациям функций в h файле
S>А, действительно, зачем вы добавляете export к декларациям функций в h-файле? S>(даже если это очепятка и подразумевалось extern, то вопрос все равно остается актуальным)
Жаль, очень жаль, что не удалось послушать начальника транспортного цеха...
S>А, действительно, зачем вы добавляете export к декларациям функций в h-файле? S>(даже если это очепятка и подразумевалось extern, то вопрос все равно остается актуальным)
в проекте много сторонних библиотек и sdk в том числе и на Си
поэтому есть части написанные на Си
если добавлять extern ко всем переменным и функциям в h это более читаемо, и не воникнет ситуации дублирования декларирования переменных
Здравствуйте, Dziman, Вы писали:
D>А это как тогда понять? D>
D>вчера этот коллега настоял что я должен переделать библиотеку которую я пишу, так как он иначе жить не может (что не правда)
человек не разрабатывает данную библиотеку, не использует ее в работе, насколько я знаю иногда копипестит у меня части кода связанных с обратоткой видео
Здравствуйте, sergey2b, Вы писали:
S>если добавлять extern ко всем переменным и функциям в h это более читаемо, и не воникнет ситуации дублирования декларирования переменных
extern для переменных -- это понятно.
А вот для функций extern-а в заголовочных файлов не встречал с начала 90-х.
Если вы сами extern-ы для функций в заголовочных файлах расставляете, то очень похоже, что ваш коллега пытается намекнуть на то, что вы недостаточно хорошо знаете язык программирования, которым пользуетесь. Зачем это ему другой вопрос, но основания вы ему сами подкидываете.
S>А вот для функций extern-а в заголовочных файлов не встречал с начала 90-х.
S>Если вы сами extern-ы для функций в заголовочных файлах расставляете, то очень похоже, что ваш коллега пытается намекнуть на то, что вы недостаточно хорошо знаете язык программирования, которым пользуетесь. Зачем это ему другой вопрос, но основания вы ему сами подкидываете.
это как то ухудшает код ?
в США полно компаний в которых иметь 60 000 строк кода в одном файле или несколько сот методов в одном классе считаеться нормой так что extern это невинная слабость не ухудшающая код
а как вы оцениваете человека который не использует auto в декларации переменных в вычислительном алогритме
ведь можно задекларировать пару сотен auto, современно и возможно будет работать
Здравствуйте, sergey2b, Вы писали:
S>>Если вы сами extern-ы для функций в заголовочных файлах расставляете, то очень похоже, что ваш коллега пытается намекнуть на то, что вы недостаточно хорошо знаете язык программирования, которым пользуетесь. Зачем это ему другой вопрос, но основания вы ему сами подкидываете.
S>это как то ухудшает код ?
Никак. Я и сам, зачастую, ставлю inline для функций-методов в контекстах, в которых это избыточно (скажем, для методов классов прямо в определении класса, для шаблонных функций/методов, особенно если шаблонами они стали в результате рефакторинга). Да, это избыточно, да, мне на это временами указывают, но такова уж привычка из лохматых годов.
Суть не в этом.
S>а как вы оцениваете человека который не использует auto в декларации переменных в вычислительном алогритме
Сильно зависит от типов данных, которые используются в алгоритме. Для каких-то вещей без auto не обойтись.
Здравствуйте, night beast, Вы писали:
S>>А вот для функций extern-а в заголовочных файлов не встречал с начала 90-х.
NB>
NB>extern"C" {
NB>}
NB>
NB>не?
Не. Здесь все так же строго как с extern для переменных. Не будет такого вот extern "C", не будет и нормальной линковки.
Я про то, что в начале 90-х чуть ли не в книгах (на русском языке) приводились примеры того, как в заголовочных файлов объявления функций выполнялись с помощью extern, вроде:
extern int open(const char*);
extern int close(int);
