Не сразу понял, что «pastebin.com» это «paste bin», а не «пастебин». Уж было обрадовался, что какой-то новый сайт со стёбом, но увы…
А не информации, в КаЛаб не нанимали программистов из мэйл.ру в последнее время?
Из всего вышеперечисленного использую только gmail(только для почты. Раз вы почтовый сервис причислили к инновациям, видимо, gmail умеет что-то крутое делать, чего я просто не знаю и не пытался узнать, потому что мне просто нужен был почтовый ящик) и Android. Какой-то я не инновационный совсем.
А чем chrome инновационнее firefox или oper'ы?
> Мы также думаем над вариантом с боковыми вкладками.
Пользуюсь ФФ с плагином, располагающим вкладки сбоку в виде дерева. Это единственный вариант, который меня устроил. Видны не только все открытые вкладки, но и иерархия открытия (внутри домена). Если у браузера нет возможности открывать вкладки сбоку, в виде дерева или чего-то похожего, я этот браузер даже не пытаюсь использовать, т.к. категорически неудобно. Так что очень рекомендую реализовать боковое расположение вкладок, хотя бы ради меня.)
Говорю только за С++.
Доступ к полям «благожелательнее», чем к элементам массива. Потому что адрес поля известен статически, а адрес элемента может потребоваться вычислять в рантайме (если компилятор не оптимизирует). Выравнивание всегда можно настроить, чтобы поля были так же плотно расположены, как и в массиве. С точки зрения кэша абсолютно без разницы, будет считанно 4 элемента массива или четыре переменные, расположенные друг за другом.
А вообще, если на C# или Java или других высокоуровневых языках начинают заниматься байтоёбством, то это означает лишь то, что язык для данной задачи был выбран неудачно, либо пришло время немного переписать часть программы на другом языке.
Если уж заговорили о выравнивании, то нужно сразу сказать и о порядке объявления данных-членов. Порой, можно существенно уменьшить размер структур, просто переупорядочив данные-члены. Если кратко, то наиболее компактным будет расположить данные от типов максимального размера к типам минимального, тогда будут минимальные затраты на выравнивание «пустыми» байтами.
Ну и при чём тут С++? К С++ данная оптимизация не применима хотя бы в силу того, что между классом и структурой нет никакой разницы (private/public проигнорируем).
Если уж размер указателя имеет столь большой вклад в размер объекта, то эффективнее использовать собственный аллокатор и вместо указателя на объект хранить индекс этого объекта в собственном диспетчере памяти (будет 4 байта, независимо от архитектуры. Или два байта или три или полтора).
А с чего эти нечеловеческие защитники решили, что эти шимпанзЫ хотят в заповедник во Флориде? Нужно их спросить, где они хотят жить, иначе это опять же лишение их права на свободу перемещения.
А вообще, вы просто не поняли фичу! Вот написал автор про бездумное использование шрифтов и сразу же его продемонстрировал, чтобы было понятнее. Молодец автор.
Есть «профессиональные олимпиадники», которые с лёгкостью проходят неадекватные собеседовательные задания, а потом говнокодят до тех пор, пока их не уволят или не повысят. А есть программисты, которые пишут рабочий не-всегда-говнокод, у которых могут быть проблемы с заданиями на собеседованиях, которые не имеют ничего общего с реальными программистскими задачами…
А вообще, я не сильно понял, о чём статья.
Другое дело, теперь хотя бы не упадёт, пусть и ценой потенциальных утечек и не разлоченных ресурсов.)
Теперь, если обращение к логеру произойдёт после его разрушения, то он будет создан вновь, но не будет разрушен. А если рантайм уже успел выгрузиться, то всё-равно упадёт (но это уже почти надуманная ситуация).
Код не смотрел. ReleaseSingletonObject предлагается вызывать вручную? Чтоб будет, если ошибка возникнет после вызова ReleaseSingletonObject, когда синглотон уже разрушен (ответ я знаю, потому что delete вижу, а обнуления не вижу, следовательно будет Большой Барабум)?
Почему я сразу обратил внимание на деструктор? Потому что есть куча глобальных и статических объектов (Плохо? Но такова жизнь, они всегда есть в более-менее крупном проекте, те же синглтоноуправляемые объекты, помимо этого логера). В каком порядке они удаляются? Они удаляются до или после вызова ReleaseSingletonObject? Это риторические вопросы, чтобы вы подумали над усовершенствованием механизма удаления.
> Политика создания это просто класс, который создает некоторый объект и возвращает на него некоторый интерфейс
Это-то понятно. Только параметризировать синглтон следовало бы политикой создания этого синглтона (управляемого объекта, если точнее), но это уже дело привычки и зашоренного статьями Александреску взгляда. А вот к первому абзацу комментария отнеситесь серьёзно.
> возможно, потребуется обновить вашу систему для доставки вам этих обновлений.
А мне ещё в семёрке «Центр обновления» писал, что нужно обновить «центр обновления Windows», чтобы установить обновления…
Windows… Windows не меняется.
Примечательно, что в деструкторе синглтона не вызывается ReleaseSingletonObject.
Вторая примечательность, что ПолитикаСоздания не управляет способом создания управляемого объекта (он всегда создаётся через new), но подгружает библиотеку («в нашем случае»).
Ну и заголовок статьи не соответствует содержимому. Класс TSingleton приведён настолько не полностью, что даже не скомпилируется (не хватает класса LogFromDllPolicy или его интерфейса, хотя бы).
Как-то чуть не устроился админом в сеть кафешек. На собеседовании меня спросили, какая сейчас самая мощная видеокарта (мой ответ был устаревшим примерно месяца на три-четыре, потому что я не мониторю железячные новинки). С чувством собственного превосходства и снисхождения мне рассказали, какая карта была самой крутой. На мой вопрос, зачем в кафе игровая видеокарта и, что я могу подобрать оптимальную для задач конфигурацию, ответа я не получил.
А не информации, в КаЛаб не нанимали программистов из мэйл.ру в последнее время?
А чем chrome инновационнее firefox или oper'ы?
Пользуюсь ФФ с плагином, располагающим вкладки сбоку в виде дерева. Это единственный вариант, который меня устроил. Видны не только все открытые вкладки, но и иерархия открытия (внутри домена). Если у браузера нет возможности открывать вкладки сбоку, в виде дерева или чего-то похожего, я этот браузер даже не пытаюсь использовать, т.к. категорически неудобно. Так что очень рекомендую реализовать боковое расположение вкладок, хотя бы ради меня.)
Доступ к полям «благожелательнее», чем к элементам массива. Потому что адрес поля известен статически, а адрес элемента может потребоваться вычислять в рантайме (если компилятор не оптимизирует). Выравнивание всегда можно настроить, чтобы поля были так же плотно расположены, как и в массиве. С точки зрения кэша абсолютно без разницы, будет считанно 4 элемента массива или четыре переменные, расположенные друг за другом.
А вообще, если на C# или Java или других высокоуровневых языках начинают заниматься байтоёбством, то это означает лишь то, что язык для данной задачи был выбран неудачно, либо пришло время немного переписать часть программы на другом языке.
Если уж размер указателя имеет столь большой вклад в размер объекта, то эффективнее использовать собственный аллокатор и вместо указателя на объект хранить индекс этого объекта в собственном диспетчере памяти (будет 4 байта, независимо от архитектуры. Или два байта или три или полтора).
А вообще, вы просто не поняли фичу! Вот написал автор про бездумное использование шрифтов и сразу же его продемонстрировал, чтобы было понятнее. Молодец автор.
А вообще, я не сильно понял, о чём статья.
Теперь, если обращение к логеру произойдёт после его разрушения, то он будет создан вновь, но не будет разрушен. А если рантайм уже успел выгрузиться, то всё-равно упадёт (но это уже почти надуманная ситуация).
Почему я сразу обратил внимание на деструктор? Потому что есть куча глобальных и статических объектов (Плохо? Но такова жизнь, они всегда есть в более-менее крупном проекте, те же синглтоноуправляемые объекты, помимо этого логера). В каком порядке они удаляются? Они удаляются до или после вызова ReleaseSingletonObject? Это риторические вопросы, чтобы вы подумали над усовершенствованием механизма удаления.
> Политика создания это просто класс, который создает некоторый объект и возвращает на него некоторый интерфейс
Это-то понятно. Только параметризировать синглтон следовало бы политикой создания этого синглтона (управляемого объекта, если точнее), но это уже дело привычки и зашоренного статьями Александреску взгляда. А вот к первому абзацу комментария отнеситесь серьёзно.
А мне ещё в семёрке «Центр обновления» писал, что нужно обновить «центр обновления Windows», чтобы установить обновления…
Windows… Windows не меняется.
И ведь прав! Летит, как Орёл!
Вторая примечательность, что ПолитикаСоздания не управляет способом создания управляемого объекта (он всегда создаётся через new), но подгружает библиотеку («в нашем случае»).
Ну и заголовок статьи не соответствует содержимому. Класс TSingleton приведён настолько не полностью, что даже не скомпилируется (не хватает класса LogFromDllPolicy или его интерфейса, хотя бы).
сарказм_мод_выкл