Кстати есть мнение, что компоненты лучше хранить отдельно, каждый тип в однородном контейнере, а из entity ссылаться на содержащиеся в ней компоненты по id/индексам.
Используем сходный велосипед в рабочем проекте. Отличия:
1) Для создания stack-фреймов не используется выделение памяти на куче
2) В stack-фреймы можно напихать сколько угодно и какой угодно информации, не только имя функции и номер строки
3) Функции не заворачиваются в макросы, скорее наоборот — макросы кладутся внутрь функций, причем только тех, которые реально нужны
4) Поддержка многопоточность реализована через thread-local переменные
Более того, работал в фирме, в которой ввели такое, встречено было очень негативно, но через полгода выяснилось, что весьма полезно. В компании где работаю сейчас такого официально нет, неофициально сам себе поставил таймтрекер, когда сотрудники узнали — смотрели как на идиота.
Про рендер — вы не поверите, но один хороший знакомый, долго работавший в архитектурной фирме рассказывал, как у них как-то заказали дизайн-проект, и среди прочего в одном из помещений одна стена была ярко-красная, а остальные белые. Настроили материалы, свет, сделали рендер — стены вместо белых нежно-розовые. Начальство говорит — картинка неправильная, делайте что хотите, но клиент должен увидеть белые стены. Немного фотошопа — и стены на рендере белые, начальство довольно, клиент доволен, все хорошо. Проходит какое-то время, на объекте уже ведутся чистовые работы, и тут прибегает клиент и ругается почему маляры ему стены в розовый покрасили вместо белого. Дальше по цепочке идут разборки, в итоге финальная сцена — комната, розовые стены, маляры закрывают плотной белой пленкой стену окрашенную в красный, и внезапно стены становятся белыми. Занавес.
В плане установки дополнительных проводных выключателей в уже жилой квартире — вы когда-нибудь штробили бетонную стену? Даже если это делать хорошим штроборезом с подключенным пылесосом — мелкая противная пыль будет везде. Кроме того, чтобы восстановить нормальный вид стены штробу надо будет штукатурить, ждать высыхания несколько часов, потом шпаклевать, ждать еще несколько часов, потом шлифовать (еще пыль), грунтовать, опять ждать высыхания, и только потом клеить обои/красить/что там было до этого. И хорошо если место куда нужно тянуть провод находится в стене, до которой можно доштробиться (на самом деле часто нельзя), а если нет, и окажется что нужно еще вскрывать натяжной или еще хуже гипсокартнный потолок, чтобы добраться до распаячной коробки? Даже если все это окажется дешевле радиовыключателей — многие ли захотят терпеть такой дестрой у себя дома, причем несколько дней?
Альтернатива — Z-Wave устройства, если идти по «бюджетному» варианту, то какой-нибудь силовой модуль zipato будет стоить 3500, если брать fibaro — то от 6000. Может работать и как силовой блок, и как просто «пульт». Ставится обычно в подрозетник. Если надо накладной выключатель-пульт на батерейках чтобы не портить стены — ценник от 5000. Итого стоимость «комплекта силовой модуль + выключатель на скотче» 8500, ценник ноолайта на этом фоне очень даже гуманный.
Ваши слова "50мм на кропе не становится портретником, им по прежнему нельзя отделить лицо от фона?" я воспринял именно так. Если неправильно понял — извиняюсь.
Ну и по собственному опыту — 50мм на кропе на открытой диафрагме очень даже позволяют отделить объект съемки от фона. Более того, в процессе спора с одним знакомым на тему эквивалентности фокусных/грип и т.п. пробовали снимать с одного ракурса и расстояния один и тот же объект на кроп 1.5 при 50/2.0 и на полный кадр при 75/2.8 — фото были идентичны плюс-минус шумы и цветопередача разных матриц.
По вашему лицо от фона можно и нужно отделять только "размытием в хлам"? Ну-ну...
UPD. Ну и как бы портрет — это не только лица крупным планом на длинном фокусном.
Согласен, но опять же — после усредненения многомегапиксельная матрица будет скорее всего не хуже, а без усреднения даст больше свободы (да, при наличии прямых рук/хорошего света/оптики/...).
Есть мнение, что если взять и усреднить эти 100500 мегапикселей до 12 (при одинаковом размере и техпроцессе матриц), то по шумам результат будет эквивалентен съемке на те же 12 мегапикселей сразу. Зато при хороших условиях съемки 100500 мегапикселей могут дать профит в плане качества и/или возможности кропа.
Если кропить — то действительно можно и на фишай, только тогда резко уменьшается эффективный размер матрицы. Проще говоря — будет как на мыльницу. А геометрические искажения в первую очередь зависят не от размеров матрицы, не от фокусного расстояния объектива, а от расстояния до снимаемого объекта. Если точнее — от отношения расстояния до объекта к размеру самого объекта. Все остальное — вторично.
Как мне показалось — статья наоборот о том, что не надо, извините, задрачиваться на характеристики камеры, метаться между никоном и каноном, накупать тонну дорогущей оптики — а брать то, что по карману и идти снимать уже.
Нормальное шифрование решает эту проблему. Более того, в том же wifi от перехвата пакетов защищает только шифрование, а «закрыться шторкой» там тем более не поможет. Так что тут еще вопрос что более приватно.
Это уже вопрос разумности использования, шаблоны — это просто один из инструментов. В вашем примере с матрицами и большой функцией вероятно да, шаблоны могут привести к раздуванию кода. С другой стороны, в статье ссылку на которую я кинул приводятся примеры использования шаблонов для GPIO вместе с ассемблерными листингами того, что получается на выходе, и получается очень компактно.
Дико извиняюсь за предыдущий комментарий, забыл про тег source, а исправить это месиво не успел (
Если переменные-объекты, для которых не вызываются конструкторы объявлены как глобальные или статические внутри классов или функций, и вы работаете с тулчейном arm-none-eabi-gcc, то вполне возможно вы используете ld-скрипт и startup-код, который не поддерживает вызов конструкторов глобальных переменных. Если вкратце — компилятор кладет список адресов конструкторов в секции .preinit_array и .init_array, поэтому чтобы оно заработало нужно:
1) добавить в ld-скрипт соответствующие секции
3) в startup-коде (обычно это reset-handler) перед вызовом функции main но после обнуления секции .bss и загрузки секции .data добавить что-то вроде:
for( func_t * f = &__init_array_begin; f != &__init_array_end; ++f )
(*f)();
Разумеется то же самое нужно сделать для секции .preinit_array, и если вы хотите, чтобы вызывались деструкторы, то и для .fini_array, только деструкторы вызывать после main. Это если вкратце. А если подробно, то вдумчиво читать документацию про то, как пишутся ld-скрипты, и изучать примеры, например в libopencm3 вся эта инициализация есть, исходники можно на гитхабе посмотреть.
Если переменные-объекты, для которых не вызываются конструкторы объявлены как глобальные или статические внутри классов или функций, и вы работаете с тулчейном arm-none-eabi-gcc, то вполне возможно вы используете ld-скрипт и startup-код, который не поддерживает вызов конструкторов глобальных переменных. Если вкратце — компилятор кладет список адресов конструкторов в секции .preinit_array и .init_array, поэтому чтобы оно заработало нужно:
1) добавить в ld-скрипт соответствующие секции
.init_array: {
. = ALIGN(4); init_array_begin = .;
KEEP ((.init_array)) init_array_end = .;
} >rom
2) сделать доступными указатели на начало и конец секции в коде, например так:
typedef void (func_t)();
extern func_t init_array_begin;
extern func_t init_array_end;
3) в startup-коде (обычно это reset-handler) перед вызовом функции main но после обнуления секции .bss и загрузки секции .data добавить что-то вроде:
for( func_t f = &init_array_begin; f != &__init_array_end; ++f )
(f)();
Разумеется то же самое нужно сделать для секции .preinit_array, и если вы хотите, чтобы вызывались деструкторы, то и для .fini_array, только деструкторы вызывать после main. Это если вкратце. А если подробно, то вдумчиво читать документацию про то, как пишутся ld-скрипты, и изучать примеры, например в libopencm3 вся эта инициализация есть, исходники можно на гитхабе посмотреть.
Только мне показалось, что на фото Riva 128 на микросхеме кроме логотипа nVidia стоит еще и логотип ST Microelectronics, тех самых, которые сейчас клепают довольно популярные микроконтроллеры?
1) Для создания stack-фреймов не используется выделение памяти на куче
2) В stack-фреймы можно напихать сколько угодно и какой угодно информации, не только имя функции и номер строки
3) Функции не заворачиваются в макросы, скорее наоборот — макросы кладутся внутрь функций, причем только тех, которые реально нужны
4) Поддержка многопоточность реализована через thread-local переменные
Ну и по собственному опыту — 50мм на кропе на открытой диафрагме очень даже позволяют отделить объект съемки от фона. Более того, в процессе спора с одним знакомым на тему эквивалентности фокусных/грип и т.п. пробовали снимать с одного ракурса и расстояния один и тот же объект на кроп 1.5 при 50/2.0 и на полный кадр при 75/2.8 — фото были идентичны плюс-минус шумы и цветопередача разных матриц.
UPD. Ну и как бы портрет — это не только лица крупным планом на длинном фокусном.
Если переменные-объекты, для которых не вызываются конструкторы объявлены как глобальные или статические внутри классов или функций, и вы работаете с тулчейном arm-none-eabi-gcc, то вполне возможно вы используете ld-скрипт и startup-код, который не поддерживает вызов конструкторов глобальных переменных. Если вкратце — компилятор кладет список адресов конструкторов в секции .preinit_array и .init_array, поэтому чтобы оно заработало нужно:
1) добавить в ld-скрипт соответствующие секции
2) сделать доступными указатели на начало и конец секции в коде, например так:
3) в startup-коде (обычно это reset-handler) перед вызовом функции main но после обнуления секции .bss и загрузки секции .data добавить что-то вроде:
Разумеется то же самое нужно сделать для секции .preinit_array, и если вы хотите, чтобы вызывались деструкторы, то и для .fini_array, только деструкторы вызывать после main. Это если вкратце. А если подробно, то вдумчиво читать документацию про то, как пишутся ld-скрипты, и изучать примеры, например в libopencm3 вся эта инициализация есть, исходники можно на гитхабе посмотреть.
1) добавить в ld-скрипт соответствующие секции
.init_array: {
. = ALIGN(4);
init_array_begin = .;
KEEP ((.init_array))
init_array_end = .;
} >rom
2) сделать доступными указатели на начало и конец секции в коде, например так:
typedef void (func_t)();
extern func_t init_array_begin;
extern func_t init_array_end;
3) в startup-коде (обычно это reset-handler) перед вызовом функции main но после обнуления секции .bss и загрузки секции .data добавить что-то вроде:
for( func_t f = &init_array_begin; f != &__init_array_end; ++f )
(f)();
Разумеется то же самое нужно сделать для секции .preinit_array, и если вы хотите, чтобы вызывались деструкторы, то и для .fini_array, только деструкторы вызывать после main. Это если вкратце. А если подробно, то вдумчиво читать документацию про то, как пишутся ld-скрипты, и изучать примеры, например в libopencm3 вся эта инициализация есть, исходники можно на гитхабе посмотреть.