Скажите, вк действительно волнуют вопросы долгой жизни вкладки? Почему по прошествию всего суток автоматический предпросмотровщик ссылок в поле ввода сообщения ломается? Приходится рефрешить страницу только ради того, чтобы он снова заработал. Воспроизводится в Firefox как минимум на Ubuntu уже пару лет.
И вообще баги как-то странно обрабатываются. Еще год назад сообщил в поддержку об этом баге и еще о паре (невозможности в Firefox прикреплять файлы Drag&Drop-ом в поле ввода сообщения и проблема с нагрузкой на ЦП при открытии просмотровщика фотографий) — до сих пор не исправлено, в поддержке еще тогда ответили «передано разработчикам, как только что-нибудь будет известно, мы вам обязательно сообщим». Скажите, может, для вас это очень пустяковые баги и всегда есть более приоритетные, или причина в чем-то еще?
Браузер не закрываю подолгу, от пары недель до месяца (примерно раз в месяц понимаю, что пора перезагрузить систему). В браузере принудительно включена многопроцессность (лимит — 4 процесса, ранее 1, чтобы просто отделить GUI браузера от вкладок), из плагинов активно пользуюсь только TreeStyleTab, GreaseMonkey, FriGate и AdBlock.
После перехода на многопроцессность было ощущение буста примерно в раза 2-3 (наверное, за счет прекращения подвисаний браузера на некоторых тяжелых сайтах). Все это было на ноуте с 8 ГБ ОЗУ и i5 на борту около года назад. Сейчас на десктопе i7, 16 ГБ ОЗУ, но что на ноуте, что на десктопе, падения случались крайне редко, даже вспомнить не смогу, когда примерно.
Еще на ноуте был забавный случай, когда я в одной ветке дерева сделал хранилище из вкладок-картинок, примерно 100 штук. На удивление, браузер работал стабильно и не падал.
А мне наоборот проще ориентироваться по дереву. Часто используемые вкладки быстро запоминаются, и рука уже сама тянется в нужное место. А если несколько задач — делаем одну вкладку родительской, а остальные дочерними (как у меня на скрине с хабром). Понадобилось отложить на время — скрыл дерево, захотел продолжить — развернул.
Мне с вами сложно согласиться, что boost::asio подходит для новичка. Когда только начинал знакомиться с сокетами в C++, конечно, гуглил библиотеки и буст рассматривал. Но у меня была простая задача: передать файл по сети, т.е. простая утилита по типу netcat, и я совсем не понимал, зачем буст предлагает мне какие-то io-сервисы и acceptor-ы.
В итоге накопал в интернете примеры работы с сокетами с помощью API ОС и сделал свою небольшую обертку над ним (кому интересно, репозиторий у меня на гитхабе — cppstreams). Файлы хотелось передавать между виндой и линуксом своим приложением, поэтому сделал ее кроссплатформенной, научил ее работать с C++-овым stream-ом и только после этого уже понял, для чего нужны io-сервисы, select-ы и как это вообще работает.
Но вот так с наскоку разобраться в boost::asio у меня не вышло.
Мне потребовалось год назад, а в рунете не смог найти никаких толковых статей. На английском нашел пару, но очень не хватало рабочих примеров и объяснения некоторых тонкостей. Оба этих недостатка постарался исправить в своей статье.
Кстати, почему поздновато? Сейчас используют что-то другое с подобным функционалом?
Попытался построить простую модель решаемой задачи:
Код
class TBase {};
class Target : public TBase {
protected: int target_function(){ return 5; }
};
class Base {
private: TBase *tbase;
public: Base(TBase *t) : tbase(t) {}
};
class Main : public Base {
private: Target t;
public:
Main() : Base(&t) {}
const Target &getTarget(){ return t; }
};
int main(){
Main m;
int val = m.getTarget().target_function(); //нужно получить это
}
Реальные классы можете посмотреть в коде библиотеки. Для решения задачи наследованием нужно внедрить в класс basic_pstream своего наследника basic_pstreambuf.
Работа с целевым классом в используемой мной библиотеке ведется не напрямую, а через еще один класс.
Потоки из стандартной библиотеки устроены таким образом, что сначала реализуется наследник std::streambuf, а потом он используется в другом классе, наследующем std::iostream. Чтобы правильно внедрить свой streambuf, пришлось бы разбираться еще и в классе-наследнике iostream.
Если знаете способ обойти это, буду признателен за совет.
Интересный вариант! Причем и для private-членов должно сработать.
Но есть один недостаток: то для «взлома» мне нужно было самому осознанно писать имя макроса, а ваше делает видимым вообще все и без макросов.
Мне все же больше понравился вариант с using.
2 равновероятных вариант будет только в том случае, если рассматривать это как новую задачу. Но у нас задача изначально другая.
Изначально 3 двери, за 2-умя их них козлы. Значит шанс ткнуть неправильную дверь = 2/3. Монти-Холл в любом случае откроет дверь с козлом. А значит в 2 из 3 случаев если мы изменим выбор, то попадем на выигрышную дверь (т.к. вторая проигрышная уже открыта Монти-Холлом, а первую мы выбрали сами).
Мне кажется, konstantin_berkow имел в виду именно тот факт, что вообще HelloWorld занимает больше мегабайта. А так да, согласен с вами, что 1.4 ближе к одному, чем к нескольким мегабайтам.
И все же печалит, что по умолчанию подключаются толстые библиотеки, которые не всегда нужны. В большинстве небольших приложений, коих сейчас штопают пачками, без них можно вполне обойтись, а пользователь сэкономит по мегабайту с каждого такого приложения. Кто-то скажет, что сейчас-то о весе приложения уже можно и не париться. Да, возможно, если речь идет всего об одном приложении. Но если с каждого сэкономить по мегабайту, глядишь, еще одна игрушка объема Angry Birds влезет, или минута видео важного события из вашей жизни.
Если же приложению действительно нужны эти библиотеки, то это уже, как мне кажется, задача разработчика понять, что нужно их использовать. Это, конечно, требует некоторых знаний и повышает порог вхождения, но зато некачественные приложения будут фильтроваться самими пользователями, а качественный софт будет в топах.
Нет, ничего он не погорячился с мегабайтами, только неделю назад скачивал андроид студию и создавал простейшее HelloWorld приложение средствами среды с настройками по умолчанию. Готовый apk занимает 1.4 мегабайта.
Просто шикарная концовка!
Уже когда конец статьи виднелся на мониторе, я все гадал, как еще половина рабочего дня уместится в пару абзацов. И это превзошло все мои ожидания! Браво!
И вообще баги как-то странно обрабатываются. Еще год назад сообщил в поддержку об этом баге и еще о паре (невозможности в Firefox прикреплять файлы Drag&Drop-ом в поле ввода сообщения и проблема с нагрузкой на ЦП при открытии просмотровщика фотографий) — до сих пор не исправлено, в поддержке еще тогда ответили «передано разработчикам, как только что-нибудь будет известно, мы вам обязательно сообщим». Скажите, может, для вас это очень пустяковые баги и всегда есть более приоритетные, или причина в чем-то еще?
После перехода на многопроцессность было ощущение буста примерно в раза 2-3 (наверное, за счет прекращения подвисаний браузера на некоторых тяжелых сайтах). Все это было на ноуте с 8 ГБ ОЗУ и i5 на борту около года назад. Сейчас на десктопе i7, 16 ГБ ОЗУ, но что на ноуте, что на десктопе, падения случались крайне редко, даже вспомнить не смогу, когда примерно.
Еще на ноуте был забавный случай, когда я в одной ветке дерева сделал хранилище из вкладок-картинок, примерно 100 штук. На удивление, браузер работал стабильно и не падал.
В итоге накопал в интернете примеры работы с сокетами с помощью API ОС и сделал свою небольшую обертку над ним (кому интересно, репозиторий у меня на гитхабе — cppstreams). Файлы хотелось передавать между виндой и линуксом своим приложением, поэтому сделал ее кроссплатформенной, научил ее работать с C++-овым stream-ом и только после этого уже понял, для чего нужны io-сервисы, select-ы и как это вообще работает.
Но вот так с наскоку разобраться в boost::asio у меня не вышло.
Кстати, почему поздновато? Сейчас используют что-то другое с подобным функционалом?
Реальные классы можете посмотреть в коде библиотеки. Для решения задачи наследованием нужно внедрить в класс basic_pstream своего наследника basic_pstreambuf.
Потоки из стандартной библиотеки устроены таким образом, что сначала реализуется наследник std::streambuf, а потом он используется в другом классе, наследующем std::iostream. Чтобы правильно внедрить свой streambuf, пришлось бы разбираться еще и в классе-наследнике iostream.
Если знаете способ обойти это, буду признателен за совет.
Но есть один недостаток: то для «взлома» мне нужно было самому осознанно писать имя макроса, а ваше делает видимым вообще все и без макросов.
Мне все же больше понравился вариант с using.
Изначально 3 двери, за 2-умя их них козлы. Значит шанс ткнуть неправильную дверь = 2/3. Монти-Холл в любом случае откроет дверь с козлом. А значит в 2 из 3 случаев если мы изменим выбор, то попадем на выигрышную дверь (т.к. вторая проигрышная уже открыта Монти-Холлом, а первую мы выбрали сами).
И все же печалит, что по умолчанию подключаются толстые библиотеки, которые не всегда нужны. В большинстве небольших приложений, коих сейчас штопают пачками, без них можно вполне обойтись, а пользователь сэкономит по мегабайту с каждого такого приложения. Кто-то скажет, что сейчас-то о весе приложения уже можно и не париться. Да, возможно, если речь идет всего об одном приложении. Но если с каждого сэкономить по мегабайту, глядишь, еще одна игрушка объема Angry Birds влезет, или минута видео важного события из вашей жизни.
Если же приложению действительно нужны эти библиотеки, то это уже, как мне кажется, задача разработчика понять, что нужно их использовать. Это, конечно, требует некоторых знаний и повышает порог вхождения, но зато некачественные приложения будут фильтроваться самими пользователями, а качественный софт будет в топах.
Уже когда конец статьи виднелся на мониторе, я все гадал, как еще половина рабочего дня уместится в пару абзацов. И это превзошло все мои ожидания! Браво!
А где можно почитать «почти готовый» стандарт про них? Интересно, как он выглядит на данный момент.