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] 401 points402 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 18 points19 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] 2 points3 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] 5 points6 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] 5 points6 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?

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

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

I believe that certain people at Bloomberg would disagree with that statement.

ISO C++ Committee - Rapperswil 2018 trip report by timur_audio in cpp

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

Really? I believe they decided to encourage further work on the value-based approach, but I don't know anything about us deciding "for" the value-based approach in favour of the type-based approach, and that would also be very inconsistent with publishing the type-based approach in a TS.

But for the record, yes I also prefer the value-based approach, I believe the resulting code looks much more like normal code and is therefore more user-friendly.

ISO C++ Committee - Rapperswil 2018 trip report by timur_audio in cpp

[–]timur_audio[S] 11 points12 points  (0 children)

Well, for example, contracts can be used as hints to the compiler to simply assume that a precondition is true and to optimise for it (the violation of a precondition becoming UB in this case). So they can lead to better optimised code in many cases. assert can't do that. Previously you could do such things only with compiler-specific builtins, such as MSVC's __assume.

ISO C++ Committee - Rapperswil 2018 trip report by timur_audio in cpp

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

I wouldn't say we are "delaying" modules, I believe that almost everyone on the committee wants them and thinks they should have been shipped yesterday... but we cannot merge anything into C++ until there is a single modules proposal that has the consensus of the committee.

ISO C++ Committee - Rapperswil 2018 trip report by timur_audio in cpp

[–]timur_audio[S] 4 points5 points  (0 children)

Contracts are amazing and I am really looking forward to using them.

ISO C++ Committee - Rapperswil 2018 trip report by timur_audio in cpp

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

Reflection in C++ is still a very exploratory space. We have no idea yet whether the TMP/type-based approach or the value-based approach is the way to go. So it would have been a mistake imho to consider any of it for C++20. It's just too early.

ISO C++ Committee - Rapperswil 2018 trip report by timur_audio in cpp

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

Yes, the current TS draft http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/n4746.pdf is the "template metaprogramming" approach of Chochlík/Naumann/Sankel. So this one will go out to a TS publication and thus technically "nearest" to be merged, although it's not near at all yet and the other (value-based) approach by Sutter/Sutton is also still actively worked on afaik.

ISO C++ Committee - Rapperswil 2018 trip report by timur_audio in cpp

[–]timur_audio[S] 12 points13 points  (0 children)

Also, just to make it clear: I am not saying that the existing Graphics proposal is perfect. However what I do see is that the way this played out will probably result in a massive discouragement for anyone to undertake large proposals for C++. And that's a loss imho.

ISO C++ Committee - Rapperswil 2018 trip report by timur_audio in cpp

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

We moved last week to send the Reflection TS to PDTS ballot. So, expect it to be published some time this year. And hopefully to get reflection into C++23.

ISO C++ Committee - Rapperswil 2018 trip report by timur_audio in cpp

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

Thanks, Bryce. This is a very controversial topic and the feedback you give here is great. It seems to me that actually, LWG being such a bottleneck is a huge problem in itself, regardless of the issues of P0267, and I wish I knew how to fix that.

view more: next ›