Тёмная тема
- kkolyan
- Участник
Went
понятно что с опытом видно все больше и больше проблем и решений)
foxes
> Пользуйся фреймворком и будет тебе счастье.
не совсем понял чт оты имеешь в виду. я жалуюсь на много клацаний для совершения простых вещей (даже с автокомплитом и другими фичами IDE). например, чтобы добавить параметр в метод, надо его добавить в cpp, в hpp, а также инклуд добавить. какой фреймворк поможет это сократить по кол-ву инпута хотя-бы вдвое?
foxes
> Поэтому чистым C++ ни кто не пользуется (очень зря) и понятия не имеют как он работает.
что такое "чистый C++"? без векторов, смартпоинтеров (я полагаю, это значит - с этим всем, но написанным самостоятельно)?
kkolyan
> например, чтобы добавить параметр в метод, надо его добавить в cpp, в hpp, а
> также инклуд добавить. какой фреймворк поможет это сократить по кол-ву инпута
> хотя-бы вдвое?
Visual Assist эту проблему решают. Тот же самый QT может генерить заголовок за тебя. Но это не проблема C++, если ты в яве добавишь параметр в используемый метод, то тебе тоже придется бегать по всему коду и исправлять использование этого метода. А еще, возникновение подобной ситуаций означает неправильное планирование. И дай бог чтобы это было только внутреннее использование, а не внешняя библиотека. По этому с одной стороны это доп. действия, с другой ты десять раз подумаешь прежде чем создавать метод.
kkolyan
> что такое "чистый C++"? без векторов, смартпоинтеров
Смартпоитреры и вектора - это на столько базовый предмет что копипастятся из фреймвокра в фреймворк иногда без каких либо изменений.
Чистый С++ - это прежде всего твои знания о нем и то как он работает (а не фреймворк), и он способен на большее чем предлагают фреймворки, но это очевидно не без собственных ручек, фантазии и глубоких знаний. Также это не значит полное отрицание фрейморка, прежде всего это твое полное понимание что такое C++.
Фреймворк фреймворку рознь и если ты возьмешь QT то половина твоих знаний о стандарте C++11 20 40 ... (смартпоинтеры вектора и прочее ооп) могут отправиться в трубу.
rcsim
> А причём тут инстансы?
Инстансы тут к тому, что типичная проблема при доработке софта - "был один контекст такой-то задачи (допустим, хттп-запроса), стало нужно сделать их несколько (допустим, чтобы ресурсы могли качаться параллельно), а имплементация на глобальных (или статических) переменных".
Panzerschrek[CN]
> Лучше передавать не контекст как целое, а только отдельные зависимости.
Собственно говоря, любые явные передачи чего-либо - это сильный геморрой, отсутствием которой глобальные переменные и заруливают. Как пример. Допустим, есть некий тип Number, понятно для чего. Нужно ли ему сувать в конструктор что бы то ни было, похожее на контекст? По идее, нет - ну простой по смыслу класс, чего ему надо-то для счастья. Ладно, запилили интерфейс с конструктором, в который не нужно передавать ничего неочевидного. Напилили кода с этим интерфейсом. И вдруг оказывается, что имплементация немного ограничена по возможностям, а для её расширения надобно бы динамическую аллокацию, желательно специально оптимизированную. А специально оптимизированная динамическая аллокация - через специальный короткоживущий аллокатор. А специальный аллокатор - в контексте... И опаньки.
kkolyan
> ненужной писанины меньше - это хорошо
Это всего лишь побочка (кстати, можно сначала писать заголовки, а потом через хот-кей создавать пустые определения функций - никакого лишнего печатания не нужно).
Речь о другом.
// A.h class A { struct PrivateDataA { // много всякой штуки }; static PrivateDataA someAClassPrivateData; void foo(); // тут используем someAClassPrivateData }; // A.cpp #include "A.h" PrivateDataA A::someAClassPrivateData; // приватная статическая переменная член-класса // B.h class B { void foo( ); // тут используем someBClassPrivateData }; // B.cpp #include "B.h" namespace { struct PrivateDataB { // много всякой штуки }; PrivateDataB someBClassPrivateData; // свободная переменная, локальная для единицы трансляции } // main.cpp #include "A.h" #include "B.h" // PrivateDataA виден (хотя и недоступен) и будет ещё раз компилироваться, PrivateDataB не виден.
kkolyan
> в этом и суть ограничения, что не должны переменную использовать все кто хотят.
> должны тольок те, кому позволили.
Именно об этом и речь. Позволено только тем, кто находится в той же единице трансляции.
// SomeLogic.h class A { void foo(); }; class B { void foo( ); }; // SomeLogic.cpp #include SomeLogic.h static int allowedForABOnly = 0; void A::foo( ) { ++allowedForABOnly; } void B::foo( ) { std::cout << allowedForABOnly; } // SomeOtherLogic.cpp class C { void foo( ) { ++allowedForABOnly; } // compilation error: unknown symbol };
foxes
> если ты возьмешь QT то половина твоих знаний о стандарте C++11 20 40 ...
> (смартпоинтеры вектора и прочее ооп) могут отправиться в трубу
Чистая правда. В Qt вообще своя атмосфера.
foxes
> Visual Assist эту проблему решают. Тот же самый QT может генерить заголовок за тебя. Но это не проблема C++, если ты в яве добавишь параметр в используемый метод, то тебе тоже придется бегать по всему коду и исправлять использование этого метода.
все сказанное мной выше - с учетом того, что я активно пользуюсь возможностями IDE (т.к. привык к навороченным явовским IDE). не юзал именно продукт "Visual Assist", и готов допустить что он чуть покруче чем CLion. Возможно стоит погонять Visual Assist или ReSharper++... но я не верю в магию - в крестах очень много вариативности и никакая IDE их не покроет так хорошо как в яве, которая проста как сапог.
> А еще, возникновение подобной ситуаций означает неправильное планирование. И дай бог чтобы это было только внутреннее использование, а не внешняя библиотека. По этому с одной стороны это доп. действия, с другой ты десять раз подумаешь прежде чем создавать метод.
вообще ты прав, именно на каких-то мелких изменениях уже готового большого продукта, ява не сильно выигрывает по кол-ву действий (и такого по работе очень много).
Но вот сейчас я очень много пишу на крестах, постоянно все переписываю, рефакторю. можно конечно сослаться на то что я новичок и все проблемы из-за этого, а матерый крестовик сначала подумает а потом напишет сразу правильно. но я и на яве, в которой далеко не профан, часто прототипирую, экспериментирую и рефакторю. и вот здесь всплывает большая разница в тысяче мелочей, где в яве все идет по маслу (благодаря IDE на 80%), а в крестах IDE принципиально за меня сделать не может, т.к. вариативность.
насчет твоего призыва "писать на языке, а не на фреймворках" - разделяю полностью. нет ничего плохого в использовании фреймворков, когда хорошо понимаешь как каждый из них устроен и в случае чего можешь запилить свой аналог. к сожалению, многие программируют именно складывая большие черные ящики, не интересуюясь основами, причем даже не только в крестах - даже в простой яве с огнем не сыщешь тех кто хорошо понимает платформу и не боится кода - большинство "сеньоров с 10+ лет опыта" прячутся за аббревиатуры аля JMS и прочие J**.
foxes
> Фреймворк фреймворку рознь и если ты возьмешь QT то половина твоих знаний о стандарте C++11 20 40 ... (смартпоинтеры вектора и прочее ооп) могут отправиться в трубу.
любопытно будет потрогать.
Sbtrn. Devil
> Собственно говоря, любые явные передачи чего-либо - это сильный геморрой, отсутствием которой глобальные переменные и заруливают.
++
и в управляемых языках этот геморой ощутимо слабее.
pahaa
> кстати, можно сначала писать заголовки, а потом через хот-кей создавать пустые определения функций - никакого лишнего печатания не нужно
естественно, я так и делаю) но даже сами заголовки писать - это тоже рутина ведь. в управляемых языках можно например просто вызывать у объекта несуществующий метод и он сгенерится с правильными типами. а в крестах откуда ему знать как ты хочешь передавать аргументы - как минимум два очевидных варианта, но ведь есть еще и move, и имплисит преобразования. в итоге приходится ручками перебивать (в двух местах, бгг). можно конечно сильно кастомизировать IDE, но их возможности не резиновы и таких мелочей куча.
> Речь о другом.
спасибо за пример. да, я именно так тебя сразу и понял. просто я не вижу в этом особой ценности за исключением редких случаев.
> Позволено только тем, кто находится в той же единице трансляции.
но каждый кто может создать инстанс A (т.е. кто угодно), автоматом при этом получает и аксессор к скрытой глобальной переменной. да, это намного лучше чем если бы она была совсем открыта для всех глаз. но по-моему еще более намного лучше чтобы A нельзя было создать не имея доступа к объекту, владеющему переменной allowedForABOnly. например как в Java/C# нельзя получить входйщий сокет без доступа к слушающему сокету, в то время как открыть исходящий можно из любой точки программы. кейс с исходящим - норм, т.к. сетевое железо является естественным глобальным стейтом, хотя теоретически и там можно было бы упороться по объектам - ведь сетевой интерфейс не один... но здравый смысл никто не отменял. UPDATE: на самом деле упарываться здесь не надо не тошлько из-за здравого смысла. дело в том, что случающий сокет мы сами создаем, привязывая его к конкретному порту. из другой (независимой) точки программы получить такой же глобально уже не выйдет, т.к порт занят. в случае же с сетевыми интерфейсами - они для Java/C# фактически просто всегда глобально дсотупные справочники, позволяющие при желании выбрать на что биндить сокет. позволять по умолчанию брать какой-то из них автоматом - нормальный сахар, не нарушающий принцип избегания глобальной адресации пользовательского стейта.
kkolyan
> не юзал именно продукт "Visual Assist"
Это маст хев инструмент.
https://www.wholetomato.com/features/feature-refactoring
Ну по крайней мере юзаешь аналоги и ладно.
kkolyan
> в крестах очень много вариативности
Ооо брат, это и есть С++. Организуй работу под себя, выбирай свою вариативность как тебе удобней.
kkolyan
> а матерый крестовик сначала подумает а потом напишет сразу правильно.
Это фантастика. Тут дело не в языке совсем. И проблема рефакторинга - всегда этап разработки, а не пунктик новичков. Просто для профов он более организован и менее непреодолим. Конечно в контексте написания форматов методов косяков у матерых меньше. Потому что стараются писать по шаблону. Но оригинальное велосипедо строение всегда через грабли.