Skip to content

Conversation

@cacharle
Copy link
Contributor

@cacharle cacharle commented Jan 9, 2026

I'd like to be able to construct a message_t with std::vector<char> or other containers with a character as their value type.

I assume the condition to disallow this was to avoid conflicts with std::string and std::string_view.

@cacharle cacharle force-pushed the allow-message-t-contruction-from-char-containers branch 2 times, most recently from 3ecbe6a to 1bc926e Compare January 28, 2026 20:30
@cacharle
Copy link
Contributor Author

Not sure how to test this more (How to test that the std::string and std::string_view constructors are indeed called instead of the range one)..

@cacharle cacharle force-pushed the allow-message-t-contruction-from-char-containers branch from 1bc926e to 5aae699 Compare January 28, 2026 21:05
@cacharle cacharle force-pushed the allow-message-t-contruction-from-char-containers branch from 5aae699 to 17a530a Compare January 29, 2026 06:56
@coveralls
Copy link

Pull Request Test Coverage Report for Build 21468739280

Details

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage remained the same at 88.068%

Totals Coverage Status
Change from base Build 21434492698: 0.0%
Covered Lines: 930
Relevant Lines: 1056

💛 - Coveralls

@cacharle cacharle marked this pull request as ready for review January 29, 2026 07:00
@gummif
Copy link
Member

gummif commented Jan 29, 2026

Yes, so took a bit to figure recall, but the reason is string literals, so message_t("hi") is size 3, which calls the deprecated function

    template<
      class Char,
      size_t N,
      typename = typename std::enable_if<detail::is_char_type<Char>::value>::type>
    ZMQ_DEPRECATED("from 4.7.0, use constructors taking iterators, (pointer, size) "
                   "or strings instead")
    explicit message_t(const Char (&data)[N]) :
        message_t(detail::ranges::begin(data), detail::ranges::end(data))
    {
    }

So we need to be sure if we removed this overload, that the other one does not accept string literals.
Well, maybe we won't ever remove it, may mark it as = delete.
What do you think?

@cacharle
Copy link
Contributor Author

cacharle commented Jan 29, 2026

I see, what was so wrong about this string literal constructor that it was deprecated? Seems useful to me..

Marking it as = delete seems fine. I'll check if the range constructor gets called on string literals

EDIT: indeed, message_t can be constructed from a string literal with the range constructor if I comment out the deprecated one. Marking it as = delete works`

@gummif
Copy link
Member

gummif commented Jan 30, 2026

Ok. What is wrong it that it includes the null character, which I would say is unexpected. So for backwards compatibility it has to be like it is I guess.

@gummif gummif merged commit 041f755 into zeromq:master Jan 30, 2026
11 checks passed
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