докину еще своего отношения, последние годы я покупаю именно 3-ех летней давности флагманы, когда в момент выхода они стоят почти в 2 раза дороже но через 3 года их цена заметно падает, а значит у меня есть еще 2-3 года времени жизни с хорошим устройством по хорошей цене
Так, к примеру, я когда то купил xiaomi a2 (отличный смарт, маленький шустрый хорошая камера но без стабилизации)
Сейчас у меня xiaomi redme note 8 pro (купил ровно год назад), планирую с ним хотя бы 3 года прожить
он немного великоват, хорошая камера (для fullhd есть стабилизация видео), их хваленый макрообъектив не сильно отличается от их штатного 64мбитного фото (делаешь фото с максимальным приближением и пользуешься цифровым зумом), есть nfc (ни разу не включал), из явных недостатков - он очень скользкий и хрупкий (сделано это специально, поэтому уродовать его чехлом), я читал есть те кто покрывают свои корпуса резиноподобным пластиком (вопрос не изучал но говорят помогает)
Сегодня я его бы и рекомендовал, ну возможно xiaomi 10 pro ...
Изучай под цели, нужна ли тебе большая лопата или легкий миниатюрный экран, нужно ли много памяти, нужна ли карта памяти для фото и тьма тьмущая опций, обычно вариантов и не остается
оп а сразу сказать что тебе именно надо?
чтобы разбирать пакет данных с элементами разного типа у тебя 2 подхода
* первый - заведи свой тип данных в виде структуры, описывающей весь пакет твоих данных (к сожалению это подходит только для тех типов пакетов, структура которых не имеет динамических блоков, например строк переменной длины, или их мало)
struct MyPacket
{
uint16_t myFirstElement;
uint8_t[16] myFixedLenName;
...
}
тогда твой буфер - это буквально переменная этого типа, и работать с ней можно как есть, в си есть не только простые типы но и битовые (переменная являющаяся несколькими битами от куска памяти) и union, когда один и то же блок в структуре может быть на выбор разными элементами, лишь бы размер был одинаковый.
недостаток, компиляторы по своей прихоти, ради оптимизации могут добавлять в структуру выравнивания и даже менять порядок, у разных компиляторов есть соответствующие директивы
#pragma pack(push, 1) // это отключит выравнивание по 32-64 битам
* второй - держи пакет данных в виде массива байт без типа void* (хотя любой другой подойдет, но удобнее байтовый тип), затем по шагам ты берешь нужное количество байт из этого массива и сдвигаешь указатель на соответствующее количество байт, размером с этот элемент, пример:
*(uint16_t*)buf; // читаем данные
buf+=sizeof(uint16_t); // делаем сдвиг
этот подход самый гибкий, но нужно следить за выходом за границы, так как преобразования типов ненадежны, в смысле если ты допустишь ошибку, ты можешь об этом не сразу узнать.
майкрософт ограничила типы ситуаций, в который будет работать их internet sharing
там требуется 2 ethernet подключения (по уму можно wireless настроить но не уверен что в win10 это не сломали) и главное никаких инструментов настройки, например только dhcp у адаптера, чей интернет делается общим
я выкручивался виртуальной машиной (когда то давно на 32-битных версиях работал colinux, не требовал ресурсов и весь спектр сетевого функционала на руках)
ну где то так, обычный поиск, иногда регулярками
может софт и есть который анализирует html но нужно понимать что веб сайты это не статичные страницы а код их генерации, поэтому универсального решения ожидать не стоит, ведь искать надо в этом коде
не в ответе потому что я этим не занимаюсь уже много лет, вполне возможно что ситуация стала иной и софт все же есть
Foxik1, это стеб?
localhost - это 127.0.0.1
по этому адресу ты можешь подключиться только к самому себе (если конечно перенаправления хитрые не настроишь)
Использовать один сервер, эти объемы минимальны, конечно если у тебя будут десятки-сотни тысяч активных пользователей, возможно нагрузка станет неподъемной для одной машины, но что то мне говорит что на старте тебе хватит 10$-vps
full-text поиск используй то что нравится и на чем лучше всего пишешь, хотя современные sql базы отлично и с этим справляются, многим нравятся некоторые фичи эластика
sql база данных идеальна для случаев, когда нужна будет аналитика но еще непонятно какая, никаких json и других document-oreiented подходов, все разбивай на элементы и храни в полях и таблицах, сем меньше у тебя будет универсальных данных, тем легче тебе будет. Данные должны быть машиночитаемыми.
Совет стороннюю базу для full-text поиска используй как довесок для основной sql базы данных, а не как основное хранилище, пусть оно дублирует его.
Так, к примеру, я когда то купил xiaomi a2 (отличный смарт, маленький шустрый хорошая камера но без стабилизации)
Сейчас у меня xiaomi redme note 8 pro (купил ровно год назад), планирую с ним хотя бы 3 года прожить
он немного великоват, хорошая камера (для fullhd есть стабилизация видео), их хваленый макрообъектив не сильно отличается от их штатного 64мбитного фото (делаешь фото с максимальным приближением и пользуешься цифровым зумом), есть nfc (ни разу не включал), из явных недостатков - он очень скользкий и хрупкий (сделано это специально, поэтому уродовать его чехлом), я читал есть те кто покрывают свои корпуса резиноподобным пластиком (вопрос не изучал но говорят помогает)
Сегодня я его бы и рекомендовал, ну возможно xiaomi 10 pro ...
Изучай под цели, нужна ли тебе большая лопата или легкий миниатюрный экран, нужно ли много памяти, нужна ли карта памяти для фото и тьма тьмущая опций, обычно вариантов и не остается