Примерно как anbox сейчас делает

И как оно сейчас?

Все так же запутанно и требует большого бубна. Первый запуск все так же крышесносящ — о том как называются два демона на вики не пишут, но прилагают картинку о том что они существуют :-)

Правда появились отдельные «выжившие», которые скриптуют установку тех же opengapps… но не только лишь всякий может долйти до этого шага.

Тут еще такой момент, знать != участвовать.

Если гм гм «Грязный Гарри» вместе бухают с «Лаки Люком», а с Люком терки, то странно рассчитывать что Гарри придет на помощь :-)

Увы, но далеко не всю бумажную работу можно делегировать. Но как минимум все бла-бла точно снимались бы, так что — присоединяюсь к вопросу :-)

Ха, это герой у них дохлый был.

Я лично знаю героя, который не только в одно лицо выдал «продукт года» в транс-наци-анальной конторе, но и при этом уволил парочку директоров (включая собственного начальника), пытавшихся успех перехватить. Несмотря на попытку в последний момент слить героя его собственной крышей в виде Senior VP, хехе.

И да, герой добровольно покинул транс-наци-анальную лавку после триумфа, мотивировав под пиво так: «Ну, если они сами хотят в интриги вместо результата, как я могу им помочь?»

:-)

Уже год героя зовут обратно в эту лавку. Нужны новые прорывы, а «по скраму» хорошо только с тикетами и KPI поверх них… Герой смеется, и говорит что как пропозал дотикает до x3 от его прошлой salary с бонусами, он подумает :-) До x2 уже дотикало, шансы есть…

Я бы даже добавил, что в местах где «непонятно, в чем заключается работа» получение однозначно положительного результата действительно можно сравнить с геройством.

Я таких живьем видел.

«Пока мы все нарезали круги вокруг кофеварки и славили гендира, этот отморозок в свитере с оленями что-то там реально сделал. Подвергнем же его остракизму!»

:-)

из этих крутых лавок не выходила бы всякая говнотека ± среднего индусского уровня

Это вещи слабосвязанные.

Можно любого «крутяка» укатать, устрой ему кранчей на пару месяцев нон-стоп, «патамушта-бызнесь-хочет-вчера». И как инженер ни крут, а сидит и херачит по тикетам, с дейли митингами и ретроспективами. И каждый день оправдывается — почему не успевает.

И выбора у него нет — говнокод или говнокод :-)

А бывает еще круче. Бывает что саентисты по скраму должны выдавать прорывные инвеншены по тикетам (сам такое видел, офигел в край и быстро убег). Результат? Зачем?

str.reserve(1024);
...
str += " " + std::to_string(i) + " " + std::to_string(j) + ":";

Визуально хоть пытается выглядеть не ужас-ужасом, не?

Зато сколько тут копирований и вызовов небесплатного и недешевого аллокатора… вроде бы (вроде бы!) мы не должны за это все радостно платить, а по факту — ух!!!

Давайте попробуем удешевить.

str.reserve(1024);
str += " " += std::to_string(i) += " " += std::to_string(j) += ":";

Вот так уже несколько лучше. std::to_string() все еще делает много лишнего, но это уже лучше. Теперь — задумаемся, а в правильном ли порядке идут вычисления, и не добавить ли скобок? А то присваивания идут справа налево…

str.reserve(1024);
(((((str += " ") += std::to_string(i)) += " ") += std::to_string(j)) += ":");

Ну и кто в здравом уме будет так писать?

Не, в Java/C# это решали умные люди, у них компилятор автоматом преобразует строчные плюсики в

str = (new StringBuilder(N)).append(...).append(...).toString();

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

Пайтонисты и дотнетчики пошли еще дальше — и у них в строчках прямо переменные указывать можно, типа такого

str += $" {i} {j}:";

и некоторые даже этим злоупотреблять научились, указывая вместо переменных многоэтажные конструкции :-)

Вы спросите, так а чем не нравится путь комитета? Тем более stringstream завезли, стало чуть проще…

std::stringstream ss;
ss << << str << " " << i << " " << j << ":" ;
str = ss.str();

Вполне же?

Давайте вспомним, как часто и зачем нам надо в коде много форматирования? Вот именно, логи! И что, нам теперь по три строчки каждый раз вставлять, и плодить локальных переменных? Не, конечно можно… но лениво.

Неужели все так плохо?

По счастью, нет. В новейшем стандарте завезли std::format! Господь услышал наши молитвы!

Что делать олдфагам тем, у кого легаси? Нууу, в принципе, можно вот как-то так вывернуться —

#include <memory>
#include <string>
#include <stdexcept>

template<typename ... Args>
std::string string_format( const std::string& format, Args ... args )
{
    size_t size = snprintf( nullptr, 0, format.c_str(), args ... ) + 1; // Extra space for '\0'
    if( size <= 0 ){ throw std::runtime_error( "Error during formatting." ); }
    std::unique_ptr<char[]> buf( new char[ size ] ); 
    snprintf( buf.get(), size, format.c_str(), args ... );
    return std::string( buf.get(), buf.get() + size - 1 ); // We don't want the '\0' inside
}

но тут наш sprintf все еще с нами и у него все те же проблемы несоответствия фактического списка параметров и декларированных спецификаций форматирования. Да и кроме примитивных типов есть еще и структуры-классы, они снова идут мимо.

И зачем я это все вспомнил -\_(o^o)_/-

Выбираешь нужные лего-кирпичики, соединяешь — гарантированно работает. Программист станет, в сущности каменьщиком.

… предрекли в 1960х, когда появились общие библиотеки :-)

Меня бы устроило, если бы этот «эмулятор» работал по типу Wine — имитируя не телефон, а именно андроид как окружение. Примерно как anbox сейчас делает, но чтобы не выполнять инструкцию из 18 пунктов для установки opengapps :-)

А уж ели в каком-то разумном виде заработает хотя бы часть гуглосервисов — то это будет вполне себе победа, запустил полдесятка андроидо-приложений, каждое в своем окошке одновременно — лепота…

И подозреваю, куда-то в эту сторону мы в итоге и придем.

Вкратце: получаешь незаменимый и нерелевантный опыт.

… и чем древнее изначальная кодовая база — тем больше этого опыта и получаешь :-)

Вот насчет «не нужно» — споры как раз и идут. Оно наверное все еще полезно, уметь в структуры данных, обычно это хэштаблицы-списки-кольца-деревья, графы уже сильно реже. Но это неточно :-)

Шутка в том, что я еще помню, как задача транспонирования матрицы занимала несколько суток, занимая при этом весь объем — нет, не тогдашней оперативы, а тогдашнего жесткого диска! и я тогда самолично изобретал — как это в почти 3 мегабайта кэша воткнуть работу с матрицей, которая сводится к треугольному виду методом Гаусса. Lookahead и вот это вот все, чтобы диск не трещал так жалобно своими головами.

Причем даже не «повысить перформанс», а потому что «в лоб» предыдущий диск за выходные сгорел. :-)

Уже в двухтысячных — такие матрицы просто помещались в оперативе, их сводили стандартным матпакетом или на пайтоне, и перформанс вообще никого не волновал.

Теперь сотни мегабайт воспринимаются как «лабораторная работа», тут вообще нечего делать. Что тут оптимизировать?..

Соответственно в мейнстриме и «тюнинг» структур данных и алгоритмов вокруг них — нет, не исчез! но сильно изменился :-)

Все так же — кто во что горазд. Вплоть до сумрачных фантазий из 90х, типа такого

str.reserve(1024);
...
sprintf(str.c_str() + ::strlen(str.c_str()), " %d %d:", i, j);

за что хочется немедленно убить на месте, съесть и закопать. Но с другой стороны, что предлагает нам комитет?

str.reserve(1024);
...
str += " " + std::to_string(i) + " " + std::to_string(j) + ":";

это как бы не сильно лучше :-)

Да, второй вариант категорически неправильный. Но что с правильным?

std::stringbuf buffer;
std::ostream os (&buffer);
os << str << " " << i << " " << j << ":" ;
os.flush();
str = buffer.str();

И так — во всех местах, где надо форматный вывод? Да ну нафиг, что там с неверным вариантом, может уже не так плох? :-)

«Шо, опять?!» (с) известный мультфильм.

(присаживается поудобнее в кресло-качалку, накрывается клетчатым пледом, наливает в кружку что-то горячее с молоком, отхлебывает)

А ведь я застал-с те времена, когда знание алгоритмов всяческих там сортировок, деревьев и прочих списков было обязательным, да-с…

Лет двадцать пять назад, когда программы были маленькие, а 640 килобайт еще многим хватало, я непосредственно и всегда использовал эти самые алгоритмы и структуры данных. В этом было целое искусство — как бы так написать, чтобы втиснуться в требования задачи…

Вся работа начиналась вот примерно с таких креативов

struct foo_nlist {
    struct foo_nlist* next;
    ...
};

struct foo_nlist* foo_lookup(struct foo_nlist* root, ...);
struct foo_nlist* foo_insert(struct foo_nlist* root, ...);
struct foo_nlist* foo_remove(struct foo_nlist* root, struct foo_nlist* elem);

в тяжелых случаях вытаскивался препроцессор

#pragma pack(1)

struct nlist_header {
    struct nlist_header* next;
};

#define DECLARE_LIST_ENTRY(foo_nlist_name, foo_type) \
    struct foo_nlist_name { \
        struct nlist_header header; \
        foo_type value; \
    }

struct foo {
    ...
};

struct bar {
    ...
};

#define TO_VALUE(header, foo_type) \
    ((foo_type*)((char*)(header) + sizeof(struct nlist_header)))
#define TO_LIST(value) \
    ((struct list_header*)((char*)(value) - sizeof(struct nlist_header)))
 
DECLARE_LIST_ENTRY(foo_nlist, struct foo) foo_root;
DECLARE_LIST_ENTRY(bar_nlist, struct bar) bar_root;

struct nlist_header* nlist_lookup(struct nlist_header* root, ...);
struct nlist_header* nlist_insert(struct nlist_header* root, ...);
struct nlist_header* nlist_remove(struct nlist_header* root, struct nlist_header* elem);

На этом полет креатива не останавливался — появлялись mutex для параллельной работы, списки менялись на деревья и прочая, а для работы со структурами данных изобретался паттерн visitor в стиле «лямбд пока не завезли»:

#define FOR_EACH_NLIST(foo_type, item, nlist) { \
    for(struct nlist_header* hdr = (nlist); hdr; hdr = hdr->next) { \
        foo_type* item = TO_VALUE(hdr, foo_type);
#define FOR_EACH_END() \
        }\
    }
...
    FOR_EACH_NLIST(struct foo, foo_item, foo_root) 
        if (foo_item-> ..) {
            FOR_EACH_NLIST(struct bar, bar_item, bar_root) 
                ...
            FOR_EACH_END()
        }
    FOR_EACH_END()

Это сейчас за такое я джунов луплю по рукам линейкой не одобряю, а тогда… тогда даже строки были квадратно-колесными, и в приличном проекте их было полдюжины разных. Роднило их только одно — все они умели в char*, а наиболее грамотные — еще и в const char*.

Это сейчас за попытку изобрести свой аналог std::string ваш лид спросит — в своем ли вы уме, а 25 лет назад он бы поинтересовался, как это удалось сделать copy-on-write и при этом работающую форму

str[n] = 'a';

и как при этом избежать O(n^2) в случае классики

result = a + "\\" + b +"\\" + c + "." + d; 

Следом обычно шел кастомный аллокатор, современный tcmalloc() тогда тоже еще не завозили, и героическая борьба с memory leaks…

И вот когда я в очередной раз читаю про штурм вершин изучение алгоритмов для собеса, я вспоминаю эти уже далекие времена.

Вот честно сказать, если бы я в то время ушел «на руко-водящую работу», больше бы не программировал (ну кроме макросов в экселе), и мне бы вдруг! надо было бы отсобесседовать молодежь — я бы вспомнил именно про алгоритмы :-)

Ну, просто потому, что на «а вот тут у нас в шаблоне дуал байндинг», или «а тут я сделал автомаппинг дэтэошек на доменную модельку через аннотации», «а тут у нас стандартный рипазиторий», «а спрингбутовый тест я сделал через рест темплейт», я бы смог только выдавить «че?...»

А вот когда я грозно бы спросил про о-большое в случае реализации ArrayList на вставку в середине — я бы и произвел нужное впечатление на молодняк, и хотя бы смог бы понять их ответ :-)

Яблочные вот анонсировали. Андроидные вполне в anbox можно, тем кому opengapps хватает.

Глядишь, и мелкомягкие тоже через пару лет очухаются, и мы еще не раз потом услышим, что именно в микрософт придумали запускать на десктопе мобильные приложения, еще в 2012 году :-)

Что поделать, те времена давно прошли, беру те картинки что хотя бы иллюстрируют тезис о том, что общесистемные цветовые палитры (темы) — это не изобретение последних пары лет :-)

Так и 30 лет назад тоже были не все темными по умолчанию… но многие :-) и почти все — переключались в темную нативную тему.

Даже такие



Или вот еще



Говорят, существовали версии маков без темной темы — но я такого не застал :-)

System-wide темную тему первыми ввели именно apple

вы не правы, она изначально появилась в виндофонах

(смеется) а видели ли вы Windows 3.1?



Темные темы 20-30 лет назад были по-моему у всех, считалось хорошим тоном — поддерживать темную тему повсеместно. Порносайты имеют черный фон именно с тех времен, когда все и так было черным…

А у вас — прямо таки дискуссия, кто у кого скопировал :-)

Стилус тоже — MS добавить добавили, а что с ним делать не придумали.

Они так придумали, что даже сами не стали этим пользоваться. Предполагалось, что будет отдельный класс приложений для ввода световым пером, для чего в WinAPI накрутили всякого разного… но вот индустрия не оценила.

samsung с их линейкой note.

Тут кстати намного лучше. Просто модный аксессуар для «порисовать палкой по экрану», а не «новый революционный способ ввода».

дизайн windows phone не «плоским», а «примитивным»

… и это даже не учитывая тот факт, что важность дизайна сильно переоценена.

И да, дизайн окошек в динамике — это что-то с чем-то.

Когда компы были большими, и еле тянули простейшую графику — микрософт продвигала свой 3d look, с анимациями и темами (Win95). Когда же компы стали мощными, и стало можно наворачивать эффекты любой сложности — скатились в примитивизм.

и не умеет запускать x64 приложения

… поэтому микрософт предлагает в 2020 году использовать 32битный офис в эмуляторе :-)

Что отдельно неимоверно доставляет, да… пересобрать под AArch64 — совсем никогда такого не слышали ©

НТ4 была мультиплатформенная… Куда же все пропало?

Пропала не ось, а тулчейн.

Это такой своеобразный привет от команды вижуалстудии, когда они изобрели свой сишный рантайм, отличный от системной msvcrt.dll.

Я еще помню те времена, когда вдруг общесистемную библиотеку стало нельзя использовать, зачем-то. :-)