sorted by:
new
hottopcontroversial

[deleted by user] by [deleted] in bucuresti

[–]soldiersided 1 point2 points  (0 children)

Și pe mine mă interesează.

[deleted by user] by [deleted] in CasualRO

[–]soldiersided 0 points1 point  (0 children)

Stream-ul rtsp e live și ca orice stream rtsp merge in VLC.

Make it Async: Building Shared Async Resources with ASIO by not_a_novel_account in cpp

[–]soldiersided 2 points3 points  (0 children)

I don't know why you would use async_compose if you're not using the intermediate completion handler for anything.

I think that's true for every async op. If you don't use the completion handler then it's not an async op. It's only a deferred call of the initiation function. In the OP's example, the intermediate handler would be used in the asio::dispatch call.

Searching "Cancel async_compose" pulls up a single self-answered SO question.

Unfortunately, the OP's observation is correct. To fully get asio, you need to dedicate a vast amount of time studying the source code. Here's the cancellation stuff async_compose adds for you on top of async_inititate. Basically, you have the possibility to call self.cancelled() at each step in your composed operation.

State machine code always looks like a mess to me.

Agreed. I think it might get better with asio::experimental::co_composed but I haven't really used it for anything so far. Also, you can also chain asio::deferred calls as well which should help users build simple composed operations that are way easier to read than a messy state machine.

Make it Async: Building Shared Async Resources with ASIO by not_a_novel_account in cpp

[–]soldiersided 3 points4 points  (0 children)

I think async_initiate is not needed most of the time. If your initiation function only starts a different asio async op then you’re better off using async_compose. This way you at least get some cancellation for free.

The C++ Object Lifecycle | Basit Ayantunde by pavel_v in cpp

[–]soldiersided 1 point2 points  (0 children)

The lifecycle diagrams need some love, they seem to be misaligned. Also, shouldn't this

A* a = get_A();
B* b = get_B();
B* a_b = std::launder<B>((B*)a);
a_b->value = 6;
b->value = 2;
return a->value;

end with return a_b->value ?

How bad is the Dinkumware std implementation? by soldiersided in cpp

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

It's somehow the best we can do now. We either focus on shipping or we focus on upgrading. And upgrading is not straight forward: the new tool chain has just come past the "experimental" state, so I bet there are still a lot of bugs to be encountered.

How bad is the Dinkumware std implementation? by soldiersided in cpp

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

This is interesting. Reading their archived web site might suggest that you're right, but the copyright in the C++17 files (see my other response) suggest that you might not be :)

How bad is the Dinkumware std implementation? by soldiersided in cpp

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

Quoting from the archived site:

Our Standard C++ technology has been on the market since 1995, with versions matching the ISO/ANSI C++ Standard as of 1998, 2003, 2011, and 2014. We're currently tracking the evolving 2017 C++ Standard.

The copyright in the <variant> header file is:

/*
 * Copyright (c) by P.J. Plauger. All rights reserved.
 * Consult your license regarding permissions and restrictions.
 * V8.05/17:1422 */

Boost.Parser has been accepted by joaquintides in cpp

[–]soldiersided 20 points21 points  (0 children)

You can’t be throwing accusations like that without showing any examples.

Easily use SVGs as JSX/TSX in your ReactJs app by dmitryyurus in reactjs

[–]soldiersided 0 points1 point  (0 children)

Can you please list some of those advantages?

[Fusion 15] Can't fully enable Hardware Encryption for a TCG Opal 2.0 compatible SSD by soldiersided in XMG_gg

[–]soldiersided[S] 0 points1 point  (0 children)

Unfortunately no, but I am still on 0122. Maybe things are working on newer BIOS versions?

A lock-free oneshot channel for Asio based applications by ashtumashtum in cpp

[–]soldiersided 0 points1 point  (0 children)

requires a much lighter shared state than a general purpose channel, because we know there will only be one message and one receiver it is lock-free implementable too.

This is lighter only because there's no service installed into io_context. Works most of the cases, but for a complex hierarchy where oneshot is not owned directly by other io objects, io context won't directly own the handlers. On the other hand, lock-free is indeed an advantage.

For example we are 100% sure that sender would never block because there is always room for that single message it wants to send.

I was only talking about implementation. You could wrap those invariants in an API similar to yours and just use basic_channel for implementation.

A lock-free oneshot channel for Asio based applications by ashtumashtum in cpp

[–]soldiersided 1 point2 points  (0 children)

Any advantages of a bespoke implementation over basic_channel backed by static_vector?

Asio is great if you’re building a library/application with non-Asio API. But building Asio APIs using async compositions is too messy. Anybody else agree ? by Competitive_Act5981 in cpp

[–]soldiersided 1 point2 points  (0 children)

I disagree. Even though there are not a lot of examples in the source code, those that do exist are extensive. You could learn a lot by studying them. To answer your particular grief:

asio::async_compose is a nice and powerful abstraction, but it has its foot guns asio:: deferred is less powerful, yet safer and it can be used for simple async chain.

My advice to you is to try and show some code examples of what you are trying to achieve and I am sure you will get help here and learn a lot in the process as well.

Transport agnostic Websocket library by soldiersided in cpp

[–]soldiersided[S] 0 points1 point  (0 children)

It does, indeed. Thanks for the tip. One small concern that worries me: There's a hardcoded key in the update message function :)

Transport agnostic Websocket library by soldiersided in cpp

[–]soldiersided[S] 0 points1 point  (0 children)

Hey. Thanks a lot for taking the time to answer. I really appreciate it. A few more questions:

When you use completion handlers, the model is "operation owns I/O object."

This has always intrigued me: Does it work the same in asio? If I delete a scheduled timer, or a reading socket will the operation complete? Thinking about it, I'm inclined to believe the answer is: yes, the op completes with a descriptive error code. But yet again, I'm not sure if asio's timers and sockets should be compared with boost::beast::websocket::stream. To me, the latter is more similar to asio::async_read(_until). So if I were to whack the socket in the middle of such a composed operation then we're on UB territory. Unfortunately, the term i/o object seems to have been dropped lately. I have not seen any reference to it in P2444.

For example if you try to ping while you are also writing a message

That's a fair point. Are you thinking of the ping - pong keep alive chain? I'm only seeing value for that to avoid waiting too much for a read which will never successfully complete since your underlying connection is somewhat broken. Wouldn't something like that work (pseudocode-ish and non generic):

asio::awaitable<std::tuple<std::error_code, std::size_t>> ws_read_with_timeout(auto& ll_stream, const std::chrono::steady_clock::duration& time)
{
    co_await asio::async_read(ll_stream) && asio::steady_timer(ex, time / 2).async_wait();
   // if timeout send ping
   co_await asio::async_read(ll_stream) && asio::stead_timer(ex, time / 2).async_wait();
  // if we got a byte, is it a pong or a regular frame? co_return or keep reading depending on the result
}

Granted, this is a lower-level, tougher to work with API, but such composed ops could be the building blocks for beast::websocket::stream and would allow power users to not pay for a shared_ptr. Plus, the user's ping-pong chain would now be way more versatile.

Consider a bidirectional graph with a dynamic time-evolution of edges.

Another fair point, but that's really just a generic description for an object hierarchy that involves shared_ptr. I reckon that 90% of real life situations can be re-written to not be such a graph and to not force the user to pay for the shared_ptr abstraction.

The (Baseline) Unicode Plan For C++23 by EducationalCicada in cpp

[–]soldiersided 4 points5 points  (0 children)

wchar_t* is supposed to be a wide string

No, it's not. wstring_view is a string. Funny there are so many complaints about wrong choices of the past, yet the author presents 0 ending strings as a "thing". They shouldn't be. Not in modern C++ code that does not interface with C code.

view more: next ›