Форум на Исходниках.RU

Текущий Стандарт С++ и перспективы его развития

shm — Fri, 31 Oct 2025 19:35:09 +0000

shm: Славян, ты пытаешься изобрести tuple.

Добавлено 31.10.25, 19:40

std::tuple<int, char, float> MyFunc(int a)

{

return {a-1,'A',3.14};

}

Добавлено 31.10.25, 19:42
Смотрю выше уже написали, тогда не понимаю к чему спор.

Добавлено 31.10.25, 19:43
К слову, реальных применений tuple не так уж и много.

Текущий Стандарт С++ и перспективы его развития

Славян — Sat, 04 Oct 2025 11:15:11 +0000

Славян:

Цитата B.V. @ 03.10.25, 15:20

А как обращаться к полям такой структуры?

Ровно так же, как и к неименованым аргументам: никак. Разработчик убрал имя, значит сейчас оно ему не нужно. Как/когда понадобится - обзовёт. И мы были бы близки к идеалу:

struct {int;char;float;} MyFunc(int a)

{

...

return (a-1,'A',3.14);

}

Но тут вылезает другой изъян: запятая. Которая сейчас как бы говорит "верну то, что справа". И сейчас же получается, что фраза:

x = 5,6;

вроде бы превращается в возврат 6 последним. Посему, конструкция "a-1,'A',3.14" намекает, что вернётся 3.14, как последнее. Хотя компилятор не допускает

f = sin(0,1);

А должен был бы (по логике) скормить 1 синусу. Короче, много неясностей каких-то...

Текущий Стандарт С++ и перспективы его развития

Majestio — Fri, 03 Oct 2025 15:32:53 +0000

Majestio:

Цитата B.V. @ 03.10.25, 15:20

А как обращаться к полям такой структуры?

По идее такую шляпу можно было бы использовать в двух случаях:

Текущий Стандарт С++ и перспективы его развития

B.V. — Fri, 03 Oct 2025 15:20:51 +0000

B.V.:

Цитата Славян @ 03.10.25, 01:30

Жаль, что пустые=неименованые поля в структурах недопустимы (вроде бы).

А как обращаться к полям такой структуры?

Текущий Стандарт С++ и перспективы его развития

Славян — Fri, 03 Oct 2025 01:30:20 +0000

Славян:

Цитата Qraizer @ 02.10.25, 18:11

От так тож можно, ибо структурное связывание языковое, а не либовое:

Вот, уже ближе к желанному! Но осуществляется как бы уход в какие-то другие языки, a'la:

MyFunc( args )

{

...

MyFunc = val1; // то, что вернётся

...

MyFunc = val2;

}

Жаль, что пустые=неименованые поля в структурах недопустимы (вроде бы). Так бы:

struct { int; int; int; } TranslateSysAddrToCS(unsigned SystemAddr);

Хотя в аргументах неименование разрешается!:

int myFunc( int, int a, int)

{

...

}

Текущий Стандарт С++ и перспективы его развития

Majestio — Thu, 02 Oct 2025 21:33:08 +0000

Majestio: Ну можно попробовать сам exe задебажить. Я качнул x64dbg. Но не хватило ни опыта в этом, ни терпения.
Если есть желание, присоединяю сам exe.
test.exe.7z (, : 32)

Добавлено 02.10.25, 21:41

Цитата Qraizer @ 02.10.25, 18:11

P.S. Кстати, за либы. От так тож можно, ибо структурное связывание языковое, а не либовое

Это интереснее чем tuple, но тогда уж еще typedef и будет классика.

Добавлено 02.10.25, 22:05
На всяк случай скидываю линк на интересный утиль - плагин для FAR PE analyzer.

Текущий Стандарт С++ и перспективы его развития

Qraizer — Thu, 02 Oct 2025 18:11:11 +0000

Qraizer: Та фик там что найдёшь. Я даже myfunc не нашёл, а main аж две.

P.S. Кстати, за либы. От так тож можно, ибо структурное связывание языковое, а не либовое:

struct { int i1; int i2; int i3; } TranslateSysAddrToCS(unsigned SystemAddr);

Текущий Стандарт С++ и перспективы его развития

Majestio — Thu, 02 Oct 2025 17:16:38 +0000

Majestio:

Цитата macomics @ 02.10.25, 17:02

Скорми ELF в objdump

Файлы прикрепил.
test_intel.asm.7z (, : 29)
test.aot.7z (, : 33)

Текущий Стандарт С++ и перспективы его развития

macomics — Thu, 02 Oct 2025 17:02:27 +0000

macomics:

Цитата Majestio @ 02.10.25, 14:00

Есть отдельный ключ - он компилячит в объектный файл, но там сигнатура ELF, да и размер тоже сравнимый с exe

Скорми ELF в objdump

Текущий Стандарт С++ и перспективы его развития

Majestio — Thu, 02 Oct 2025 14:00:02 +0000

Majestio:

Цитата Qraizer @ 02.10.25, 13:17

А нет волшебного ключика "сделай asm"? Как у Студии -FA, например. Мож он тогда только своё сгенерит, без всякой либовой обвязки

Увы, нету. Я изучил вопрос. Сам Дарт сперва компилячит в свое внутренне представление, а потом из него в код целевой платформы. Есть отдельный ключ - он компилячит в объектный файл, но там сигнатура ELF, да и размер тоже сравнимый с exe. Максимум, что я могу сделать - представить кусок кода на js, но это всё совсем не то.

var A = {

printString(string) {

if (typeof dartPrint == "function") {

dartPrint(string);

return;

}

if (typeof console == "object" && typeof console.log != "undefined") {

console.log(string);

return;

}

if (typeof print == "function") {

print(string);

return;

}

throw "Unable to print message: " + String(string);

_Universe_addRules(universe, rules) {

return A._Utils_objectAssign(universe.tR, rules);

_Universe_addErasedTypes(universe, types) {

return A._Utils_objectAssign(universe.eT, types);

_Utils_objectAssign(o, other) {

var i, key,

keys = Object.keys(other),

$length = keys.length;

for (i = 0; i < $length; ++i) {

key = keys[i];

o[key] = other[key];

}

main() {

A.printString("42, hello");

}

};

Текущий Стандарт С++ и перспективы его развития

Qraizer — Thu, 02 Oct 2025 13:17:17 +0000

Qraizer: А нет волшебного ключика "сделай asm"? Как у Студии -FA, например. Мож он тогда только своё сгенерит, без всякой либовой обвязки

Добавлено 02.10.25, 13:20
Упс. В примерах кода прошмыгнуло чуток конфиденциальности. Подправил.

Текущий Стандарт С++ и перспективы его развития

Majestio — Thu, 02 Oct 2025 11:59:42 +0000

Majestio:

Цитата Qraizer @ 02.10.25, 11:51

Можно на Dart посмотреть?

Такое я еще не пробовал. Дело в том, что Dart сперва копилирует свой код в промежуточный, а уже потом тулчейнами в код целевой платформы. Я пока баловался только для Web - а там целевой код javascript. В принципе могу собрать exe для винды, но как там найти нужные места в ассемблерном представлении - я х3. Хэлоу ворлд будет порядка 20 метров. Хотя консольное приложение должно быть поменьше, т.к. хэлоу ворлд я делал на Dart+Flutter. А там статически влинковывается весь графический движок.

Добавлено 02.10.25, 12:13
Хотя, о чем это я :) Для винды у Dart - формируется второе промежуточное представление на С++, и из него тулчейном уже собирается exe-шник. Поэтому имеет смысл просто смотреть сгенерированный С++ код. Будет время - проверю что там генерится.

Засада! Оказывается промежуточное представление на С++ делает не Dart, а Flutter для свои "обвязок". Код на Dart компилячится напрямую.

Добавлено 02.10.25, 12:50
exe получается 5 мегов, а дизасемблирование 105 мегов ассемблерного кода. Ну его нафиг! :huh:

Текущий Стандарт С++ и перспективы его развития

Qraizer — Thu, 02 Oct 2025 11:51:08 +0000

Qraizer: К вопросу об оверхеде

auto [found, node, cs] = TranslateSysAddrToCS(0x12345678u);

mov edx, 305419896 ; 12345678H

lea rcx, QWORD PTR $S1$[rsp] ;<-

call ?TranslateSysAddrToCS@@YA?AV?$tuple@HHH@std@@I@Z ; TranslateSysAddrToCS

; Line 10

mov r8d, DWORD PTR $S1$[rsp] ;<-

mov edx, DWORD PTR $S1$[rsp+4] ;<-

mov ecx, DWORD PTR $S1$[rsp+8] ;<-

std::tuple<int, int, int> TranslateSysAddrToCS(unsigned SystemAddr)

{

int CSFound = SystemAddr >> 16, NodeID = SystemAddr % (1 << 16), CS = SystemAddr != 0;

/* ... */

return { CSFound, NodeID, CS };

}

xor eax, eax

movzx r8d, dx

mov r9d, edx

; File D:\VS2019\VC\Tools\MSVC.29.30133\include\tuple

; Line 158

mov DWORD PTR [rcx+4], r8d ;<-

; File D:\Work\DelMe\qq.cpp

; Line 5

shr r9d, 16

test edx, edx

; File D:\VS2019\VC\Tools\MSVC.29.30133\include\tuple

; Line 158

mov DWORD PTR [rcx+8], r9d ;<-

; File D:\Work\DelMe\qq.cpp

; Line 5

setne al

; File D:\VS2019\VC\Tools\MSVC.29.30133\include\tuple

; Line 158

mov DWORD PTR [rcx], eax ;<-

; File D:\Work\DelMe\qq.cpp

; Line 7

mov rax, rcx

; Line 8

ret 0

Можно на Dart посмотреть?

Текущий Стандарт С++ и перспективы его развития

Majestio — Thu, 02 Oct 2025 10:46:26 +0000

Majestio:

Цитата D_KEY @ 02.10.25, 06:12

tuple тоже в 11 появился (хотя были потом изменения).

Я знаю. Написал это к тому, что на дворе 2025 год, а до сих пор это неудобство.

Например в Dart тоже формально нельзя возвращать более одного значения, но там допустима конструкция:

(int, String) myfunc() {

return (42, "hello");

}

void main() {

var (num, str) = myfunc(); // деструктуризация

print("$num, $str");

}

Функция myfunc по факту возвращает одно значение типа Record. Но посмотри как это красиво записано, и не нужно каких-либо библиотек. Без оверхеда лучше.

Текущий Стандарт С++ и перспективы его развития

Majestio — Thu, 02 Oct 2025 10:35:56 +0000

Majestio:

Цитата D_KEY @ 02.10.25, 06:12

В перл можно управлять захватом контекста лямбды? Можно определять, по значению, по ссылке или вообще перенести данные в лямбду?

По ссылке

my $x = 10;

my $f = sub { return $x++ };

$f->(); # изменяет $x

По значению

my $x = 10;

my $f = do {

my $copy = $x; # создаём локальную копию

sub { return $copy++ }

};

$f->(); # не изменяет $x

Перенос

my $x = 10;

my $f = do {

my $moved = $x;

undef $x; # "обнуляем" внешнюю переменную

sub { return ++$moved }

};

$f->(); # переносит 10 в лямбду, а $x становится undef

Цитата D_KEY @ 02.10.25, 06:12

Вот и получается, что слово одно, а фичи разные

:tong:

Текущий Стандарт С++ и перспективы его развития

D_KEY — Thu, 02 Oct 2025 06:12:10 +0000

D_KEY:

Цитата Majestio @ 02.10.25, 03:42

В далеком 2011 году в Стандарте С++ появилась киллер-фича "лямбды". Сколько себя помню в Perl, а это примерно 1997 год, там всегда это было.

В перл можно управлять захватом контекста лямбды? Можно определять, по значению, по ссылке или вообще перенести данные в лямбду? Вот и получается, что слово одно, а фичи разные :)

Добавлено 02.10.25, 06:16

Цитата Majestio @ 02.10.25, 03:42

Для С ... бида-пичаль, а для C++ ... ешьте std::tuple в 2025 году! ;)

Скрытый текст

#!/usr/local/bin/perl

use strict;

use warnings;

my ($sign, $int, $frac) = SuperDiv(3,-2);

print "$sign$int.$frac\n";

sub SuperDiv {

my ($dividend, $divisor) = @_;

my $res = $dividend / $divisor;

my $sign = ($res < 0) ? "-" : "";

my $int = int(abs($res));

my $frac = abs($res) - $int;

$frac =~ s/^0\.//;

return ($sign, $int, $frac);

}

-1.5

:victory:

Это так, коротко о хороших и гениальных языках программирования!

tuple тоже в 11 появился (хотя были потом изменения).
Кстати, это класс стандартной библиотеки, а не часть самого языка. Т.е. возможности языка позволяют реализовать подобное не включая в сам язык.

Добавлено 02.10.25, 06:18

Цитата Majestio @ 02.10.25, 03:42

Никогда такого не было, и вот опять!!! Сколько себя помню в Perl, а это примерно 1997 год...

Ну а чего perl? Чего там 97 год?
Можно лисп вспомнить :lol:

Текущий Стандарт С++ и перспективы его развития

Majestio — Thu, 02 Oct 2025 03:42:04 +0000

Majestio: Сперва сдержался, но всеж не могу - уж очень хочется поёрничать, очень! :D

В далеком 2011 году в Стандарте С++ появилась киллер-фича "лямбды". Сколько себя помню в Perl, а это примерно 1997 год, там всегда это было.
Никогда такого не было, и вот опять!!! Сколько себя помню в Perl, а это примерно 1997 год, там всегда была возможность возврата множественного результата. Для С ... бида-пичаль, а для C++ ... ешьте std::tuple в 2025 году! ;)

Скрытый текст

#!/usr/local/bin/perl

use strict;

use warnings;

my ($sign, $int, $frac) = SuperDiv(3,-2);

print "$sign$int.$frac\n";

sub SuperDiv {

my ($dividend, $divisor) = @_;

my $res = $dividend / $divisor;

my $sign = ($res < 0) ? "-" : "";

my $int = int(abs($res));

my $frac = abs($res) - $int;

$frac =~ s/^0\.//;

return ($sign, $int, $frac);

}

-1.5

:victory:

Это так, коротко о хороших и гениальных языках программирования!

Текущий Стандарт С++ и перспективы его развития

Majestio — Wed, 01 Oct 2025 19:29:54 +0000

Majestio:

Цитата Qraizer @ 01.10.25, 18:32

В Плюсах есть, но синтаксис другой.

Речь не о плюсах. В Си такое реализовать наиболее просто на структурах.

Текущий Стандарт С++ и перспективы его развития

Qraizer — Wed, 01 Oct 2025 18:32:52 +0000

Qraizer: В Плюсах есть, но синтаксис другой. Вроде того:

std::tuple<int, int, int> TranslateSysAddrToCS(uint32_t SystemAddr){

/* ... */

return { CSFound, NodeID, CS };

}

int [found, node, cs] = TranslateSysAddrToCS(0x12345678u);

Текущий Стандарт С++ и перспективы его развития

Majestio — Wed, 01 Oct 2025 16:21:55 +0000

Majestio:

Цитата Славян @ 01.10.25, 15:40

И простой вопрос: это же концептуальная запись (возврат нескольких значений)? Нет же такого ни в какой версии Си-компилятора?

Это С-подобный псевдокод. Смотрится нагляднее, чем возвращать структуру. Но это невалидный С-код.

Цитата Славян @ 01.10.25, 15:40

А то вечно приходится "костыли" городить, чтобы вернуть два-три значения... Эх...

Да нет, структуры это решают красиво. Автор решил еще "приукрасить" :lol:

Текущий Стандарт С++ и перспективы его развития

Славян — Wed, 01 Oct 2025 15:40:06 +0000

Славян: Наткнулся на описание функции из книжки AMD (BIOS and Kernel Developer’s Guide for the AMD Athlon™ 64 and AMD Opteron™ Processors):

(int,int,int) TranslateSysAddrToCS((uint32)SystemAddr){

int CSFound, NodeID, CS, F1Offset, F2Offset, Ilog;

uint32 IntlvEn, IntlvSel;

uint32 DramBase, DramLimit, DramEn;

uint32 HoleOffset, HoleEn;

uint32 CSBase, CSLimit, CSMask, CSEn;

uint32 InputAddr, Temp;

CSFound = 0;

for(NodeID = 0; NodeID < 8; NodeID++){

F1Offset = 0x40 + (NodeID << 3);

DramBase = Get_PCI(bus0, dev24 + NodeID, func1, F1Offset);

DramEn = DramBase & 0x00000003;

IntlvEn = (DramBase & 0x00000700) >> 8;

DramBase = DramBase & 0xFFFF0000;

...

if(CSFound) break;

}

return(CSFound,NodeID,CS);

}

И простой вопрос: это же концептуальная запись (возврат нескольких значений)? Нет же такого ни в какой версии Си-компилятора?
Снова простая попытка/схема реализовать столь нужный функционал! А то вечно приходится "костыли" городить, чтобы вернуть два-три значения... Эх... :'(

Текущий Стандарт С++ и перспективы его развития

Majestio — Sun, 21 Sep 2025 22:50:20 +0000

Majestio: amk, привет, дружище!!! :victory:

Вообще без проблем поговорить по этому вопросу и набраться современных знаний - тема есть, но наука то не стоит!
Будь добр, обеспечить свои утверждения линками-пруфами по этим темам, чисто для ознакомления.

Текущий Стандарт С++ и перспективы его развития

amk — Sun, 21 Sep 2025 21:11:19 +0000

amk:

Цитата Majestio @ 14.09.25, 18:07

Заметь! 2 потом 3, а не 3 потом 2

Тут ты ошибся.
Сперва из текста программы удаляются комментарии и производится склейка строк.
Потом производится разбор текста на лексемы, включая и строки с директивами препроцессора.
И уже после разбора на лексемы работает препроцессор, удаляя куски уже разобранного текста и заменяя макросы.

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

В ранних компиляторах C (K&R), состоящих из отдельных программ, каждая из которых выполняла свой проход, порядок был другой. Препроцессор выполнялся до разбора на лексемы, но после удаления комментариев (собственно он их и удалял).

Текущий Стандарт С++ и перспективы его развития

Majestio — Thu, 18 Sep 2025 10:13:08 +0000

Majestio:

Цитата Qraizer @ 15.09.25, 15:39

Никсоидам может быть и нормуль, когда make генерит makefile, по которому make генерит три makefile, по которым make генерит N makefiles для сборки N/3 пререквизитов, по которым рекурсивно процесс повторяется для сборки пререквизитов, ещё один собирает собственно проект с пререквизитами и ещё один конфигурит и инсталит, и поэтому им нормуль, когда половина пререквизитов автогенерится своими makefile, точнее, их половиной, тогда как вторая половина их собственно собирает... а, не, половина от N/3... ойфсё.

Вот тут про никсоидов было очень обидно сказано! Нагнал жути :lol:

Спецом побеседовал с ChatGPT по этой теме, т.к. практического использования bison+flex не имел. Ради прикола собрал парсер С++ кода, который из кода извлекает все литералы и распечатывает их. Заметь, я не использовал make, а сделал это современными и отчасти удобными средствами сборки cmake+ninja.

А вот сам пример (да, понимаю, что сильно упрощенный - но наглядный)

lexer.l

#include "parser.tab.h" // Включаем заголовок от Bison для токенов

%option noyywrap

/* Состояния */

%x SINGLE_COMMENT

%x MULTI_COMMENT

/* Пропуск пробелов и другого кода (мы фокусируемся только на литералах и комментариях) */

[ \t\n]+ ; // Игнорируем whitespace

/* Начало однострочного комментария */

"//" { BEGIN(SINGLE_COMMENT); }

<SINGLE_COMMENT>[^\n]* ; // Потребляем до конца строки

<SINGLE_COMMENT>\n { BEGIN(INITIAL); } // Возврат в нормальное состояние

/* Начало многострочного комментария */

"/*" { BEGIN(MULTI_COMMENT); }

<MULTI_COMMENT>[^*]* ; // Потребляем всё, кроме *

<MULTI_COMMENT>"*"+[^*/]* ; // Потребляем * не за которыми /

<MULTI_COMMENT>"*"+"/" { BEGIN(INITIAL); } // Конец комментария

/* Строковый литерал (упрощённо, с escape) */

\"(\.|[^\"])*\" { yylval.str = strdup(yytext); return STRING_LITERAL; }

/* Символьный литерал (упрощённо) */

\'(\.|[^\'])*\' { yylval.str = strdup(yytext); return CHAR_LITERAL; }

/* Другие символы (пропускаем, так как не интересуют) */

. ; // Игнорируем остальной код

parser.y

#include <iostream>

#include <vector>

#include <string>

#include <cstring>

extern int yylex();

void yyerror(const char* s);

std::vector<std::string> literals; // Глобальный список для собранных литералов

%union {

char* str;

}

%token <str> STRING_LITERAL

%token <str> CHAR_LITERAL

%start program

program: statements

;

statements: statement

| statements statement

;

statement: STRING_LITERAL { literals.push_back(); free(); }

| CHAR_LITERAL { literals.push_back(); free(); }

| /* пусто */ { /* Игнорируем другие токены или пустые */ }

;

void yyerror(const char* s) {

std::cerr << "Ошибка парсинга: " << s << std::endl;

}

main.cpp

#include <iostream>

#include <vector>

#include <string>

#include <windows.h> // Для Windows API

#include "parser.tab.h"

extern std::vector<std::string> literals;

extern FILE* yyin;

// Функция для вывода строки в CP1251 через WriteConsoleW

void print_in_cp1251(const std::string& str) {

// Конвертируем UTF-8 или ASCII строку в UTF-16 (Windows использует UTF-16)

int wstr_size = MultiByteToWideChar(CP_UTF8, 0, str.c_str(), -1, nullptr, 0);

std::wstring wstr(wstr_size, 0);

MultiByteToWideChar(CP_UTF8, 0, str.c_str(), -1, &wstr[0], wstr_size);

// Выводим в консоль с CP1251 (Windows автоматически конвертирует UTF-16 в CP1251 для консоли)

HANDLE hConsole = GetStdHandle(STD_OUTPUT_HANDLE);

WriteConsoleW(hConsole, wstr.c_str(), wstr.size() - 1, nullptr, nullptr);

}

int main(int argc, char** argv) {

// Устанавливаем кодировку консоли на CP1251

SetConsoleOutputCP(1251);

if (argc > 1) {

yyin = fopen(argv[1], "r");

if (!yyin) {

print_in_cp1251("Не удалось открыть файл: " + std::string(argv[1]) + "\n");

return 1;

}

yyparse(); // Запускаем парсер

// Выводим собранные литералы

print_in_cp1251("Собранные строковые и символьные литералы (вне комментариев):\n");

for (const auto& lit : literals) {

std::cout << lit << std::endl; // Литералы в ASCII, их можно выводить через std::cout

}

if (yyin != stdin) fclose(yyin);

return 0;

}

CMakeLists.txt

cmake_minimum_required(VERSION 3.10)

project(CPPScanner LANGUAGES C CXX)

# Стандарт C++17

set(CMAKE_CXX_STANDARD 17)

set(CMAKE_CXX_STANDARD_REQUIRED ON)

# Включаем статическую линковку

set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -static -static-libgcc")

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -static")

# Найти Flex и Bison

find_package(BISON REQUIRED)

find_package(FLEX REQUIRED)

# Генерация парсера из parser.y (с подавлением предупреждений Bison)

BISON_TARGET(MyParser parser.y ${CMAKE_CURRENT_BINARY_DIR}/parser.tab.c

DEFINES_FILE ${CMAKE_CURRENT_BINARY_DIR}/parser.tab.h

COMPILE_FLAGS "-Wnone")

# Генерация лексера из lexer.l

FLEX_TARGET(MyLexer lexer.l ${CMAKE_CURRENT_BINARY_DIR}/lex.yy.c)

# Зависимость: парсер зависит от лексера

ADD_FLEX_BISON_DEPENDENCY(MyLexer MyParser)

# Собрать исполняемый файл

add_executable(scanner

main.cpp

${BISON_MyParser_OUTPUT_SOURCE} # parser.tab.c

${FLEX_MyLexer_OUTPUTS} # lex.yy.c

)

# Указываем, что генерированные .c файлы — это C++

set_source_files_properties(${BISON_MyParser_OUTPUT_SOURCE} ${FLEX_MyLexer_OUTPUTS} PROPERTIES LANGUAGE CXX)

# Подавляем предупреждение о deprecated для Clang

set_source_files_properties(${BISON_MyParser_OUTPUT_SOURCE} ${FLEX_MyLexer_OUTPUTS} PROPERTIES

COMPILE_FLAGS "-Wno-deprecated")

# Включить директории для заголовков

target_include_directories(scanner PRIVATE ${CMAKE_CURRENT_BINARY_DIR})

# Добавить путь к библиотекам clang64

target_link_directories(scanner PRIVATE E:/Tools/MSys64/clang64/lib)

# Линковка со статическими библиотеками C++ и unwind

target_link_libraries(scanner PRIVATE -static libc++.a libunwind.a)

Процесс сборки:

mkdir build && cd build

cmake -G Ninja ..

ninja

-- The C compiler identification is Clang 20.1.8

-- The CXX compiler identification is Clang 20.1.8

-- Detecting C compiler ABI info

-- Detecting C compiler ABI info - done

-- Check for working C compiler: E:/Tools/MSys64/clang64/bin/cc.exe - skipped

-- Detecting C compile features

-- Detecting C compile features - done

-- Detecting CXX compiler ABI info

-- Detecting CXX compiler ABI info - done

-- Check for working CXX compiler: E:/Tools/MSys64/clang64/bin/c++.exe - skipped

-- Detecting CXX compile features

-- Detecting CXX compile features - done

-- Found BISON: E:/Tools/MSys64/usr/bin/bison.exe (found version "3.8.2")

-- Found FLEX: E:/Tools/MSys64/usr/bin/flex.exe (found version "2.6.4")

-- Configuring done (1.7s)

-- Generating done (0.0s)

-- Build files have been written to: E:/Tools/MSys64/home/Majestio/work/bison_flex/build

[6/6] Linking CXX executable scanner.exe

Проверяем на файле input.cpp следующего содержимого:

// Это комментарий с "строкой", которую нужно пропустить

int main() {

std::string s = "hello world"; // Строка для сбора

char c = 'a'; // Символ для сбора

/* Многострочный комментарий с 'b' и "test", которые пропустить */

return 0;

}

E:\Tools\MSys64\home\Majestio\work\bison_flex\build>scanner.exe input.cpp

Собранные строковые и символьные литералы (вне комментариев):

"hello world"

'a'

По-моему не всё так страшно-ужасно как ты расписал :victory:

Текущий Стандарт С++ и перспективы его развития

Qraizer — Mon, 15 Sep 2025 15:39:30 +0000

Qraizer: Ну я бы не был так категоричен на предмет производительности. Другое дело, компиляция... <_<
Та и в целом, меня напрягает любой автоматически непонятно кем непонятно как генерируемый код, вставляемый в мой проект. Никсоидам может быть и нормуль, когда make генерит makefile, по которому make генерит три makefile, по которым make генерит N makefiles для сборки N/3 пререквизитов, по которым рекурсивно процесс повторяется для сборки пререквизитов, ещё один собирает собственно проект с пререквизитами и ещё один конфигурит и инсталит, и поэтому им нормуль, когда половина пререквизитов автогенерится своими makefile, точнее, их половиной, тогда как вторая половина их собственно собирает... а, не, половина от N/3... :wacko: ойфсё. И да, в Cях метакодить иначе никак. Спасибо, я всё ж лучше метакодить по Стандарту буду

Текущий Стандарт С++ и перспективы его развития

Majestio — Mon, 15 Sep 2025 14:37:41 +0000

Majestio: Bison + Flex однозначно лучше, когда требуется максимальная производительность парсинга для обработки больших входных данных, а грамматика подходит для LALR, так как они генерируют оптимизированный C-код, который работает быстрее, чем парсеры, созданные с помощью Boost::Spirit.

Текущий Стандарт С++ и перспективы его развития

Qraizer — Mon, 15 Sep 2025 13:56:49 +0000

Qraizer: Зачем такое старьё, если есть boost::spirit :lol: ?

Текущий Стандарт С++ и перспективы его развития

Majestio — Mon, 15 Sep 2025 09:28:00 +0000

Majestio: Qraizer, тебе квест! ;)

Цитата Qraizer @ 13.09.25, 20:13

Как-то пришлось писать утилю, которая заменяла все я на Я, потому как используемая тулза (инструментатор исходного кода под: сбор структурного покрытия; сбор информации WCET, анализ потоков данных и/или управления; оценка наихудшего использования стека) на ASCII символах == 0xFF бажила. (Дело не в русской букве, а именно коде символа. В европейских кодировках на этом символе тот же баг.) Так это было целое приключение, т.к. заменять всё было нельзя, только в комментах. А то, что в строках, нужно оставить нетронутым, иначе меняется поведение кода, благо на таких тулза не бажила.
В итоге это вылилось в весьма нетривиальный алгоритм.

Я уверен, что сей велосипед ты навелосипедил на все 100% правильно. Но ты тогда, imho, пошел самым упоротым путем. Ибо для таких задач уже давно существовали специальные решения. А именно связка либ - bison (1985) + flex (1987). Генераторы парсеров и лексические анализаторы в лице вышеупомянутых либ.

Слабо изучить матчасть и перевести свой код под эти "платформы"?

Скрытый текст

заодно и мы поучимся ... а?

Текущий Стандарт С++ и перспективы его развития

Majestio — Mon, 15 Sep 2025 04:03:28 +0000

Majestio:

Цитата Qraizer @ 14.09.25, 21:56

В чём именно ты видишь неправильность?

Ну я же написал выше. Не неправильность, а скорее запутанность. Проще написать, что внутри литералов не может быть комментов, равно как и внутри комментов не может быть литералов.
Тогда всё ясно и понятно. И да, давай не будем душнить =)

Текущий Стандарт С++ и перспективы его развития

Qraizer — Sun, 14 Sep 2025 21:56:44 +0000

Qraizer: В чём именно ты видишь неправильность? Я не собирался описывать алгоритм, хошь сырцов?, они есть. Я описал спектр учитываемых аспектов. Естественно их не следует применять в описанном порядке. Давайте не будем душнить. Плз.

Текущий Стандарт С++ и перспективы его развития

Majestio — Sun, 14 Sep 2025 18:07:54 +0000

Majestio: Qraizer, склейка строк не спасет от неправильности твоего этого утверждения.
Хотя нет, не от неправильности. Твое это утверждение отчасти верно. Просто оно записано так, что несколько ломает причинно-следственные связи :lol: А именно ... как бы это правильно сказать: литералы все же первичны, конструкции комментариев вторичны. Т.е., выражаясь академическим языком, и чтобы не туманить мозги С++ неофитам, ты должен был выразить мысль в более "календарном" смысле, в обратном порядке:Заметь! 2 потом 3, а не 3 потом 2. Если я не ошибаюсь, это что-то типа раздел 5.2 "Phases of translation" текущего Стандарта.

Текущий Стандарт С++ и перспективы его развития

Qraizer — Sun, 14 Sep 2025 15:59:42 +0000

Qraizer: Majestio, ну да. Это и означает, что

std::cout << "Тут я не должна заменяться, даже /* если я размещу её */ вот так"; // в отличие от "Тут я должна быть \

заменена", потому что это всё ещё коммент

нужно уметь правильно обработать

Текущий Стандарт С++ и перспективы его развития

Majestio — Sun, 14 Sep 2025 15:08:30 +0000

Majestio:

Цитата Qraizer @ 13.09.25, 20:13

Не всё, что внутри /**/ или //EOL, является комментом, а только то, что не в строковом литерале.

Крайне подозрительное утверждение. Внутри комментариев - не может быть литералов. И если мы что-то решили закомментировать (я имею ввиду по правилам), то любые литералы автоматом превращаются в комментарии.

Текущий Стандарт С++ и перспективы его развития

Majestio — Sun, 14 Sep 2025 14:03:50 +0000

Majestio:

Цитата Славян @ 13.09.25, 12:58

Может это и нормально, но совершенно выбесило меня!..

Да, это проблемы раскрашивателя кода. Он не учитывает, что комментарии не могут начинаться, и не могут заканчиваться внутри строковых и символьных литералов.

Цитата macomics @ 14.09.25, 00:04

Судя по этому утверждению, тогда "\\\" должен быть завершенной строкой. Но не будет. Стоило сказать про нечетное количество \.

Проще не заморачиваться количеством или чётностью. А просто определиться с обработкой.

Символ \ может участвовать:
Экранирование
Работает только внутри литералов. Символ \ может экранировать " или ' или \

Escape-преобразования
Работают только внутри литералов. Всем известные \n \r \t \a \0 \x42 ....

Компилятор сканирует код посимвольно. Встречая символы, которые могут иметь и обычное, и управляющее значение. Компилятор, в процессе сканирования, "назначает" встретившему символу "роль" (обычный или управляющий) в зависимости от ряда состояний.

Текущий Стандарт С++ и перспективы его развития

macomics — Sun, 14 Sep 2025 12:06:19 +0000

macomics: Проверю.

$ cat test.cpp

#include <iostream>

int main() {

std::cout << "Test \\";

return 0;

}

$ g++ -o test test.cpp

test.cpp:4:22: предупреждение: отсутствует завершающий символ "

4 | std::cout << "Test \\";

| ^

test.cpp:4:22: ошибка: отсутствует терминирующий символ "

4 | std::cout << "Test \\";

| ^~~~~~~~~~~

test.cpp: In function «int main()»:

test.cpp:5:9: ошибка: expected primary-expression before «return»

5 | return 0;

| ^~~~~~

$ cat test.cpp

#include <iostream>

int main() {

std::cout << "Test \\";

return 0;

}

$ g++ -o test test.cpp

$ ./test

Test \$

Текущий Стандарт С++ и перспективы его развития

Qraizer — Sun, 14 Sep 2025 07:28:52 +0000

Qraizer: Почему это? Не будет. \, предшествующий ", маскирует конец литерала и означает просто символ " как его элемент, тогда как если этому \ предшествует ещё один \, то это означает просто символ \ как элемент литерала, и если следом идёт ", то это его граница. Если мы видим \\\, то первые два означают просто \, а последний является модификатором следующего символа, и какой-то смысл они имеют только совместно. \\\" означает два обычных символа \ и ", не специальных, \\\t означает \ и TAB итп

Текущий Стандарт С++ и перспективы его развития

macomics — Sun, 14 Sep 2025 00:04:34 +0000

macomics:

Цитата Qraizer @ 13.09.25, 20:13

Не все \, предшествующие ", маскируют конец строкового литерала, а только те, которым в свою очередь не предшествует ещё один \.

Текущий Стандарт С++ и перспективы его развития

Qraizer — Sat, 13 Sep 2025 20:13:39 +0000

Qraizer: Как-то пришлось писать утилю, которая заменяла все я на Я, потому как используемая тулза (инструментатор исходного кода под: сбор структурного покрытия; сбор информации WCET, анализ потоков данных и/или управления; оценка наихудшего использования стека) на ASCII символах == 0xFF бажила. (Дело не в русской букве, а именно коде символа. В европейских кодировках на этом символе тот же баг.) Так это было целое приключение, т.к. заменять всё было нельзя, только в комментах. А то, что в строках, нужно оставить нетронутым, иначе меняется поведение кода, благо на таких тулза не бажила.
В итоге это вылилось в весьма нетривиальный алгоритм.В общем, регулярками тут не обойтись никак, одного только распознавания токенов будет недостаточно. Нужен хоть и несложный, но всё ж грамматический разбор последовательности токенов.

P.S. Кому надо сырцы солью, мне не жалко.

Текущий Стандарт С++ и перспективы его развития

Славян — Sat, 13 Sep 2025 12:58:32 +0000

Славян: Только что случайно обнаружил, что следующий код нормально не красится:

int i;

fprintf(f, "/* коммент в выводимой строке*/");

int j;

Может это и нормально, но совершенно выбесило меня!.. :angry:

Текущий Стандарт С++ и перспективы его развития

Majestio — Sat, 03 Aug 2024 23:32:26 +0000

Majestio: D_KEY, благодарю!

Текущий Стандарт С++ и перспективы его развития

D_KEY — Sat, 03 Aug 2024 12:58:27 +0000

D_KEY: -Wuninitialized
Входит и в -Wall.

Я вообще люблю -Werror еще включать. И даже для легаси кода постепенно к этому приходить. В большинстве случаев это помогает, а там где мешает, лучше в коде явно выключить предупреждение (сильно при этом локализовав).

На всякий случай еще напомню про существование clang-tidy и пр. прекрасных утилит. И все это легко интегрируется в CI/CD.

Честно говоря, не понимаю, как люди без этого на плюсах кодят и зачем.

Текущий Стандарт С++ и перспективы его развития

Majestio — Fri, 02 Aug 2024 20:00:22 +0000

Majestio:

Цитата Qraizer @ 02.08.24, 16:58

Majestio, ты часто упускаешь из виду, что неопределённое поведение говорит, лишь о том, что программа не соответствует Стандарту языка. Однако не означает, что она неверна, конкретные реализации имеют право доопределить поведение для частных случаев, и на них программа, допускающая такие нарушения Стандарта, тем не менее будет корректна.

Хотя вот этот ответ - не совсем корректен для этого топика. Мы же тут именно про Стандарт говорим, а не про разработку вообще.

Добавлено 02.08.24, 20:05

Цитата Qraizer @ 02.08.24, 16:58

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

Кстати да ... а какой опцией компилятора (gcc, clang) этот детект включить?

Добавлено 02.08.24, 20:21

Цитата Qraizer @ 02.08.24, 16:58

Мне вот не интересен заботливый родитель, который держит за ручку и сыпет "нельзя", "осторожно", "не так", "надень шапку", "не простудись"

Тут конечно дело вкуса. А мне последнее время начал нравится подход а-ля:

#pragma GCC diagnostic push

#pragma GCC diagnostic ignored "-Wключ_предупреждения"

// Участок кода, в котором нужно подавить определенное предупреждение

#pragma GCC diagnostic pop

Текущий Стандарт С++ и перспективы его развития

Qraizer — Fri, 02 Aug 2024 18:05:06 +0000

Qraizer: P.S. И местами даже не соваться туда, на что в Стандарте описано как "приговаривается к пожизненному расстрелу". Плюсы вообще редко что запрещают абсолютно и навсегда, но чем опаснее хотелка, тем больше усилий требуется для её достижения. Но уж ежели кто озаботился, либо ССЗБ, либо явно не случайно это в программе появилось, по теории вероятности вселенная столько ещё не живёт.

Текущий Стандарт С++ и перспективы его развития

Qraizer — Fri, 02 Aug 2024 16:58:22 +0000

Qraizer: Majestio, ты часто упускаешь из виду, что неопределённое поведение говорит, лишь о том, что программа не соответствует Стандарту языка. Однако не означает, что она неверна, конкретные реализации имеют право доопределить поведение для частных случаев, и на них программа, допускающая такие нарушения Стандарта, тем не менее будет корректна. Самый наитипичнейний пример — что-то типа:

*reinterptret_cast<void **>(nullptr) = ccm_ram + ccm_ram_size;

устанавливающий стек по reset на STM32.

Добавлено 02.08.24, 17:10

Цитата Majestio @ 02.08.24, 03:16

Следующая программа завершится просто Segmentation fault. Кстати, а тут можно какое-то предупреждение для компилятора включить?

Неинициализированные переменные компиляторы умеют детектить настолько давно, что я уж и не знаю, как найти хоть один, который бы этого не сделал. Если же ты спросишь, почему это не ошибка, а всего лишь ворнинг, то ответ до банальности прост: это нельзя стандартизировать как ошибочное поведение, т.к. в отдельных случаях подобный под будет корректным. Поэтому это лишь неопределённое поведение. Оно следует из пункта, что UB является использование объекта, которого не существует. Прикол в том, что несмотря на отсутствие инициализирующего кода, объект всё ж может существовать. Например, уже сконструирован и прошит во флэш. Звучит странно, но это возможно и для локальных переменных на отдельных исполнительных платформах. Т.к. Стандарт не определяет размещение автоматических объектов, для них необязательно используется стек, тут надо читать ABI. И кроме того, в embedded я сам пишу линкеру скрипт, определяющий разметку адресного пространства и распределение секций исполняемого объектного кода по нему. Это тебе не hosted, где всем обычно рулит ОС.

Добавлено 02.08.24, 17:48
В общем и целом, я уже много раз говорил, что C с Плюсами многого не могут себе позволить, просто исходя из того, для какой ниши они позиционируются. Точнее для одной из каких ниш. И Плюсы активно вытесняют C оттуда, не вытеснились разве что ленивые и консерваторы. Недаром же в Стандарте есть куча всего касательно freestanding помимо hosted. И нам неленивым реформистам нынешний вид Плюсов очень нравится. Мне вот не интересен заботливый родитель, который держит за ручку и сыпет "нельзя", "осторожно", "не так", "надень шапку", "не простудись" итд итп идр. Я работаю в сфере, где иначе просто не выйдет, ибо исполнительные окружения предъявляют, и хрен ты с этим что сделаешь.
Но с другой стороны, у Плюсов позиционируемых ниш пруд пруди, и ради пары особенных жертвовать нормальными методиками и парадигмами, конечно, не резон. За C ничего не скажу, ИМХО он с C99 топчется на месте, а вот Плюсы делают всё возможное, чтобы кто если б захотел, собрал себе родителя по потребностям. Моё ~~ИМХО~~... нет, это понимание, выстраданное опытом, это уже не ИМХО... моё чёткое понимание философии Плюсов давно уж незыблемо: не тот хорошо знает язык, кто выштрудировал себя на Стандарте и либах, а тот, кто умеет договариваться с компилятором о разделе сфер ответственности. Я могу объяснить ему, куда ему можно лезть со своими "не упади" и "осторожно, поранишься", куда прям-таки нужно "стоять! придурок" и "хрен тебе, а не сладкое", а куда пусть не суётся вообще. Покажи мне ещё один язык с такой фичей.

Текущий Стандарт С++ и перспективы его развития

ЫукпШ — Fri, 02 Aug 2024 16:27:04 +0000

ЫукпШ:

Цитата Славян @ 31.07.24, 19:30

Ну или даже до 3...n значений.
Эх...

Да хоть 100500.
Просто измени подход.
Ты пытаешься писать на С.
Попробуй на С++.
Если необходимо менять сразу несколько значений одновременно,
значит.. это объект.
Объедини переменные в объект.
Перегрузи для этого объекта операцию = ( operator=() )
и все какие надо другие, если потребуются.
И всё получится.

s = A ? p : q;

Текущий Стандарт С++ и перспективы его развития

Majestio — Fri, 02 Aug 2024 03:16:52 +0000

Majestio:

Цитата Qraizer @ 01.08.24, 22:26

Осталось только пояснить, почему ты это называешь "нюансом".

Ну это можно назвать и "механизмом потенциального бага", если так будет угодно. Но, с учетом, уточнения D_KEY, если выставить абсолютно все предупреждения компилятора - это будет не совсем корректно. Т.к. разработчику хоть и разрешено такое делать, но он всеж может быть предупрежден. Но может и не быть, если забудет выставить предупреждения.

Кстати "нюансом" в С++ можно назвать и объявление без явной инициализации. На сколько я помню, в Стандарте С++ неявной инициализации посвящены отдельные подразделы? Давайте проведем сравнение.

C++

Следующая программа завершится просто Segmentation fault. Кстати, а тут можно какое-то предупреждение для компилятора включить?

#include <iostream>

class Bug {

int number;

public:

Bug(int num):number(num) {}

void hello() {

std::cout << "Bug number:" << number;

}

};

int main() {

Bug *bug;

bug->hello();

return 0;

}

Dart

В Dart все переменные по умолчанию Null-safety. Чтобы реализовать подобный код, нужно использовать модификатор ? для снятия Null-safety. Вот пример:

class Bug {

int? number;

Bug(int num) {

number = num;

}

void hello() {

print('Bug number: $number');

}

void main() {

Bug? bug;

bug.hello();

}

Но и тут просто так не прокатит. Компилятор просто выдаст ошибку:

main.dart:15:7: Error: Method 'hello' cannot be called on 'Bug?' because it is potentially null.

- 'Bug' is from 'main.dart'.

Try calling using ?. instead.

bug.hello();

^^^^^

Если же мы воспользуемся "советом" компилятора, то bug?.hello(); просто не будет выполнен, и программа завершит работу.
В общем все эти неявные неявности С++ зло :lol:

Скрытый текст

Кстати, я так и не понял, а почему отрабатывает следующий код? Тут должно быть неопределённое поведение, но программа не падает:

#include <iostream>

class Bug {

int number;

public:

Bug(int num):number(num) {}

void hello() {

std::cout << "Bug";

}

};

int main() {

Bug *bug;

bug->hello();

return 0;

}

Текущий Стандарт С++ и перспективы его развития

D_KEY — Thu, 01 Aug 2024 22:43:40 +0000

D_KEY:

Цитата Majestio @ 01.08.24, 19:34

Код отрабатывает и не мяукает

-Wconversion

Текущий Стандарт С++ и перспективы его развития

Qraizer — Thu, 01 Aug 2024 22:26:39 +0000

Qraizer: Осталось только пояснить, почему ты это называешь "нюансом".

Текущий Стандарт С++ и перспективы его развития

Majestio — Thu, 01 Aug 2024 19:34:48 +0000

Majestio: Я вот сейчас во всю изучаю Dart. Естественно изучаю его фичи и сравниваю с С++. На счет неявного приведения типов. Вот смотри пример "зла" :lol:

С++

Я спецом использовал trу-catch, просто показать, что это бесполезно, никаких исключений. Код отрабатывает и не мяукает. Выводит 44.

#include <iostream>

int main() {

int init = 300;

uint8_t value;

try {

value = init; // <--------------------------------------------------------------

std::cout << static_cast<int>(value) << std::endl; // выводит 44

} catch(...) {

std::cout << "Error" << std::endl;

}

return 0;

}

Dart

В Dart нет встроенных 8-битных чисел. Если извратится через библиотеки, то присвоение Uint8 = int совсем не прокатывает на этапе компиляции, ибо Uint8 - неконструируемый тип. Но я нашел вот такое "решение":

import 'dart:typed_data';

import 'dart:ffi';

void main() {

int init = 300;

Uint8List value = Uint8List.fromList([init]);

print(value[0]); // Выводит: 44

}

Как резюме. Dart - в принципе новодел. Но в нем учтены различные вот такие "нюансы", чтобы неявно не делалось того, чего не ждешь. Но если хочешь именно того чего не ждешь - ищи извраты :lol:

Текущий Стандарт С++ и перспективы его развития

Qraizer — Thu, 01 Aug 2024 17:30:04 +0000

Qraizer: Если ты о строгой типизации, то оно тоже зло. В Паскале у меня, бывало, голова кипела из-за его дурацких ругательств в адрес смешения байтов и интов, к примеру. Мне пофигу, что они разного размера, для меня они оба целые, и мне только это важно. Я не хочу думать о репрезентации типов, я хочу думать об из свойствах и взаимоотношениях.
С этой позиции неявные касты более чем допустимы. Беда в том, что в разных ситуациях нужны и немного разные свойства и взаимоотношения, и для стандартных типов их не настроишь. Тут да, увы. Но фактически я как раз и настраиваю эти самые взаимоотношения между типами, когда пишу метакод или там перегружаю кастующие конструкторы и/или операторы. Вот этого от Плюсов отнять никак нельзя ни в коем разе.

Текущий Стандарт С++ и перспективы его развития

Majestio — Thu, 01 Aug 2024 15:27:28 +0000

Majestio:

Цитата Qraizer @ 01.08.24, 14:45

Я так думаю, предложение в Комитет о расширении синтаксиса ?: было, но из-за озвученных проблем, ведущих, как я в раннем в посту уже обращал внимание, к сюрпризам его отклонили, ибо вероятности программеру наглючить слишком велики. Я вот как-то даже теряюсь в том, чтобы просчитать всякоразные нюансы с выбором типа ?: и даже поведения. А что, если типы в кортеже разные? А что, если типы элементов кортежей посередине и справа не все совпадают? А вдруг там вперемежку значения и разного рода ссылки? Обычные, правосторонние, константные... Как при всём этом выполнять касты с учётом правил приоритетности от identical до ellipsis?

На самом деле, автоматическое приведение типов, ИМХО - зло! Самое ламповое место для внезапных багов. И тут желательно делать явные касты, даже в ущерб большей писанины. Другое дело автоматическое выведение типов. Увидел auto или decltype, сразу маячок, мол "смотри, что выводится".

Текущий Стандарт С++ и перспективы его развития

Qraizer — Thu, 01 Aug 2024 14:45:17 +0000

Qraizer: Вообще, желаемая Славяном конструкция сама по себе довольно сомнительна. Ведь ?:, как и любое выражение, имеет результат, у которого вполне определённый тип. Даже для стандартного ?: там довольно неочевидно, что да как, и эти ?: в C и C++ отличаются из-за наличия ссылок в последнем. Например, можно написать

(cond ? a : b) = expr;

но только в Плюсах, а в C нужно так:

*(cond ? &a : &b) = expr;

Ещё интереснее, если типы между ? и : и после : разные. Там интуитивно понятные, но довольно непростые правила вывода результирующего типа, ведь он у ?: должен быть однозначно определён, не взирая на то, какое именно выражение формирует его результат.
Я так думаю, предложение в Комитет о расширении синтаксиса ?: было, но из-за озвученных проблем, ведущих, как я в раннем в посту уже обращал внимание, к сюрпризам его отклонили, ибо вероятности программеру наглючить слишком велики. Я вот как-то даже теряюсь в том, чтобы просчитать всякоразные нюансы с выбором типа ?: и даже поведения. А что, если типы в кортеже разные? А что, если типы элементов кортежей посередине и справа не все совпадают? А вдруг там вперемежку значения и разного рода ссылки? Обычные, правосторонние, константные... Как при всём этом выполнять касты с учётом правил приоритетности от identical до ellipsis?

Текущий Стандарт С++ и перспективы его развития

Majestio — Thu, 01 Aug 2024 07:28:52 +0000

Majestio: Qraizer, зацени как элегантно это (ну почти это) обыграно в ЯП Dart:

myList = [1, 2, 3, 4];

final [b, _, c, _] = myList;

print('b: $b, c: $c'); // b: 1, c: 3

var myList = [1, 2, 3, 4, 5, 6, 7];

final [a, ..., b] = myList;

print('a: $a, b: $b'); // a: 1, b: 7

Это примеры только по деструктуризации списков. Для деструктуризации записей, хэшей и классов - там тоже очень красиво :good:

А если перевести именно мой кусок с С++ на Dart, то это будет выглядеть так:

void main() {

int p1 = 3, p2 = 4, q1 = 5, q2 = 5;

bool b = true;

var (s1, s2) = b ? (p1, p2) : (q1, q2);

print("s1: $s1");

print("s2: $s2");

}

:wub:

Текущий Стандарт С++ и перспективы его развития

Qraizer — Thu, 01 Aug 2024 05:27:17 +0000

Qraizer: Я сперва тоже так хотел, но увы, структурное связывание может использоваться только при определении для инициализации. Тут же речь об обычном присваивании, т.е. однажды определив, те же сущности должно быть можно изменять присваиванием, а не определять новые. std::tie формально решает, однако он не допускает или делает крайне неудобными ситуации, когда типы данных слева и справа от = не совпадают и нуждаются в кастах. Тут легко можно запутаться, т.к. = в std::tie имеет несколько иную семантику, нежели в обычном =. У меня = сохраняет семантику, и новых сюрпризов не вносит. Но не буду спорить, что в целом этот более простой вариант имеет право быть.

Добавлено 01.08.24, 05:35
Впрочем, что у тебя, что у меня варианты грешат "лишними" буквами. Конечно с простыми {} было бы поприятнее. Подождём C++26, там на метаклассах, возможно, получится поэлегантнее.

Текущий Стандарт С++ и перспективы его развития

Majestio — Thu, 01 Aug 2024 02:21:03 +0000

Majestio: Славян, в стандарте С++17 было введено "структурное связывание" (Structured binding declaration). Поэтому твой код можно записать вот так:

#include <iostream>

#include <tuple>

int main() {

int p1 = 3, p2 = 4, q1 = 5, q2 = 5;

bool b = true;

auto [s1, s2] = b ? std::make_tuple(p1, p2) : std::make_tuple(q1, q2); // если s1 и s2 объявлены ранее, то вместо auto [s1, s2] используем std::tie(s1, s2)

std::cout << "s1: " << s1 << std::endl;

std::cout << "s2: " << s2 << std::endl;

return 0;

}

Важно чтобы количество элементов в кортежах было одинаковое.

Текущий Стандарт С++ и перспективы его развития

Qraizer — Wed, 31 Jul 2024 22:16:02 +0000

Qraizer: Ну попробуй так:

#include <iostream>

#include <tuple>

#include <utility>

template <typename ...Args>

class Multi

{

std::tuple<Args...> left;

public:

explicit Multi(Args&& ...list): left(std::tuple<Args...>(list...)){}

template <typename ...Params>

Multi& operator=(const Multi<Params...>& right)

{

auto generator = [counter = 0]()mutable { return counter++; };

auto assigner = [](int idx, auto& l, const auto& r) { std::get<idx>(l) = std::get<idx>(r); };

(assigner(generator(), left, right.left), ...);

return *this;

}

};

template <typename ...Args>

auto multi(Args&& ...args)

{

return Multi<Args...>(std::forward<Args>(args)...);

}

void check(bool b)

{

int p1 = 123, p2 = 321,

q1 = 456, q2 = 654;

int s1 = 789, s2 = 987;

multi(s1, s2) = b ? multi(p1, p2) : multi(q1, q2); // аналог того, чего хотел

std::cout << s1 << '\t' << s2 << std::endl;

}

int main()

{

check(true);

check(false);

}

Может кто до ума доведёт...

Текущий Стандарт С++ и перспективы его развития

Славян — Wed, 31 Jul 2024 19:30:14 +0000

Славян: В Си есть=допустима такая конструкция:

s = A ? p : q;

Тут как-то захотелось, чтобы она была расширяема до такого:

{s1,s2} = A ? {p1,p2} : {q1,q2};

Ну или даже до 3...n значений.
Эх...

Текущий Стандарт С++ и перспективы его развития

Majestio — Tue, 24 Oct 2023 06:36:55 +0000

Majestio:

Цитата Славян @ 23.10.23, 17:31

1. Само распаковалось на 123 МБ. Мне думается, что это сильно много, ибо BorlandC где-то под 30 МБ раньше выходил и делал весьма много.

Ну сравнил хрен с пальцем :lol: Посмотри внимательно содержимое распакованного, там только каталог с заголовками весит 30 метров. Проект живой, под современные вёнды, потому и весит столько.

Цитата Славян @ 23.10.23, 17:31

Просто открыть файл (с примером выше) и откомпилить не удалось - ей проект надо делать и всё такое. Минус.

Минус тебе ;) Можно было бы не делать поспешных выводов, а почитать документацию! Правда юзергайд надо искать на сайте. Единственное смущает, что его сделали с инсталлятором. Тем не менее, можно компилячить и линковать без использования IDE от этого проекта, чисто его утилитами командной строки.

Цитата Славян @ 23.10.23, 17:31

При сохранении проекта, закрытии его и нажатии "открыть" прога упала.

Без комментариев :blink: У меня такое не получалось. Хотя, скажу честно, я не часто эту софтину пользую.

Цитата Славян @ 23.10.23, 17:31

Резюме: сильно попытались заморочиться, им надо было бы как-то попроще быть...

Еще раз посоветую внимательнее разобраться. Но, как говорят, если нет ... на нет и суда нет. Это не моя софтина ~~мопед не мой~~, тогда да, придется тебе самому "идеал искать".

Текущий Стандарт С++ и перспективы его развития

Славян — Mon, 23 Oct 2023 17:31:21 +0000

Славян: Попробовал. Печально. А именно:
1. Само распаковалось на 123 МБ. Мне думается, что это сильно много, ибо BorlandC где-то под 30 МБ раньше выходил и делал весьма много.
2. Просто открыть файл (с примером выше) и откомпилить не удалось - ей проект надо делать и всё такое. Минус. :no-sad:
3. При сохранении проекта, закрытии его и нажатии "открыть" прога упала. :facepalm:

Резюме: сильно попытались заморочиться, им надо было бы как-то попроще быть... :whistle:
В идеале бы: TurboC x64 (кой у меня 1,3 МБ). :rolleyes:

Текущий Стандарт С++ и перспективы его развития

Majestio — Sun, 22 Oct 2023 21:47:15 +0000

Majestio:

Цитата Славян @ 21.10.23, 19:38

Какой покрохотнее компилятор посоветуете? - дабы скомпилил под Винду нечто такое:

Попробуй lcc-win

Текущий Стандарт С++ и перспективы его развития

Славян — Sat, 21 Oct 2023 19:38:10 +0000

Славян: Пардон, вопрос конечно не про то, что тема ведёт, но всё же:
Какой покрохотнее компилятор посоветуете? - дабы скомпилил под Винду нечто такое:

#include <stdio.h>

#include <math.h>

int

main()

{

for( int i=0; i<180; i+=10)

printf("sin(%d)=%f", i, sin(i*M_PI/180);

return 0;

}

Желательно под 64-бита, но желание это маленькое.

Текущий Стандарт С++ и перспективы его развития

Qraizer — Sun, 22 Jan 2023 11:32:19 +0000

Qraizer: Ну, сочувствую. Это C, тут это нормально. В язык complex не введут, для встроек это крайне нерентабельно. А вот в библиотеки ввести можно, т.к. соответствующий заголовок для freestanding можно объявить необязательным. Собственно так и сделали.
Не подходит, тогда тебе в Плюсы или в Фортран.

Текущий Стандарт С++ и перспективы его развития

Славян — Sun, 22 Jan 2023 05:58:44 +0000

Славян:

Цитата phprus @ 19.01.23, 20:02

Тогда Complex number arithmetic из C99

Что-то почитываю, и что-то не нравятся эти намёки вида:
1. Файл corecrt_math.h

struct _complex

{

double x, y; // real and imaginary parts

};

#if _CRT_INTERNAL_NONSTDC_NAMES && !defined __cplusplus

// Non-ANSI name for compatibility

#define complex _complex

#endif

2. Файл complex.h

#ifndef _C_COMPLEX_T

#define _C_COMPLEX_T

typedef struct _C_double_complex

{

double _Val[2];

} _C_double_complex;

typedef struct _C_float_complex

{

float _Val[2];

} _C_float_complex;

typedef struct _C_ldouble_complex

{

long double _Val[2];

} _C_ldouble_complex;

#endif

typedef _C_double_complex _Dcomplex;

typedef _C_float_complex _Fcomplex;

typedef _C_ldouble_complex _Lcomplex;

//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

// Macros

//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

#define _DCOMPLEX_(re, im) _Cbuild(re, im)

#define _FCOMPLEX_(re, im) _FCbuild(re, im)

#define _LCOMPLEX_(re, im) _LCbuild(re, im)

#define _Complex_I _FCbuild(0.0F, 1.0F)

#define I _Complex_I

Такое ощущение, что Си-шники очередной раз всякими макросами и пр. пытаются обмануть систему. <_<

Стандарт, - это когда можно будет написать такой код:

complex kvadrat( complex z) { return z*z; }

// далее - что угодно

#include <math.h>

#include <complex.h>

int main()

{

complex z=5;

return abs(kvadrat(z)); // ну или cabs, или ещё нечто такое

}

Добавлено 22.01.23, 06:06
Пардон, так:

return (int)abs(kvadrat(z)); // ну или cabs, или ещё нечто такое

Текущий Стандарт С++ и перспективы его развития

phprus — Thu, 19 Jan 2023 20:02:06 +0000

phprus:

Цитата Славян @ 19.01.23, 19:54

Имелось ввиду принятие его в язык Си, а не Си++.

Тогда Complex number arithmetic из C99

Текущий Стандарт С++ и перспективы его развития

Славян — Thu, 19 Jan 2023 19:54:34 +0000

Славян: Имелось ввиду принятие его в язык Си, а не Си++.

Текущий Стандарт С++ и перспективы его развития

phprus — Thu, 19 Jan 2023 19:04:14 +0000

phprus:

Цитата Славян @ 19.01.23, 18:54

Есть ли хоть какой-то шанс (хоть 1%-й), что введут в стандарт тип complex? Для комплексных чисел.

std::complex уже давно в стандарте.

Текущий Стандарт С++ и перспективы его развития

Славян — Thu, 19 Jan 2023 18:54:45 +0000

Славян: Есть ли хоть какой-то шанс (хоть 1%-й), что введут в стандарт тип complex? Для комплексных чисел.
А то, мне думается, что чуть ли не 'каждый второй' ваял такой класс/методы работы с ними, но всё же (при наличии стандарта) много ж было бы несколько проще.
Или же работает принцип "есть же в бусте, значит наплюём!"?

Текущий Стандарт С++ и перспективы его развития

Qraizer — Fri, 06 Jan 2023 01:21:35 +0000

Qraizer: Запятая вносит точку следования между левым и правым операндом, так что все сайд-эффекты после вычисления левого должны быть нейтрализованы. В твоём случае в , нет смысла, т.к. её приоритет ниже, чем у присваивания.

Текущий Стандарт С++ и перспективы его развития

Majestio — Thu, 05 Jan 2023 20:16:37 +0000

Majestio: Славян, по идее, при операции запятая сперва вычисляется левый операнд, а потом правый. В твоем случае, при таком присвоении вычисляется *b и присваивается для а, потом вычисляется b++ и отбрасывается.

А вот если бы было:

a = (*b, ++b);

То тогда, сперва бы вычислялся операнд *b, потом инкремент b, и результат инкремента присваивался бы a. Но если бы было как написано b++, инкремент был бы строго после присвоения.

Текущий Стандарт С++ и перспективы его развития

Славян — Thu, 05 Jan 2023 19:52:37 +0000

Славян: Нановопрос. (Давно уж спрашивал, но подзабыл ответ).
Если я пишу

a = *b, b++;

, то оговорено ли стандартами, что вначале всё же гарантированно будет сделана часть до запятой, а потом - то, что после запятой?
П.С. просто сие видится как "один сложный кусок в единице трансляции/интерпретации, а потому программист должен сам быть уверен, что каша в его выполнении не несёт ничего многозначного"...
:thanks:

Текущий Стандарт С++ и перспективы его развития

Majestio — Mon, 02 Jan 2023 15:50:05 +0000

Majestio:

Цитата Qraizer @ 28.12.22, 13:54

К тому же не только переменными едиными. Как быть с типами, именами структур/классов/объединений, перечислениями, функциями, пространствами имён... ?

Последнее время мне приходится работать с PHP. Поверь мне, у меня есть достаточный опыт работы и с С++, и с PHP, соответственно - некоторые оправданные временем умозаключения. Даже скорее не умозаключения - а, как говорят, мышечная память, на уровне набора исходного кода. У PHP много хорошего, которое стоило бы перенять. Но есть и "шлак" в виде "персонального" обозначения видимости методов - в С++ это сделано компактнее, естественние.

Текущий Стандарт С++ и перспективы его развития

Qraizer — Wed, 28 Dec 2022 13:54:38 +0000

Qraizer: Ну, так было изначально. В Фортране, например. А потом ещё в Бейсике. Не прижилось, потому что неудобно.
К тому же не только переменными едиными. Как быть с типами, именами структур/классов/объединений, перечислениями, функциями, пространствами имён... ?

Текущий Стандарт С++ и перспективы его развития

Majestio — Mon, 26 Dec 2022 13:32:53 +0000

Majestio:

Цитата Qraizer @ 26.12.22, 13:04

Несложно поднастроить парсер исходного кода, наделив его знанием о новых токенах, немножечко сложнее наделить граммер знанием о характеристиках этого токена. Самое сложное – не поломать существующую кодовую базу, насчитывающую 50-летнюю историю.

Кстати, хорошая и важная тема! В этом плане С++, да и ряд еще "перпендикулярных" ЯП, типа Pascal, Rust, D и подобных - будут в жутком цейтноте переработки парсеров по мере развития стандартов. То ли дело Perl :lool: Шучу, еще и PHP. Они сделали когда-то очень, ИМХО, "знаковый" шаг - разделили понятие "переменная" и все остальное. На мой взгляд, это знатно упрощает парсинги. Я когда-то, лет 20 назад, плотно сидел на Паскале (Borland Turbo, Virtual Pascal, Delphi, Free Pascal), и спустя уже n-месяцев словил себя на мысли, да какого хрена мне писать присвоение как ":="?!! Сравнений на порядки меньше присваиваний. А потом сишные {} вместо паскалевских begin-end просто манили. Так я пришел к Перлу :lool:

Ну а если без шуток и пафоса ... если бы ввели четкое ограничение в С++ как и в PHP & Perl - именовать переменные, начиная с $ - сложность разбора, ИМХО, сильно бы просела. Повторюсь - IMHO!

Текущий Стандарт С++ и перспективы его развития

Qraizer — Mon, 26 Dec 2022 13:04:05 +0000

Qraizer: Если коротко, то тебя обманули. В C/C++ нет чётких характеристик типов данных, есть только их характеристики относительно друг друга. (Единственное исключение – char. Его sizeof == 1, но даже для него нет требований в количестве бит.) В этом смысле long double должен быть не менее мощен, нежели double, и в частности характеристики этих типов могут совпадать.
Даже больше. Стандарты C/C++ не регламентируют представление типов с плавающей точкой. (В отличие от целочисленных, для которых какое-никакое представление регламентируется.) Они описаны в абстрактных понятиях мантиссы/порядка/знака с поведением, основанным на части IEEE-754. Другими словами, реализации не обязаны придерживаться IEEE-754 или чего-то подобного для репрезентации float/double/long double. Просто чаще всего железяки проектируют не конкретно под C/C++, а под RFS-стандарты, и следование IEEE для компоненты FPU обычно выгоднее, т.к. делает эти железяки вполне удобными безотносительно к инструментальным средствам и знакомыми программистам. Поэтому средства разработки тоже не выделываются и просто реализуют IEEE. Причём даже если исходно железяка не поддерживает плавающую точку, и среда вынуждена имитировать её наличие программными методами.
Что касается новых слов, то тут всё гораздо прозаичнее. Несложно поднастроить парсер исходного кода, наделив его знанием о новых токенах, немножечко сложнее наделить граммер знанием о характеристиках этого токена. Самое сложное – не поломать существующую кодовую базу, насчитывающую 50-летнюю историю. Когда, скажем, хренадцать лет назад писалась некая большая система, например Oracle DB, никаких bool, typeof, complex итд итп идр в языке не было, поэтому программисты вольны были использовать их в своих целях. Несложно представить, что бы произошло, если бы в C99 добавили bool с false и true. Причём имеющему влияние на всю систему целиком, независимо от того, каково было их распространение в исходном виде, пусть даже и сугубо локальное в отдельных функциях. Поэтому появление нового ключевого слова в языке всегда очень нежелательный процесс.

Текущий Стандарт С++ и перспективы его развития

Славян — Sun, 25 Dec 2022 16:38:07 +0000

Славян: Увидел, что 128-битное плавающее записывается как 'long double'.
А почему делают именно связку имеющихся типов, а не какой-то новый, скажем 'longdouble' ?
Так как-то парсер проще настроить, или ещё какие-то соображения есть? :-?