Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
G
gtkmm
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 29
    • Issues 29
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 4
    • Merge Requests 4
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • GNOME
  • gtkmm
  • Issues
  • #50

Closed
Open
Opened Jun 23, 2019 by Daniel Boles@dbolesDeveloper

Add Gtk::SelectionData::get_data_as_vector() and _as_span() ?

Gtk::SelectionData::get_data() returns a guchar*, and you need get_length() to know how much you're allowed to read from there. This is the classic problem of 'pointer plus size' with all the verbosity and pitfalls that entails: now you have to declare 2 variables and call 2 functions, might get the returned size mixed up with some other local variable, and so on. Besides - you have a raw pointer in any case, which is thoroughly discouraged.

As of now, a way to bundle the data and size together in a nicer way - if at the expense of an allocation/copy - is to use get_data_as_string(). However, if the data in the selection is really not characters, you're now using the wrong semantics (see std::byte, etc.). So, this is a slight improvement, but in terms of semantics and self-documenting it's not ideal.

I'd propose 2 improvements here:

  • Right now, we could add get_data_as_vector(), nearly the same code as _as_string() but not implying text-ness.
  • Once we require C++20, we could add get_data_as_span() -> std::span, which would avoid the mentioned allocation.

If anyone thinks these are worth doing, I can write the patches.

We might even want to think about using std::byte instead of guchar (unsigned char), but that's a far larger question.

In any case, std::span might come in handy in various other places once glibmm/gtkmm can use C++20 features.

Edited Jun 23, 2019 by Daniel Boles
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: GNOME/gtkmm#50