Если речь идет о постановочной съемке, то для того, чтобы сделать выбор экспозиции, размещение объекта фотоснимка в пространстве, выбор собственной позиции для совершения фотосъемки, установка света и/или адаптация своего местонахождения и места нахождения объекта фотосъемки под имеющееся освещение нужно сначала представить в голове желаемую картину, а для этого таланты очень даже требуются.
В нормальных фреймворках для property-based тестирования случайности не совсем случайны. Например, если требуется какой-то int, то хорошим тоном будет считаться существенно более частое выпадение значений в районе 0, INT_MIN и INT_MAX. И шансы, что тест этой функции зафейлится даже на 10 тестах уже довольно высоки. А итераций без проблем может быть и 1000.
Я реализовал такое, но на C99. Даже почти довел до первого релиза, думал статью на хабре написать, но в какой-то момент очень резко кончилось свободное время. Поэтому похоже вместо статьи будет этот коммент.
Основной целью было сделать тестовый фреймворк, в котором максимально просто писать тесты, которым можно тестировать plain C код, и для работы которого не обязательно наличие системного malloc. Насколько получилось — можно посмотреть тут. К сожалению пока там есть места с говнокодом, с неконсистентыми именами (с этим вообще беда, иногда подолгу метался между разными вариантами) и не все покрыто тестами — но оно поэтому и не релиз пока что. Зато вроде получилось действительно просто писать тесты (тестирую фреймворк самим собой), и реализовано упрощение тестовых наборов при падении теста. Ну и если кто-то будет смотреть — хотелось бы обратной связи — оно вообще в таком виде кому-то надо/интересно? Стоит ли продолжать работу?
К списку готовых реализаций я бы добавил еще вот это: https://github.com/nothings/stb/blob/master/stretchy_buffer.h
Причем основные идеи там практически как у вас.
К слову о камелионах — у меня в кладовке лежат 12 сгоревших из 12 купленых камелионов по 15 Вт под патрон Е27, причем жили они меньше полугода. Вскрыть лампы без разрушения невозможно. Вскрыл одну на пробу посмотреть что же не так — от светодиодной платы _отпаялся_ один из проводов питания от драйвера.
+1 за совет обратиться к специалисту, главное попасть к нормальному. По собственному опыту — за 4 месяца вылез из состояния «все надоело, пора выходить из окна» до «все офигительно», причем с какого-то момента включается положительная обратная связь.
Крышка действительно алюминиевая? Картинки как снаружи так и внутри до боли похожи на внутренности samsung 530u3, у которого корпус покрашен серебрянной краской, но реально пластиковый. Петли — один в один, как у этого китайца, и доставили много боли как мне, так и еще одному знакомому — тоже владельцу такого ноута (самсунга, не китайца). Если вкратце — из-за пластикового корпуса под нагрузкой этих петель два раза ломалась верхняя крышка (которая с экраном) и один раз сам корпус с материнкой. Пластиковые стойки к которым прикручены петли просто с мясом отрывало. Если у китайца корпус действительно алюминиевый и достаточно жесткий — то при такой цене это просто замечательно.
Раз уж в этой статье упоминаются сразу несколько разных комплексов АРК, думаю будет не лишним дать ссылку на их производителя: http://ircos.ru Там много еще интересного — и характеристик, и фоток, и скриншотов…
Прокатитесь как-нибудь в ясную погоду километров 100 от населенных пунктов, остановитесь в поле, выключите все свои фонарики, телефоны — все что светит. Подождите минут 5. После этого вы больше никогда не напишете подобный комментарий.
Кстати есть мнение, что компоненты лучше хранить отдельно, каждый тип в однородном контейнере, а из entity ссылаться на содержащиеся в ней компоненты по id/индексам.
Используем сходный велосипед в рабочем проекте. Отличия:
1) Для создания stack-фреймов не используется выделение памяти на куче
2) В stack-фреймы можно напихать сколько угодно и какой угодно информации, не только имя функции и номер строки
3) Функции не заворачиваются в макросы, скорее наоборот — макросы кладутся внутрь функций, причем только тех, которые реально нужны
4) Поддержка многопоточность реализована через thread-local переменные
Более того, работал в фирме, в которой ввели такое, встречено было очень негативно, но через полгода выяснилось, что весьма полезно. В компании где работаю сейчас такого официально нет, неофициально сам себе поставил таймтрекер, когда сотрудники узнали — смотрели как на идиота.
Про рендер — вы не поверите, но один хороший знакомый, долго работавший в архитектурной фирме рассказывал, как у них как-то заказали дизайн-проект, и среди прочего в одном из помещений одна стена была ярко-красная, а остальные белые. Настроили материалы, свет, сделали рендер — стены вместо белых нежно-розовые. Начальство говорит — картинка неправильная, делайте что хотите, но клиент должен увидеть белые стены. Немного фотошопа — и стены на рендере белые, начальство довольно, клиент доволен, все хорошо. Проходит какое-то время, на объекте уже ведутся чистовые работы, и тут прибегает клиент и ругается почему маляры ему стены в розовый покрасили вместо белого. Дальше по цепочке идут разборки, в итоге финальная сцена — комната, розовые стены, маляры закрывают плотной белой пленкой стену окрашенную в красный, и внезапно стены становятся белыми. Занавес.
Если речь идет о постановочной съемке, то для того, чтобы сделать выбор экспозиции, размещение объекта фотоснимка в пространстве, выбор собственной позиции для совершения фотосъемки, установка света и/или адаптация своего местонахождения и места нахождения объекта фотосъемки под имеющееся освещение нужно сначала представить в голове желаемую картину, а для этого таланты очень даже требуются.
Посмотрите питоновскую библиотеку hypothesis — в плане идей "как надо делать" это просто праздник какой-то.
В нормальных фреймворках для property-based тестирования случайности не совсем случайны. Например, если требуется какой-то int, то хорошим тоном будет считаться существенно более частое выпадение значений в районе 0, INT_MIN и INT_MAX. И шансы, что тест этой функции зафейлится даже на 10 тестах уже довольно высоки. А итераций без проблем может быть и 1000.
Я реализовал такое, но на C99. Даже почти довел до первого релиза, думал статью на хабре написать, но в какой-то момент очень резко кончилось свободное время. Поэтому похоже вместо статьи будет этот коммент.
Основной целью было сделать тестовый фреймворк, в котором максимально просто писать тесты, которым можно тестировать plain C код, и для работы которого не обязательно наличие системного malloc. Насколько получилось — можно посмотреть тут. К сожалению пока там есть места с говнокодом, с неконсистентыми именами (с этим вообще беда, иногда подолгу метался между разными вариантами) и не все покрыто тестами — но оно поэтому и не релиз пока что. Зато вроде получилось действительно просто писать тесты (тестирую фреймворк самим собой), и реализовано упрощение тестовых наборов при падении теста. Ну и если кто-то будет смотреть — хотелось бы обратной связи — оно вообще в таком виде кому-то надо/интересно? Стоит ли продолжать работу?
Наверное это немного оффтопик, но разве в таких ситуациях unrolled linked list не будет лучшим решением?
Причем основные идеи там практически как у вас.
1) Для создания stack-фреймов не используется выделение памяти на куче
2) В stack-фреймы можно напихать сколько угодно и какой угодно информации, не только имя функции и номер строки
3) Функции не заворачиваются в макросы, скорее наоборот — макросы кладутся внутрь функций, причем только тех, которые реально нужны
4) Поддержка многопоточность реализована через thread-local переменные