#cpp

Day 37.

Иногда можно хулиганить.

Как????

Сейчас расскажу.

Давайте возьмём такой странный пример:

#define SCAN(...) __VA_ARGS__
#define EMPTY()
#define LOOP_INDIRECTION() LOOP
#define LOOP(x) x LOOP_INDIRECTION EMPTY()() (x)

SCAN вы знаете. EMPTY() раскрывается в пустоту. А два последних понятно во что раскрываются. Там прям справа написано. Но как это работает, мы сейчас рассмотрим.

Давайте сначала поймём, во что раскроется LOOP(1):

LOOP(1)
// 1 LOOP_INDIRECTION EMPTY()() (1)
// 1 LOOP_INDIRECTION EMPTY()() (1) // раскрываем EMPTY()
// 1 LOOP_INDIRECTION () (1)

Вот тут важный момент: между LOOP_INDIRECTION и () есть пробел. А значит препроцессор воспринимает это как два отдельных токена. из-за чего раскрывать LOOP_INDIRECTION() он не станет. Так что мы на этом останавливаемся.

Теперь давайте просканируем:

SCAN(LOOP(1))
// SCAN(1  LOOP_INDIRECTION () (1))
// 1 LOOP_INDIRECTION()(1) // токены рассматриваются как один поток
// 1 1 LOOP_INDIRECTION () (1)

То есть получили уже 2 единицы в начале.

Обобщая идею можно реализовать EVAL:

#define EVAL(...)  EVAL1(EVAL1(EVAL1(__VA_ARGS__)))
#define EVAL1(...) EVAL2(EVAL2(EVAL2(__VA_ARGS__)))
#define EVAL2(...) __VA_ARGS__

И для

EVAL(LOOP(1));

мы получим единицы на всю глубину EVAL:

1 1 1 1 1 1 1 1 1 1 1 1 1 1 LOOP_INDIRECTION ()(1)

Можно в итоге написать макрос, которые из

E3(LOOP(f,1,2,3,4,5,6,7,8,9,END))

раскроется в

// f(1) f(2) f(3) f(4) f(5) f(6) f(7) f(8) f(9)

@thisnotes. Patreon, Boosty.
Спасибо Artyom Garkavy и niki4smirn.

#cpp

Day 38.

Есть целая отдельная библиотека Boost.Preprocessor, в которой используется довольно много подходов, на которые мы с вами смотрели.

Код там забористый.

@thisnotes. Patreon, Boosty.
Спасибо Artyom Garkavy и niki4smirn.

#cpp

Day 39.

Начинаем уровень 6.

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

Давайте реализуем list:

#define LIST_HEAD(a,b) a
#define LIST_TAIL(a,b) b

LIST_HEAD(1,(2,(3,))) // 1
LIST_TAIL(1,(2,(3,))) // (2,(3,))

И на самом деле этого достаточно.

Можно научиться проверять на конец:

#define TUPLE_AT_1(x,y,...) y
#define CHECK(...) TUPLE_AT_1(__VA_ARGS__,)
#define LIST_END(...) ,0
#define LIST_IS_END(x) CHECK(LIST_END x,1)

LIST_IS_END((9,))          // 0
LIST_IS_END(LIST_TAIL(9,)) // 1

Теперь вспомним пост про реализацию BOOL и IF и поймём, что это можно использовать как условие в тех конструкциях.

@thisnotes. Patreon, Boosty.
Спасибо Artyom Garkavy и niki4smirn.

#cpp

Day 40.

Представьте, что вы хотите на препроцессоре писать не макросами, а на каком-нибудь Lisp-like языке программирования (ну просто попытайтесь представить, что вы этого хотите).

Есть такая библиотека ORDER_PP:

ORDER_PP(8to_lit(8add(8, 5))) // 13

или

ORDER_PP(
  8to_lit(
    8mul(
      8add(2,3),
      8add(4,5)
    )
  )
) // 45

Язык на самом деле мощнее. Можно объявлять переменные, писать функции, рекурсию, списками пользоваться, ленивые вычисления мутить (вроде как).
Можем вот факториал вычислить (это всё будет вычислено препроцессором!):

ORDER_PP
(
(8define FACT
  (8fn (8N)
    (8if (8zero 8N)
         1
         (8mul 8N
               (FACT (8sub 8N 1)))))
))

ORDER_PP(8to_lit (FACT 6))

(возможно оно не скомпилируется, но суть такая)

Как это работает? И что это за 8 перед командами?

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

Во время лексического анализа препроцессор не знает ни про какие числа. Он знает про токены языка. А они бывают разные:

identifier
pp-number
string-literal
punctuator
... and others

Нас интересует pp-number. Ниже примеры того, что является pp-number:

123
1e10
0xFF
3.14
1E+10
0x123ABC

1abc
123hello
8X
8let
8mul
0foobar

И пусть вторую пачку компилятор не сможет разобрать как литералы, это всё равно pp-number (данные, а не identifier). А макросы ищутся только среди идентификаторов.

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

ORDER_PP пользуется этой возможностью хранить программу как данные и где-то внутри библиотеки в нужный момент происходит склейка pp-numbers в полноценные макросы:

ORDER_PP_8mul // for example

После этого перехода в мир стандартных макросов уже начинается жоское вычисление всего вокруг.

Чего только не напридумывают.

@thisnotes. Patreon, Boosty.
Спасибо Artyom Garkavy и niki4smirn.

#cpp

Day 41.

Кроме хорошо знакомого вам assert был и ещё никак не связанный с первым #assert.

Подразумевалось, что #assert будет помогать генерировать какие-то утверждения для препроцессора. Например

#assert cpu(x86)
#assert os(linux)
#assert this(notes)

после чего вы могли писать

#if #cpu(x86) // true
...
#if #os(linux) // true
...
#if #this(notes) // true
...
#if #os(win) // false
...

То есть с помощью #assert препроцессор записывал в отдельную табличку верные утверждения, а потом умел сообщать, есть ли такой факт. Причём проверка проводилась для predicate(argument).

Ещё утверждения можно было отменять с помощью

#unassert cpu(x86)

И больше это неправда.

Фактически это примитивная логическая база знаний.

Выше я писал «был», потому что в C11 #assert и #unassert не стало. Потому что фактически почти никто не реализовал. Все писали примерно:

#define CPU_X86 1

#if CPU_X86
#ifdef CPU_X86

@thisnotes. Patreon, Boosty.
Спасибо Artyom Garkavy и niki4smirn.

#cpp

Day 42.

Представьте такую ситуацию: Вы мегаумный программист, разрабатывающий инфру в какой-нибудь компании. И Вы хорошо понимаете, какие ошибки совершают ваши коллеги чаще других. Вы бы хотели оградить коллег от частых ошибок. Например, запретить пользоваться какой-то функцией из стандартной библиотеки и сообщить в ошибке альтернативу.

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

Для решения таких задач можно подменить стандартный хедер на свой.

Для начала его надо реализовать:

// my_headers/string.h

#pragma once

#include <string.h> // подключаем системный хедер

#define strcpy(...) static_assert(false, "Use strncpy instead")

И начать компилировать вашу программу как-нибудь так:

clang++ -I my_headers ...

(тут мы указываем путь к хедерам, так как наш my_headers расположен первым, то и проверяться он будет первым)

Или через cmake как-то так:

target_include_directories(
    my_target
    BEFORE PRIVATE my_headers
)

Теперь пользователь будет писать

#include <string.h>

и вместо системного хедера подключится ваш. Круто?

А видите ли вы какую-нибудь проблему в реализации my_headers/string.h?

Например, что внутри мы тоже подключаем <string.h>, который (согласно нашей сборке проекта) будет искаться в my_headers/string.h.

Какая-то рекурсия!

Для решения этой проблемы некоторые компиляторы реализовали нестандартное расширение #include_next. Достаточно в нашем хедере использовать именно его:

#include_next <string.h>

#include_next будет инклудить указанный файл, но поиск файла будет осуществляться после того каталога, в котором находится текущий файл. То есть в нашем примере мы сразу пропустим директорию my_headers и начнём искать где-то ещё. Если у вас нет других string.h до системных хедеров, мы получим нужный файл из стандартной библиотеки.

@thisnotes. Patreon, Boosty.
Спасибо Artyom Garkavy и niki4smirn.

#cpp

Day 43.

Так как писать код на препроцессоре бывает неимоверно неприятно, есть тулы в помощь. Например, ppstep, который позволяет интерактивно (пошагово) разбираться в раскрытии ваших макросов и всего вокруг.

@thisnotes. Patreon, Boosty.
Спасибо Artyom Garkavy и niki4smirn.

#cpp

Day 44.

Сегодня ссылка, где Paul Mensodines скрупулёзно поясняет механизм раскрытия макросов: How macro expansion works.

@thisnotes. Patreon, Boosty.
Спасибо Artyom Garkavy и niki4smirn.

#cpp

Day 45.

Мы уже обсуждали, как сделать LIST, но есть и более свойственная препроцессору структура данных: sequence.

Sequence это просто набор элементов в скобках:

(1)(2)(3)(4)(5)

Тут 5 элементов. Но конечно мы не ограничиваемся числами:

(a)(b)(c)
(int)(double)(bool)
(1)(2)()((),w,())(awoo())(())

Основные операции иногда реализуются просто:

#define SEQ_PUSH_FRONT(x, seq) (x) seq
SEQ_PUSH_FRONT(z, (a)(b)(c)) // (z)(a)(b)(c)

#define FRONT(seq) FRONT_I seq
#define FRONT_I(x) x
FRONT((a)(b)(c)) 
// FRONT_I(a)(b)(c)
// a

В конце на самом деле надо ещё как-то убрать (b)(c), но сейчас это не так важно.

Другие операции могут быть чуть сложнее, но концептуально там ничего такого. В любом случае самим реализовывать вам не нужно. Берите Boost Preprocessor и крутите

BOOST_PP_SEQ_SIZE((a)(b)(c)) // 3
BOOST_PP_SEQ_ELEM(1, (a)(b)(c)) // b
BOOST_PP_SEQ_PUSH_BACK(seq, x)

Там ещё и итерироваться можно, но про это завтра.

@thisnotes. Patreon, Boosty.
Спасибо Artyom Garkavy и niki4smirn.

#cpp

Day 46.

Шагаем на ступеньку номер 7.

Мы бы могли с вами реализовать итерацию по sequence, но иногда лучше вовремя остановиться и заиспользовать что-то готовое:

#define PRINT(r, data, elem) elem

BOOST_PP_SEQ_FOR_EACH(
    PRINT,
    _,
    (a)(b)(c)(d)
)

Получим

a b c d

Как это реализовано?

Ну вот примерно как вчера откусываете по одному токену из начала и применяете к нему «функтор». Чего непонятно-то???

@thisnotes. Patreon, Boosty.
Спасибо Artyom Garkavy и niki4smirn.

#cpp

Day 47.

Я уже упоминал Paul Mensodines, который написал огромное письмо про механизм раскрытия макросов.

И упоминал про Boost.Preprocessor.

Вот Paul когда-то написал chaos-pp — настоящая глыба в мире препроцессорных библиотек. Там вообще всё что хотите. Рекурсия, высокоуровневые алгоритмы (MAP, FOLD, FILTER, ZIP и др.), лямбды и частичное применение макросов, разные контейнеры (sequence, tuple, list).

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

Но как артефакт кайфово.

@thisnotes. Patreon, Boosty.
Спасибо Artyom Garkavy и niki4smirn.

#cpp

Day 48.

Если вам нужна сравнительно мощная, но более современная альтернатива chaos-pp, стоит взглянуть на Metalang99.

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

Так что Metalang99 — ваш второй выбор (после Boost.Preprocessor).

@thisnotes. Patreon, Boosty.
Спасибо Artyom Garkavy и niki4smirn.

#cpp

Day 49.

Одна из моделей, которую можно реализовать на макросах (хотя мы выяснили, что можно любую видимо) — continuation machine. Фактически это штука, в которой вы можете построить пайплайн работы с данными (но такими словами про неё не говорят, слишком современно). На картинке ниже страшная реализация для простого кейса работы с регистрами (разбирать мы ёе не будем, я хочу просто подышать.....).

Кстати репозиторий это что-то вроде оптимизированного интерпретатора Brainfuck. Есть и другие альтернативы: bfi, CPP_COMPLETE.

@thisnotes. Patreon, Boosty.
Спасибо Artyom Garkavy и niki4smirn.

#cpp

Day 50.

Макросы можно класть на и доставать из (со) стека:

#define PRAMGA(...) _Pragma(#__VA_ARGS__)
#define POP(m) PRAMGA(pop_macro(#m))

#define X 1 POP(X)
#pragma push_macro("X")
#define X 2 POP(X)
#pragma push_macro("X")
#define X 3 POP(X)
#pragma push_macro("X")
#define X 4 POP(X)
X // 4
X // 3
X // 2
X // 1

Не уверен, что понимаю, зачем это нужно.

@thisnotes. Patreon, Boosty.
Спасибо Artyom Garkavy и niki4smirn.

#cpp

Day 51.

Есть ещё несколько интересных репозиториев, связанных с препроцессором:
• datatype99 (фактически синтаксический сахар для генерации типов, но с дополнительными плюшками вроде паттерн матчинга)
• interface99 (Golang/Rust inspired интерфейсы для C99)
• boline (integer arithmetics with base 16).

У последнего код с вайбом ASCII-art.

И есть ещё подгон от подписчика про расширение в clang, позволяющее делать макросы рекурсивными. Названо оно __THIS_MACRO__:

#define fold_left(op, head, ...)(__VA_OPT__(__THIS_MACRO__(op,__VA_ARGS__)op)head)

fold_left(+, 1, 2, 3, 4) // раскрывается в ((((4)+3)+2)+1)

@thisnotes. Patreon, Boosty.
Спасибо Artyom Garkavy и niki4smirn.

#cpp

Привет.

Сегодня последний day 52 марафона.

Я знаю, что кому-то он поднадоел. Не зря от меня отписалось больше полусотни человек.

Мне тоже надоело, если честно.

Если вдруг вы не узнали/не знали, марафон был основан на C++ Preprocessor Iceberg. Я в целом шёл от начала почти по каждому пункту, скипая что-то, что выглядит совсем мутным и невнятным, что я не смог заставить работать или не смог осознать. Попутно старался дополнять своим ресёрчем. Постов фактически вышло на пару десятков меньше, чем пунктов в оригинальном источнике. Мы примерно на половину задели Deep water и совсем не задели The abyss. К концу я уже высох от темы и решил, что душить себя не очень полезно. Лучше чем-то в радость позаниматься. Так что заинтересованные могут доисследовать самый низ айсберга.

Расскажите в комментах, как вам. Надо такое делать вообще ещё когда-нибудь? На какие темы? Или нахер и лучше ограничиться обычными форматами?
Не факт конечно, что я ваше мнение учту, но мне хочется его знать.

Если не хотите писать открытым текстом, то вот варианты quite feedback:
🔥 — круто, можно повторять
🥴 — круто, можно повторять, но слишком долго
🤯 — круто, лучше не повторять
🌚 — не круто, лучше не повторять.

Ниже собрал ссылочки для удобства. Пересылайте друзьям, мамам и папам. Пользуйтесь в будущем сами.

Above the iceberg:
• #include
• include guards
• #pragma once
• #if
• заворачивание в скобки
• do-while
• ARRAY_SIZE и sizeof

On the iceberg:
• stringification operator
• token concatenation operator
• __VA_ARGS__
• #undef
• #error
• comments concatenation
• X-macro

Below the water:
• FILE and LINE
• DATE and TIME
• #line
• триграфы и иже с ними
• _Pragma
• -E

Middle of the iceberg:
• COUNTER
• CONCAT
• #elifdef #elifndef
• #embed
• SCAN
• лимит на макросы
• mcpp
• перегрузка макросов
• default args в макросах

Bottom of the iceberg:
• blue paint
• BOOL, IF
• INC/DEC
• LOOP
• Boost.Preprocessor

Below the iceberg:
• LIST
• ORDER_PP
• #assert
• #include_next
• ppstep
• how macro expansion works
• sequence

Deep water:
• итерация по sequence
• chaos-pp
• Metalang99
• не знаю точно что это
• push/pop макросов
• ещё несколько ссылочек

#cpp и не только.

НАПОМИНАЮ, что 1ого августа будет Back to Back: в Москве back to back трек + C++ трек, в Ереване только back to back, а в Белграде только C++ one.

Программу на плюсовый трек мы собрали сочную. Старались, честное слово. Коллеги по цеху на Back to Back тоже интересного выбрали.

Меня, дай бог всё будет хорошо, сможете найти в Белграде. Можем с вами за здоровье Страуструпа выпить ракии (хотя я ещё её не пробовал, может и не моё).

Буду стараться за неделю после конфы выдать трип репорт.

У вас ещё есть время зарегистрироваться!

#cpp

Back to Back 2026 (который был C++ Zero Cost Conf).

Я выбрал несколько докладов из всех 4х треков. Если доклад не выбран, это не значит, что он плох. Возможно он не зашёл мне темой, а возможно не так интересен, как другие. Навалить вам просто все доклады мне не очень хотелось.

0. 9 миллиардов этажей concurrency. Андрей Аксёнов.

Доклады бывают в разных форматах. Этот доклад не должен глубоко раскрывать тему, на мой взгляд. Он скорее должен дать вам много разных слов, с которыми вы должны пойти разбираться.
Ну и это Андрей Аксёнов со своей подачей. Хулиганской.

1. Трассирую и профилирую — бесплатно. Александр Емеленко.

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

2. Building the tiniest pomodoro app. Miloš Anđelković.

Хороший доклад для понимания техник уменьшения размера ваших бинарных файлов. От отказа от зависимостей и правильной компиляции до переписывания всего совсем иначе.

3. Profile-Guided Optimisation. Taming the pitfalls in the name of performance. Alexander Zaitsev.

Я особо раньше не смотрел доклады про PGO, потому что они сразу куда-то в дебри уходят. Как будто для них нужен уже солидный такой контекст.
А вот тут не так. Тут Alexander рассказывает про базовые понятия, проблемы, кто что умеет, как делать, профит. Такое солидное введение в тему.

4. Google's Highway Library for SIMD Programming — Does It Deliver the Promise? Ivica Bogosavljevic.

Ivica рассказывает про гугловую SIMD либу. В местах, где она хороша (как и заявлено), и где не очень хороша и не справляется со своими задачами (или справляется, но не очень хорошо).

5. Microseconds in Network Code. Artur Soloviev.

Artur рассказывает про несколько вариантов работы с сетью, чтобы было быстро.

6. To 264 and Beyond: Modern Approaches to Distributed Identifier Algorithms. Mons Anderson.

Тут Mons рассказывает про огромное количество (штук 15 может) разных distributed ID. Их устройство, некоторые принципы работы, tips & tricks для разработки своего решения. Плюсы и минусы разных подходов.

Как один из критериев ещё обсуждалась длина закодированого ID. Это важно, ведь если ваши ID в огромнющей системе сделать на байт короче, это может вылиться в Гигабайты экономии.
А ещё это важно, потому что некоторые строки (покороче) попадают в SSO буфер, а некоторые нет. Мета, например, когда-то ровно по причине увеличения SSO буфера переходила на свой fbstring. А потом вернулась на стандартную строку, когда clang научился давать 23 символа в SSO буфере из коробки.
Возможно, вы можете пойти и поменять тип для хранения ваших ID на small_string или как оно у вас называется. И получить какой-нибудь профитик.

#cpp

С марафоном препроцессорным я подотстал от происходящего в мире. Потому некоторые штучки-дрючки довольно поздно выкладываются. Мда.

Ну и ладно! Я что, СМИ? У меня жена ваапче-то есть. Некогда мне тут сидеть круглыми сутками, да следить за новостями бесконечно.

Смотрели документалку про C++?

The Story of C++ : The World's Most Consequential Programming Language | The Official Story.

А после можно последующее обсуждение:
Inside C++'s Biggest Challenge | Panel Discussion with Bjarne Stroustrup, Herb Sutter & More.

Вообще ощущения от фильма кайфовые. Сделано дорого-богато (HRT всё-таки имеют денюжку в кармане, могут себе позволить). Местами ощущалось, что это чуть ли не документалка про какое-то ужасное событие. Стихийное бедствие или терракт. Не знаю почему. Может быть вайб того, как снято. Музыка на фоне.

Но вообще-то довольно познавательно. Интервью с важными, даже ключевыми, фигурами в развитии языка дают веса истории. Хорошо передана история 80х и 90х (хотя я появился после, так что мне можно рассказать что угодно). Интересно рассказана история STL (хотя явно не достаточно глубоко, и на самом деле там были какие-то конфликтные моментики). Есть забавные истории.

Чтобы сформировать более сбалансированное мнение, я заодно почитал там-сям обсуждения. В основном предъяв несколько:
• история слишком official и почти полностью от лица участников ISO комитета
• про Boost почти не упоминают, хотя он сильно повлиял на развитие языка
• в 2000х был кризиc, который упоминается мимоходом, хотя на самом деле тогда это была огромная проблема. Драму сгладили
• молчат про экосистему, хотя это одна из главных проблем языка. Документалка в целом на языке сосредоточена

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

В итоге это скорее история C++ от лица создателей C++, но не исчерпывающая история языка. Чтобы получить честную, полную картину, хорошо бы послушать мнения оппонентов.

Зацените, как дед кайфово в шляпе выглядит.

@thisnotes. Patreon.
Спасибо Artyom Garkavy и niki4smirn.
На правах мегапатрона послание подписчикам от Artyom Garkavy:

Try it today: google.com.

#cpp

ACCU on Sea 2026.

Помните, я в июне на конфе был? Пора отдавать долги.

Конфа проходила в Folkestone. Это город на юге UK. Прям у моря, так что название не врёт.

Раньше это было две отдельные конференции: ACCU conference (более общепрограммистская, пусть ACCU непосредственно с C и C++ и связано) и C++ On Sea. Мне несколько раз независимо сказали, что объединились они стратегически: сложно таскать участников дважды в год на похожие мероприятия, да ещё и денюжек у всех мало, так что от сотрудничества все только выиграют. Охотно верю.
Если в России подобные конфы часто делают проф организации, которые на этом деньги зарабатывают, то тут это скорее сборище энтузиастов. Надеюсь, они не работают в минус.

Сравнить с предыдущими конфами той же серии у меня конечно не получится. Но я могу сравнить с СНГшными альтернативами.
Во-первых, очень непривычно ездить на длинные конфы. Самая большая до этой у меня была на 2 дня. А тут все 4, и это я 2 дня воркшопов пропустил.
Во-вторых, очень непривычно ездить (на поезде), а не на самолёте летать. То есть уже кпд повыше (время в пути относительно времени на конференцию).
В-третьих, просто потому что это такая локация, вдали от Лондона (там дорого, причём и участникам, и организаторам), город отдаёт чуть больше Англией. Вот этой дефолтной обычной. У жил в гостинице старше моих дедов, с двумя кранами (для холодной и горячей воды) и под крышей. Вокруг всё такое деревянное. Короче даёт вайбом.
Морюшко рядом просто замечательное. За пару дней до конференции мы приезжали просто город посмотреть. Кроме огромного количества мошек у воды нареканий не было. Симатишно.

В силу того, что конференция так-то довольно большая и известная, было очень много известных чуваков. Вот лист рандомных имён, на которые удалось посмотреть вживую, с кем-то даже пообщаться: Andrei Alexandrescu (я пожал ему руку и хотел её больше никогда не мыть, но жена не разрешила), Jason Turner, Matt Godbolt, Walter E Brown, Klaus Iglberger, Nicolai M. Josuttis, Victor Ciura, Andreas Fertig, Sandor DARGO, Hana Dusíková, Timur Doumler, Arne Mertz и много других (коллег по компании не упоминаю). Они все настоящие, как и я настоящий. Очень необычно видеть людей вживую спустя 8 лет просмотров по телевизору.

Кормили дефолтно по-английски.
Стенды компаний вокруг были в основном трейдинги разного направления.
Вечерние активности были довольно интересными. Квиз особенно. Мы с коллегой вдвоём его начинали и для усиления привлекли группу из 5 случайных мужчин с пивом в руках. Победить нам это не помогло, но усилиться точно.
Walter E Brown в какой-то из вечеров устраивал Movie Night. Это он показывал на большом экране прикольные видосы с вайбом из ВК 2015. Визуализации сортировок. Как забавно хор имитирует звуки виндовс. Короче дедовские мемы.

Очень понравился формат лайтнингов.
Я несколько лет на C++ Russia с ними выступал и посмотрел на них тут. Отличия радикальные. На C++ Russia это сайдактивность где-то там в уголке, пока в главном зале большинство участников мощно пьют пиво и в конкурсах участвуют (по крайней мере в прошлые года, в этом я не посещал). На тебя приходит посмотреть человек 10-15, лайтнинги не blazingly fast (до 20 минут). Их мало.
На ACCU On Sea лайтнинги до 5 минут. Строго. Если превышаешь тайминги, у тебя отберут микрофон силой. Они идут час после докладов (то есть 12-14 лайтнингов успеваем) и они каждый день. Фактически за 3 вечера ты слушаешь ещё дополнительные ≈35 микродокладов на самые разные темы: рандомные плюсовые приколы, рекламы стартапов, астрономия, как клаву под себя собрать, про ос, какой-то чувак просто песню спел, даже не про C++. И это всё происходит в главном зале, куда фактически все приходят изначально, а значит у тебя есть большая аудитория. Гораздо более энергичный и заряженный формат. Рекомендую попробовать, друзья из джуг ру груп.