Skip to content

optimized std::stack usage in simplecpp::TokenList::combineOperators() #659

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
firewave wants to merge 2 commits into
base: master
Choose a base branch
from
+1 −2
Open

optimized std::stack usage in simplecpp::TokenList::combineOperators() #659

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
3ef1187
use `std::vector` as underlying container for `std::stack` in `simple…
firewave Jun 10, 2026
a80a3ea
initialize `std::stack` with intial value instead of inserting it in …
firewave Jun 10, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 1 addition & 2 deletions simplecpp.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1031,8 +1031,7 @@ static bool isAlternativeAndBitandBitor(const simplecpp::Token* tok)

void simplecpp::TokenList::combineOperators()
{
std::stack<bool> executableScope;
executableScope.push(false);
std::stack<bool, std::vector<bool>> executableScope{{false}};

@danmar danmar Jun 20, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isn't std::vector<bool> bad to use overall in c++11..
are you sure that all usage here will work fine..

@firewave firewave Jun 20, 2026

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As this is about performance and valgrind indicates that is fine in either compiler so I see no problem.

libc++ has been adding special handling for vector<bool> and we are also not using it as a bit field here (which is the common usage for that IIRC).

@danmar danmar Jun 27, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not talking about performance nor stuff that valgrind will detect. I referred to such problems:

  • No direct references: Because individual bits don't have memory addresses, std::vector::operator[] cannot return a bool&. Instead, it returns a temporary proxy object
  • Breaks generic code: If you write a template function expecting a T&, it will fail to compile if T is bool because a proxy object cannot be bound as a standard reference
  • Pointer failures: You cannot create a bool* pointing to elements inside a vector since a pointer requires an addressable byte.
  • Concealed auto-deduction issues: If you use auto& to deduce a boolean element, you will actually deduce the proxy object, not a boolean.
  • Thread safety pitfalls: Because multiple boolean elements share the same underlying byte or machine word, writing to different adjacent bits from different threads causes data races. They logically represent different indices, but they are physically the same memory block.
  • Incompatibility with Modern APIs: Modern C++ features like std::span cannot be used directly with vector because there is no contiguous bool* storage to point at.

for (Token *tok = front(); tok; tok = tok->next) {
if (tok->op == '{') {
if (executableScope.top()) {
Expand Down
Loading