to post messages and comments.

← All posts tagged C++

Смотрел одного летсплеера, он играл, играл, и тут у него игра вылетела. И прямо такое неподдельное удивление. Игра на консоли — и вылетает! Ну надо же, какой нежданчик! И у яблочников такое удивление встречал. Надо же, на Макосе программы тоже глючат и падают! И на Линуксе, представьте себе. Уж их собирали-собирали, в репозитории пакетов отправляли-отправляли. Как только над ними ни колдовали, какой только хренью, кроме того, что действительно поможет, ни занимались, а они всё равно падают и глючат.

Пользователей пека через уязвимости в программах, написанных на C и C++, имеют в хвост и в гриву двадцать лет, и всем плевать. А что, на игровых консолях в ходу какие-то другие языки разработки? Или, может, на Макинтошах Objective-C штурмует высоты безопасной разработки, конкурируя с Ada, Cyclone и Rust? Я что-то не слышал таких новостей. Так откуда эти завышенные ожидания? Можно только поздравить маркетологов, которые продают консоли и макинтоши как будто это философский камень, на котором программы на C и C++ чудесным образом начинают работать как-то не так, как обычно.

Можно бросать исключение как только заподозрено неладное и стучать на сервер по делу, а можно позволить ошибке дать метастазы, коллекционировать на сервере дампы, и по метастазам, разползшимся по всему дампу, определять, откуда они пошли.
<pewpew> плесну-ка и я бензинчику в ваш костёрчик: знаете ли вы, что когда флайлинк падает, он отправляет на сервер дамп памяти, в котором есть, в том числе, и ваши пароли?
<Karumo> pewpew, плеснул так плеснул....
<pewpew> то-то же, бережней обращайся с предметом, не роняй почём зря
<Karumo> у меня он пока не падал, да и паролей я там предусмотрительно не держу)
<HackFresse> но там — это ж в оперативке
<FlylinkDC-dev> pewpew полный дамп формируется если юзер соглашается с этим, а также если стек падения ранее не встречался. все последующие дампы такого типа идут в mini формате.
<FlylinkDC-dev> вот пример топового стека — yadi.sk все дампы мини и содержат только стек.
<FlylinkDC-dev> но раз тут такие параноики завелись можно будет приделать затирку пароля после отправки на сервер
<FlylinkDC-dev> pewpew предлагай где хранить пароль. чтобы он не попадал в дамп.

Был такой компилятор AdaMagic, умел транслировать Ada в C и C++. Там ещё и в Java компиляция была, но это и сейчас есть в GNAT. Потом SofCheck был куплен AdaCore, и этот компилятор пропал из поля зрения. Однако, его продают под другим брендом тут. Его там завернули в какой-то AppCOE на базе Eclipse, но всё это можно развернуть, выкинуть лишнее и докопаться до самых важных файликов, adacgen.exe и adabgen.exe. На них навешена типа защита. Типа — потому что там, во-первых, есть отладочная информация, во-вторых, неиспользуемые функции не выбрасываются. Очень пригодилась мне такая неиспользуемая функция, как write_license_file, например.

Файл license_key.txt генерить научился, зашифрованные DES файлы типа libadartl.a.enc, разшифровал, для PDF пароль нашёл, поставлю qpdf и тоже разшифрую, впрочем, PDF в открытом виде можно и так скачать с сайта. Сейчас пишу инструкции, чтобы мои действия можно было повторить со следующими версиями. Вообще, не похоже, чтобы новый владелец-индиец разбежался развивать этот компилятор, он, скорее, вокруг достраивает всякие OS абстракторы на C, так что смысла большого обновляться не вижу, но тем не менее. Если думать на тему использования вместе со всякими emscripten, то от libadartl.a толку не очень много, но на всякий случай оно есть. С самим компилятором надо ещё разбираться. Он по умолчанию работает в режиме Ada->C->GCC, но в GCC есть GNAT, который гораздо лучше, и если кто-то заинтересовался AdaMagic, как я, то сценарий изпользования у него будет позабористее, и надо читать доки.

Таким образом, теперь есть компилятор Ada->C/C++, с помощью которого можно целиться во всякие дурацкие, но иногда нужные платформы, хостится он либо на Windows, либо на Linux, а через эмуляторы можно потенциально запускать из ещё большего набора OS. По плану выложить на форум только для зарегистрированных пользователей. Раз и навсегда адвокаты языков программирования, для которых на всех платформах есть транслятор, уедят.

Надо было по работе скомпилировать Wt, а он на C++. Причём, если говорят «беда не приходит одна», то это именно тот случай. Если C++, то ещё и boost, а если boost, то ещё и boost.spirit. Короче, на всю голову больные. Нет бы на C с классиками пописывать и не напрягать тех, кому это потом компилировать. Нет бы взять обычный внешний генератор парсеров. Настрадался я от этого boost.spirit. То там string table overflow at offset 10000004 в section .debug_frame случится, то
function_operator_10.hpp: In instantiation of 'const typename boost::phoenix::detail::expression::function_eval<F, A0, A1, A2, A3, A4>::type boost::phoenix::function<F>::operator()(const A0&…
Ну это манипуляциями с ключиками ещё как-то преодолел. Дальше проблемы, компоновщику тупо памяти не хватает. Вот тут посоветовали взять сборку отсюда. Не подошло:
c:/TDM/TDM-GCC-64-2017-01-07/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: c:/TDM/TDM-GCC-64-2017-01-07/bin/../libexec/gcc/x86_64-w64-mingw32/5.1.0/liblto_plugin-0.dll: error in plugin cleanup (ignored)
c:/TDM/TDM-GCC-64-2017-01-07/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: c:/TDM/TDM-GCC-64-2017-01-07/bin/../libexec/gcc/x86_64-w64-mingw32/5.1.0/liblto_plugin-0.dll: error loading plugin
И библиотеку указанную тоже пробовал заменять. Никак. Откатился на оригинальный ld.exe

Впрочем, оказалось, что снять у него ограничения по памяти не так сложно. Открыл HIEW, по смещению 0x96 пропатчил 0f 03 на 2f 03, что соответствует включению флага IMAGE_LARGE_ADDRESS_AWARE, и этим компоновщиком наконец смог собрать. Научить программы использовать больше памяти не так уж сложно, оказывается.

Using C++ classes in JavaScript
Вычитал тут такое:
JavaScript will automatically garbage collect any of the wrapped C++ objects when there are no more references. If the C++ object doesn’t require specific clean up (i.e. it doesn’t have a destructor) then no other action needs to be taken.Это каким, интересно, образом, движок JavaScript залезет в кучу emscripten и пометит область памяти как неиспользуемую именно тем способом, каким это делает текущая версия аллокатора emscripten

«Под Куполом» спонсировался Microsoft, и поэтому там у всех виндопланшеты с Windows 8. А в S02E08 хакер ломает комп, и что же на компе? Неужели тоже винды? Да, винды. Седьмые.

Но в восьмёрке–то все сишные и плюсовые компоненты переписали на Аде, такой Windows хакеры бы не сломали, уж конечно

Средства разработки для ПЭВМ «Эльбрус 401‑PC»
Не меньший интерес из‑за своей экзотичности вызывает технология защищённого исполнения программ на языках C/C++, где использование указателей предоставляет обширный круг возможностей выстрелить себе в ногу. Концепция контекстной защиты, совместно реализуемая компилятором на этапе сборки и процессором на этапе выполнения, а также операционной системой в части управления памятью, не позволит нарушить область видимости переменных, — будь то обращение к закрытой переменной класса, частным данным другого модуля, локальным переменным вызывающей функции. Любые манипуляции с изменением уровня доступа допустимы только в сторону уменьшения прав. Блокируется сохранение ссылок на короткоживущие объекты в долгоживущих структурах. Предотвращаются также попытки использования зависших ссылок: если объект, на который некогда была получена ссылка, уже был удалён, то даже расположение другого, нового объекта по тому же адресу не будет считаться оправданием для доступа к его содержимому. Пресекаются поползновения использовать данные в качестве кода и передачи управления невесть куда.
Напоминает CHERI. Вот уж, где не ждал увидеть. И если CHERI/BERI — университетские прототипы, то Эльбрус всё же помассовее будет.
Интересно, а что, в МЦСТ и ядро Линукса заставили плясать под эту дудку? Или glibc. Там же наверняка куча кода не предусматривает такую работу.

интерпретаторы: erlang 15.b.1, gawk 4.0.2, lua 5.1.4, openjdk 1.6.0_27 (jvm 20.0‑b12), perl 5.16.3, php 5.4.11, python 2.7.3, slang 2.2.4, tcl 8.6.1;Зачёт.

Сеанс гадания на кофейной гуще за сим давайте закончим, пока не дофантазировались до совсем уж нелепых предположений. Будем надеяться, что однажды справочник команд и руководство по программированию и оптимизации станут достоянием общественности.
По уровню минимальности утечек информации наш МЦСТ прямо как Apple. Подумать только, сидят русские программисты и изучают русский же компьютер как шпионы какие–то. Ну и времена.

OpenFL Setup Windows
In order to build Neko applications for Windows, no further dependencies are required. However, in order to build C++ applications for Windows, you must have a compatible version of Visual Studio C++ installed on your system.
Currently, OpenFL requires a version of Visual Studio capable of targeting Win32. For newer versions of Visual Studio, this requires the "Windows Desktop" version of the software.
Что у них вместо мозгов? Выбирать компилятор от Microsoft? Чем они вообще думали? У меня уже есть компилятор C++, интегрированный с компилятором Ады и есть совместимый с Delphi C++ Builder. Зачем кто–то тащит ничем не интересный компилятор от Microsoft?

Это уже напоминает Яндекс.Бар, производитель которого доплачивает тем, кто спамит этим УГ в своих программах.

You can only target Windows from a Windows system right now
Ну ещё бы. Думать же надо было

Провёл, наверное, часов уже 16 с wxWidgets. То они сами не соберутся, то Hello World не компонуется, вот почти только что заставил–таки его скомпоноваться. И угадайте, что? Оно крашится. Это там такие стабильные релизы.

Немного про странноватых менеджеров, которые хотят переписать на C++
A new project manager at my company asserts that Delphi can not be used in an FDA approved medical device. Has anyone heard of such a thing; do you have an contra evidence ? He assert the same for Windows Embedded, Linux and C++ is what it must be.
I don't think he has a basis, other than C++ programmer's distain and disrespect for Delphi plus the desire to do things the way he has done in the past. The Devices are Class 1, with no chance of patient harm. Problem is we have a large code base, developed over 15 years, that according to the project manager must be ported to C++ (at the risk of breaking the bank).
Your comments that "never been raised as an issue" is what I have heard from others, regulators don't care what language the software is written in.
Thanks for your comments; I'm not sure if I will continue to fight the anti-Delphi biases.

Matt, thanks for your testimonial. I'll add it to my bucket of evidence.
The 2nd reason my PM says we MUST port to C++ is the difficulty of finding Delphi programmers. There is a grain of truth perhaps to that, but I don't think it should be elevated to a reason to risk the company by undertaking a costly port to C++.

The argument about C++ programmers being more prevalent may be valid (there are other threads that discuss this), but if for the sake of argument we assume that it's true, then his argument is about the tradeoff for the perceived safety of a larger body of programmers at a cost of longer development and debug times. It also harkens back to the old saying (pre-PC days) "No one ever got fired for buying IBM". Your manager may be a CYA type. So it goes.
The previous product suffered a rewrite into C++ and never came back to life, and still sits in a pile on the floor. One would think people would not repeat the same mistake, but that CEO and PM were fired because of the failure and the new ones have big egos and don't want to hear about history. Go Figure.

public.dhe.ibm.com
Добрался потестировать на чистой машине. Этот патч, как и другие, сделан путём замены одних файлов другими, но на этот раз заменяющих файлов так много, что этого хватит на то, чтобы запустить компилятор. Проверил эту гипотезу.
1) Разпаковал в C:\home\OCTAGRAM\DTS
2) Запустил отдельную командную строку
3) Выполнил set SOMBASE=C:\home\OCTAGRAM\DTS\ibmcppw
4) Запустил C:\home\OCTAGRAM\DTS\ibmcppw\bin\SOMENV.BAT
5) Сделал cd C:\home\OCTAGRAM\DTS\ibmcppw\samples\compiler\dts
6) Для надёжности nmake clean
7) nmake
8) hhmain.exe так просто не запускается, так как .dll для него собирается в другой каталог, поэтому я сделал set PATH=%PATH%;C:\home\OCTAGRAM\DTS\ibmcppw\samples\compiler\dts\xhmain\dtsdll
9) Запустил hhmain.exe, получил:
C:\home\OCTAGRAM\DTS\ibmcppw\samples\compiler\dts>hhmain.exe
Local anInfo->x = 5
Local anInfo->_get_x() = 5
Local anInfo->y = A
Local anInfo->_get_y() = B
{An instance of class info at address 0092E318

}

С виду, всё в порядке. Таким образом, у нас есть возможность пощупать настоящий Direct-to-SOM C++. Если бы в своё время такой C++ среди других C++ стал мейнстримом, он бы не стал такой каждой бочке затычка. И другим языкам не мешал бы, и в тупик не был сейчас загнан необходимостью совместимости.

В продолжение #2761490
Идея сделать такой компилятор C++, который уже существующие библиотеки скомпилирует в SOM, достаточно заманчива, чтоб от неё так просто отказаться. Но делать это придётся эвристически. Учитывая, что нормального множественного наследования в C++ нет, его толком никто и не применяет, а то, что применяют — это Адско–Джавовская модель со множественным наследованием интерфейсов и одиночным наследованием классов, и отличать класс от интерфейса придётся эвристикой, ну или как в Asm.js, выполнять дополнительные проверки, отличающиеся от стандартов языка–носителя. То есть, если одиночно–наследованный класс (за неимением альтернатив в стандарте C++) делает родительский вызов поимённо, такой вызов эвристически заменяется на родительский вызов SOM, который может привести отнюдь не к тому классу, который был указан по имени в исходном коде. А если вызываются несколько родителей, останавливать компиляцию, так как такой случай не предусмотрен.

Одна из преград на пути к тому, чтобы код для C++ «просто работал» поверх SOM — это тот способ, которым вызывается унаследованный метод. В Delphi есть ключевое слово inherited, в Java и Objective-C super, в Dylan тоже что–то есть, а В C++ нужно точно указывать родителя. Причём, если родителей несколько, то и потомок вроде бы как должен сразу всех вызвать, поимённо. В CLOS и SOM родитель неизвестен в том смысле, что вызывается не родитель, а просто следующий класс по порядку нахождения методов (Method Resolution Order aka Class Precedence List). Этот следующий класс в MRO разных потомков может отличаться. В DTS C++ для вызова родительской реализации пришлось ввести новый синтаксис __parent->

en.wikipedia.org
У сабжа, судя по Talk, несколько недель лежит сайт, но в кеше Гугля ещё свежо предание.

Сабж компилирует C++ не сам, а посредством компиляции в C, и среди перечисленных поддерживаемых back-end'ов был даже древний Borland C++. Цена 50 USD за лицензию.