Skip to content
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.

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

Furi: update string documentation #3803

Merged
merged 2 commits into from
Jul 29, 2024
Merged

Furi: update string documentation #3803

merged 2 commits into from
Jul 29, 2024

Conversation

skotopes
Copy link
Member

@skotopes skotopes commented Jul 23, 2024

What's new

Verification

  • See docs

Checklist (For Reviewer)

  • PR has description of feature/bug or link to Confluence/Jira task
  • Description contains actions to verify feature/bugfix
  • I've built this code, uploaded it to the device and verified feature/bugfix

Copy link

github-actions bot commented Jul 23, 2024

Compiled f7 firmware for commit 00b18093:

@CookiePLMonster
Copy link
Contributor

CookiePLMonster commented Jul 23, 2024

I'll make use of this PR to raise a point - is there any practical purpose to furi_string_alloc_move (and furi_string_move) in its current form, where it destroys the source string? It seems like it's equivalent to just reassigning a FuriString pointer and then clearing the source pointer.

Making it not destruct the source string (just empty it) may be more productive, as then it'll allow for patterns where e.g. a temporary string is being built in a loop, and results are being moved out to destinations after every step. In pseudocode, I mean something like:

FuriString* tmp = furi_string_alloc();
while (results_not_done) {
   // Do stuff to tmp

   results.push_back(furi_string_alloc_move(tmp));
}
furi_string_free(tmp);

@skotopes
Copy link
Member Author

I'll make use of this PR to raise a point - is there any practical purpose to furi_string_alloc_move (and furi_string_move) in its current form, where it destroys the source string? It seems like it's equivalent to just reassigning a FuriString pointer and then clearing the source pointer.

Making it not destruct the source string (just empty it) may be more productive, as then it'll allow for patterns where e.g. a temporary string is being built in a loop, and results are being moved out to destinations after every step. In pseudocode, I mean something like:

FuriString* tmp = furi_string_alloc();
while (results_not_done) {
   // Do stuff to tmp

   results.push_back(furi_string_alloc_move(tmp));
}
furi_string_free(tmp);
image

@CookiePLMonster
Copy link
Contributor

I'll make use of this PR to raise a point - is there any practical purpose to furi_string_alloc_move (and furi_string_move) in its current form, where it destroys the source string? It seems like it's equivalent to just reassigning a FuriString pointer and then clearing the source pointer.
Making it not destruct the source string (just empty it) may be more productive, as then it'll allow for patterns where e.g. a temporary string is being built in a loop, and results are being moved out to destinations after every step. In pseudocode, I mean something like:

FuriString* tmp = furi_string_alloc();
while (results_not_done) {
   // Do stuff to tmp

   results.push_back(furi_string_alloc_move(tmp));
}
furi_string_free(tmp);
image

Contrary to the C++ choice of using "conservative move" semantic (you still need to call the destructor of a moved object in C++) M*LIB implements a "destructive move" semantic (this enables better optimization).

This explains my confusion, thanks!

@hedger hedger added the Documentation Everything related to docs & code comments label Jul 23, 2024
@hedger hedger merged commit 360005c into dev Jul 29, 2024
11 checks passed
@hedger hedger deleted the aku/string_docs branch July 29, 2024 13:06
ofabel pushed a commit to ofabel/flipperzero-firmware that referenced this pull request Sep 26, 2024
Co-authored-by: hedger <hedger@nanode.su>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Documentation Everything related to docs & code comments
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Documentation: furi string
3 participants