Задать вопрос

Mingun

Лайки

  • Возможно ли узнать сигнатуру виртуального метода из рантайма?

    xomachine
    @xomachine Автор вопроса
    Сам спросил, сам нашёл решение (пусть и не универсальное)
    Можно с высокой долей вероятности успешно вычислить сигнатуру метода по глубине стека, на которую обращаются инструкции. Для этого потребуется дизассемблировать метод и отследить регистры связанные со стеком.
    Рабочий прототип отслеживающей процедуры для моего случая можно найти тут. Прототип написан на Nim с использованием libopcode и libbfd из пакета binutils, который входит в большинство дистрибутивов линукс.

    На скриншоте результат подобного угадывания количества аргументов методов (CAdapterSteamClient017, справа) и (слева) кусок исходника, соответствующий данному классу. (надеюсь, Valve меня не забанят за публикацию скриншота с маленьким куском исходников)
    Как видно из скриншота, предсказанное количество аргументов соответствует реальному.
    5a4e980def378215372175.png
    Ответ написан
    Комментировать
    Комментировать

  • Какова правильная логика обновления клиента игры?

    @dponyatov
    Поднимите свой git-сервер для бинарных релизов и открытых скриптов, раз уж Microsoft за 20 лет не разродился apt update. В особо извращенных случаях можно даже отдавать часть исходников, и собирать stand-alone gcc на клиенте с оптимизацией -arch=host.
    Ответ написан
    2 комментария
    2 комментария

  • Что не так с библиотекой SDL 2.0 на С?

    @viktorokh96 Автор вопроса
    Student, programmer
    UPD: После многочасовых нервосрывов задача была решена очень тривиально. функцию close стоит переименовть на что нибудь другое, например closeWin(), в таком случае наша программа не будет переопределять эту, уже определенную функцию в подключенных библиотеках. В С++ это всё работало, видимо, именно потому что, что есть пространства имен и другие фичи по скрытию имен. Впервые на такие грабли наступаю и никому такого не пожелаю.
    Ответ написан
    Комментировать
    Комментировать

  • Как генерировать код из XML?

    Nipheris
    @Nipheris Куратор тега C++
    В xml(xsd) список некоторых элементов, из которых нужно сгенерировать много кода на C/C++, который руками писать (и править) долго, муторно и чревато опечатками.

    Ну тогда берите XSLT и сможете сгенерить все что захотите, хоть сказку. Ничего более конкретного посоветовать не могу.
    Ответ написан
    Комментировать
    Комментировать

  • Есть ли альтернатива Windows Termilal?

    @res2001
    Developer, ex-admin
    ConEmu, но это не альтернатива, а обертка.
    Ответ написан
    1 комментарий
    1 комментарий

  • Как разобраться в исходном коде такого проекта как Mysql?

    fshp
    @fshp
    Поиск использования и определения очень помогает. В любой IDE есть. В Vim/Emacs/Других плагинами реализуется.

    Ну и не ждите, что вы выучите исходники, просто читая их, и будете досконально в них разбираться. Так не бывает.
    Сначала определитесь, зачем вам смотреть исходники. Маленькая производительность - подрубаем профайлер, ищем узкие места. Лезем в код, оптимизируем, тестируем. Повторяем пару итераций.
    Не хватает функционала? Например, новый тип добавить хотим. Ищем модули, которые реализуют похожий функционал. Делаем свой тип по подобию существующих. Тестируем сервер, реплику. Профилировщик натравливаем и т.д.
    И вот вы уже разобрались в некоторых частях.

    А без цели лезть в код, что бы "стать спецом" - ничего не выйдет.
    Ответ написан
    Комментировать
    Комментировать

  • В чем преимущество динамически типизированных языков?

    Tiendil
    @Tiendil
    Разработчик ПО.
    Преимущество у динамически типизированных языков, конечно, не в синтаксисе, а в семантике.

    Благодаря определению типов во время исполнения программы сильно облегчается метапрограммирование. Очень сильно облегчается. Оно, в свою очередь, упрощает всю остальную работу.

    Благодаря гибкости кода в рантайме (см. тот же duck typing) и интроспекции (анализ свойств объектов и кода) получается на порядок проще и быстрее писать универсальные алгоритмы и конструкции вроде декораторов, всяческих ORM и подобных вещей. Это сильно упрощает интерфейсы библиотек, что в совокупности ведёт к более простому коду и к плавной кривой обучения новичков.

    Из моей практики (5 лет писал на C++, потом столько же на Python, эти сроки немного пересекались) могу сказать, что с точки зрения ошибок типизации (а собственно их и ставят в недостаток динамически типизированным языкам) разница минимальна — они очень редки и все отлавливаются автоматическими тестами. Конечно, если у вас руки откуда надо растут, а если не откуда надо, то эти ошибки будут далеко не самой большой проблемой. Поэтому в области разработки софта, не требовательного к производительности, такие языки рулят.

    Преимущество же статически типизированных языков в том, что, налагая дополнительные ограничения на программиста и на гибкость кода, они позволяют компилятору получить дополнительную информацию о программе и сделать более специфичные операции. Однако нынче почти везде используют JIT и это частично нивелирует разницу в производительности.

    В итоге мы получаем классическую дилемму: повышение уровня абстракции против повышения уровня специализации. У каждого пути есть свои плюсы и минусы.

    По производительности питона ссылок уже накидали, но в любом случае тут надо исходить из требований конкретной задачи — проще взять и протестировать самому.
    Ответ написан
    Комментировать
    Комментировать

  • Куда поступать на программиста?

    @asArtem
    Вуз в образовании и работе вообще ничего не решает. В том числе любой иностранный, разве что кроме MIT.
    Ни база, ни что-то другое. Конечно, речь не идёт о каком-то задрипанном коррумпированном частном вузе, но подойдёт любой областной технический университет с базовым ИТ направлением, где тебя будут дрючить нормально. И поверь, в ВУЗе лучше учиться тому, что там дают, в т.ч. устаревшим вещам. А самообразованием займёшься в первые два года работы и всю жизнь придётся заниматься. Потому что вузовский материал потом сложнее нагнать и понять, если там ничего не делать. Но тоже не критично. Онлайн видео-курсы тоже стенфорда с лихвой покрывают многие важные пробелы, которых может не быть в вузе.
    Всё решает:
    1. Желание учиться: готовиться к лекциям и парам, читать много, делать все задания.
    2. Умение впитывать и заставлять себя впитывать новое, часто очень непонятное
    3. Интерес, который проявляется часто курсу к 4ому. А вот соскакивают все курсе на 2ом. Это проявляется в т.ч. и в самообразовании и в просмотре курсов и в использовании полученных знаний и в чтении форумов.

    Круто, если хотябы один-два препода в вузе будут практиками и ещё лучше, если они будут твоим научными руководителями, но это всё не критично. Потому что всё равно нужно просто интересоваться самому и читать самому. Так процесс построен. А что у нас плохо учат говорят те, кто со школой ещё не расстался и хочет чтобы ему что-то объясняли, а он решал : понимать это или завтра ещё раз объяснят.

    Математика нужна мало. Всё уже давно решено. В случае с микроконтроллерами там вообще одна схемотехника и очень специфическое программирование на Си или реже Ассемблере. С++ нет и близко. С++ это только игры, операционные системы и высоконагруженные проекты. Очень специфичная область с высоким порогом входа.

    Вот мы с коллегой работаем в одной компании, получаю я его больше, он меня старше, манагер и был раньше тестировщиком, а я разработчик. Он МФТИ закончил, я СевНТУ. Все что он мог бы, так это просто понт кинуть, как он учился в МФТИ, но хватает ума так не делать.
    Может для экономистов и важны знакомства, в ИТ - нет. Программисты не манагеры, если родственников одних набрать, то и разориться легко можно, поэтому только через знания и честные собеседования.

    Сам программист, 6 лет опыта, за плечами успешные собеседование в европейские компании. У нас жить и работать на иностранцев выгоднее (если в долларах получать), заканчивал именно специальность по микроконтроллерам и сетям, но работаю с вебом.
    Ответ написан
    4 комментария
    4 комментария

  • Как писать техническую документацию к софту?

    @MonkAlex
    C#, SQL, Delphi, C++ etc
    Главный вопрос - размер проекта.
    Если там до 3 тысяч строк, то будет достаточно хороших xml комментариев к классам и методам.

    Если кода много, то как минимум нужна архитектура (кто от кого зависит, кто за что отвечает и т.д.) , плюс мне всегда помогают тесты, если они есть.
    Ответ написан
    Комментировать
    Комментировать

  • Как писать техническую документацию к софту?

    @DISaccount
    А вот, пожалуйста. Натравливаем на исходники и заполняем пробелы в описании/комментариях.
    Ответ написан
    Комментировать
    Комментировать

  • Какой язык выбрать для api сервера?

    viktorvsk
    @viktorvsk
    Сайт буду просматривать пользователи, и делать всякое разное. он должен быть максимально быстрым.

    Преждевременная оптимизация. Сайт для пользователя будет быстрым, если будут учтены все нюансы фронтенда (кеширование, минификация, спрайты, разные поддомены для ассетов...), а на сервере - правильно настроено кеширование и, где нужно, очереди.
    Разделение на разные приложения - это просто часть архитектуры, которая не обязательно должна удовлетворять требованиям производительности.

    Api будет выполнять ресурсоёмкие задания: вычисления, запись из бд в файл и наоборот, и прочие функции которые не выдержит сайт.

    API не делает задания. А вычисления и запись из бд в файл - не являются ресурскоемкими операциями в общем случае. Да и сайт их обычно тоже не производит. В таком контексте сайт - это, скорее, фронтенд. А вычисления будут производиться на сервере.

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

    Тут вообще не понял. Многопоточность зависит от типа и настроек вебсервера (например, который стоит на nginx-ом). Чем не угодила асинхронность - тоже не понятно. И как она зависит с возможностью обрабатывать много и сразу - так же неясно. Очень упрощенно можно сказать, что с помощью асинхронности можно создать у пользователя впечатление, что сайт реагирует мгновенно (работает очень быстро)

    Возможно, это все потому что 3 (4) часа ночи и вы переварили очень большой объем информации. Тогда попробуйте конкретизировать.

    Если по существу:
    1. Неважно, какой язык выбирать. Тот - который лучше всего знаешь. На любом языке можно реализовать что угодно. Большинство "производительности" достигается не за счет быстродействия стандартной библиотеки языка, а за счет кеширования, оптимизации sql запросов, настройки веб-сервера и базы данных и использования очередей.
    2. Видимо, для вас важен вопрос: "Стоит ли разносить API сервера и клиент приложения на разные приложения, языки, инстансы?". Здесь ответить сразу не получится, потому что все зависит от задачи. Смотря как вы будете использовать свои инстансы. Какие вычисления будут проводиться и т.д. - больше конкретики по предметной области.
    Ответ написан
    5 комментариев
    5 комментариев

  • Портабельный макрос для получения строки версии C++ компилятора и времени сборки приложения?

    EXL
    @EXL
    Энтузиаст
    Находим серьёзную кросс-платформенную программу с открытыми исходниками, я выбрал Qt Creator.

    Заходим в диалог "About" и видим как раз то, что нам нужно:

    wmUZzbo.png

    Находим построение этого диалога в исходном коде - [src/plugins/coreplugin/versiondialog.cpp | 77].

    Видим, что для получения даты и времени сборки использованы тривиальные предопредёленные макросы __DATE__ и __TIME__, которые гарантировано должны быть предопределены во всех компиляторах.

    А вот для нахождения версии компилятора используется специальная функция ICore::buildCompatibilityString(). Проследуем по цепочке вызовов: [src/plugins/coreplugin/icore.cpp | 472].

    В функции ICore::buildCompatibilityString() используется вызов статической функции compilerString() для получения информации о компиляторе и QSysInfo::WordSize для получения информации о битности порождаемого компилятором кода.

    Функция compilerString() [src/plugins/coreplugin/icore.cpp | 440-458] выглядит так:

    static QString compilerString()
{
#if defined(Q_CC_CLANG) // must be before GNU, because clang claims to be GNU too
    QString isAppleString;
#if defined(__apple_build_version__) // Apple clang has other version numbers
    isAppleString = QLatin1String(" (Apple)");
#endif
    return QLatin1String("Clang " ) + QString::number(__clang_major__) + QLatin1Char('.')
            + QString::number(__clang_minor__) + isAppleString;
#elif defined(Q_CC_GNU)
    return QLatin1String("GCC " ) + QLatin1String(__VERSION__);
#elif defined(Q_CC_MSVC)
    if (_MSC_VER >= 1800) // 1800: MSVC 2013 (yearly release cycle)
        return QLatin1String("MSVC ") + QString::number(2008 + ((_MSC_VER / 100) - 13));
    if (_MSC_VER >= 1500) // 1500: MSVC 2008, 1600: MSVC 2010, ... (2-year release cycle)
        return QLatin1String("MSVC ") + QString::number(2008 + 2 * ((_MSC_VER / 100) - 15));
#endif
    return QLatin1String("<unknown compiler>");
}

    Макросы Q_CC_CLANG, Q_CC_GNU и Q_CC_MSVC можно заменить на __clang__, __GNUC__ || __MINGW32__ и _MSC_VER соответственно. Вызовы QLatin1String() можно заменить обычным std::string, QString::number() - чем-нибудь типа sprintf, itoa, std::to_string (если используете c++11).

    А QSysInfo::WordSize это простой:

    enum Sizes {
        WordSize = (sizeof(void *)<<3)
};

    Удачи!
    Ответ написан
    1 комментарий
    1 комментарий

  • Как узнать какие dll будет использовать программа(mvs c++)?

    @HHoulds55
    Воспользуйтесь программой Dependency Walker
    Ответ написан
    Комментировать
    Комментировать