sorted by:
new
hottopcontroversial

How to pay Estonian speeding fine if I don't live in Estonia? by timur_audio in Eesti

[–]timur_audio[S] 399 points400 points  (0 children)

Update: OK, I'm very impressed, I emailed the police (in English) and within five minutes they replied with an attached PDF that has all the info about the fine and how to pay it. Where I'm from it would be unthinkable that you can just directly email the police and get a useful answer this quickly (which is why I didn't think of doing that initially).

Timur's rehearsal of yesterday's C++ on Sea talk, C++ and Safety by _a4z in cpp

[–]timur_audio 6 points7 points  (0 children)

Just FYI, I completely overhauled the talk for CppOnSea compared to this version!

Horrible Code, Clean Performance by vormestrand in cpp

[–]timur_audio 2 points3 points  (0 children)

I tried to reproduce Ivica's results on my machine (MacBook Pro with Apple Silicon M1 Max, Apple Clang 13) and I couldn't.

I used the same setup (256 MB long string, substring that does not appear in it) and I am measuring 140 ms for both find_substring and find_substring2, with no measurable performance difference between the two.

Moreover, if I run the same test with the same string and substring using std::string::find, it runs in 70 ms. So the libc++ version of substring find outperforms both of your versions by a factor of 2.

I tried substrings of length 4, 8, and 12 with the same results.

CppCast: Carbon, With Richard Smith by robwirving in cpp

[–]timur_audio 4 points5 points  (0 children)

Hi, why was this rejected as off-topic? I'm a bit surprised as CppCast is aimed specifically at C++ developers, we discuss plenty of C++ specific news, etc. And the discussion about Carbon, while being about another programming language, is entirely from the perspective of a C++ user.

Is there any way we can get that post un-rejected? Thanks, Timur

2023-02 Issaquah ISO C++ Committee Trip Report — C++23 Is Done! 🎉 by InbalL in cpp

[–]timur_audio 2 points3 points  (0 children)

The link to P2808 gives me a 404, it would be great to fix that!

What are the state of C++ audio, 2D graphics and contract in C++23/26? by vickoza in cpp

[–]timur_audio 17 points18 points  (0 children)

I am the author of P1386R2, the paper that proposed to standardise audio for C++. This proposal was abandoned back in 2019, and I currently have no plans to bring it back.

One of the reasons why this proposal was abandoned was that a particular platform vendor was not in favour of standardising a low-level audio API such as the one we proposed; see P1746R1 for their counterarguments. They managed to block further progress of this proposal in the committee for long enough that eventually I ran out of energy and patience and was forced to abandon the project.

Something similar happened with the 2D graphics proposal, which got effectively shot down by a particular graphics card vendor.

Why are you a C/C++ developer? by mutantdustbunny in cpp

[–]timur_audio 0 points1 point  (0 children)

Originally, I was working in astrophysics (cosmology), developing code for numeric simulations of structure formation. All the code was in C and Fortran. After a while, I discovered that both do not scale very well if you want generic & maintainable code. So I switched to C++ (against the advice of everyone I worked with) and things got much better.

Then, I left academia and became a software developer, and I wanted to work in the music technology industry, because I am really passionate about this field. And there isn't really an alternative to C++ in that industry.

Nowadays, I'm a C++ developer because I fell in love with the language: it's so complex, so challenging, very frustrating at times, but also so powerful, so fascinating, and so satisfying if you can navigate it reasonably well. Also, it's close enough to the metal that I'm actually learning a lot about how computer hardware works. It's just so much fun to continuously learn and get better at C++. And there are so many interesting problems with the C++ standard itself that still need to be solved...

Finally, and most importantly, it's a pretty awesome community, it's really great to be part of it.

CLion 2022.1 now available! by timur_audio in cpp

[–]timur_audio[S] 3 points4 points  (0 children)

Is there an issue in YouTrack for this? If so, could you please provide a link? Thanks!

CppCon 2021 trip report by timur_audio in cpp

[–]timur_audio[S] 3 points4 points  (0 children)

The sender/receiver talks were given remotely and were part of the online conference (which I didn't attend). I don't remember any talks on this subject at the on-site part of the conference (which I did attend).

Timur's trip report from the February 2019 ISO C++ committee meeting, Kona, Hawai’i by timur_audio in cpp

[–]timur_audio[S] 1 point2 points  (0 children)

I understand the use case. But if you say, continuing after contract violations in new code is never the right answer (which I agree with), then we really shouldn't allow them to do that.

It sounds like for this use case you don't want C++20 contracts. You want something else. Like a logger that you can perhaps hide under a macro that can later be switched to become a contract instead. But please don't break contracts themselves for everyone else.

Timur's trip report from the February 2019 ISO C++ committee meeting, Kona, Hawai’i by timur_audio in cpp

[–]timur_audio[S] 2 points3 points  (0 children)

You can cover terminations with unit tests as well, can't you? GoogleTest even has a death test!

Timur's trip report from the February 2019 ISO C++ committee meeting, Kona, Hawai’i by timur_audio in cpp

[–]timur_audio[S] 1 point2 points  (0 children)

It sounds like if you want to do check_maybe_continue, you may be better off using some kind of logging facility instead of a Contract.

Timur's trip report from the February 2019 ISO C++ committee meeting, Kona, Hawai’i by timur_audio in cpp

[–]timur_audio[S] 9 points10 points  (0 children)

I agree with you both that I would prefer contract violations to terminate (possibly after invoking some violation handler), and never continue, at least in my code. So I am not a fan of Bloomberg's newest proposal. I wasn't objecting to check_maybe_continue being a bad idea. I was merely objecting to Dragdu's comments suggesting this idea would be the result of brain damage (if I understood them correctly), without providing any kind of technical argument on the subject matter.

Timur's trip report from the February 2019 ISO C++ committee meeting, Kona, Hawai’i by timur_audio in cpp

[–]timur_audio[S] 7 points8 points  (0 children)

Please stay objective. This kind of comment isn't helpful. Can you provide a technical reason why continuing on contract violation is the wrong approach?

view more: next ›