Bibliotecas C++ Sãs

Objetivos gerais e posicionamento

• A biblioteca visa modelar um “mundo C++ alternativo” mais parecido com Python/Node/Zig/C: funcionalidade prática, I/O assíncrono, abstração de plataforma, binários menores, sem exceções/RTTI/stdlib.
• O autor enfatiza diversão, simplicidade e o foco nos “95% dos casos de uso” em vez de todos os casos extremos.
• Alguns veem isso como um meio-termo entre C inseguro e o libstdc++ inchado; outros consideram que “sem stdlib / sem exceções / atomics próprios” não é inerentemente “são”.

Evitar a stdlib e fragmentação do ecossistema

• Vários კომენტadores objetam que ignorar a STL garante ainda mais fragmentação e pior interoperabilidade; eles já enfrentam dificuldade com cada biblioteca C++ definindo seus próprios tipos String/Vector.
• Outros argumentam que a STL tem bagagem de design/compatibilidade (por exemplo, vector<bool>, mapas padrão, std::regex, templates pesados, builds de debug lentos) e que muitos projetos sérios já constroem sua própria biblioteca central.
• Comparação com Abseil: Abseil complementa a STL, enquanto este projeto substitui intencionalmente a maior parte dela.

Contêineres, algoritmos e estruturas de dados

• O conjunto atual de contêineres é visto como incompleto; a falta de sets, queues, deques e hash maps no estilo padrão é um bloqueio para alguns.
• Alguns usuários dependem muito de stack/deque; o autor é cético em relação a deque e prefere soluções baseadas em vector e contêineres no estilo arena.
• A biblioteca de “algoritmos” atualmente mostra bubbleSort em primeiro lugar; isso gerou críticas, e o autor esclareceu que é um placeholder e que a biblioteca vai crescer com o tempo.

Gerenciamento de memória, smart pointers e exceções

• O projeto omite deliberadamente SharedPtr/UniquePtr, com base em um princípio contra muitos pequenos objetos heap e propriedade compartilhada/indefinida.
• Alguns discordam fortemente, querendo smart pointers para todos os objetos heap e vendo-os como ferramentas de segurança com custo zero ou baixo.
• Outros descrevem padrões usando vectors/arenas, handles e grupos claros de propriedade em vez de smart pointers.
• Debate maior: muitos comentaristas defendem C++ sem exceções (frequentemente com tipos no estilo ErrorOr) como algo comum e prático; outros insistem que C++ “não pode ser livre de exceções” em qualquer sentido significativo, argumentando que todo tratamento de erro ainda são “exceções disfarçadas”.
• Preocupações com exceções de C++ incluem custo não nulo, RTTI, fluxo de controle oculto, comportamento de lançamento pouco claro pelas assinaturas de função e incentivo a código focado apenas no “caminho feliz”.

Atomics e preocupações de baixo nível

• Atomics próprios são questionados, dado que std::atomic está profundamente ligado ao modelo de memória de C++.
• A regra de não usar stdlib é o motivo imediato; o autor sugere uma futura flag opt-in para usar headers padrão onde disponíveis.

Sistema de build e macros

• Descrever builds em C++ é criticado como não sendo “são”; argumentos pró-declarativos citam escalabilidade e simplicidade.
• O autor responde que ferramentas “declarativas” populares (por exemplo, CMake) são, na prática, DSLs imperativas.
• Alguns não gostam do uso de macros do projeto por considerá-lo não “são”; o autor observa que a maioria das macros são seletores de plataforma, com macros opcionais em reflection.