То, когда я создал свои классы помощника, является мной по разработке?
Добавьте этот стиль на свою страницу
table.dataTable thead .sorting::after {
opacity: 0.2;
content: "";
}
7 ответов
You're probably right, but on the other hand if everyone in the company decided that they don't like the existing APIs, and each designed their own shims and helper functions, that only they used, then maintenance would be tricky.
If your array wrapper is "over-designed", then I'd question whether the code reviewer considers any amount of design to be acceptable. It looks harmless to me[*]. I suppose you could have just made it a struct with two public members, and lose the benefit of read-onliness. How keen are your colleagues on const-correctness in general?
I think the goal for 2 should be to reach consensus on whether that C API should be used directly from C++, or wrapped. If it should be wrapped (and the arguments for that are probably quite strong, what with namespacing and RAII), design a wrapper that everyone will use, and designate it "the C++ API for this module" rather than "a C++ wrapper that one module uses for this other module".
It's possible that everyone else genuinely prefers the API as it is, over a more OO API or using STL. Following their conventions will make it easiest for them to maintain your code, as long as their conventions are solid C programming style. C++ is a multi-paradigm language, and "C with a limited number of bells and whistles" isn't the paradigm you're used to. But it is a valid paradigm, and if it's what the existing codebase uses then you have to question whether what your company needs right now is a one-man revolution, however enlightened.
[*] (the API, that is. They might question whether it will be passed by value inappropriately, and whether it's wise for every instance to have to be as big as the biggest. That's all for you to argue out with the reviewer, but is nothing to do with "over-design".
Перво-наперво: вы присоединились к новой компании, поэтому можете ожидать, что вам нужно научиться играть по их правилам. Вы по-прежнему «новичок», и «ваш способ» поведения будет сопротивляться, даже если он лучше. Привыкайте к ним и постепенно интегрируйте себя и свои идеи.
Что касается пункта 1, то передача указателя + размера, безусловно, является проблемой для программиста, но это наиболее эффективный с точки зрения памяти способ решения задач. Ваш класс не разработан "сверх", но что произойдет, если MAXSIZE станет действительно большим в какой-то момент в будущем? Все ваши экземпляры будут занимать столько места каждый, даже если они не нужны. Вы можете столкнуться с нехваткой места просто потому, что изменился MAXSIZE, даже если ничто не требовало такого количества места.
Что касается пункта 2, это вопрос, действительно ли он »
A c++ wrapper for the already existing c-style container-library is a nice thing to have. But make sure it's really a wrapper, not a wrapper with bolted on bells and whistles.
If you declare all your access functions as inline and write your wrapper using the leanest possible implementation there should be exactly zero overhead in code and data-size.
Such a wrapper will just give you a class-like interface to the c-library, and that's good practice for a C/C++ project.
I suggest to check your code. Take a look at the disassembly of a little test-case using your wrapper and compare it to a c-only implementation. If you see any additional complexity, allocations or calls to your class implementation you have overhead and maybe overengineered a bit.
Proving that your wrapper generates more or less identical code compared to the c-version may convince the other programmers that a wrapper here and there does no harm. It follows the way C++ programs are written and will result in a cleaner and more consistent code-base.
Btw - The "we don't want no useless wrapper-class in our repository" thing is a social problem, not a technical one. You're the new guy. If I would be in your position I would play by their rules for a couple of month and - after I've proven myself - introduce them to your ideas.
С одной стороны, если вам комфортно с C ++, и они используют C, тогда вспомогательные классы, вероятно, подойдут для вас в наименее. С другой стороны, если вы пишете какой-либо контейнерный класс, вам почти наверняка лучше использовать STL напрямую и написать вспомогательную функцию , чтобы преодолеть разрыв между вашим контейнером STL и кодом C. Не изобретайте велосипед.
«Излишне спроектированный» - это очень относительно. C-ребята из вашей группы, вероятно, видят проблему с вашим классом, потому что, когда вы передаете свой класс по ссылке, вы собираетесь сделать копию всего этого массива. Это может занять изрядное количество времени во «встроенной» системе (в зависимости от вашего определения встроенного). Конечно, если вы переходите по адресу, это не проблема.
Ваш №2 - проблема культуры. Если они не хотят пробовать новые методы программирования, вас будут рассматривать как аутсайдера. Этого вы не хотите. Вносите их медленно.
Что до того, что не положить в репозиторий - это чушь собачья. Каждый должен поместить все в репозиторий, чтобы люди могли получить к нему доступ и позже найти ошибки.
Чтобы не гудеть в мой собственный рог, Использование C ++ во встроенной среде
Я не уверен насчет 1 . Может быть, вы могли бы привести простой пример кода для иллюстрации.
Что касается 2, я согласен с вами. Как закаленный программист на C, который пытается быстро освоить C ++, я полностью увлечен идеей создания тонких фасадов вокруг существующих API C для упрощения обработки ошибок и управления ресурсами.
Вы делаете копию данных для ваш класс, который больше не квалифицирует ваш класс как простой класс-оболочку. Хотя это защитит вас от того, что данные будут удалены из-под вас, если исходные данные были изменены, ваши данные будут устаревшими.
Идея инкапсуляции массива с указанным размером является разумной. Возможно, вы можете заставить их добавить поле размера в свой контейнер, если это не просто const int *. But I can see that for the mere privilege of encapsulating the size, the overhead of extra memory and runtime to model and initialize the class may seem unpalatable for them.
Beyond that, I have to sympathize completely as far as dealing with the classic C-bias, which is that C++ is evil and slow. Flashbacks...shudder.