this post was submitted on 21 Apr 2024
65 points (95.8% liked)

Rust

6133 readers
67 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

[email protected]

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 2 years ago
MODERATORS
65
submitted 8 months ago* (last edited 8 months ago) by [email protected] to c/[email protected]
 

This is my first project in rust, called: since. A small tool to filter logfiles or any other files with a timestamp in it, by a given timestamp.

For example:

since 1h /var/log/messages prints all lines from the last hour. since 00:00 /var/log/messages prints all lines since 00:00.

It would be nice if you could take a look at the code. What would you change, what should I change?

I’m not a professional programmer, this is just a hobby, but I want to learn as much as possible.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 7 points 8 months ago (1 children)

@larix @Ephera it's better to return an Option<&str> as a String may DeRef to &str.

For example

self.name.as_deref()

[–] [email protected] 2 points 8 months ago (2 children)

Hmm, interesting. The documentation tells me, it creates a new Option value, and allocating memory every time someone just wants to look at a value could be pretty bad.

But I guess, an Option of a reference never needs to allocate memory, because it'll either be a pointer to a value (Some) or a pointer to null (None). Right?

Well, that explains why it's technically possible.
As for why Option<&str> is preferrable then:
It hides away your internals. Your caller should only care whether they can get the value or not (Some vs. None), not what the precise reason is. That reason or your internal structure might change.

@larix

[–] [email protected] 2 points 8 months ago

 Well, that explains why it's technically possible.

As for why Option<&str> is preferrable then: It hides away your internals. Your caller should only care whether they can get the value or not (Some vs. None), not what the precise reason is. That reason or your internal structure might change.

Yes, that makes sense too. Great!

I’ve updated the code as recommended.

@[email protected] @[email protected]