Обновить
17
Bulashevich Dmitrii@Corviniol

Embedded Developer

18
Подписчики
Отправить сообщение
комплектующие закупаются и на их основе выпускается уже свой продукт, который и продаётся с добавочной стоимостью
. Это правило прекрасно работает в мирное время для потребительской техники. Те же iPhone используют чуть ли не аккумуляторы производства LG.
Но когда при разработке сколько-нибудь стратегического продукта меня спрашивают можно ли его изготовить целиком из отечественных компонентов мне приходится отвечать «нет». Просто потому что отечественных аналогов некоторых микросхем пока что нет. А если копнуть глубже то выясняешь что и часть материалов зависит от импорта. Например — запрос в Google «производство стеклотекстолита FR4» в первых двух ссылках дал мне вещи вроде
Предприятие ЗАО «Новатор» занимается поставкой материала российского производства марки FR4 с фирменным логотипом ML «Марий Лам». Материал поставляется ведущим российским производителем.
Фольгированный стеклотекстолит ML FR4 изготавливается на новейшем итальянском оборудовании с использованием высококачественных препрегов и медной электролитической фольги.

Я подозреваю что аналогичная ситуация наблюдается в ЛЮБОЙ стране, включая Китай, США и Японию. Так что вопрос становится острым именно в случае «изоляции».
Несомненно в случае изоляции можно будет «поднять» полный цикл производства. Но время будет уже упущено. Вообщем в мировой экономике продолжает действовать принцип «если ты плюнешь в коллектив — коллектив утрётся. А если коллектив плюнет — то ты утонешь.» Так что вопрос влияния страны — это, скорее, вопрос размеров собственного плевка.
да, но так как все параметры позиционные, а не именные нельзя пропустить несколько, а после них несколько задать.
Т.е.
void foo(int *ptr = NULL, int int_arg = 5);

int glob_int = 5;

foo(); // ОК эквивалентно foo(NULL,5)
foo(&glob_int); // OK, эквивалентно foo(&glob_int, 5)
foo(13); // BAD - мы попытались привести int к указателю, вместо вызова foo(NULL, 13)

Мне вот интересно: А это всё compile-time решения? Т.е. не разрастётся ли скомпилированный код от этих наворотов. Второй вопрос — обёртывание базового типа int в структуру с методом добавит нам указатели на методы или нет?
Я не специалист в C++, но мне кажется что вся эта обвеска сильно утяжелит передачу параметров (больше места в стеке) и т.д.
Главная миссия именованных параметров — исключить ошибки при вызове функций и повысить читабельность кода — осуществляется.
Если сужать миссию именованных параметров до такой — то выполняется. Но мне кажется что опциональность параметров — очень важная возможность. И её пользовательскими типами не решить. Иначе придётся либо писать функции со множеством параметров, либо всё равно городить костыли описанные по ссылкам в начале вашей статьи.
Не вопрос. Но большинство задач из жизни вообще имеют некорректные/неполные формулировки. Это только в математике удаётся описать задачу полностью, ничем не пренебрегая. Вот, например, «хозяева квартиры вас внутрь пускать не хотят». Но не указано не хотят априори и непоколебимо или это можно изменить. Например — угрожая оружием, предлагая тройную стоимость стеклопакета, предложив сексуальные или иные услуги (вдруг кому-то незатратно) и т.д.
Затраты бывают не только денежными. Надо смотреть на задание шире. Если мне обещали X денег за разбитие окна, то через 1000 лет я во-первых не дождусь, а во-вторых деньги обесценятся.
В условии сказано «наименее затратными способами». Не сомневаюсь что для кого-то данный способ не является затратным, но всё же.
Про Pi: Взять программу SuperPi и сравнить результат вычислений с файлом в TotalCommander

  1. Попробовать с помощью пневматики. Если не поможет забраться по пожарной лестнице справа с промальповской обвязкой, спусковухой, жумаром и молотком. Закрепиться на крыше, спуститься к окну, разбить, profit!!!
  2. Подумать 5 минут и забить.
  3. Составить список самых бесящих вещей, отсортировать по времени на устранение и лечь спать.
Потребление прямо пропорционально емкости аккумуляторов
Это вы что имели в виду?
Я имел в виду, что потребление электроники мало по сравнению с потреблением движков. Хотя глядя на 600мА для модели B+ готов признать свою ошибку.
Вообще вся матемактика нереальна :-). Но некоторые математические выкладки позволяют предсказать поведение реальных предметов.
Так и с комплексными числами, и с волновой функцией. Хотя мне ближе пример с комплексной амплитудой и импедансом.
Вообще у БПЛА неплохая коммерческая ниша, даже у маленьких, несущих только камеру и имеющих меньше часа полётного времени.
Пример: unmanned.ru/service/irvideo.htm
Мне кажется что моторы жрут сильно больше. И интересовать здесь должно не потребление электроники, а её вес и габариты.
А вся третья часть относилась к
«Soon» doesn't necessarily mean «instantly»
. Да?
Понравились (в исторической перспективе) первые две части, понравилась третья отдельно, но связка между ними какая-то уж очень тоненькая.
С одной стороны — довольно узкий. С другой — это могут быть всякие мини-игры, встроенные в большие проекты. Вспомните, например, игру на взлом компьютера из SystemShock2. Я не уверен полностью, т.к. наблюдаю GameDev со стороны, но мне кажется что удобный движок мог бы увеличить количество подоных мини-игр, которые, на мой взгляд, сущетсвенно добавляют антуража.
Видимо я нечётко выразил свою мысль. Говоря " если бизнес-номера ещё можно узнать из каких-нибудь каталогов" я подразумевал что это общедоступная информация и, следовательно, не требует специального разрешения на обработку (и по закону не является ПД, т.к. юрлицо это не «персона»).
Очень востребованный. Ибо среди «игроделов» (который в резюме называют себя game designer'ами) достаточно много людей которые могут придумывать правила игры и гораздо меньше тех, кто готов эти правила воплощать в законченную разработку. Им нужен внятный интерфейс с разработчиками-программистами, которые будут превращать это всё в готовый продукт (при поддержке художников и иже с ними).
Мне кажется что подобный скриптовый язык практически идеально годится на роль этой прослойки. Игроделы будут писать внутреннюю логику игры, а программисты — движок визуализации, клиент-серверный обмен и т.д.
Ну вот я на весь день залип читая вашу статью. Но захода в 3 читается очень интересно. А открывать 3 разных статьи по одной теме вряд ли стал бы.
Я думаю, что сервис найдёт свою аудиторию и развитие если будет реализован эффектиный механизм обновления базы номеров. И если бизнес-номера ещё можно узнать из каких-нибудь каталогов и т.д. то номера физических лиц придётся заносить пользователям.
Здесь же встаёт вопрос о юридической правомерности данного действия. Согласно ст. 3 Федерального закона 27.07.2006 г. № 152-ФЗ «О персональных данных» телефонный номер связанный с именем уже является персональными данными. Соответсвтенно данный сервис автоматически попадает под все требования к оператору персональных данных.
Так что правомерно с его стороны будет только лишь идентифицировать тех пользователей, которые сами внесут себя в базу.
А так идея хорошая.
Аргумент! У меня тоже регулярно случается что вспомогательные утилиты останавливаются на этапе «стало лень».
Интересно. Почитал результат работы вашего скрипта и имею к нему несколько вопросов:
  1. Зачем там динамическое выделение памяти? Ведь все данные уже известны на момент генерации исходников.
  2. Зачем там столько memcpy при создании меню? Можно ведь
    memcpy( menu[0].welcome_string, "Hello! Welcome to the test menu.\n", string_lengths[0] );
    
    заменить на
    menu[0].welcome_string = "Hello! Welcome to the test menu.\n";
    
    Или потом эти данные как-то изменяются?

Хотя вообще идея генерации исходных кодов мне нравится — она позволяет каждую часть проекта писать на том языке, который для этого лучше подходит. Ну и изобретать при этом свой язык, при необходимости.

Информация

В рейтинге
Не участвует
Откуда
Санкт-Петербург и область, Россия
Зарегистрирован
Активность