А вообще, мне кажется, что в архитектуре компилятора msvc есть какая-то беда с константностью. Т.е. им отчего-то трудно обеспечивать поддержку стандарта в этой области. Думаю, не случайно constexpr появился только в 2015-й студии, хотя мог бы еще в 2010-й, когда стали делать поддержку C++11. Но это исключительно мое мнение на основе ощущений.
константным sizeof'ом можно, например, инстанцировать шаблоны. Понятно, что на неконстантный компилятор мог бы и ругнуться, но, мне кажется, сущность языка, которая может быть константной и неконстантной в зависимости от контекста — это плохо. Больше путаницы, сложнее компилятор. Я просто уверен, что C и C++ строится одним и тем же компилятором msvc. И делать поддержку неконстантного sizeof, чтобы уметь собирать код стандарта, которого на самом деле не так и много, при том, что всегда можно выкрутиться при помощи alloca, в ms просто сочли экономически нецелесообразным.
Думаю ответ вас разочарует. Просто хотел избежать критики моего стиля программирования. Это ведь мой первый opensource проект, до этого весь мой код был доступен ограниченному кругу лиц. Но потом понял — нечего тут стесняться. Работает? Стабильно работает? Значит всё хорошо. А если что-то не нравится — милости просим всё исправить и сделать еще лучше. На то он и opensource.
Я сужу с точки зрения C++. Возможно для C неконстантный sizeof и не является проблемой.
Если более предметно — toxcore. Там динамические массивы используются в основном для генерации пакета, который имеет максимальный размер, что то порядка 1.4kb (чуть меньше). И я не вижу причин не создавать на стеке эти самые 1.4 килобайта, и просто использовать из них не всё. Это бы даже быстрее работало, т.к. выделить на стеке константное количество байт всяко быстрее, чем неконстантное.
Есть люди, в том числе и за рубежом, которые прямо сейчас используют Isotoxin и он их устраивает внешним видом и функциональностью. Ну или они просят меня что-то поменять и я с радостью иду им на встречу. Даже если бы это был всего один человек (кроме меня), я был бы рад.
Я занимаюсь тем, чем мне нравится заниматься — программированием. Кому-то это приносит пользу и меня это устраивает. Я не зарабатываю на этом денег и видимо поэтому вы решили, что я занимаюсь «непонятно чем». Чем же, по вашему, я должен заниматься?
Собственный протокол для общения внутри локальной сети — вот от этого надо бы уйти
Этот протокол создавался для отладочных целей. Понимаете, в текущей архитектуре нужно иметь хотя бы два работающих протокола, чтобы как следует все отладить. Так-то я никому этот протокол не навязываю. А если вы удалите proto.lan.dll, так он даже места на вашем диске занимать не будет.
Но, может быть вы имеете в виду нечто другое — то что я вношу в tox изменения, которые задействованы только в Isotoxin'е? Но, во первых, эти изменения никак не влияют на работу Isotoxin'а с другими tox-клиентами, т.е. соблюден принцип полной обратной совместимости. Во вторых, кто ж мне позволит внести эти плюшки в основной код протокола? Для этого нужно быть своим в среде разработчиков, а я там никто. Мне так кажется. Может я и ошибаюсь. В любом случае, нужно обосновать эти изменения, чтобы их приняли. А с английским у меня плохо.
По внешнему виду — тут я пас. Я, конечно, продолжу улучшать движок интерфейса и приводить внешний вид к современным канонам красоты. Но это всё очень субъективно. И я понятия не имею, чем именно для вас внешний вид qTox'а более привлекателен. Может цветами? В следующей версии я сделаю возможность выбирать цвета.
Вы поверите, если я скажу, что люблю программировать? Я ж не ради денег это делаю.
А что касается внешнего вида — это просто из меня плохой дизайнер — сделал как смог. С технической стороны нет никаких ограничений — все контролы формируются из полноценных RGBA изображений и их внешний вид ограничен только фантазией дизайнера.
Ну и это вопрос вкуса. Мне, например, интерфейс Windows 10 не нравится. Как раз «напоминает эксперименты 15 летней давности», а это вроде как самое лучшее, что есть.
Профиль в своем формате — sqlite база. Стандартный формат токса не предусматривает возможности хранения истории, а я хотел сделать все в одном файле, т.к. это удобнее. Однако, Isotoxin понимает стандартный профиль. В диалоге добавлении tox соединения, можно выбрать tox-save файл и из него будет импортирован ToxID и список друзей.
Прошу прощения за неверную информацию: я ошибался. Детектор статуса работает прекрасно. Просто я умудрился запустить ноду с другим ключем. Т.е. нода работала и участвовала в DHT сети, но с другим публичным ключем. А под тем ключем, который был в таблице нод, детектор мою ноду не обнаруживал и показывал ее как OFFLINE. Сейчас все работает как надо.
Там крутится вот это: github.com/Tox/ToxStatus
Само оно только умеет определять состояние ноды, и не всегда правильно. Чтобы попасть в этот список, нужно написать письмо на infrastructure(мыло)tox.chat
Забавно, буквально неделю назад поднял ноду на CentOS'е
Я сто раз уже пожалел, что взял VPS'ку на CentOS'е. Учитывая мои, мягко говоря, неглубокие знания внутренней линукс-кухни, каждая установка чего-то в CentOS'е выливается в испытание моей воли и терпения.
В принципе, если опустить всякие заморочки с устаревшими dev-тулзами, которые приходилось вытягивать из отдельных репозиториев или собирать самому, то по минимуму осталась одна заморочка с запуском ноды в виде демона. Инструкции по запуску, которые идут в комплекте с исходниками toxcore, для CentOS'а не подходят. Пришлось импровизировать.
Походу обнаружился косяк в online-определителе nodes.tox.chat — там моя нода (и некоторые другие) по началу была в OFFLINE, хотя на самом деле она ONLINE. Impyy (автор этого проверяльщика) выкатил фикс и ONLINE нод в списке стало больше. Сейчас в этом списке моя нода снова OFFLINE, хотя на самом деле с ней все хорошо. Недофиксили.
Студент, или недавний студент. Недавно принят на работу. Месяц кодил тулзу для внутренних нужд с интерфейсом на DevExpress. Прилетел таск на основной код на C++, с которым знаком только в теории. Практика ужаснула.
Я сейчас описал реальный случай.
Не на всех. Там где нет ssse3, используется обычная c/c++ реализация. Вот только ssse3 появилась как минимум в Core 2 duo, т.е. охват этой ssse3 оптимизации по железу довольно неплох (если не сказать, 100%-й)
> Да и AlphaBlend вроде бы аппаратно ускорена
Возможно она ускорена, если работает с видеопамятью. При работе с обычным Memory DC — максимум mmx, и то не факт.
Кстати да, XP я поддерживаю, причем приходится прилагать определенные усилия к этому. Например, первая версия с поддержкой видеозвонков не видела камеру под XP. Два дня убил, чтобы найти причину.
А вот qTox, кажется, отказался от поддержки XP. Не проверял, может и ошибаюсь, но что-то такое на эту тему видел в чате разработчиков Tox'а.
Я понимаю ваш вопрос. Действительно, существует огромное количество средств создать графический интерфейс у своего приложения, не работая с GDI напрямую. Однако вы должны понимать, что все эти средства так или иначе основаны на GDI, исключая, возможно, какие-то специальные разработки майкрософта, а также интерфейс, на основе 3D графики (в играх, например).
Так что я, сознательно отказавшись от всех этих средств (почему — отдельный вопрос), встал перед выбором: либо GDI, либо Direct3D (или OpenGL). Как показала практика, GDI вполне себе быстр и нет необходимости прибегать к мощностям GPU. Во всяком случае, решение этого вопроса я отложил на неопределенный срок.
Гайд прекрасный! Но вы не внимательны: в статье есть ссылка на этот гайд. Собственно, по нему я все и делал.
Что же касается использования интринсиков вместо голого асма — я не отвергаю интрисики — штука крайне полезная. Просто ассемблер… ну это как первая любовь. Неравнодушен я к нему. Я же и оптимизировал в основном из спортивного интереса. Несомненно, как только появится свободное время, я перепишу часть кода на интринсики. Да я в любом случае это сделаю, т.к. у меня в планах перейти на 64 бита.
С другой стороны, перенимая опыт разработчиков кодека VPx: там 64 битный код написан на интринсиках или вообще на C, а 32-битный — на ассемблере. Думаю поступить также.
Если более предметно — toxcore. Там динамические массивы используются в основном для генерации пакета, который имеет максимальный размер, что то порядка 1.4kb (чуть меньше). И я не вижу причин не создавать на стеке эти самые 1.4 килобайта, и просто использовать из них не всё. Это бы даже быстрее работало, т.к. выделить на стеке константное количество байт всяко быстрее, чем неконстантное.
Я занимаюсь тем, чем мне нравится заниматься — программированием. Кому-то это приносит пользу и меня это устраивает. Я не зарабатываю на этом денег и видимо поэтому вы решили, что я занимаюсь «непонятно чем». Чем же, по вашему, я должен заниматься?
Этот протокол создавался для отладочных целей. Понимаете, в текущей архитектуре нужно иметь хотя бы два работающих протокола, чтобы как следует все отладить. Так-то я никому этот протокол не навязываю. А если вы удалите proto.lan.dll, так он даже места на вашем диске занимать не будет.
Но, может быть вы имеете в виду нечто другое — то что я вношу в tox изменения, которые задействованы только в Isotoxin'е? Но, во первых, эти изменения никак не влияют на работу Isotoxin'а с другими tox-клиентами, т.е. соблюден принцип полной обратной совместимости. Во вторых, кто ж мне позволит внести эти плюшки в основной код протокола? Для этого нужно быть своим в среде разработчиков, а я там никто. Мне так кажется. Может я и ошибаюсь. В любом случае, нужно обосновать эти изменения, чтобы их приняли. А с английским у меня плохо.
По внешнему виду — тут я пас. Я, конечно, продолжу улучшать движок интерфейса и приводить внешний вид к современным канонам красоты. Но это всё очень субъективно. И я понятия не имею, чем именно для вас внешний вид qTox'а более привлекателен. Может цветами? В следующей версии я сделаю возможность выбирать цвета.
А что касается внешнего вида — это просто из меня плохой дизайнер — сделал как смог. С технической стороны нет никаких ограничений — все контролы формируются из полноценных RGBA изображений и их внешний вид ограничен только фантазией дизайнера.
Ну и это вопрос вкуса. Мне, например, интерфейс Windows 10 не нравится. Как раз «напоминает эксперименты 15 летней давности», а это вроде как самое лучшее, что есть.
Если человек чаще минусует, чем плюсует, то он несет в мир злое и только в этом случае его карма должна страдать тоже.
Какая-то отписка ради инвайта.
Само оно только умеет определять состояние ноды, и не всегда правильно. Чтобы попасть в этот список, нужно написать письмо на infrastructure(мыло)tox.chat
Я сто раз уже пожалел, что взял VPS'ку на CentOS'е. Учитывая мои, мягко говоря, неглубокие знания внутренней линукс-кухни, каждая установка чего-то в CentOS'е выливается в испытание моей воли и терпения.
В принципе, если опустить всякие заморочки с устаревшими dev-тулзами, которые приходилось вытягивать из отдельных репозиториев или собирать самому, то по минимуму осталась одна заморочка с запуском ноды в виде демона. Инструкции по запуску, которые идут в комплекте с исходниками toxcore, для CentOS'а не подходят. Пришлось импровизировать.
Походу обнаружился косяк в online-определителе nodes.tox.chat — там моя нода (и некоторые другие) по началу была в OFFLINE, хотя на самом деле она ONLINE. Impyy (автор этого проверяльщика) выкатил фикс и ONLINE нод в списке стало больше. Сейчас в этом списке моя нода снова OFFLINE, хотя на самом деле с ней все хорошо. Недофиксили.
Я сейчас описал реальный случай.
> Да и AlphaBlend вроде бы аппаратно ускорена
Возможно она ускорена, если работает с видеопамятью. При работе с обычным Memory DC — максимум mmx, и то не факт.
А вот qTox, кажется, отказался от поддержки XP. Не проверял, может и ошибаюсь, но что-то такое на эту тему видел в чате разработчиков Tox'а.
Так что я, сознательно отказавшись от всех этих средств (почему — отдельный вопрос), встал перед выбором: либо GDI, либо Direct3D (или OpenGL). Как показала практика, GDI вполне себе быстр и нет необходимости прибегать к мощностям GPU. Во всяком случае, решение этого вопроса я отложил на неопределенный срок.
Что же касается использования интринсиков вместо голого асма — я не отвергаю интрисики — штука крайне полезная. Просто ассемблер… ну это как первая любовь. Неравнодушен я к нему. Я же и оптимизировал в основном из спортивного интереса. Несомненно, как только появится свободное время, я перепишу часть кода на интринсики. Да я в любом случае это сделаю, т.к. у меня в планах перейти на 64 бита.
С другой стороны, перенимая опыт разработчиков кодека VPx: там 64 битный код написан на интринсиках или вообще на C, а 32-битный — на ассемблере. Думаю поступить также.