у меня есть коллега, который начал работать в проекте на месяц раньше меня, principal developer, проработал несколько лет в амазоне
2 недели назад спрашиваю его — как сделать вот это, ответ 2-3 строчки и он его точно знает, тк я видел что он это делал раньше
он отвечает — не скажу
я офигел но решил узнать причину, спрашиваю — почему
на что он отвечает — потому что я посмотрел твой код и он мне не нравиться, я его переделаю
после этого как я теперь знаю — он позвонил к тимлидеру и обсудил с ним мой код без меня, и получил ответ оставить мою версию
в этой истории странно, что он сразу пошел на обостренние, что время между моим вопросом и его ответом было меньше минуты те он мой код смотрел заранее
и что тутже стал обсуждать втихаря не чего мне не сказав
я минимизировал общение с ним
в пятницу тим лидер говорит мне — сделай тот то, а как делать распроси вот этого товарища
я обратился к нему, он распросил о проблемах и что именно я не понимаю
и после этого перестал отвечать на мои сообщения
сегодня утром на стендапе он говорит — я сделал задачу сергея
что это все значит ?
стоит ли обсуждать это с тим лидером, что ситуация выглядит странной
Здравствуйте, sergey2b, Вы писали:
S>что это все значит ? S>стоит ли обсуждать это с тим лидером, что ситуация выглядит странной
А ты в первый раз что-ли такое видишь. Некоторые люди не хотят с тобой или возможно с другими сотрудничать и всё. У них просто такой характер.
Возможные причины проблем.
1. У вас в компании не налажены процессы разработки. Нет сервера с менеджером задач (для примера Redmine), системой управления версий (для примера Git) и непрерывной интеграцией (для примера Jenkins).
2. Тим лид на самом деле не ведущий команды, а просто лицо назначенное сверху. Если тим лиду, менеджеру или кто у вас там плевать на результат сотрудничества, то ты тем более ничего не сделаешь.
Кстати, сейчас у хрюш модно тестировать людей на то могут ли они работать в команде. Это когда один человек подходит к другому и тот его не посылает по координатам xyz, а даже общается или вообще немыслимое работает вместе.
Но хрюши сами по себе бывают токсичны, а в компании с говнопроцессами и без руководства единственный способ делать всё в одиночку. Вспоминаются смешные цитаты.
То, что один программист может сделать за один месяц, два программиста могут сделать за два месяца.
— Фред Брукс
Сейчас у хрюш ещё развилась такая тема как софт скиллы, то есть в переводе на русский умение общаться с людьми. Типа лучше взять человека с софт скиллами, чем с хард скиллами.
Хард скиллы это умение решать технические задачи в одиночку. А софт скиллы это общаться даже с теми, с кем ты не хочешь общаться или вовремя позависать с руководителем.
«Один из лучших навыков программирования, который вы можете получить, — это знать, когда нужно уйти на некоторое время». — Оскар Годсон
Но если собственные хард и софт скиллы не вывозят, есть ещё запасной вариант вовремя свалить. Всё равно 90% стартапов проваливаются, туда им и дорога.
процессы поставленны хорошо, код в git, все обложенно тестами и метриками
постоянный перекрестный код ревью
единственное с чем пока не свыкся это задачи в одну строчку — добавить в X поддержку Y
и что из них что мне не известно
самое длинное описание задачи за два месяйца было в 3 строки
я об этом тоже хотел погворить, но стесняюсь, остальные же молчат
Здравствуйте, reversecode, Вы писали:
R>это означает что я как всегда оказался прав
Так а в чём корень бед? Его опять пытаются выдавить из команды по какой-то причине, вот только не понятно по какой?
Здравствуйте, sergey2b, Вы писали:
S>что это все значит ?
Это значит, что по мнению того товарища вы плохо работаете, не обладаете нужными знаниями и навыками. Обсуждать это с вами — не его компетенция, поэтому он поговорил с менеджером и сообщил о своих переживаниях. То что менеджер некрасиво разруливает ситуацию — ну, я менеджеров тоже не люблю.
У меня были аналогичные ситуации — людей переводили в другие проекты.
Здравствуйте, aik, Вы писали:
aik>По-моему, коллега просто троллит нас
Хорошо если так, но что то не складываются кусочки мозаики в такую картину.
aik> ну, и, по-своему, косплеит мыщьха
Не, чтоб качественно косплеить крЫса ему безумия не хватает.
Здравствуйте, Kernan, Вы писали:
R>>это означает что я как всегда оказался прав K>Так а в чём корень бед?
В нём.
K>вот только не понятно по какой?
Чтобы точно ответить на этот вопрос надо иметь информацию от другой стороны, чтоб сравнить что он про себя рассказывает с тем, что видели и слышали другие.
Здравствуйте, sergey2b, Вы писали:
S>Я примерно аналогично оцениваю ситуацию и причины S>Я налажал работая с командной строки git, раньше такого опыта у меня не было
По одному эпизоду вряд ли кто-то станет делать большие выводы (и тем более действовать), поэтому я думаю, что там успело накопиться достаточно свидетельств.
S>С другой стороны я им уже сделал две задачи которые они не могли сделать много месяцев
Не зная что это за задачи, сложно сделать выводы. Обычно когда приходишь в проект, первые задачи дают тривиальные, "на разогрев" — просто чтобы с рабочим процессом разобраться — откуда клонировать репозиторий, как прогонять тесты локально, как сделать свой бранч, как отправить на код ревью, как смёржить, как передвинуть тикет в джире, и т.д.
наверное вы правы
R>Не зная что это за задачи, сложно сделать выводы. Обычно когда приходишь в проект, первые задачи дают тривиальные, "на разогрев" — просто чтобы с рабочим процессом разобраться — откуда клонировать репозиторий, как прогонять тесты локально, как сделать свой бранч, как отправить на код ревью, как смёржить, как передвинуть тикет в джире, и т.д.
Здравствуйте, sergey2b, Вы писали:
S>сегодня утром на стендапе он говорит — я сделал задачу сергея
А свою задачу он сделал при этом? Или он просто выбирает то, что хочет, не ставя никого в известность?
S>что это все значит ?
Это значит, что он не верит, что ты свою задачу сможешь сделать.
Прав он или нет в своём неверии — вопрос отдельный.
S>стоит ли обсуждать это с тим лидером, что ситуация выглядит странной
Стоит. Или не стоит.
Мы же не знаем твоих отношений с командой и тим лидом.
Соотвественно, не можем оценить риски и потенциальные выгоды от беседы.
Здравствуйте, _ABC_, Вы писали:
_AB>Мы же не знаем твоих отношений с командой и тим лидом. _AB>Соотвественно, не можем оценить риски и потенциальные выгоды от беседы.
отношений еше нет, я работаю всего два месяца
вся команда удаленная по разным странам
Здравствуйте, rosencrantz, Вы писали:
S>principal developer, проработал несколько лет в амазоне R>Обычно когда приходишь в проект, первые задачи дают тривиальные, "на разогрев" — просто чтобы с рабочим процессом разобраться
Могу только сказать что если Principal ломанулся самостоятельно делать задачу, которую выдали новоприбывшему, это довольно таки нехороший знак.
Здравствуйте, CreatorCray, Вы писали:
CC>Могу только сказать что если Principal ломанулся самостоятельно делать задачу, которую выдали новоприбывшему, это довольно таки нехороший знак.
Без контекста — . Может быть, у principal-а стояла работа из-за этой задачи, и ему самому это сделать 5 минут, а Сергею объяснять — час. Я бы так делать не стал, ибо это passive aggressive, и проще дать готовое решение новичку, объяснить, чем оно лучше, и попросить его допилить по мелочи, чтобы заодно разобрался. Но у программистов с дипломатией обычно плохо.
Здесь надо развесить уши локаторами и декодировать, так сказать, данные из субканала. Т.е., кто как о ком отзывается, над чем подшучивает, кто с кем вместе работал, кого привел и т.п. Но Сергей этого делать не умеет, и в итоге, всегда оказывается крайним.
Здравствуйте, Quebecois, Вы писали:
Q>Может быть, у principal-а стояла работа из-за этой задачи, и ему самому это сделать 5 минут, а Сергею объяснять — час.
Скорее всего так оно и было.
Q> Я бы так делать не стал, ибо это passive aggressive
А ждать пока новичок родит — counterproductive.
Q>Но Сергей этого делать не умеет, и в итоге, всегда оказывается крайним.
Bingo!
Здравствуйте, Quebecois, Вы писали:
Q>Без контекста — . Может быть, у principal-а стояла работа из-за этой задачи, и ему самому это сделать 5 минут, а Сергею объяснять — час.
вы правы
я посмотрел все закрытые мной задачи имеют заголовок и половина из них имеет максимум 2 строки описания
я потратил заметное время понять что от меня хотят и нахожусь постянно в стрессе
одна из задачь описанна одной строкой имплементация примерно 2 тыс строк
Здравствуйте, sergey2b, Вы писали:
S>одна из здачь, в инете есть вопросы как сделать, но намек как сделать написал только один человек S>http://rsdn.org/forum/media/8664424.1
S>Я налажал работая с командной строки git, раньше такого опыта у меня не было
Ну как там можно было належать-то, если не совсем джун-то Ну ладно локально что-то не так сделал, ну попросил у кого-то помощи, погуглил, откатил, понял, что не надо это в удаленный репо заливать. Да даже если совсем все плохо было — ну удалил все, переписал с нуля.
Короче, не понимаю, как там можно было критически належать. Это в том числе может говорить о вас как о профессионале. И коллеги могли это учесть.
Здравствуйте, so5team, Вы писали:
S>А вы какой стандарт C++ используете?
c++ 17
в примере кода не было цели написать красиво или по стандарту
конечная цель была получить поинтер на cuda блок памяти которым можно оперировать в opencv
R>>С другой стороны я им уже сделал две задачи которые они не могли сделать много месяцев
S>одна из здачь, в инете есть вопросы как сделать, но намек как сделать написал только один человек S>http://rsdn.org/forum/media/8664424.1
Как-то сомнительно... Вполне простая задача, гуглится на раз-два (точное название функций я не знаю). По сути надо положить в surface/texture в память и потом забрать из другого фреймворка. Две функции по сути нагуглить. Сделал два запроса в Гугле — первые же ссылки выдали ответы
Вряд ли принципал не мог это сделать. Вряд ли какой-то местный сеньор не мог такое сделать. Это мил мог сделать. НАверное, у них до этого не доходили просто руки.
По этим вашим репликам, кстати, можно предположить, что вы там строите из себя мега-гуру с задранным носом и других лошками считаете, типа, "два месяца не могли сделать, на РСДН никто ответить не мог, в целом интернете только 1 ответ был, а тут я пришел такой весь в белом и сразу сделал". А в общении вы можете еще более явно транслировать подобное, если это действительно имеет место быть.
Здравствуйте, DiPaolo, Вы писали:
DP>Ну как там можно было належать-то, если не совсем джун-то Ну ладно локально что-то не так сделал, ну попросил у кого-то помощи, погуглил, откатил, понял, что не надо это в удаленный репо заливать. Да даже если совсем все плохо было — ну удалил все, переписал с нуля.
несколько человек одновременно работают с одним репо
rebase merge все из командной строки
S>процессы поставленны хорошо, код в git, все обложенно тестами и метриками S>постоянный перекрестный код ревью
Пррррррр... стоп-стоп. То, что есть гит и тесты — не означает, что процессы поставлены хорошо. Помимо этого есть еще всякие вопросы менеджмента, описания задач, проведения митингов, шаринг знаний, внутрикомандного и межкомандного взаимодействия и прочее-прочее. Гит — это капля в море.
S>единственное с чем пока не свыкся это задачи в одну строчку — добавить в X поддержку Y S>и что из них что мне не известно S>самое длинное описание задачи за два месяйца было в 3 строки
Здравствуйте, DiPaolo, Вы писали:
DP>Как-то сомнительно... Вполне простая задача, гуглится на раз-два (точное название функций я не знаю). По сути надо положить в surface/texture в память и потом забрать из другого фреймворка. Две функции по сути нагуглить. Сделал два запроса в Гугле — первые же ссылки выдали ответы
поделитесь вашими ответами которые с вашей точки зрения решают эту задачу и работаю в DirectX 12
DP>По этим вашим репликам, кстати, можно предположить, что вы там строите из себя мега-гуру с задранным носом и других лошками считаете, типа, "два месяца не могли сделать, на РСДН никто ответить не мог, в целом интернете только 1 ответ был, а тут я пришел такой весь в белом и сразу сделал". А в общении вы можете еще более явно транслировать подобное, если это действительно имеет место быть.
я из себя мегагуру давно не строю и веду себя скромно
S>несколько человек одновременно работают с одним репо
ну обычно дело. Для того и придумали системы контроля версий
S>rebase merge все из командной строки
и в чем сложность. Вот как выше и описал: попробовал, не получилось — спросил коллег, совсем не получилось — скопипасти в папку, складировал заново, в самом крайнем случае написал заново, сделал копию и пробуешь до посинения
S>rebase merge все из командной строки
ну пользуйся UI клиентом. Я лично так делаю и ничего зазорного в этом нет. Или тебя заставляют из командной строки пользоваться?
Здравствуйте, DiPaolo, Вы писали:
S>>rebase merge все из командной строки DP>и в чем сложность. Вот как выше и описал: попробовал, не получилось — спросил коллег, совсем не получилось — скопипасти в папку, складировал заново, в самом крайнем случае написал заново, сделал копию и пробуешь до посинения
я примерно так и делаю
S>>rebase merge все из командной строки DP>ну пользуйся UI клиентом. Я лично так делаю и ничего зазорного в этом нет. Или тебя заставляют из командной строки пользоваться?
так а что где пошло не так? В чем косяк случился?
S>да заставляют
Тут я хз что сказать. Звучит максимально странно
точно? Может что-то не так понял? Если оно так, то это уже для тебя звонок, что надо крепко задуматься, а не бежать ли оттуда
может, вас еще венгерскую нотацию заставляют использовать?
и да — это признак плохих процессов. Не сам по себе, а как один из признаков. При нормальных процессах всем пофиг на:
— ОСь, под которой ты пишешь
— ИДЕ, которую ты используешь
— ГИТовый клиент
— гуем или командной строкой пользуешься
S>вы правы S>я посмотрел все закрытые мной задачи имеют заголовок и половина из них имеет максимум 2 строки описания S>я потратил заметное время понять что от меня хотят и нахожусь постянно в стрессе
зачем просто возвращаешь и просишь дать описание. Или пинаешь тимлида, ПМа, менеджера, старших коллег, пока не дадут хорошее описание, ЧТО ты должен сделать
как грится "без ТЗ — результат ХЗ"
"процессы у них там хорошие"
тут, конечно, может быть такое, что они тебя специально игнорят и дают задачи без описания + не делают описания, даже если спрашиваешь. И вот тут может быть оттого, что ты им не понравился и они не хотят с тобой работать
S>2 недели назад спрашиваю его — как сделать вот это, ответ 2-3 строчки и он его точно знает, тк я видел что он это делал раньше S>он отвечает — не скажу
можешь дословно привести свой вопрос и его ответ? Что-то вот прям не верится. Это ж все западная бизне-культура: там чтобы получить такой ответ, нужно ооооочень сильно постараться, тем более от новичка в компании
S>я офигел но решил узнать причину, спрашиваю — почему S>на что он отвечает — потому что я посмотрел твой код и он мне не нравиться, я его переделаю
туда же. Даже разрабы-токсики в западной бизнес-культуре обычно так не отвечают. Нужно сильно его достать, а может и вывести из себя. К тому же, он работает там 3 месяца.
S>в этой истории странно, что он сразу пошел на обостренние, что время между моим вопросом и его ответом было меньше минуты те он мой код смотрел заранее S>и что тутже стал обсуждать втихаря не чего мне не сказав
ну учитывая, что он сам в компании 3 месяца всего лишь, видимо он либо в хороших отношения с ТЛ, либо уже поняли про тебя и поставили на тебе крест
S>что это все значит ?
я в прошлые разы пытался помочь тебе. Другие смеялись, мол, все то же самое. Теперь я тоже понимаю: у тебя каждый раз по кругу. И всегда одно и то же. Тебе наверное это незаметно, но так и есть. Ты каким-то образом постоянно попадаешь вот в такие ситуации.
либо ты сам такие компании подсознательно выбираешь, либо ты сам себя каким-то образом ведешь так, что провоцируешь других на обострение отношений и игнор тебя, а потом и саботаж.
Здравствуйте, sergey2b, Вы писали:
S>>А вы какой стандарт C++ используете?
S>c++ 17
Хм...
#include"opencv2/core.hpp"#include <opencv2/core/utility.hpp>
#include"opencv2/highgui.hpp"#include"opencv2/imgproc.hpp"#include"opencv2/cudaimgproc.hpp"#include"cuda_runtime.h"#include"device_launch_parameters.h"#include <stdio.h> // Почему не cstdio?#include <stdlib.h> // Почему не cstdlib?
// Ну и главное: а зачем это все?using namespace std;
using namespace cv; // Зачем это, если все равно ниже cv::Mat и cv::cuda::GpuMat?using namespace cv::cuda;
//#define hsize 256
//#define vsize 256#define hsize 1024 /* define в C++?!!! Почему не constexpr? Ну или хотя бы const? */#define vsize 1024 /* define в C++?!!! Почему не constexpr? Ну или хотя бы const? */#define IMAGE_TYPE unsigned char/* Почему не using? Почему не typedef накрайняк? */
/* Зачем здесь вообще этот IMAGE_TYPE, если он не используется? */int main()
{
uint8_t* imgPtr; // Почему не std::uint8_t?
// Почему без начального значения? Сложно написать imgPtr{}?
cv::Mat left, downloadedLeft;
cv::cuda::GpuMat gpuLeft;
// Какой смысл в C++ все переменные объявлять в начале функции?
// Почему нельзя было сделать так:
//
// cv::Mat left = imread("c:/videos/leftview.jpg", cv::IMREAD_GRAYSCALE);
// cv::cuda::GpuMat gpuLeft(left);
left = imread("c:/videos/leftview.jpg", cv::IMREAD_GRAYSCALE);
gpuLeft.upload(left);
// Приведение в стиле Си? В C++ должен быть reinterpret_cast.
cudaMalloc((void**)&imgPtr, gpuLeft.rows * gpuLeft.step);
cudaMemcpyAsync(imgPtr, gpuLeft.ptr<uint8_t>(), gpuLeft.rows * gpuLeft.step, cudaMemcpyDeviceToDevice);
// following code is just for testing and visualization...
cv::cuda::GpuMat gpuImg(left.rows, left.cols, left.type(), imgPtr, gpuLeft.step);
gpuImg.download(downloadedLeft);
imshow("test", downloadedLeft);
waitKey(0);
return 0;
}
В общем, есть ощущение, что:
a) человек не владеет современным C++ (хотя бы C++11);
b) человек разделяет "нормальный" код и код "на выброс", т.е. позволяет писать себе в стиле "на отвали". Что подозрительно.
S>в примере кода не было цели написать красиво или по стандарту
C++ник должен иметь навык писать нормально сразу. Даже с таким навыком со временем код превращается в говно, а без оного он таким оказывается сразу. Безопасные языки наплевательское отношение к качеству исходников до какой-то степени прощают, а вот C++ -- нет.
Соответственно, если бы мне попадалось много фрагментов кода коллег, написанных в таком духе, то я бы поставил вопрос об их служебном соответствии. Правда, я бы сперва провел ликбез и на конкретных примерах объяснил бы людям что плохо и почему. Но если бы это не дало результата, то точно бы озадачил руководство вопросом о целесообразности держать таких пассажиров на борту.
S>это один из 2 как то работающих примеров что я нашел
S>это пример не позволяет получить указатель который можно использовать в opencv S>вот этот человек https://forums.unrealengine.com/t/copy-render-frame-directx12-to-opencv/1387467 S>пытаеться сделать кофнвертацию базируясь на приведенном вами примере и у него тоже не получаеться
S>в вашем примере человек cv::cuda::GpuMat data on gpu
ну ясен пень что надо докурить это. Я ж не буду сейчас все это делать. Суть задачи ясна (кстати, от вас она была не очень четко сформулирована — это тоже может быть вашей проблемой, котороую видят ваши коллеги):
— D3D12 texture to cuda (но видимое не D3D, а DirectX)
— opencv read texture from cuda
S>в моем случаи надо из DirectX использовать cuda а потом передать поинтер на блокпамяти в cuda в opencv что бы не копировать 4к фреймы
Здравствуйте, sergey2b, Вы писали:
S>поделитесь вашими ответами которые с вашей точки зрения решают эту задачу и работаю в DirectX 12
А где в твоём решении хоть один вызов DX12?
Здравствуйте, sergey2b, Вы писали:
S>я посмотрел все закрытые мной задачи имеют заголовок и половина из них имеет максимум 2 строки описания S>я потратил заметное время понять что от меня хотят и нахожусь постянно в стрессе S>одна из задачь описанна одной строкой имплементация примерно 2 тыс строк
Дай-ка я угадаю: взяли на Senior позицию?
Возможно ещё и в стартап (возможно бывший, свежекупленный)?
Здравствуйте, sergey2b, Вы писали:
S>несколько человек одновременно работают с одним репо
Это как бы норма
S>rebase merge все из командной строки
Дык просто поставь себе клиента, тот же Fork порекомендую — очень удобный и работает не в пример быстрее чем Source Tree.
Здравствуйте, CreatorCray, Вы писали:
S>>поделитесь вашими ответами которые с вашей точки зрения решают эту задачу и работаю в DirectX 12 CC>А где в твоём решении хоть один вызов DX12?
я не публиковал своего решения
если взять приведенный DiPaolo пример, творчески его допилить, использовать мой пример
то задача решиться
Здравствуйте, sergey2b, Вы писали:
S>в моем случаи надо из DirectX использовать cuda а потом передать поинтер на блокпамяти в cuda в opencv что бы не копировать 4к фреймы
Здравствуйте, so5team, Вы писали:
S>define в C++?!!! Почему не constexpr? Ну или хотя бы const?
А не пофигу ли?
Мeня вон например новомодный nullptr откровенно раздражает, потому продолжаю пользоваться NULL, ибо под капотом там одно и то же но NULL в коде в глаза бросается получше.
S>Почему не std::uint8_t?
А зачем?
S>Приведение в стиле Си? В C++ должен быть reinterpret_cast.
Это одна из тех практик которые у меня лично вызывают cringe.
Я знаю что новые касты намеренно сделали fugly, и именно это мне в них и не нравится.
Потому если уж приходится кастить (и это не редчайший случай dynamic_cast, для которого нет альтернативы) то я предпочитаю function style cast, ибо если уж до такого дошло то я точно знаю что должно получиться.
По остальному особых возражений нет.
S>Безопасные языки наплевательское отношение к качеству исходников до какой-то степени прощают, а вот C++ -- нет.
Плюсы в первую очередь не прощают бардак в голове, исходники всего лишь его отражение в текстовом виде.
А попробуй не «налаживать с ним отношения», а просто делать работу так, чтоб никакой урод не пискнул.
Не туда направляешь ментальную и эмоциональную энергию
Здравствуйте, sergey2b, Вы писали:
S>да свежекупленный
Тогда там ещё стартапская культура "скорей, скорей, завтра будет поздно!!!"
Отсюда и крайне сжатые сроки и высокие требования к самостоятельности (АКА Seniority) девелоперов.
Здравствуйте, Артём, Вы писали:
Аё>PS перекличка сипипи фаперов произведена .
Вот чтоб именно С++ в данной задаче нету совсем, банальная проблема знания нужного API и как его правильно использовать.
H>А попробуй не «налаживать с ним отношения», а просто делать работу так, чтоб никакой урод не пискнул. H>Не туда направляешь ментальную и эмоциональную энергию
Здравствуйте, CreatorCray, Вы писали:
S>>я не публиковал своего решения CC>А это не твоё? Там тобой же написано так что нет никаких намёков на то, что это не твоё решение. CC>Re: запись D3D12 texture в cuda и отображение через opencv
Здравствуйте, sergey2b, Вы писали:
S>как впрочем там нет не единого намека что это мое решение
Было опубликовано тобой, нет ни одного указания что ты его где то взял — значит твоё.
Если не твоё — было бы неплохо указать авторство или хотя бы источник.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Hоmunculus, Вы писали:
H>>Просто не вижу смысла в умничаньях «ну воооот опяяяять», а просто дал совет
CC>Ты думаешь ты тут такой первый?
Не ставил перед собой цели быть первым. И кстати, моя пара предложений заняло у меня гораздо меньше времени чем ваши опусы по поводу «никогданебылоивотопять»
Здравствуйте, CreatorCray, Вы писали:
S>>define в C++?!!! Почему не constexpr? Ну или хотя бы const? CC>А не пофигу ли?
Во-первых, это демонстрирует привычки. Если человек в C++ продолжает использовать define, то это, имхо, плохой знак. Начиная с C++98 оставалось не так много мест, для define были бы удобны для задания констант, а начиная с С++17 таких мест, вроде бы, вообще не осталось.
Если не писать заголовочные файлы, которые могут использоваться как в чистом Си, так и в C++ (т.е. если выйти за рамки Си-шного подмножества), то надобности в define для констант в C++ уже нет. И это уже должно было бы закрепиться на уровне привычек.
Во-вторых, потенциальные проблемы значений из define никуда не уходят.
В случае constexpr, скорее всего, было бы написано:
constexpr unsigned hsize = 1000;
и у hsize был бы тип unsigned не смотря на то, что инициализируется он литералом типа int.
В случае define у hsize значение будет иметь тип int, что затем, скорее всего, приведет к смешению unsigned и signed значений в выражениях.
Ну и прочие потенциальные прелести define-ов.
CC>Мeня вон например новомодный nullptr откровенно раздражает, потому продолжаю пользоваться NULL, ибо под капотом там одно и то же но NULL в коде в глаза бросается получше.
ЕМНИП, я и в C++98 NULL не особо-то использовал, т.к. (опять же ЕМНИП) были рекомендации в C++ просто применять значение 0.
S>>Почему не std::uint8_t? CC>А зачем?
Когда в проекте смешивается куча разных библиотек, лучше бы явно указывать uint8_t из какой именно нам нужен.
Но здесь, скорее всего, подразумевался именно std::uint8_t, т.к. выше был using namespace std;
S>>Приведение в стиле Си? В C++ должен быть reinterpret_cast. CC>Это одна из тех практик которые у меня лично вызывают cringe. CC>Я знаю что новые касты намеренно сделали fugly, и именно это мне в них и не нравится. CC>Потому если уж приходится кастить (и это не редчайший случай dynamic_cast, для которого нет альтернативы) то я предпочитаю function style cast, ибо если уж до такого дошло то я точно знаю что должно получиться.
Как раз из-за того, что наличие кастов -- это плохой знак, то лучше всего когда касты сразу бросаются в глаза. Особенно C-шные касты опасны в случае const значений, т.к. сишный каст может снимать константность без каких-либо предупреждений.
S>>Безопасные языки наплевательское отношение к качеству исходников до какой-то степени прощают, а вот C++ -- нет. CC>Плюсы в первую очередь не прощают бардак в голове, исходники всего лишь его отражение в текстовом виде.
Здравствуйте, Hоmunculus, Вы писали:
H>И кстати, моя пара предложений заняло у меня гораздо меньше времени чем ваши опусы по поводу «никогданебылоивотопять»
Замечательно, тут ты тоже не был первым.
Мы потратили куда больше времени прежде чем в итоге переключиться в facepalm mode.
Здравствуйте, so5team, Вы писали:
S>Во-первых, это демонстрирует привычки.
#define для констант и удобнее и универсальнее.
S> Если человек в C++ продолжает использовать define, то это, имхо, плохой знак.
S>а начиная с С++17 таких мест, вроде бы, вообще не осталось.
И что же удобнее?
S>надобности в define для констант в C++ уже нет.
Тем не менее они продолжают прекрасно работать (и бесить пуристов )
S> И это уже должно было бы закрепиться на уровне привычек.
Кому должно?
S>и у hsize был бы тип unsigned
И нахрена он там нужен?
S>В случае define у hsize значение будет иметь тип int
#define не имеет типа. По определению. Препроцессор не так работает.
S>Когда в проекте смешивается куча разных библиотек, лучше бы явно указывать uint8_t из какой именно нам нужен. S>Но здесь, скорее всего, подразумевался именно std::uint8_t, т.к. выше был using namespace std;
А тебя там не смутил using namespace std?
S>Как раз из-за того, что наличие кастов -- это плохой знак, то лучше всего когда касты сразу бросаются в глаза.
А они и так бросаются, но комитетский вариант ещё и уродлив донельзя.
Здравствуйте, CreatorCray, Вы писали:
S>>Во-первых, это демонстрирует привычки. CC>#define для констант и удобнее и универсальнее.
Как хорошо, что я с вами не работаю. Надеюсь, что и не придется.
S>> Если человек в C++ продолжает использовать define, то это, имхо, плохой знак. CC>
Вы -- наглядный пример. До сих пор жить с NULL и вещать с таким апломбом -- это нужно суметь. А вы умеете с завидной регулярностью. Впрочем нет, не завидной.
S>>а начиная с С++17 таких мест, вроде бы, вообще не осталось. CC>И что же удобнее?
Появился inline const, так что даже строковые константы сейчас можно запросто в заголовочных файлах объявлять в виде const std::string.
S>>надобности в define для констант в C++ уже нет. CC>Тем не менее они продолжают прекрасно работать (и бесить пуристов )
Прекрасно только до первой проблемы.
S>> И это уже должно было бы закрепиться на уровне привычек. CC>Кому должно?
Не вам, не парьтесь.
S>>и у hsize был бы тип unsigned CC>И нахрена он там нужен?
Есть люди, которые считают, что размеры и индексы желательно иметь беззнаковыми. Для них там нужен будет unsigned (или std::size_t).
Для остальных сойдет и какой-то знаковый целочисленный тип.
S>>В случае define у hsize значение будет иметь тип int CC>#define не имеет типа. По определению. Препроцессор не так работает.
Речь не про препроцессор, а про значение, которое подставляется в код. Это значение будет иметь тип int.
S>>Когда в проекте смешивается куча разных библиотек, лучше бы явно указывать uint8_t из какой именно нам нужен. S>>Но здесь, скорее всего, подразумевался именно std::uint8_t, т.к. выше был using namespace std; CC>А тебя там не смутил using namespace std?
Смутил.
S>>Как раз из-за того, что наличие кастов -- это плохой знак, то лучше всего когда касты сразу бросаются в глаза. CC>А они и так бросаются
Увы, нет. Особенно в коде любителей длинных строк (от 120 и дальше) и трехэтажных выражений.
Здравствуйте, so5team, Вы писали:
S>Как хорошо, что я с вами не работаю.
Взаимно. Давно устал от пуристов, которым форма важнее содержания.
S> Надеюсь, что и не придется.
Аналогичен просто до безобразия!
S>До сих пор жить с NULL и вещать с таким апломбом -- это нужно суметь.
NULL жеж implementation specific и под капотом там #define NULL nullptr
Ах да, тыж #define отверг с негодованием!
Пуристы, такие пуристы!
S>Появился inline const, так что даже строковые константы сейчас можно запросто в заголовочных файлах объявлять в виде const std::string.
Замечательно, а если мне не надо в виде const std::string?
Если одна и та же строка может быть использована для передачи в API который принимает const WCHAR* и const char* + ещё и законкатеначена с другой?
Код жеж пишется не в вакууме.
S>Прекрасно только до первой проблемы.
А когда они начнут проявляться? С прошлого века всё жду.
S>Есть люди, которые считают, что размеры и индексы желательно иметь беззнаковыми. Для них там нужен будет unsigned (или std::size_t).
Это не отвечает на вопрос зачем константу заранее запихивать в фиксированный тип
S>Речь не про препроцессор, а про значение, которое подставляется в код. Это значение будет иметь тип int.
Это значение будет посимвольно скопировано в выхлоп препроцессора как будто ты его натайпал руками прямо в месте разворачивания макры.
S>Увы, нет. Особенно в коде любителей длинных строк (от 120 и дальше)
Достаточно не жалеть пробелов и явно расставлять скобки.
Проблемы читабельности возникают от сгущённого кода, в котором не видно его структуры.
S> и трехэтажных выражений.
Такого делать не надо, да.
Здравствуйте, CreatorCray, Вы писали:
S>>Как хорошо, что я с вами не работаю. CC>Взаимно. Давно устал от пуристов, которым форма важнее содержания.
Вы путаете пуристов и людей с многократно отстрелянными ногами. Поэтому там, где одним видится устав, написанный кровью, другим мерещатся эстетические изыски. Впрочем, ваше самомнение в очередной раз не дает вам осознать многообразие мира.
S>>До сих пор жить с NULL и вещать с таким апломбом -- это нужно суметь. CC>NULL жеж implementation specific и под капотом там #define NULL nullptr
Во времена C++98 не было nullptr и отказаться от использования NULL следовало уже тогда.
CC>Ах да, тыж #define отверг с негодованием!
И вам советовал бы, если бы вы могли посмотреть дальше своего носа.
S>>Появился inline const, так что даже строковые константы сейчас можно запросто в заголовочных файлах объявлять в виде const std::string. CC>Замечательно, а если мне не надо в виде const std::string?
Делайте не в виде std::string, а в виде любого другого типа. После появления inline const в C++17 это возможно.
CC>Если одна и та же строка может быть использована для передачи в API который принимает const WCHAR* и const char* + ещё и законкатеначена с другой? CC>Код жеж пишется не в вакууме.
Можно пример?
S>>Прекрасно только до первой проблемы. CC>А когда они начнут проявляться? С прошлого века всё жду.
Когда подключитесь к проекту, в котором у C++ников знания и умения будут пониже вашего. Долго ждать не придется.
S>>Есть люди, которые считают, что размеры и индексы желательно иметь беззнаковыми. Для них там нужен будет unsigned (или std::size_t). CC>Это не отвечает на вопрос зачем константу заранее запихивать в фиксированный тип
Чтобы у константны был конкретный тип.
S>>Речь не про препроцессор, а про значение, которое подставляется в код. Это значение будет иметь тип int. CC>Это значение будет посимвольно скопировано в выхлоп препроцессора как будто ты его натайпал руками прямо в месте разворачивания макры.
Ну сделайте следующий логический шаг: у вас вместо hsize будет 1000, что будет представлять из себя литерал типа int. И для многих будет сюрпризом, что это именно int, а не unsigned int или std::size_t.
S>>Увы, нет. Особенно в коде любителей длинных строк (от 120 и дальше) CC>Достаточно не жалеть пробелов и явно расставлять скобки.
Вот только почему-то многие этого не делают.
CC>Проблемы читабельности возникают от сгущённого кода, в котором не видно его структуры.
Здравствуйте, so5team, Вы писали:
S>Вы путаете пуристов и людей с многократно отстрелянными ногами. S> Поэтому там, где одним видится устав, написанный кровью, другим мерещатся эстетические изыски.
Ты это что, предлагаешь пиписьками меряться что ли?
Я с прошлого века живу в плюсах, причём приличная доля этого проведена в кернеле, где баги приводят к обрушению всей машины или порче данный на storage.
До нынешнего места писал enterprize virtualized storage, там вообще можно было протеривать кастомерскую инфу распределённо и сразу терабайтами.
Как ты думаешь, какой у меня опыт написания непадучего кода?
S>Во времена C++98 не было nullptr и отказаться от использования NULL следовало уже тогда.
S>Делайте не в виде std::string, а в виде любого другого типа.
Тот тип, в виде кого мне как правило нужны строковые константы, банально не constexpr-able, так что не применимо.
CC>>Если одна и та же строка может быть использована для передачи в API который принимает const WCHAR* и const char* + ещё и законкатеначена с другой? S>Можно пример?
Пример чего именно? Как работают макросы со строками? Как конкатенация L"blah" "foo" даёт L"blahfoo"?
S>Когда подключитесь к проекту, в котором у C++ников знания и умения будут пониже вашего.
И сколько таких проектов должно случиться?
S> Долго ждать не придется.
А я всё жду и жду...
CC>>Это не отвечает на вопрос зачем константу заранее запихивать в фиксированный тип S>Чтобы у константны был конкретный тип.
И это нужно зачем именно? Я и через define то же самое сделаю, только в явном виде а не потому что хоть какой то тип придётся задать?
S>Ну сделайте следующий логический шаг: у вас вместо hsize будет 1000, что будет представлять из себя литерал типа int.
И чем именно это будет отличаться если я прямо в коде вместо hsize напишу 1000?
S> И для многих будет сюрпризом, что это именно int, а не unsigned int или std::size_t.
Там, где важно задать размерность — её надо задавать в явном виде полюбас.
Вне зависимости через какой из множества вариантов эта константа определена.
S>Вот только почему-то многие этого не делают.
Они ещё много чего не делают, и?
Подавляющему колву погромистов и вовсе нельзя давать пользоваться всем сабсетом языка.
А за попытки усложнять и наворачивать без реальной на то необходимости — бить по рукам.
CC>>Проблемы читабельности возникают от сгущённого кода, в котором не видно его структуры. S>Вам бы в реальный мир окунуться.
Куда уж реальнее
Здравствуйте, CreatorCray, Вы писали:
CC>Ты это что, предлагаешь пиписьками меряться что ли?
Нет, у тех, кто это предлагает, явно длиннее.
CC>Я с прошлого века живу в плюсах, причём приличная доля этого проведена в кернеле, где баги приводят к обрушению всей машины или порче данный на storage. CC>До нынешнего места писал enterprize virtualized storage, там вообще можно было протеривать кастомерскую инфу распределённо и сразу терабайтами. CC>Как ты думаешь, какой у меня опыт написания непадучего кода?
Я, я, я... В жопу себе свое самомнение засуньте, а то я уже устал указывать вам на его чрезмерную раздутость.
Вы, полагаю, работаете в больших компаниях, с суровым отбором, с опытными специалистами, отлаженными процессами, нормальными бюджетами и сроками.
Кроме этого есть и случаи, когда код пишут вчерашние студенты, да еще и под руководством 20-летних сеньоров или дедов, которые о C++ составили впечатление в 1989-ом году и с тех пор дальше не продвинулись.
И если вы не видите в своих проектах чего-то вроде:
то это не значит, что такого нет за пределами вашего сурового ынтырпрайзного мира. К сожалению.
S>>Делайте не в виде std::string, а в виде любого другого типа. CC>Тот тип, в виде кого мне как правило нужны строковые константы, банально не constexpr-able, так что не применимо.
Это вы от незнания предмета стали путать inline const и constexpr? Или от невнимательности?
Я вообще-то говорил о inline const на примере const std::string. А не о constexpr std::string.
CC>>>Если одна и та же строка может быть использована для передачи в API который принимает const WCHAR* и const char* + ещё и законкатеначена с другой? S>>Можно пример? CC>Пример чего именно? Как работают макросы со строками? Как конкатенация L"blah" "foo" даёт L"blahfoo"?
Пример того, как это используется.
S>>Когда подключитесь к проекту, в котором у C++ников знания и умения будут пониже вашего. CC>И сколько таких проектов должно случиться?
Одного должно бы хватить.
CC>>>Это не отвечает на вопрос зачем константу заранее запихивать в фиксированный тип S>>Чтобы у константны был конкретный тип. CC>И это нужно зачем именно?
Хотя бы затем, чтобы было меньше неявных преобразований типов и неявного смешения разных типов в одном выражении.
S>>Ну сделайте следующий логический шаг: у вас вместо hsize будет 1000, что будет представлять из себя литерал типа int. CC>И чем именно это будет отличаться если я прямо в коде вместо hsize напишу 1000?
У вас будет такой же литерал типа int. И, повторюсь, для многих это будет неожиданно. Как, например, для многих неожиданно, что "abc" -- это const char[4].
S>> И для многих будет сюрпризом, что это именно int, а не unsigned int или std::size_t. CC>Там, где важно задать размерность — её надо задавать в явном виде полюбас. CC>Вне зависимости через какой из множества вариантов эта константа определена.
Я лично немного видел define-ов, которые бы выглядели вот так:
#define SIZE 100u
или так:
#define LONG_SIZE 100ull
И если уж заставлять людей выписывать тип, то зачем зазубривать особенности define-ов, если можно сделать:
constexpr unsigned size{ 100 };
constexpr unsigned long long long_size{ 100 };
S>>Вот только почему-то многие этого не делают. CC>Они ещё много чего не делают, и?
И лучше их заставлять находиться в жестких рамках, чем позволять пользоваться небезопасными возможностями.
Здравствуйте, sergey2b, Вы писали:
S>у меня есть коллега, который начал работать в проекте на месяц раньше меня, principal developer, проработал несколько лет в амазоне
S>2 недели назад спрашиваю его — как сделать вот это, ответ 2-3 строчки и он его точно знает, тк я видел что он это делал раньше S>он отвечает — не скажу S>я офигел но решил узнать причину, спрашиваю — почему S>на что он отвечает — потому что я посмотрел твой код и он мне не нравиться, я его переделаю S>после этого как я теперь знаю — он позвонил к тимлидеру и обсудил с ним мой код без меня, и получил ответ оставить мою версию
S>в этой истории странно, что он сразу пошел на обостренние, что время между моим вопросом и его ответом было меньше минуты те он мой код смотрел заранее S>и что тутже стал обсуждать втихаря не чего мне не сказав
S>я минимизировал общение с ним
S>в пятницу тим лидер говорит мне — сделай тот то, а как делать распроси вот этого товарища S>я обратился к нему, он распросил о проблемах и что именно я не понимаю S>и после этого перестал отвечать на мои сообщения
S>сегодня утром на стендапе он говорит — я сделал задачу сергея
S>что это все значит ? S>стоит ли обсуждать это с тим лидером, что ситуация выглядит странной
Думаю я бы пробовал решить задачу сам и параллельно подыскивал новое место работы
Здравствуйте, Aleksei_Lekomtsev, Вы писали:
A_L>Думаю я бы пробовал решить задачу сам и параллельно подыскивал новое место работы
Он этим перманентно занимается
Здравствуйте, sergey2b, Вы писали:
S>я посмотрел все закрытые мной задачи имеют заголовок и половина из них имеет максимум 2 строки описания S>я потратил заметное время понять что от меня хотят и нахожусь постянно в стрессе S>одна из задачь описанна одной строкой имплементация примерно 2 тыс строк
Не надо стресса. Открываешь OneNote, составляешь список неизвестных вещей. Гуглишь, заполняешь пробелы. Составляешь документ на 1-2 страницы, где описываешь, что и как будешь имплементировать, и какие есть вопросы и пробелы. Отправляешь по почте коллегам и CC начальству. Это проходит пару-тройку итераций редактирования, пока все не согласятся, ты добавляешь сроки и промежуточные deliverables, отправляешь начальству и идешь кодить.
Это поведение сеньора. А "мне не показали куда копать" — это тебя щас снова уволят и отправишься обратно баги фиксить ради самооценки очередного самодура.
А с не отвечающим коллегой, у вас разные стили общения. Одному, написать-принять 100 сообщений в день не помеха, а другому подавай документ на ревью раз в день. Я, например, из вторых и не могу работать, когда меня постоянно отвлекают. Если бы пришел джун и пинал бы меня каждые 5 минут, я бы тоже на стенку полез (точнее, тактично бы обсудил с ним и начальником, как наладить общение, чтобы всем было удобно).
Здравствуйте, sergey2b, Вы писали: S>сегодня утром на стендапе он говорит — я сделал задачу сергея S>что это все значит ? S>стоит ли обсуждать это с тим лидером, что ситуация выглядит странной
Дело тут совершенно не в исходном коде и не в подходе к труду, который ты используешь. Ты переехал за рубеж, а ожидаешь от тамошних людей отношения, свойственного тому, к чему ты привык на родине. В этом заключена суть недопонимания.
Представим, что идёшь ты по пригороду Бостона. Газончики подстрижены, заборчики покрашены. Обывателю кажется, что как тут всё прекрасно и какие аккуратные люди тут живут! Только дело тут в том, что заборы покрашены не потому что люди такие заботливые, а потому что людей накажут, если газоны будут нестриженные и заборы непокрашенные. Люди просто опасаются штрафов и наказаний.
Заходим в контору на работу. Никто не болтает, все сидят и делают вид, что усердно трудятся. Тут тоже дело не в том, что сотрудники такие сознательные, а в том, что если расслабиться и начать бездельничать, то свои же сотрудники, с кем ты десять минут назад пил чаёк, сходят к начальству втихаря и донесут на тебя "из благих побуждений ради процветания общего дела". Поэтому все сотрудники сидят и помалкивают из-за опаски доноса.
Необходимо просто понять, что окружающие условия создаются людьми, а не возникают сами по себе. Если ты выбрал жизнь на Западе, то будь готов к тому, что сотрудники будут ходить с доносами на тебя к начальству, соседи будут вызывать полицию при малейшем шуме, а баба сбежит к другому мужику ибо в эгоистичном обществе, где каждый думает только о себе, крепкая семья неизбежно развалится.
Пойми уже, что американцы, как народ, это говно. Тогда и недопонимания не будет.
Здравствуйте, so5team, Вы писали:
S>Я, я, я... В жопу себе свое самомнение засуньте
Порвался таки, а как дышал...
S>Кроме этого есть и случаи, когда код пишут вчерашние студенты, да еще и под руководством 20-летних сеньоров
И? Как это влияет на людей с опытом, которые знают как оно устроено, как оно работает, и которым не надо ритуальные подгузники чтобы писать нормальный код.
В серьёзных проектах никто в здравом уме не станет подпускать маппетов к коду, ибо как ты не приседай они всё равно накосячат, и на борьбу с ними всё равно будет уходить слишком много времени.
S>И если вы не видите в своих проектах чего-то вроде: S>
Я вижу тут ровно одну проблему: недостаток скобок.
S>Это вы от незнания предмета стали путать inline const и constexpr? S>Я вообще-то говорил о inline const на примере const std::string. А не о constexpr std::string.
А я говорил про строковые константы, инициализация которых даже через constexpr не выразима.
S>Пример того, как это используется.
#define FOO_FILEPATH "/blah/bar/foo"
#define FOO_FILEPATH_W L"" FOO_FILEPATH
S>>>Когда подключитесь к проекту, в котором у C++ников знания и умения будут пониже вашего. CC>>И сколько таких проектов должно случиться? S>Одного должно бы хватить.
Если уровень пониже на порядок — таких просто не берём, ибо вреда от них больше чем пользы.
Если просто слегка пониже то это либо достаточно быстро дотягивается до достаточного, либо досвидульки.
S>Хотя бы затем, чтобы было меньше неявных преобразований типов и неявного смешения разных типов в одном выражении.
Эк ты заморачиваешься на ровном месте.
S>У вас будет такой же литерал типа int. И, повторюсь, для многих это будет неожиданно.
Ты хочешь сказать что если тебе надо в коде что то перемножить на 3 то ты вместо foo *= 3; будешь заводить отдельную константу с явно прописанным типом и потом умножать на неё?
S> Как, например, для многих неожиданно, что "abc" -- это const char[4].
А также const char*, и чо?
S>Я лично немного видел define-ов, которые бы выглядели вот так: S>
S>#define SIZE 100u
S>
S>или так: S>
S>#define LONG_SIZE 100ull
S>
Потому что в подавляющем колве случаев такие заморочки нафиг не нужны.
S>И если уж заставлять людей выписывать тип, то зачем зазубривать особенности define-ов, если можно сделать: S>
S>constexpr unsigned size{ 100 };
S>constexpr unsigned long long long_size{ 100 };
S>
Не надо замусоривать код. Тип для константы выписывается там, где он реально нужен.
S>И лучше их заставлять находиться в жестких рамках, чем позволять пользоваться небезопасными возможностями.
Студней — да, пока не осознают.
Спецы знают как оно работает, сам себя ограничивают где это приносит максимальную пользу, но детские памперсы им только мешают.
Всё давно придумано до нас:
Когда начинаешь что то изучать то следуешь советам: никогда не делай Х
Когда изучил — понимаешь почему никогда не надо делать Х
Когда поднабрался опыта — осознаёшь что иногда всё таки надо делать Х
Когда накопил достаточно опыта — точно знаешь когда надо делать Х
Когда спрашивают "а как правильно" — осознаёшь что объяснить все нюансы не хватит никакого времени и терпения, вздыхаешь и говоришь "никогда не делай Х!"
(С) прошлый век
Здравствуйте, sergey2b, Вы писали:
S>Коллега китаец проработавший в Амазоне несколько лет
Китаец из Китая, китаец из Гонконга, или же китаец выросший уже здесь?
Это три большие разницы
Здравствуйте, sergey2b, Вы писали:
S>Дополню твой список S>Китаец и Тайваня, китаец из Сингапура и китаец из Малайзии
Это уже тайванец, сингапурец и малайзиец
Слишком давно разделение произошло, культуры уже сильно разные.
Если правда не использовать "китаец" в смысле "азиат, но откуда именно — сходу не понятно"
Здравствуйте, Doom100500, Вы писали:
Аё>>Наверное это недокументированная фича
D>В моём детстве в школе училки говорили в подобных случаях "Услышал звон, да не знаю где он".
А ты шо, знаток OpenCV? Я то с ним имел секас работать.
Аё>>PS перекличка сипипи фаперов произведена .
D>А не это: "смотрю в книгу — вижу фигу".
Здравствуйте, CreatorCray, Вы писали:
S>>Я, я, я... В жопу себе свое самомнение засуньте CC>Порвался таки, а как дышал...
Как дышал, так и дышу: я вам говорю объективные вещи о том, что у макросов в качестве констант есть врожденные недостатки, которых нет у нормальных C++ных констант. Вы же в своем духе упоротого самодура вещаете "А у меня все работает! Да у меня такие проекты за плечами!"
S>>Кроме этого есть и случаи, когда код пишут вчерашние студенты, да еще и под руководством 20-летних сеньоров CC>И? Как это влияет на людей с опытом, которые знают как оно устроено, как оно работает, и которым не надо ритуальные подгузники чтобы писать нормальный код.
На упорышей, вроде вас, полагаю, никак. Остальные могли бы подумать о том, что защита от элементарных опечаток и для них тоже будет работать.
CC>В серьёзных проектах никто в здравом уме не станет подпускать маппетов к коду
Кроме "серьёзных" проектов есть куча и всяких других. А CreatorCray такой один единственный и всю работу не сделает. Поэтому можно, мягко говоря, забить на то, что о себе думает CreatorCray и поизучать безопасные практики, которые в C++ уже не одно десятилетие рекомендуют "лучшие собаководы".
S>>И если вы не видите в своих проектах чего-то вроде: S>>
?
CC>А я говорил про строковые константы, инициализация которых даже через constexpr не выразима.
Ну так разбейте инициализацию и представление. Пока в C++ в compile-time генерация строк делается через Ж, эту самую генерацию приходится делать через макросы, но хранить результат уже давно можно и не в виде макро-подстановки.
S>>Пример того, как это используется. CC>#define FOO_FILEPATH "/blah/bar/foo" CC>#define FOO_FILEPATH_W L"" FOO_FILEPATH CC>
Тю, а разговоров-то было.
Если бы мне пришлось иметь что-то такое, то в современном C++ сделал бы что-то вроде:
CC>Если уровень пониже на порядок — таких просто не берём, ибо вреда от них больше чем пользы. CC>Если просто слегка пониже то это либо достаточно быстро дотягивается до достаточного, либо досвидульки.
О том и речь. Но как быть всем остальным, кто не так крут, как CreatorCray? Послать рекомендации Страуструпа, Мейерса, Саттера и прочих в сад и набивать шишики самостоятельно?
Вопрос риторический.
S>>Хотя бы затем, чтобы было меньше неявных преобразований типов и неявного смешения разных типов в одном выражении. CC>Эк ты заморачиваешься на ровном месте.
Когда твой код люди компилируют с -Wall -Wextra -Werror (и даже -Weverything), то приходится.
S>>У вас будет такой же литерал типа int. И, повторюсь, для многих это будет неожиданно. CC>Ты хочешь сказать что если тебе надо в коде что то перемножить на 3 то ты вместо foo *= 3; будешь заводить отдельную константу с явно прописанным типом и потом умножать на неё?
Нет, только если 3 повторяется более одного раза. И, скорее всего, придется думать о суффиксе.
S>> Как, например, для многих неожиданно, что "abc" -- это const char[4]. CC>А также const char*, и чо?
Таки не const char*.
Как и 0.1 -- это double, а не float, как иногда думают.
S>>Я лично немного видел define-ов, которые бы выглядели вот так: S>>
S>>#define SIZE 100u
S>>
S>>или так: S>>
S>>#define LONG_SIZE 100ull
S>>
CC>Потому что в подавляющем колве случаев такие заморочки нафиг не нужны.
Это до тех пор, пока ошибка компиляции не возникнет. Как, например, здесь:
#include <vector>
#define msize 1000
//constexpr std::size_t msize{ 1000 };template<typename T>
T selector(T a, T b) { return a < b ? a : b; }
bool get_result(const std::vector<int> & a) {
const auto limit = selector(a.size() / 2, msize);
return a.size() < limit;
}
int main()
{
std::vector<int> arr{1, 2, 3, 4, 5};
return get_result(arr);
}
S>>И если уж заставлять людей выписывать тип, то зачем зазубривать особенности define-ов, если можно сделать: S>>
S>>constexpr unsigned size{ 100 };
S>>constexpr unsigned long long long_size{ 100 };
S>>
CC>Не надо замусоривать код. Тип для константы выписывается там, где он реально нужен.
Так он и указывается там, где он нужен. Причем всего один раз.
S>>И лучше их заставлять находиться в жестких рамках, чем позволять пользоваться небезопасными возможностями. CC>Студней — да, пока не осознают.
Ага, человек учится на constexpr, затем обретает дзен и начинает херачить константы в виде define. Самому не смешно?
CC>Спецы знают как оно работает, сам себя ограничивают где это приносит максимальную пользу, но детские памперсы им только мешают.
Магические спецы уровня CreatorCray, ага, ага. Тормоза, технику безопасности и изоляцию на проводах придумали трусы, настоящие спецы в этом всем не нуждаются.
Здравствуйте, sergey2b, Вы писали:
S>да заставляют
В каждой команде должна быть веточная стратегия, она должна быть известна всем, кто коммитит, и если ты её не нарушаешь, всем должно быть пофиг, какой инструмент ты используешь (если он не нарушает некие корпоративные ИТ стандарты). Раз используются инструменты ревью кода, скорее всего, наиболее опасные операции (прямой пуш в "основную" ветку) запрещены технически. Но особенность git в том, что принципиально он проще иных проприетарных систем, т.к. меньше сущностей (файл, индекс), и потому он ближе к unix-way, и работа из командной строки обычное дело.
Здравствуйте, so5team, Вы писали:
S>я вам говорю объективные вещи о том, что у макросов в качестве констант есть врожденные недостатки, которых нет у нормальных C++ных констант.
Ты пока не показал ничего что можно было бы считать недостатком.
S> Вы же в своем духе упоротого самодура S> На упорышей, вроде вас S> Пилять, lavrov.jpg
Юг вооон там, горячий вьюноша.
CC>>В серьёзных проектах никто в здравом уме не станет подпускать маппетов к коду S>Кроме "серьёзных" проектов есть куча и всяких других.
Ты сам то понял что сказал?
S>Ага. А есть ли он здесь:
Тут ты скобки поставил
S>Тю, а разговоров-то было.
Ну наконец то до тебя этот элементарнейший пример дошёл.
S>Если бы мне пришлось иметь что-то такое, то в современном C++ сделал бы что-то вроде: S>#define
А как же твои крики про недопустимость #define?
S>Но как быть всем остальным
Учиться!
S>Когда твой код люди компилируют с -Wall -Wextra -Werror (и даже -Weverything), то приходится.
-Werror я лично считаю обязательным, весь мой код пишется именно с ним.
S>если 3 повторяется более одного раза. И, скорее всего, придется думать о суффиксе.
S>Как и 0.1 -- это double
А вода — мокрая!
CC>>Потому что в подавляющем колве случаев такие заморочки нафиг не нужны. S>Это до тех пор, пока ошибка компиляции не возникнет.
Она там возникает исключительно из-за за уши притянутого template.
И это как раз редкий случай в котором просто дописывается ull
Всяко короче чем твой вариант.
S>Так он и указывается там, где он нужен. Причем всего один раз.
Суффикс в #define 1000ull тоже указывается там, где он нужен, и тоже всего один раз.
S>Ага, человек учится на constexpr, затем обретает дзен и начинает херачить константы в виде define. Самому не смешно?
Поживёт в реальном мире — станет.
S>Тормоза, технику безопасности и изоляцию на проводах придумали трусы, настоящие спецы в этом всем не нуждаются.
Ох дитятко...
Хм... а в каком месте оно деалоцируется? Меня в первую очередь этот вопрос будет волновать, хоть я и не знаю Куду.
C++ник должен иметь навык писать нормально сразу. Даже с таким навыком со временем код превращается в говно, а без оного он таким оказывается сразу. Безопасные языки наплевательское отношение к качеству исходников до какой-то степени прощают, а вот C++ -- нет.
Код, очевидно, не почищен, и выложен "как есть", но придирки в основном "к шашечкам". C++ никогда не избавится от наследия C.
Это один из.
CC>>>В серьёзных проектах никто в здравом уме не станет подпускать маппетов к коду S>>Кроме "серьёзных" проектов есть куча и всяких других. CC>Ты сам то понял что сказал?
Я-то понял, мне не только в "серьезные" приходится заглядывать.
S>>Ага. А есть ли он здесь: CC>Тут ты скобки поставил
Во-первых, матчасть про фигурные скобки при инициализации подучите.
Во-вторых, перепишите без скобок и попробуйте найти там такой же недостаток, как и в макросах.
S>>Если бы мне пришлось иметь что-то такое, то в современном C++ сделал бы что-то вроде: S>>#define CC>А как же твои крики про недопустимость #define?
Вообще-то речь шла о недопустимости #define для обозначения констант. За нитью разговора следите, плз:
Начиная с C++98 оставалось не так много мест, для define были бы удобны для задания констант, а начиная с С++17 таких мест, вроде бы, вообще не осталось.
Если не писать заголовочные файлы, которые могут использоваться как в чистом Си, так и в C++ (т.е. если выйти за рамки Си-шного подмножества), то надобности в define для констант в C++ уже нет.
S>>Но как быть всем остальным CC>Учиться!
Ну вот пусть и учатся сразу хорошему, а #define пусть оставят для матерых профи, вроде CreatorCray.
CC>>>Потому что в подавляющем колве случаев такие заморочки нафиг не нужны. S>>Это до тех пор, пока ошибка компиляции не возникнет. CC>Она там возникает исключительно из-за за уши притянутого template.
Там вообще весь пример из пальца чтобы показать ветеранам ынтырпрайзного софтострителя как оно бывает в дикой природе.
CC>И это как раз редкий случай в котором просто дописывается ull
А если пользоваться C++ными константами, то и ull не придется дописывать. Кстати говоря, ull -- это не тот суффикс, который должен использоваться для значений std::size_t. А корректный суффикс появится только в C++23, который не всем доступен, а кому-то может быть недоступен еще долго.
S>>Так он и указывается там, где он нужен. Причем всего один раз. CC>Суффикс в #define 1000ull тоже указывается там, где он нужен, и тоже всего один раз.
Только вот ull (даже не смотря на то, что он не для std::size_t) опционален и его легко забыть. Как и скобки вокруг значений в #define.
CC>Ох дитятко...
Адрес куда вам следует засунуть свое самомнение уже был указан.
__>Хм... а в каком месте оно деалоцируется? Меня в первую очередь этот вопрос будет волновать, хоть я и не знаю Куду.
В таких примерах "на выброс" не заморачиваются ни проверкой на ошибки, ни деаллокациями. Так что и я не стал.
__>
__>C++ник должен иметь навык писать нормально сразу. Даже с таким навыком со временем код превращается в говно, а без оного он таким оказывается сразу. Безопасные языки наплевательское отношение к качеству исходников до какой-то степени прощают, а вот C++ -- нет.
__>Код, очевидно, не почищен, и выложен "как есть", но придирки в основном "к шашечкам".
Эти самые шашечки зачастую оказываются очень точными "лакмусовыми бумажками".
__>C++ никогда не избавится от наследия C.
Что не значит, что нужно это наследие эксплуатировать при наличии более безопасных альтернатив из C++.
А почему не constexpr???
Ну мимоходом к прошлогоднему срачу, где ты картинно закатывал глаза про префикс m_, тоже выяснилось что в твоём sobjectizer он повсеместно используется.
Прошёлся по моим ответам тебе — там такие же твои пуристические истерики.
Здравствуйте, so5team, Вы писали:
S>Это один из.
Тут скорее вопиющая неопытность аффтара. Классический пример "верхнее но без среднего".
Препроцессор работает по простым принципам, которые просто позорно не знать.
S>Я-то понял, мне не только в "серьезные" приходится заглядывать.
Не ты один, и?
S>Во-первых, матчасть про фигурные скобки при инициализации подучите. S>Во-вторых, перепишите без скобок и попробуйте найти там такой же недостаток, как и в макросах.
Отпусти сову.
S>Вообще-то речь шла о недопустимости #define для обозначения констант. Да что ты говоришь!
S>надобности в define для констант в C++ уже нет.
То, что появились дополнительные возможности со своими бонусами никак не мешает выбирать наиболее удобный для решения конкретной задачи инструмент.
S>Ну вот пусть и учатся сразу хорошему
Дык я и не против
S>А если пользоваться C++ными константами, то и ull не придется дописывать
Придётся дописывать аж полный тип
S>и его легко забыть
Дык он в подавляющем колве случаев нафиг не нужен.
S> Как и скобки вокруг значений в #define.
Это примерно как трусы забыть надеть при выходе из дома.
Называется профнепригодность
S>Адрес куда вам следует засунуть свое самомнение уже был указан.
Так уж и быть, раз так просишь, наклоняйся — засуну.
Здравствуйте, CreatorCray, Вы писали:
S>>Цитату можно? CC>Я в той теме тоже ответил, посмотри у себя в ответах тебе.
Доказывать что-либо должен тот, кто тезис выдвинул. Так что вперед, за цитатой. Мне даже интересно, что я про префикс m_ говорил, если я использую его чуть ли не с 2000-го года.
Здравствуйте, CreatorCray, Вы писали:
S>>Это один из. CC>Тут скорее вопиющая неопытность аффтара.
Повторяющаяся с завидным постоянством.
Итого: есть такой факт в макросах? Есть.
Есть такой факт в C++ных константах? Нет.
Вопрос закрыт.
По поводу того, что литерал в define может иметь неожиданный для пользователя тип уже говорилось выше. Такой же факт.
Но вы матерый ынтырпрайзный спец, я уверен, что вы способны с фактами успешно поспорить.
CC>То, что появились дополнительные возможности со своими бонусами никак не мешает выбирать наиболее удобный для решения конкретной задачи инструмент.
Вы видите удобство, но не желаете замечать рисков.
S>>А если пользоваться C++ными константами, то и ull не придется дописывать CC>Придётся дописывать аж полный тип
И это всяко лучше, чем полагаться на неявные правила вывода. В C++ и так слишком много неявных преобразований.
Здравствуйте, so5team, Вы писали:
S>Мне даже интересно, что я про префикс m_ говорил, если я использую его чуть ли не с 2000-го года.
CC>Я просто оставил имена как есть, поправив только совсем уж угробищное _ в конце имени.
S>Еще хуже объяснять умудренному опытом (но не гибкостью мышления и способностью смирится с тем, что его мнение нифига не единственно правильное) ветерану с 25-летним опытом, что префикс m_ многими воспринимается как такое же говно, как и суффикс _.
CC>Префикс лучше чем суффикс банально потому, что он стоит В НАЧАЛЕ и сразу бросается в глаза для любого, кто читает слева направо.
CC>Потому что это позволяет легко сузить scope для intellisense подсказок при наборе имени переменной, в саааамом начале набора её имени.
Здравствуйте, Aleksei_Lekomtsev, Вы писали:
A_L>Думаю я бы пробовал решить задачу сам и параллельно подыскивал новое место работы
Зачем? Так у него вроде проблем нету с тимлидом как я понял. Ну, какой то хер в его команде занимается фигней, бывает. Но это проблемы тимлида, а не его.
Я бы тоже, сказал забить на него болт. А все акты саботтажа с его стороны тут же докладывать тимлиду. Или вообще ставить тимлида в сс в любую коммуникацию с ним.
Здравствуйте, so5team, Вы писали:
CC>>Тут скорее вопиющая неопытность аффтара. S>Повторяющаяся с завидным постоянством.
Поря бы тебе уже изучить матчасть и перестать повторяться
S>Итого: есть такой факт в макросах? Есть.
Какой факт? Что они работают как и должны?
S>Есть такой факт в C++ных константах? Нет.
Они тоже работают как задизайнены
S>По поводу того, что литерал в define может иметь неожиданный для пользователя тип уже говорилось выше.
Неожиданный?
S>Вы видите удобство, но не желаете замечать рисков.
Риски я вижу и принимаю во внимание, но ты их похоже панически боишься.
S>И это всяко лучше, чем полагаться на неявные правила вывода. В C++ и так слишком много неявных преобразований.
Зубов бояться...
Для меня легко читаемый код важнее потенциальных непоняток от теоретических нубов.
Ибо нечитабельность трёхэтажных нагромождений всегда доставляла больше реальных проблем.
Здравствуйте, CreatorCray, Вы писали:
S>>Мне даже интересно, что я про префикс m_ говорил, если я использую его чуть ли не с 2000-го года.
CC>
CC>>Я просто оставил имена как есть, поправив только совсем уж угробищное _ в конце имени.
S>>Еще хуже объяснять умудренному опытом (но не гибкостью мышления и способностью смирится с тем, что его мнение нифига не единственно правильное) ветерану с 25-летним опытом, что префикс m_ многими воспринимается как такое же говно, как и суффикс _.
CC>>Префикс лучше чем суффикс банально потому, что он стоит В НАЧАЛЕ и сразу бросается в глаза для любого, кто читает слева направо.
CC>>Потому что это позволяет легко сузить scope для intellisense подсказок при наборе имени переменной, в саааамом начале набора её имени.
Да вы батенька, и читать-то не умеете.
Где здесь написано, что префикс m_ мной воспринимается как говно?
Многими воспринимается, да. А вот я больше 20 лет использую, потому что мне удобно. Гораздо удобнее чем префикс/суффикс _.
Здравствуйте, CreatorCray, Вы писали:
S>>Повторяющаяся с завидным постоянством. CC>Поря бы тебе уже изучить матчасть и перестать повторяться
Я define для констант не использую, мне учить не нужно. А вот исправлять говнокод за другими, кто не столь велик, как CreatorCray, приходится.
S>>Итого: есть такой факт в макросах? Есть. CC>Какой факт? Что они работают как и должны?
Такой, что если не добавить скобок, то получается неожиданный для некоторых результат.
S>>По поводу того, что литерал в define может иметь неожиданный для пользователя тип уже говорилось выше. CC>Неожиданный?
Да, для многих неожиданный.
S>>Вы видите удобство, но не желаете замечать рисков. CC>Риски я вижу и принимаю во внимание, но ты их похоже панически боишься.
Избегаю по возможности. И другим настоятельно советую, раз уж возможность такая есть.
S>>И это всяко лучше, чем полагаться на неявные правила вывода. В C++ и так слишком много неявных преобразований. CC>Зубов бояться... CC>Для меня легко читаемый код
Легко читаемый для вас необязательно будет легко читаемым для других. Как и необязательно свободных от таких сюрпризов, как неявное сравнение знаковых с беззнаковыми или выводом типов в шаблонах.
Здравствуйте, sergey2b, Вы писали:
S>Коллега китаец проработавший в Амазоне несколько лет
Мне известно у случаях со женским рукоприкладством, истериками и прочим, закачивающимся разговором с тем(и) с кем лучше не говорить и неразговорчивыми неграми в самом конце. Мужики тоже так себе, за мою практику контракничества было пару эпизодов на грани. Но надо понимать и болевые точки их, нельзя критиковать при начальстве, или насмехаться над их вежливо-наивным стилем общения, который часто вызывает улыбку у человека неподготовленного. соблюдая паритет, вы всегда пойдете дальше.
Хабитатом таких конфликтов являются гомогенные чуть не написал гомофобные среды, что хорошо показывает истинный смысл понятия "наши".
Здравствуйте, so5team, Вы писали:
S> префикс m_ говорил, если я использую его чуть ли не с 2000-го года.
Ты прямо как мамонт в вечной мерзлоте сохранился- с 2000-го года
я в 15 году ходил на собеседование в mathworks в тим который мне самому хотелось попасть
уже стали оффер обсуждать но из за просроченной h1b послали
пару недель назад я присутствовал на собеседовании программиста из mathworks который меня собеседовал когда то, чел phd даже начальником там стал
я распросил его какие интересные проекты он делал последнии 9 лет
пусть меня жизнь потрепала, но морального удовлетоврения я получил заметно больше, если бы меня тогда взяли на работу
Здравствуйте, sergey2b, Вы писали:
S>Я примерно аналогично оцениваю ситуацию и причины S>Я налажал работая с командной строки git, раньше такого опыта у меня не было S>С другой стороны я им уже сделал две задачи которые они не могли сделать много месяцев
Тут в соседней ветке человек рассказал какого рода эти задачи -- лежат в бэклоге, не особо приоритетные,
деньги за них не заплатят и руки не доходят, но сделать желательно. Обычно дают новичкам.
Вообще говоря, это общая практика.
S>Тут в соседней ветке человек рассказал какого рода эти задачи -- лежат в бэклоге, не особо приоритетные, S>деньги за них не заплатят и руки не доходят, но сделать желательно. Обычно дают новичкам. S>Вообще говоря, это общая практика.
я уже привел пример одной из задачь
если ее не сделать то пропускной способности шины нормальной воркстейшен не хватает что бы обрабатывать видео
задачку которую я у меня отобрал китайский газлайтер была добавить поддержку локализации в приложение
и проверить что все работает нормально на 4 языкаю включая хибро (вы например знаете как выводить и выравнивать текст на хибро)
Здравствуйте, sergey2b, Вы писали:
S>Коллега китаец проработавший в Амазоне несколько лет
Лол. Даже хотел спросить выше не китаец ли он, а так и оказалось. Не надо с китайцами ничем делится и объяснять, задавать только конкретные вопросы. У китайца цель — сиюминутная выгода для себя и он использует любой шанс чтобы её получить. Это просто часть их культуры и менталитета. Когда ты раскрыл карты что надо сделать — он этим воспользовался для своей выгоды. Нельзя было ему ничего объяснять, а нужно было задавать конкретный вопрос, например, как сделать Х не вдаваясь зачем тебе это надо. Главное, не раскрывать детали зачем. Если он не отвечает, то делать самому, а на скраме говорить, что спросил Чжана, но он не знает как это сделать.
S>>Тут в соседней ветке человек рассказал какого рода эти задачи -- лежат в бэклоге, не особо приоритетные, S>>деньги за них не заплатят и руки не доходят, но сделать желательно. Обычно дают новичкам. S>>Вообще говоря, это общая практика. S>я уже привел пример одной из задачь S>если ее не сделать то пропускной способности шины нормальной воркстейшен не хватает что бы обрабатывать видео S>задачку которую я у меня отобрал китайский газлайтер была добавить поддержку локализации в приложение S>и проверить что все работает нормально на 4 языкаю включая хибро (вы например знаете как выводить и выравнивать текст на хибро)
Я могу быть неправым, но и Вы не зазнавайтесь. Где-то видать расслабились и пошло что-то не так, что не
понравилось коллегам.
Здравствуйте, sergey2b, Вы писали:
S>морального удовлетоврения
У тебя пирамида перевёрнутая. Ты паришься духовным не обеспечив материальный фундамент.
Отчего оно периодически всё разваливается.
Здравствуйте, sergey2b, Вы писали:
S>я уже привел пример одной из задачь S>если ее не сделать то пропускной способности шины нормальной воркстейшен не хватает что бы обрабатывать видео
При чём тут шина вообще? Тебе нужно избежать дорогого копирования из VRAM в RAM и обратно?
Наверное должен быть какой-то интерфейс, чтобы пеиедать handle графического объекта от одной либы в другую. Ведь use case должен быть распространённый.
Хотя это совсем другое, нежели мастурбация на C++.
Здравствуйте, Артём, Вы писали:
S>>Да ладно практически все использую m_ or суффикс _ Аё>Суффикс _ используют.
НЕМОЖЕТБЫТЬ! А я то думал что используют суффикс _ !!!
Здравствуйте, Sharov, Вы писали:
S>>b) человек разделяет "нормальный" код и код "на выброс", т.е. позволяет писать себе в стиле "на отвали". Что подозрительно.
S>не разделяет, наверное?
Именно что разделяют.
Есть персонажи, которые говорят: это у меня черновой код, не смотрите, здесь все коряво, я потом начисто все переделаю, а вот это у меня уже чистовой код.
Вот как с фрагментом от sergey2b: там вообще чуть ли не все до main-а (кроме обязательных include) следует выбросить. Но, видимо, за основу был взят какой-то чужой исходник, какие-то части из него повыбрасывали, но не все. Вот это вот "не все" в виде define-ов и осталось.
Тогда как прилежный разработчик, который не видит большой разницы между "черновым" и "чистовым" кодом поудалял бы вообще все лишнее и оставил бы самый минимум для демонстрации принципа работы.
Здравствуйте, Kernan, Вы писали:
K>Лол. Даже хотел спросить выше не китаец ли он, а так и оказалось.
Хаха, у меня тут недавно был диссонанс насчет коллеги китайца. Ну никак не вписывался в поведение китайца, кроме внешности, еще и акцент странный, хуже китайского, народ его просто не понимает. Оказалось что он родился и вырос в Швейцарии
Здравствуйте, velkin, Вы писали:
V>Сейчас у хрюш ещё развилась такая тема как софт скиллы, то есть в переводе на русский умение общаться с людьми. Типа лучше взять человека с софт скиллами, чем с хард скиллами.
Это кстати вообще маразм какой-то, потому что для сотрудника софт скиллы действительно важны, общительный человек со связями, скорее всего, займет лучшее положение, так всегда было и будет. Но зачем компании на техническую должность программиста специально отбирать по софт скиллам?! Чтобы что?
尿Ǥ푙>Хабитатом таких конфликтов являются гомогенные чуть не написал гомофобные среды, что хорошо показывает истинный смысл понятия "наши".
Ну так и написал бы "однородные"
А за хабитатом мне вообще пришлось в переводчик лезть.
Эх, не про тех bnk создавал свой недавний топик (Предлагаю запретить..
Два дня назад я на стендапе говорю -не работают х сам пофиксить не могу
Он тут же говорит что поможет пофиксить
Очень уверено говорит я реально поверил что он знает как исправить
Берет у меня подготовленные мной логи и пишет в общий чат
Что он исследовал мой компьютер и вот описание проблемы в логах
Кто знает как пофиксить ?
Я охринел от такой помощи
А сегодня зачем то начал говорить на собрании как круто я сделал функцию П
По-моему от него надо держаться подальше
С такими коллегами и вранов не надо
Здравствуйте, sergey2b, Вы писали: S>Он реально рвет мое сознание как тузик грелку
может, он наркоман? их много и они шифруются обычно. выдают себя как раз очень странным и непредсказуемым поведением
Здравствуйте, Kernan, Вы писали: K>Лол. Даже хотел спросить выше не китаец ли он, а так и оказалось. Не надо с китайцами ничем делится и объяснять, задавать только конкретные вопросы. У китайца цель — сиюминутная выгода для себя и он использует любой шанс чтобы её получить. Это просто часть их культуры и менталитета. Когда ты раскрыл карты что надо сделать — он этим воспользовался для своей выгоды. Нельзя было ему ничего объяснять, а нужно было задавать конкретный вопрос, например, как сделать Х не вдаваясь зачем тебе это надо. Главное, не раскрывать детали зачем. Если он не отвечает, то делать самому, а на скраме говорить, что спросил Чжана, но он не знает как это сделать.
ну и вообще у них в менталитете, что как правило кто-то достигает успеха из-за неудачи другого. у них нет понятия win-win стратегии
Здравствуйте, reversecode, Вы писали: R>но проблема конечно же не в программисте Сергее
тут проблема в том, что он ищет в коллеги тех, с кем привык работать, а надо искать других. то есть собеседоваться в рандомные конторы и выбирать оффер киданием монетки будет более выигрышной стратегией, чем идти "туда куда хочется" в "самый интересный проект"
Здравствуйте, sergey2b, Вы писали:
S>Берет у меня подготовленные мной логи и пишет в общий чат S>Что он исследовал мой компьютер и вот описание проблемы в логах S>Кто знает как пофиксить ?
Это, кстати, намёке на то, что можно делать точно также. Собрать логи и спросить в общем чате знает ли кто как это пофиксить.
Здравствуйте, sergey2b, Вы писали:
S>Он реально рвет мое сознание как тузик грелку
S>Два дня назад я на стендапе говорю -не работают х сам пофиксить не могу S>Он тут же говорит что поможет пофиксить
Мотивирует.
S>Очень уверено говорит я реально поверил что он знает как исправить
Знает, как искать решение
S>Берет у меня подготовленные мной логи и пишет в общий чат S>Что он исследовал мой компьютер и вот описание проблемы в логах S>Кто знает как пофиксить ? S>Я охринел от такой помощи
Ну он делегировал. В чём проблема- тебе шашечки или ехать?
S>А сегодня зачем то начал говорить на собрании как круто я сделал функцию П
Ну вот, — осветил что ты суперстар
S>По-моему от него надо держаться подальше S>С такими коллегами и вранов не надо
Тебе союзничать с ним надо. Чел вырастет в руководителя, и тебя подтянет.