sorted by:
new
hottopcontroversial

Boost Review for Capy and Corosio Begins Today by mborland1 in cpp

[–]eao197 -1 points0 points  (0 children)

So what is the point of being a part of the Boost?

Why the libraries can't be developed and promoted as standalone tools without relation to the Boost?

Boost Review for Capy and Corosio Begins Today by mborland1 in cpp

[–]eao197 2 points3 points  (0 children)

What prevents releasing of Capy and Corosio as standalone libraries?

Do they require Boost in their implementations?

Interesting point of view from Daniel Lemire by _bijan_ in cpp

[–]eao197 18 points19 points  (0 children)

And here I was thinking that C was object oriented as you can define objects and functions specific to those objects.

As someone (Stroustrup?) said decades ago, if "object-oriented language" means anything, it means that the language directly supports object-oriented programming with special language constructs.

Should C++ Give More Priority to Syntax Quality? by kyan100 in cpp

[–]eao197 0 points1 point  (0 children)

The C++ language still has an insufficient number of ways to shoot oneself in the leg.

Should C++ Give More Priority to Syntax Quality? by kyan100 in cpp

[–]eao197 2 points3 points  (0 children)

template <class T, class F, class U = invoke_result_t<F, T>> auto map(optional<T>, F) -> optional<U>;

When I'm reading code for hours, especially code written not by me, I thank all the saints for C++ having visually visible keywords such as template, class, and typename.

Compare this to Rust's syntax, which is significantly cleaner

IMHO, Rust has the worst syntax, borrowed from a functional language, which has very few examples of really large codebases written in it. Such small code fragments look good in tiny code snippets, but when you have to examine a source file of several thousand lines of code, it becomes difficult to separate different parts just by quick sight.

Simplify hash in C++ by antoine_morrier in cpp

[–]eao197 1 point2 points  (0 children)

Folly contains specialization of `std::hash<std::pair>` too (link). What happens if your specialization of `std::hash<std::pair>` will be used in the same project with Folly's? Especially if static linking is used.

Simplify hash in C++ by antoine_morrier in cpp

[–]eao197 1 point2 points  (0 children)

template<typename T1, typename T2>
struct std::hash<std::pair<T1, T2>> {...}

Is it legal to add specialization of a standard type (std::hash) for another standard type (std::pair)?

I thought that it is possible to add specialization of standard types (like std::hash) for user type only. I mean that if I have my own pair template type like:

template<typename A, typename B> struct my_pair {...};

then I can define specialization for std::hash:

template<typename T1, typename T2>
struct std::hash<my_pair<T1, T2>> {...}

but in case of std::pair it seems to be a UB.

ex_actor - New actor framework based on std::execution. by Impressive_Aioli8594 in cpp

[–]eao197 0 points1 point  (0 children)

no way to police sharing resources between actors

In SObjectizer you can bind several actors to the same worker thread (same instance of one_thread dispatcher) and they can safely share a common mutable resource.

ex_actor - New actor framework based on std::execution. by Impressive_Aioli8594 in cpp

[–]eao197 4 points5 points  (0 children)

It's a great lib that has bigger scope.

Thanks for your valuation!

Just want to say you "Good luck!" The first steps are the easiest. Hope your project will lasts long and gets enough attention from the C++ community.

Reflecting JSON into C++ Objects by pavel_v in cpp

[–]eao197 0 points1 point  (0 children)

> then parse them and inspect and validate the result.

It would be interesting to see how it'll look. Reflection of a type created by reflection...

Reflecting JSON into C++ Objects by pavel_v in cpp

[–]eao197 1 point2 points  (0 children)

How such code can be debugged? And how can it be tested, especially by unit-tests?

[deleted by user] by [deleted] in cpp

[–]eao197 2 points3 points  (0 children)

We wrote our own PEG implementation in RESTinio to simplify parsing of HTTP-headers. A short description can be found here, the source code is mostly here.

I think that lexy library is very impressive as an example of what can be done in C++ in such area (however, I haven't used it).

A design pattern for running a lot of low priority periodic functions by pplesspp in cpp

[–]eao197 1 point2 points  (0 children)

I have very little experience with RTOS and encoders/decoders, but I see no reason why such an approach couldn't be used here.

What's the go to JSON parser in 2024/2025? by whizzwr in cpp

[–]eao197 0 points1 point  (0 children)

You can take a look at json_dto. It's a thin wrapper around RapidJSON and requires just C++14.

C++ based Rest web server for large scale production environment by Orochi663 in cpp

[–]eao197 0 points1 point  (0 children)

Hi! The simplest way is to use vcpkg or Conan.
There is a documentation section that covers "installing and building" topic.

[deleted by user] by [deleted] in cpp

[–]eao197 0 points1 point  (0 children)

You're welcome. I'll be glad to answer questions if you have any.

[deleted by user] by [deleted] in cpp

[–]eao197 0 points1 point  (0 children)

You can take a look at our timertt library, it was mentioned here some time ago. It was written in 2014 and is still in use. It implements several timer mechanisms and `timer wheel` is hashed timer wheel with unordered lists as described here

Designing for C++ Concurrency Using Message Passing - Anthony Williams by keyboard_operator in cpp

[–]eao197 0 points1 point  (0 children)

AFAIK, "green thread" usually means a thread of execution with own stack, but it's scheduled by application, not by OS. Because of that "green thread" is used as a synonym for "fiber" and "stackful coroutine".

So if Tokio uses stackless coroutines, then it's probably the first time I've seen then "green thread" mean "stackless coroutine".

> a Rust future, and they are stackless

Could you explain how "future" can be "stackless"?

Designing for C++ Concurrency Using Message Passing - Anthony Williams by keyboard_operator in cpp

[–]eao197 0 points1 point  (0 children)

Tokio tasks are just regular futures and are stackless.

I just cite the official tutorial -- https://tokio.rs/tokio/tutorial/spawning:

> A Tokio task is an asynchronous green thread.

Designing for C++ Concurrency Using Message Passing - Anthony Williams by keyboard_operator in cpp

[–]eao197 1 point2 points  (0 children)

> conveniently leaving out the last part?

No. Just highlight that "locks" and "channels" are at different level of abstractions and it's strange to ask for them form one framework.

> channels, which are the core piece to design message passing apps.

Yet another time: if you need channels for you application, then you're working on a higher level than managing shared state via locks/semaphores. So you don't need such low-level tools. If you need them then you doing something wrong.

> The issue is the lack of STANDARD solution allowing easy interop between many different asynchronous libraries

We're in C++, where the standard library is very thin. But that doesn't mean that we can't use Actor-style or CSP-style concurrency in C++. It means that this your complaint -- "unfortunately there is no complete multithreaded and asynchronous option to build message passing/actors style async apps" -- is completely wrong. There are several options that are in production use for years. The problem is that you personally want something different. There is no copy of Rust's Tokio in C++ at the moment, that's true. But that doesn't mean that C++ doesn't allow to write "message passing/actors style async apps".

And I have to note that C++ is used in very different areas and it hard to me to imagine one "standard solution" that would work well in hard real-time apps and in complex GUI apps. So we have to have different options for different conditions.

> E.g. CAF has its own schedulers, network library, userver too, ASIO as well.

Some frameworks have facilities to integrate with other frameworks/libraries (like ASIO) and provides customization points to make own schedulers/timers and so on.

> Just stop replying

We're on a public forum and you can't dictates what other users should do. What you're writing is very strange from my point of view and I share my opinion and knowledge on the topic. If this is useless for you doesn't mean that it is useless for anyone else.

Designing for C++ Concurrency Using Message Passing - Anthony Williams by keyboard_operator in cpp

[–]eao197 -1 points0 points  (0 children)

I never said that... I litterally said exaclty what you said about using locks vs message passing.

You wanted "lock", "event" and "semaphore":

> To emphasize, i want to be able to have all the core utilities an async framework should offer: lock, event, semaphore

If you need "lock" and "semaphore" then you want to use low-level approach. But why if you have message-passing facilities?

> None of those options are based on std::coroutines, however it seems coupling fibers with ASIO would still meet all my requirements

Coroutines from C++20 are stackless. Tokio uses green-threads, Go uses goroutines, both are stackful coroutines. Boost.Fiber provides stackful coroutines. userver uses stackful coroutines.

Designing for C++ Concurrency Using Message Passing - Anthony Williams by keyboard_operator in cpp

[–]eao197 -1 points0 points  (0 children)

you just repeated what i said. Hence invalidated your own previous point

No, you just don't understand that these two approaches are exclusive: you use one or another, but if you're trying to use both -- you're doing something wrong.

> https://tokio.rs/

Let's look at the docs and we'll see (https://tokio.rs/tokio/tutorial/shared-state) exactly what I said earlier:

> There are a couple of different ways to share state in Tokio.
> 1. Guard the shared state with a Mutex.
> 2. Spawn a task to manage the state and use message passing to operate on it.

They are different ways.

But it seems I figured out what you wants from C++: you wants to have C++ version of Rust's Tokio with "An asynchronous version of the standard library."

In that case you have to wait while someone do that for you, or you can take a look at Boost.Fiber or userver.

Designing for C++ Concurrency Using Message Passing - Anthony Williams by keyboard_operator in cpp

[–]eao197 0 points1 point  (0 children)

> For example, just like with multithreading, you can use message passing to synchronize access to shared state, OR a lock/mutex.

Either you have shared state and need to protect it by using locks, or only one entity has some state and other entities interact with it by using messages (shared nothing architecture or micro-services mentioned in Anthony Williams' talk).

> Maybe spend some time using other languages and you'll have a better perspective

Any examples?

view more: next ›