Skip to content

macro for "construct on first use"#1629

Merged
danielhochman merged 1 commit intomasterfrom
construct-on-first-use
Sep 13, 2017
Merged

macro for "construct on first use"#1629
danielhochman merged 1 commit intomasterfrom
construct-on-first-use

Conversation

@danielhochman
Copy link
Copy Markdown
Contributor

Implements https://isocpp.org/wiki/faq/ctors#static-init-order-on-first-use in macro form. I decided to try and take a more general approach than implement SINGLETON_STRING only. Could be convinced otherwise.

Copy link
Copy Markdown
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

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

Very nice. I like it. @htuch any thoughts?

Copy link
Copy Markdown
Member

@htuch htuch left a comment

Choose a reason for hiding this comment

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

I like it as well. Two suggestions for further boiler plate reduction that came up while reading this PR. While we can keep the base CONSTRUCT_ON_FIRST_USE macro as it's flexible and applies everywhere, we could layer on top of that:

  1. A macro to generate the method/function body when the method is only a wrapper around the macro. This will make declaring non-POD statics in classes and anonymous namespaces as simple as the POD variants.
  2. Could have a specialized string variant as well that avoids needing to std::string everywhere. This one I don't feel that strongly about.

@danielhochman
Copy link
Copy Markdown
Contributor Author

@htuch i considered the first option. some functions are static, some are const, some are override, so there's not really a prevailing form. i'll merge this in its current form and if the function becomes more prevalent in one form in the future we can create a macro then.

@danielhochman danielhochman merged commit f48e0f9 into master Sep 13, 2017
@danielhochman danielhochman deleted the construct-on-first-use branch September 13, 2017 18:00
jpsim pushed a commit that referenced this pull request Nov 28, 2022
Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: JP Simard <jp@jpsim.com>
jpsim pushed a commit that referenced this pull request Nov 29, 2022
Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: JP Simard <jp@jpsim.com>
mathetake added a commit that referenced this pull request Mar 3, 2026
**Description**

This adds a new field 'prefix' as discussed in #1639. tldr is that the
existing "version" field has been overused in various and confusing
ways. Notably for OpenAI, it was literally used for expressing the
prefix of the endpoints and not really a version in any sense.

**Related Issues/PRs (if applicable)**

Closes #1639 
Closes #1629

---------

Signed-off-by: Takeshi Yoneda <t.y.mathetake@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants