Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 46
Тут примчались санитары и зафиксировали нас (с) :)
А нет такого ощущения, что переизбыточное усложение C++, с добавлением всё новых и новых абстракций, приведет примерно к тому, что C++ перестанут пользоваться?
Типа, "писать на C с плюсами (по книжке K&R 90-х) - это примитивно и устарело, а понять C++ 30 без 30-летнего опыта разработки на нём - нереально, ну его нафиг"
У меня нет 30-ти летнего опыта программирования. Но чуть знаю. Я бы посмотрел с другой стороны, к примеру java, python библиотек в стандарте намного больше но никто не говорит, что это языки монстры которые не возможно изучить. Но так же правда, что устраиваясь на мидл java или python нужно знать не только язык, но и его экосистему которая в разы больше С++.
Нет у меня, нет ощущения, что он не нужен и вот вот от него в е откажутся.
Современные стандарты добавляют очень много приятных фичей, упрощающие жизнь. К примеру писать шаблоны до с++20 и после две разные вещи. Да даже до с++17 много вещей упрощающие визуал и понимание ( if constexpr, концепты, templete for в грядущем 26 стандарте)
Проще было писать в 1999: никаких концептов, шаблонов и прочего: обычный С + некоторые удобные вольности (типа инкремента и переопределения функций) + классы.
MFC например в таком стиле был написан примерно весь
Увидеть сейчас это можно в библиотеках Ардуино, "тот самый С++".
А вот потом пошло-поехало...
Ага помним.
// helloapp.cpp : Minimal MFC Windows app.
//
// This is a part of the Microsoft Foundation Classes C++ library.
// Copyright (C) 1992 Microsoft Corporation
// All rights reserved.
//
// This source code is only intended as a supplement to the
// Microsoft Foundation Classes Reference and Microsoft
// WinHelp documentation provided with the library.
// See these sources for detailed information regarding the
// Microsoft Foundation Classes product.
#include <afxwin.h>
// Define a window class derived from CFrameWnd
class CHelloWindow : public CFrameWnd
{
public:
CHelloWindow()
{ Create(NULL, "Hello World!", WS_OVERLAPPEDWINDOW, rectDefault); }
};
// Define an application class derived from CWinApp
class CHelloApp : public CWinApp
{
public:
virtual BOOL InitInstance();
};
// Construct the CHelloApp's m_pMainWnd data member
BOOL CHelloApp::InitInstance()
{
m_pMainWnd = new CHelloWindow();
m_pMainWnd->ShowWindow(m_nCmdShow);
m_pMainWnd->UpdateWindow();
return TRUE;
}
CHelloApp HelloApp; // HelloApp's constructor initializes and runs the app Я про синтаксис )
MFC - отдельная тема. Так-то можно ещё на чистом winapi писать, со всеми этими объявлениями класса окна и какими-то костылями из Паскаля
А Паскаль то тут при чем?
MFC это тоненькая обвязка WinAPI + hwnd.
А вы погуглите.
int PASCAL MessageBox(HWND, LPCSTR,...)
Это влияло на работу со стеком. И где-то там ещё были строки паскалевского типа, где первый байт длина, и строка не завершается х0, как в С. Потому что в самом начале Винду вообще планировали на Паскале делать.
И MFC это совсем не тоненькая обвязка, а такой "классный монстр", построенный на наследовании всех классов от единого предка, CObject. CWnd в том числе.
В глубинах которой как раз и шло обращение к winapi через hwnd.
А вот hwnd - это всего лишь указатель на экземпляр класса окна в ОС, handle window, это как раз составная часть winapi. Все объекты в ней - windows, у каждого свой handle, и через него идёт передача events в окно.
Где-то на дисках в каталогах .../1/old/old/win/doc.... до сих пор валяется документация, наверное...
Мне не надо гуглить, а на нем писал =)
От Паскаля там Pascal calling convention, в Win16 API. Паскаль-строк не припоминаю. Байку такую слышал про написание на паскале, но достоверность не знаю
Upd. Кстати на Win11 прекрасно работает MS Visual C++ 1.1 32-bit с MFC 2.1 (всего 1.5 МБ исходников)
По нынешним временам - да, можно сказать "тонкая обвязка".
Но тогда...
Делал как-то программку типа "Нортона" (только графическую, с иконками каталогов и файлов) - на голом winapi она заняла что-то около 50 килобайт (всего !), на MFC подобное - от 300 и больше.
Когда хард - 240Мб весь - это существенно.
Потому что класс на классе и классом погоняет, где надо и не надо. И кстати, дало дурной заразительный пример - тоже начал так делать, пока не дошло, что это как-то неправильно...
Но в целом, С++ тогда был простым - я об этом говорю.
Точно помню информацию, что старые mac os как раз использовали pascal для разработки и довольно широко. После чего со временем перешли на objective C.
В чертогах памяти, вспоминается что использование PASCAL как пример
long FAR PASCAL WndProc ( HWND hwnd, UINT msg, UINT wParam, LONG lParam ) использовали, не потому, что первые версии были на pascal, а потому, что это ускоряло код. Откуда эта информация, не помню.
Скорее, наоборот, то, что было с 11 по 23 упростило разработку до какого-то вменяемого уровня. Сложность языка всё ещё запредельная, но писать стало приятнее.
тут надо затронуть 1 очень важную деталь, железный конь на фон Неймане который уже не тот когда был придуман С - и новое будущее, которое стучится к нам с Растом, и почему-то верификация, если на неё посмотреть архитектурно смотрится уже не так как тогда когда пытались доказать что Раст имба, тоесть мы буквально шагнули в будущее когда первые байты Раста тронули центральный процессор, так что 86-64 будем посмотреть, но эволюция двинулась вперед в мире процессоров однозначно
Наоборот, начиная с С++11 наконец на С++ стало писать проще, благодаря новым функциям языка и новым шаблонам разработки. И проявился такой неожиданный эффект - код на новых стандартах просто работает на всех системах, где этот стандарт поддерживается - фактически - везде. С++ повезло, что у него есть Бьёрн с его энергией и авторитетом.
Почему перестанут? Уже перестали ведь. В том же майкрософте с 2022 или 2023 года на плюсах новые проекты не пишут.
Столько языков новых на замену плюсам в разных нишах.
А тем, кто не перестал - запретили из-за новых требований безопасности в США.
Скоро майкрософт закроет C++ вообще, откажется от его использования и забудет о нем)
Microsoft к 2030 году планирует отказаться от языков программирования C и C++ и переписать кодовые базы на Rust с помощью «ИИ-инфраструктуры»
Об этом рассказал главный инженер компании в посте на LinkedIn.
Модернизация крупных кодовых баз и переход на Rust — не официальное заявление компании, а планы ведущего инженера Microsoft Галена Ханта. Он выложил пост на LinkedIn, в котором рассказал, что ищет инженера-программиста, чтобы убрать «каждую строку C и C++ из Microsoft к 2030 году». Для решения этой «ранее немыслимой задачи» команда собирается «объединить ИИ и алгоритмы для переписывания крупнейших кодовых баз».
Читал новость, первый же комментарий: помянем:))
Это что-то уровня отказа от Кобола. Они, конечно, могут отказаться от новых проектов на С++, но переписать весь старый код до 2030 -- это абсурд.
(Вообще, этот проект больше исследование, чем план)
у ИИ есть "наработки" в миллионы строк кода на Rust'е? или оно будет учиться на этом?
просто напишут в первом диалоге чтобы ждал файл по приходу файла транслировал этот код в равный Расту, недели 3(около 4 дней трансляции, далее около 1к вопросов на закрепление и правки нейрослопом) и далее допил командой около 3 лет что-то такое я думаю
суть еще в том что они могут диалог распечатать, соотв вопросы будет задавать их начальник типо ну мне так кажется
тоесть если это гпт 5.5 это именно так но тут момент готовы ли они кидать в сетку код
ну в любом случае наверняка уже знают лучше как это сделать я только предположил
а может не так, может просто будут брать куски и с асистентом перепиливать на Раст в обычном режиме
оба варианта на 3 года уйдёт если там много связного кода
Их последний вин11 уже прекрасный антипример. Есть сомнения, что раст какой-нибудь им поможет.
"Ну хоть, что то они не сломали:)" - Крофь ис глас текот.
Без исключений печально, std будет неполной.
Сторонний линкер с полной поддержкой COFF с MS совместимыми исключениями не вариант подобрать?
А что такого они сломали в Visual Studio, что экзешник не может запускаться под Win98 ? Стандарт PE файлов вроде не менялся, что там может быть несовместимо ?
Версия файла, но это не проблема. Проблема в новых API которые используются sв реализации стандартной библиотеки, исключения которые полагаются на новый windows api. Тоже самое с рантайм. Еще сам формат новые версии добавляют дополнительные секции, которые может обрабатывать только новый линкер, который знает только о новой винде.
Я думаю, в linux проблем будет меньше в этом плане. Пока мне не до конца понятная вещь это именно исключения, есть понимание что у каждого компилятора опора на конкретное api и если его подменить, есть шанс что заведется.
Кстати, тоже вариант. Несовместимость обычно в startup коде. Может быть, простая его подмена и решит большинство вопросов.
Проблема в новых API которые используются sв реализации стандартной библиотеки, исключения которые полагаются на новый windows api
Это очень сомнительно.
А вот рантайм в целом, наоборот, может тоже взять постарше.
Сразу предвещаю дополнительные проблемы, не описанные в статье:
иногда происходит добавление обращений к WinAPI, которые недоступны в старых ОС
Необходимо выключать также генерацию опкодов новомодных инструкций типа SSE, иначе для каких-то оптимизаций студия задействует их, и код в итоге крэшнется, и понять почему будет крайне сложно
Я ожидал проблем с манглингом имен, но их нет. Протестировал на дополнительных модулях, классы, доп using'и и компилятор применяет совместимые названия, линкер от vc 6.0 корректно все линкует.
Данный подход расширяет программирование под ретро системы. С++ 23 его фичи и использование современных компиляторов хорошо оптимизируют код. Это дополнительная производительность, за которую по сути я не плачу это из коробки. Очень приятно, мне в библиотеке LDL приходилось для софт рендера дублировать работу с разными форматами изображений, с помощью С++ я смогу это упростить и быть уверенным, что все заинлайниться так как буду использовать шаблоны, constexpr.
О, аналогично играюсь, компилируя на современной ОС минимально возможные exe, работоспособные как сейчас, так и в Windows 95. Правда, я фанат Делфи (в данной форме применения - деградировавшего почти до Паскаля + Win32 api). Также использую специфичный подход, беря .lib файлы и старый майкрософтский линкер v.5.12.
Сборка
Хоть это действительно больше игрушка, но по этой технологии реально написал пару микроутилит, актуально применяющихся в практике локального администрирования по сей день.
Не сказал бы, что игрушка. Можно писать не многопоточные программы, игры разной сложности, можно использовать динамическую линковку к dll,so. Это будет работать.
Вторым шагом можно сделать модули для SDL 1.2 и SDL3 для новых и старых систем. В модулях загружать через GetProcAddress.
Создать модуль с единым api который бы вызывал данные модули в зависимости от системы. Доделать STL.
И в итоге можно писать один код сразу для всех новых и старых систем на современном С++ 23. Пока без исключений, так как пока для меня их добавление, намного сложнее, чем написать основные библиотечные фичи и контейнеры.
А как использование всех этих возможностей влияет на производительность?
Получается ли эффективный код?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пишем на С++ 23 под Windows 95, не вызывая подозрение у санитаров