When I published my previous post on mastodon,
Sebastian pointed out 1 that using #[cfg]
is better than cfg! macro.
Documentation explains that :
cfg!, unlike #[cfg], does not remove any code and only evaluates to true or false. For example, all blocks in an if/else expression need to be valid when cfg! is used for the condition, regardless of what cfg! is evaluating.
Thanks, Sebastian!
We all know we shouldn’t use print debugging, and yet we all do 😉 1
Jokes apart, when I’m still developing the code, I use the debugger where possible. But sometimes, I want to keep certain print statements to verify runtime behaviour, especially when rolling out new feature and when there are too many variations (some of them unknown) in incoming data.
I’m aware, logging is the right way to handle this (with loglevel set to
debug or something), but it seems too much when developing toy projects.
At first, I assumed since we’ve declared the capacity upfront, it would be maximum capacity of the Vec
Turns out, since Vec is expected to shrink and grow, as needed, there is no maximum capacity for Vec
It just ensures that “sufficient” memory is allocated to the Vec, such that memory reallocation is not required.
On the other hand, if you need more that what you declared with with_capacity, you will get it, but there will need
to be reallocation (of memory), so it will be inefficient.
Today I learnt that certain rust code can be marked such that it is compiled only for specific platform.
This makes sense for low level libraries that provide platform-specific functionality that is not available on other platforms.
This is achieved by tagging the function with #[cfg(target_os = "xyz")]
Here xyz can be one of the following :
Similar to target_os, here are other options :
Put @microblog.desipenguin.com@web.brid.gy in the search box.
Thanks to Bridgy.fed this site automatically gets it’s own mastodon account.
Following this account is like subscribing to the RSS feed (I think 😄)
Few days ago, I heard about this on some podcast (maybe changelog ? 🤷♂)
I have been using similar notation for my commits - even for this blog1 - but I did not know it is a specification.
The idea is that very first word of the commit message should indicate what sort of commit is it.
Most common ones are : fix, feat (To indicate bugfix and a feature)
Other useful ones are: docs, style, refactor, test
At least for floating point numbers, it does not crash/panic! 🤷♂
fn main() {
let x = 10.0;
let y = 0.0;
println!("{:?}", x/y);
}
This above code returns inf
But if we change the number to int, compiler catches this 1 at shows the following error:
error: this operation will panic at runtime
This is a contrived example. Instead of static values, if these were passed at runtime, it would (should?) panic ↩︎
I got myself a new mobile phone after almost 5 years.
My old one is still going strong.
But there are no OS updates. I’m stuck at Android 10
Some random facts about the new phone - in no specific order
Since the phone is 5 years newer, it is better - by default - in so many categories.
I’m planning to put custom ROM on the older phone and give it to my kids, for occasional game or for web search for their studies etc.
We have a bicycle which was unused for months.
I got it fixed (some oiling, check tyres, brakes etc.) for all of Rs. 90 😄
Today, I rode bicycle for the first time after decades.
Not for long. Maybe 15 minutes.
Since I was not used to it, my legs hurt 😄
But it felt great to ride a cycle after so many years.
One of the strength of Rust is memory management. This also leads to compiler errors related to move or borrow
When we assign an existing variable to new variable, two things can happen.
Either the data is copied - in that case we can use both old and the new variable without worry. 1
Or data is moved - now we can only use the new variable, as the old variable is “out of scope”. But there is a way to access both the new and old variables. But in that case we have to explicit.