- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
struct Point3D {
float x,y,z;
float& operator [] (int i) {
switch (i) {
case 0: return x;
case 1: return y;
case 2: return z;
default: assert(false);
}
}
};-
C++ / Говнокод #14330
+15
Писал Жабапоглащенный.
Запостил:
LispGovno,
08 Января 2014
Follow us!
А что ты с Жабапоглощенного хотел?
я за .x();, .y(); ... и [].
http://habrahabr.ru/post/121799/
Наверное, все любители языка C++, которые использовали другие языки, такие как C#, удивляются: почему же в плюсах нет {{feature.name}}? Ведь это действительно удобное средство, позволяющее {{feature.description}}. Недавно и я заинтересовался данным вопросом. Подумав, полистав Страуструпа и наконец, погуглив, я пришёл к выводу, что {{feature.name}} можно реализовать средствами языка...
Синдром Бабла.
Синдром блаблабла - это когда питушок не признает фичи языка из другого языка. Тут чувак имеет фичу (то есть находиться как бы в языке более высокого уровня по наличию фичи) и пытается сэмулировать в крестах. Он не говорит, что фича не нужна. Он говорит что её можно использовать, а это уже не является синдромом блаба. Синдром блаба - семантическая слепота.
Задрал этот ёбаный понос m_size, size(), m_length, length(), это уёбищное () везде писать.
Тебя проклял кто-то
Страуструп
Из-за очень возможного 100% оверхеда по памяти, а ты предлагаешь:
на каждый член
Шарповые свойства это же всего лишь синтаксический сахар, не более того.
От них профит только в том, что кода меньше писать, чем врукопашную делать геттер и сеттер. Ну и вызов на две скобки короче.
Безнаказанно рефакторить поля на свойства, без перекомпиляции классов, использующих данный, емнип, они в шарпе все равно не позволяют, т.к. поломается интерфейс класса. Но я могу ошибаться. Шарпеи, вы где?
P.S. Да, у меня синдром Блаба, и я не признаю удобство свойств.
Так что, имхо, не нужны они в крестах.
=== BEGIN HOLY WAR ===
Во-вторых мы теряем полиморфизм (хотя мы его уже потеряли из-за требования на standard-layout или POD). Свойство не сможет понять, встроено оно в класс A, или в его потомка - класс B.
Во-вторых надо бы проверить, можно ли это смещение вычислить на уровне шаблонов. Т.к. хранить его - тот же самый оверхед, и проще, имхо, хранить указатель.
P.S. Или я туплю?
Еще как избежен!
1. можно инкапсулировать данные в самом свойстве, а не в родителе. Родителя, соответственно, зафрендить.
2. указатель на родительский объект получается в вычитанием из this объекта свойства некоторой константы.
Очень ограниченно. Теряем половину профита от сеттеров. Разве что валидацию и read-only так можно замутить.
> 2. указатель на родительский объект получается в вычитанием из this объекта свойства некоторой константы.
И полиморфизм смывается в унитаз. Если я не туплю сегодня.
Таки да.
Пункт два - я тупанул, пустой класс тоже что-то весит.
Или все-таки не смывается... Жарко дома, башка совсем не варит ;(
Пойду попробую реализовать.
Фейл. offsetof(my_class, my_prop) нельзя передать как параметр шаблона для типа самого же my_prop. Что в общем-то логично ;(
У кого еще есть какие-нибудь предложения, как замутить свойство без хранения в нем ссылки на тот объект, в котором оно лежит?)
Проверено, работает
Спасибо.
В Qt, в принципе, прикрутили метасистему. Там к свойствам из js можно обращаться, просто дергать их по имени... Но она работает только на QObject'ах, и представляет собой жуткий костыль с генерацией дополнительной сишки.
Так что так просто не отделаться ;(
а вот и нет. теперь этот сахарок в ASP.net стал важен - вьюшка и контролер не могут с полями на автомате работать, только с свойствами.
нет, методами можно, но это выливается в анальную боль.
> нет, методами можно
Ч.т.д. Сахар. Удобный, не спорю, но сахар.
Тогда и структуры тоже сахар. Т.к. без этого "сахара" я не смогу описать структуру.
интересное и позновательное
в дотнете структуры преполагается юзать приимущественно в ансейвед коде, поэтому по умолчанию по порядок следования полей в структуре в памяти определяется юзером. Однако в классах порядок выбирается компилятором. Сменить метод расположения полей можно атрибутом
[StructLayout(LayoutKind.xxxx)]
Так же можно явно задать положение полей с помощью смещений памяти
int *a = malloc(size);
*(a+n) = something();
Тем самым ты обходишься и без структур :)
Q.E.D.
А со свойствами смог бы, в геттерах-сеттерах считал бы указатель и возвращал ссылку на смещение.
правду глаголишь, боярин. Ибо метаданные разные. Свойство - это свойство, а поле - это поле. Свойство даже автоматеческое, всегда прячет за собой поле, пусть и неявно
Ну скажем так, не всегда. Например если я делаю прямоугольник, и хочу сделать ему свойства left, right, width,то одно из них останется без переменной.
int x{get; set;}
то все равно создается поле, правда явно оно не доступно.
Ну ок, я читаю значение свойства temperature с термометра, подключенного по 1-wire. Где оно хранится? )
В окружающей среде, естественно
А нахрена ему свойство? Мы будет градуснику по 1-wire температуру задавать?)
Почему нет? Вдруг это какой-то управляемый термостат. Читаешь из свойства текущую температуру, записываешь желаемую ;)
Да уж персонально меня зови, один я у вас такой.)
Задавая умные вопросы, товарищ Борманд, вы таки заставляете меня луркать (так как я не могу ответить такому человеку как вы^_^) и тем самым заставляете меня учиться
Кажется я был не прав. Конечно же свойства, геттеры\сеттеры и поля отличаются на уровне метаданных и видны через рефлексию именно как свойства.
Но в крестах нет рефлексии, так что пофиг.
Оно небось бы и заинлайнилось. Жаль бы отвратительно выглядело и пропала бы возможность модификации гетеров сетеров, заменяющая виртуальные проперти
Не монял мысли. Указатели на виртуальные методы никто не отменял.
ps: вопрошатель уже все понял
не только твоё
оно всё-таки пооптимальнее
Индейцы вроде не помешают. Они же влияют только на порядок байт в том же флоате. Но никак не на порядок флоатов между собой.
Ну и Тарас же не говорит, что эта реализация безопасна. Он только сказал, что она оптимальней.
> число i вне 0...2
Ну а что поделать? Либо проверка и теряем производительность зазря, либо нет проверки, но есть небольшой, но риск.
Можно конечно что-то типа такого запилить: p.get<0>(), но оно неюзабельно в циклах. А раз неюзабельно в циклах - вместо него можно юзать банальное p.x ;)
Одно дело, когда этот индекс взят из внешних данных. Тогда проверка нужна.
И совсем другое дело, если этот индекс юзают только в десятке функций, оперерирующих над матрицами и векторами, и больше никто к ним никогда не полезет.
Я все-таки за то, чтобы выпилить этот оператор [] нахер, а в коде всяких умножений матриц юзать .x, .y, .z, анролльнув его вручную или простеньким скриптом на питоне. Зачем этот оператор нужен то, кроме лени автора либы и ее читабельности (на которую нам немного насрать, т.к. либа явно точится под производительность)?
Координаты векторов и ячейки матриц, имхо, мало кому нужны кроме самой либы. А сама либа во френдзоне и работает с полями напрямую, поэтому скобочки мешать не будут.
Матрицы любят циклами на вектора перемножать
нафига руками
r.x = m[0]*a.x + m[1]*a.y + m[2]*a.z
Вот на тачскрине даж набрал. Хули тут писать то.
Бывают и побольше вектора, а развернуть охота
Ну вот там уже можно и развернуться :) Но там уже и проблем с .x, .y, .z не будет. Там уже будет простая и тупая индексация.