Video: CppCon 2018: G. Nishanov “Nano-coroutines to the Rescue!

[Adriano dos Santos Fernandes]

I found this very interesting:

https://www.youtube.com/watch?v=j9tlJAqMV7U&ab_channel=CppCon

I think coroutines will be very important C++ feature in the future.

It will change C++ codebases a lot, like async programming changed C#,
JavaScript and also now going to Java (with virtual threads).

Video spoiler: he made multiple lookups binary searches faster,
surprisingly, using coroutines (as later standardized in C++20),
treating a memory prefetch instruction as an async work.


Adriano

[Alex Peshkoff]

On 10/9/23 12:49, Adriano dos Santos Fernandes wrote:
> as later standardized in C++20

a bit related - are we going to switch to C++20 in fb6?

[Adriano dos Santos Fernandes]

What I would like is to switch compiler options to C++20 but commit to
C++17, with selected C++20 features per agreement depending on
usefulness and platforms and compilers supports.

We did this with C++14 / C++17 in v5 and it worked well.

BTW, I think we should upgrade compilers.

In Windows to latest VS 2022 version and in Linux to latest GCC 11 or 12.


Adriano

[Dmitry Yemanov]

10.10.2023 03:09, Adriano dos Santos Fernandes wrote:
>
> What I would like is to switch compiler options to C++20 but commit to
> C++17, with selected C++20 features per agreement depending on
> usefulness and platforms and compilers supports.

I don't mind.

> We did this with C++14 / C++17 in v5 and it worked well.
>
> BTW, I think we should upgrade compilers.
>
> In Windows to latest VS 2022 version and in Linux to latest GCC 11 or 12.

Wasn't the Windows compiler already updated for v5?


Dmitry

[Alex Peshkoff]

On 10/10/23 08:49, Dmitry Yemanov wrote:
> 10.10.2023 03:09, Adriano dos Santos Fernandes wrote:
>>
>> What I would like is to switch compiler options to C++20 but commit to
>> C++17, with selected C++20 features per agreement depending on
>> usefulness and platforms and compilers supports.
>
> I don't mind.
>

Great. Suggest a feature  - std::atomic<std::shared_ptr<T>>. Is it
supported in VC?

>> We did this with C++14 / C++17 in v5 and it worked well.
>>
>> BTW, I think we should upgrade compilers.
>>
>> In Windows to latest VS 2022 version and in Linux to latest GCC 11 or
>> 12.
>
> Wasn't the Windows compiler already updated for v5?
>

gcc definitely to be upgraded. Wanted to say to v12 but suggest to wait
for our Beta1 - may be we will have gcc v13 at that time?

[Dimitry Sibiryakov]

Adriano dos Santos Fernandes wrote 10.10.2023 2:09:
> BTW, I think we should upgrade compilers.
>
> In Windows to latest VS 2022 version and in Linux to latest GCC 11 or 12.

Are all Linux distros provide GCC 11?
How about MacOS or Android?

--
WBR, SD.

[Dimitry Sibiryakov]

Alex Peshkoff wrote 10.10.2023 10:38:
> Suggest a feature  - std::atomic<std::shared_ptr<T>>. Is it supported in VC?

IIRC std::shared_ptr is implemented as a dynamic reference counted object. Is
it compatible with Firebird pools and provide the same performance as a
Firebird::RefCnt?

--
WBR, SD.

[Alex Peshkoff]

That's sooner of all about version of c++ runtime - compiler itself is
not needed. I'm pretty sure that _latest_ release for all distros does
provide gcc 12, at least runtime support.
For Mac clang is used, and together with Android that's separate builds,
nobody requires from us to build it using same compiler.

[Alex Peshkoff]

On 10/10/23 11:44, 'Dimitry Sibiryakov' via firebird-devel wrote:
> Alex Peshkoff wrote 10.10.2023 10:38:
>> Suggest a feature  - std::atomic<std::shared_ptr<T>>. Is it supported
>> in VC?
>
>   IIRC std::shared_ptr is implemented as a dynamic reference counted
> object. Is it compatible with Firebird pools

Yes. At least it's fine with redefined global new/delete.

> and provide the same performance as a Firebird::RefCnt?
>

Sooner of all not - but I do not suggest to replace our RefCounted
everywhere blindly. But in some places where also atomic pointer
replacement is required - why not? Pay attention that
std::atomic<std::shared_ptr<T>> is not just 2 templates used on top of
each other, it's optimized specialization. Why waste time specializing
std::atomic<Firebird::RefCounted<T>> when there is working template?

[Dimitry Sibiryakov]

Alex Peshkoff wrote 10.10.2023 10:56:
> Why waste time specializing std::atomic<Firebird::RefCounted<T>> when there is
> working template?

But... reference counted objects don't need atomic pointers by design. Owner
of pointer is free to copy it and give a copy to a new owner with only counter
increase, there is no need in any atomic operation as the object is guaranteed
to be alive as long as it has at least one owner.
And synchronization is required anyway during manipulations with global
containers of such pointers which cannot be done by atomic ops.

I personally would invite std::unique_ptr and std::unordered_map but they
don't need C++20.

--
WBR, SD.

[Vlad Khorsun]

10.10.2023 8:49, Dmitry Yemanov:

Can't say about installer, but in development it is already VS 2022.
See thread "Windows official compiler" from 15.04.2023.

Regards,
Vlad

[Alex Peshkoff]

On 10/10/23 12:03, 'Dimitry Sibiryakov' via firebird-devel wrote:
> Alex Peshkoff wrote 10.10.2023 10:56:
>> Why waste time specializing std::atomic<Firebird::RefCounted<T>> when
>> there is working template?
>
>   But... reference counted objects don't need atomic pointers by
> design. Owner of pointer is free to copy it and give a copy to a new
> owner with only counter increase, there is no need in any atomic
> operation as the object is guaranteed to be alive as long as it has at
> least one owner.

Another usage. 2 threads work with shared reference counted pointer.
Both detect that an object, where that pointer points to, should be
copy-updated. Both create new copy of that object and try to change
reference counted pointer to new object.
Certainly, this may be easily solved using mutex. But what if
probability of conflict is low and new version may be created fast
enough, i.e. I do not wnt to use mutex?

> And synchronization is required anyway during manipulations with
> global containers of such pointers which cannot be done by atomic ops.
>

Hmmm... appears can.

>   I personally would invite std::unique_ptr and std::unordered_map but
> they don't need C++20.
>

That's both old enough features, what a problem?

[Dimitry Sibiryakov]

Alex Peshkoff wrote 10.10.2023 11:20:
> Another usage. 2 threads work with shared reference counted pointer. Both detect
> that an object, where that pointer points to, should be copy-updated. Both
> create new copy of that object and try to change reference counted pointer to
> new object.
> Certainly, this may be easily solved using mutex. But what if probability of
> conflict is low and new version may be created fast enough, i.e. I do not wnt to
> use mutex?

This is not the way any code that pretend to be robust should go.
Synchronization of access to an object cannot be replaced by synchronization
of access to a pointer on it.

>> I personally would invite std::unique_ptr and std::unordered_map but they don't need C++20.
>
> That's both old enough features, what a problem?

They are not on list of allowed features and there is no std-compatible
allocator for Firebird pools AFAIK.

--
WBR, SD.

[Alex Peshkoff]

Both c++11 features, all are allowed since FB5.

> and there is no std-compatible allocator for Firebird pools AFAIK.
>

Suggest one :)

[Dimitry Sibiryakov]

Alex Peshkoff wrote 10.10.2023 11:33:
>> and there is no std-compatible allocator for Firebird pools AFAIK.
>>
>
> Suggest one :)

I would rather suggest to drop pools. They demonstrated performance increase
20 years ago but since then C runtime improved a lot.

--
WBR, SD.

[Adriano dos Santos Fernandes]

On 10/10/2023 02:49, Dmitry Yemanov wrote:

> Wasn't the Windows compiler already updated for v5?
>

We're using VS 2019 16.11.16, released in June 14, 2022.


Adriano

[Adriano dos Santos Fernandes]

On 10/10/2023 05:38, Alex Peshkoff wrote:
> On 10/10/23 08:49, Dmitry Yemanov wrote:
>> 10.10.2023 03:09, Adriano dos Santos Fernandes wrote:
>>>
>>> What I would like is to switch compiler options to C++20 but commit to
>>> C++17, with selected C++20 features per agreement depending on
>>> usefulness and platforms and compilers supports.
>>
>> I don't mind.
>>
>
> Great. Suggest a feature  - std::atomic<std::shared_ptr<T>>. Is it
> supported in VC?
>

It's P0718R2. Accordingly to
https://learn.microsoft.com/pt-br/cpp/overview/visual-cpp-language-conformance?view=msvc-170,
it's supported since VS 2019 16.7.

> gcc definitely to be upgraded. Wanted to say to v12 but suggest to wait
> for our Beta1 - may be we will have gcc v13 at that time?
>

If it's to avoid old bugs (which gcc not necessarily fixes), may be ok
to use gcc 13, but if it's to use very fresh features, it may be very
problematic for the users who want to compile the sources and even to
include Firebird package in distros.


Adriano

[Adriano dos Santos Fernandes]

On 10/10/2023 06:19, Vlad Khorsun wrote:
>
>   Can't say about installer, but in development it is already VS 2022.
> See thread "Windows official compiler" from 15.04.2023.
>

Unfortunately, nobody act on the decision and it stayed with VS 2019.

Now we should decide if v5 should remain with same older VS 2019, be
updated to latest VS 2019 or latest VS 2022.

It would be interesting to know also which version was used by Paul in
Beta.1.


Adriano

[Adriano dos Santos Fernandes]

On 10/10/2023 06:20, Alex Peshkoff wrote:
>
>>   I personally would invite std::unique_ptr and std::unordered_map but
>> they don't need C++20.
>>
>
> That's both old enough features, what a problem?
>

AutoPtr had an advantage over unique_ptr that it returned const T* for a
const AutoPtr<T>, but Alex changed it. I don't agree, I asked for
discussion but nobody commented about it.

I hope we may review that decision before switch types.

Currently, AutoPtr should have no advantage over unique_ptr.


Adriano

[Adriano dos Santos Fernandes]

On 10/10/2023 06:33, Alex Peshkoff wrote:
>
>> and there is no std-compatible allocator for Firebird pools AFAIK.
>>
>
> Suggest one :)
>

What is PoolAllocator and how DoublyLinkedList works?


Adriano

[Alex Peshkoff]

On 10/10/23 12:42, Adriano dos Santos Fernandes wrote:

>
>> gcc definitely to be upgraded. Wanted to say to v12 but suggest to wait
>> for our Beta1 - may be we will have gcc v13 at that time?
>>
> If it's to avoid old bugs (which gcc not necessarily fixes),

Yes, first of all to avoid bugs. Certainly, no one fixes all bugs in
next release, moreover - new one may be added. And to avoid such bugs I
prefer to avoid doz-zero releases, i.e. use gcc 13 only if there is
13.1, better 13.2 release. In general: I can see that quality of
compiler becomes better and better with new versions, that's why this
suggestion.

> may be ok
> to use gcc 13, but if it's to use very fresh features

No, that's not what I wanted to suggest :)

> , it may be very
> problematic for the users who want to compile the sources and even to
> include Firebird package in distros.

Certainly.

[Alex Peshkoff]

On 10/10/23 12:53, Adriano dos Santos Fernandes wrote:
> AutoPtr had an advantage over unique_ptr that it returned const T* for a
> const AutoPtr<T>, but Alex changed it. I don't agree, I asked for
> discussion but nobody commented about it.
>
> I hope we may review that decision before switch types.

const AutoPtr<T> is absolutely unrelated with constness of object T. If
one wants to deal with const T, AutoPtr<const T> should be used.

[Vlad Khorsun]

10.10.2023 12:49, Adriano dos Santos Fernandes:

> On 10/10/2023 06:19, Vlad Khorsun wrote:
>>
>>   Can't say about installer, but in development it is already VS 2022.
>> See thread "Windows official compiler" from 15.04.2023.
>>
>
> Unfortunately, nobody act on the decision and it stayed with VS 2019.

What actions you expect here ? How you see that it stayed with VS 2019 ?

> Now we should decide if v5 should remain with same older VS 2019, be
> updated to latest VS 2019 or latest VS 2022.

It should be VS 2022.

Regards,
Vlad

[Adriano dos Santos Fernandes]

On 10/10/2023 07:10, Vlad Khorsun wrote:
> 10.10.2023 12:49, Adriano dos Santos Fernandes:
>> On 10/10/2023 06:19, Vlad Khorsun wrote:
>>>
>>>    Can't say about installer, but in development it is already VS 2022.
>>> See thread "Windows official compiler" from 15.04.2023.
>>>
>>
>> Unfortunately, nobody act on the decision and it stayed with VS 2019.
>
>   What actions you expect here ? How you see that it stayed with VS 2019 ?
>

builds/docker/windows/Dockerfile


Adriano

[Paul Reeves]

On Tue, 10 Oct 2023 06:49:04 -0300
Adriano dos Santos Fernandes <adri...@gmail.com> wrote:

> It would be interesting to know also which version was used by Paul in
> Beta.1.
>

Visual Studio 2022 v17.0.18


Paul
--

Paul Reeves
http://www.ibphoenix.com
Supporting users of Firebird

[Adriano dos Santos Fernandes]

On 10/10/2023 06:58, Alex Peshkoff wrote:
>
> const AutoPtr<T> is absolutely unrelated with constness of object T. If
> one wants to deal with const T, AutoPtr<const T> should be used.
>

I totally disagree.

For example, const std::vector<T> returns references to const T*.

Using of AutoPtr<const T> is totally different usage, that is
unconditional constant.

For example, see our NestConst. It's only action is to switch T* to
const T* in constant methods. That allow us to have modifing behavior
during compiler and constant behavior during execution.

There is std::experimental::propagate_const which this behaviour.

But NestConst and propagate_const do not own the object, and we used
AutoPtr with propagate/nest const semantics for years... And it was
changed in an unrelated commit.


Adriano

[Vlad Khorsun]

10.10.2023 13:12, Adriano dos Santos Fernandes:

I never use Docker for development (as I don't need it and happy with it) and
see no direct relation of this with our agreement on official compiler. Such
relations should be at least described somewhere.

Regards,
Vlad

[Adriano dos Santos Fernandes]

On 10/10/2023 07:27, Vlad Khorsun wrote:
>
>   I never use Docker for development (as I don't need it and happy with
> it) and
> see no direct relation of this with our agreement on official compiler.
> Such
> relations should be at least described somewhere.
>

Sorry, but who is forcing you to use docker?

I suppose nobody, right?

I also suppose that you can open your VS 2022 or VS 2019, and develop
Firebird v5, right?

So what you are talking about?

I suppose you understand that automated build environment do not raise
by magic and some code defines it, right?

And I suppose you remember all of this was discussed in firebird lists
and pull requests, right?

So what are you talking about?


Adriano

[Alex Peshkoff]

On 10/10/23 13:18, Adriano dos Santos Fernandes wrote:
> On 10/10/2023 06:58, Alex Peshkoff wrote:
>> const AutoPtr<T> is absolutely unrelated with constness of object T. If
>> one wants to deal with const T, AutoPtr<const T> should be used.
>>
> I totally disagree.
>
> For example, const std::vector<T> returns references to const T*.

Certainly. But that's wrong example - container object CONTAINS elements
of type T, and if it is constant itself that means that all elements
contained in it are also constants. If we change an element that means
we changed container, because element is a part of that container. With
pointer it's absolutely different case - const pointer means only that
pointer itself can not be changed, changing an object where it points
does not change a pointer to it. Therefore mentioned later
propagate_const exists.

>
> Using of AutoPtr<const T> is totally different usage, that is
> unconditional constant.
>
> For example, see our NestConst. It's only action is to switch T* to
> const T* in constant methods. That allow us to have modifing behavior
> during compiler and constant behavior during execution.
>
> There is std::experimental::propagate_const which this behaviour.
>
> But NestConst and propagate_const do not own the object, and we used
> AutoPtr with propagate/nest const semantics for years... And it was
> changed in an unrelated commit.

It was changed when I've found my old bug when worked with a code. There
is an old joke that "documented bug becomes feature". But here is a
first known to me example when _undocumented_ bug became feature :D

Well - I agree that even undocumented legacy behavior should better be
restored.
Does anyone see problems if I restore bug (undocumented feature) in
AutoPtr and use std::unique_ptr where something more traditional is needed?

[Mark Rotteveel]

On 10-10-2023 12:14, 'Paul Reeves' via firebird-devel wrote:
> On Tue, 10 Oct 2023 06:49:04 -0300
> Adriano dos Santos Fernandes <adri...@gmail.com> wrote:
>
>> It would be interesting to know also which version was used by Paul in
>> Beta.1.
>>
>
> Visual Studio 2022 v17.0.18

May I ask why an out-of-date version is used? The latest overall is
17.7.4 (September 2023), and 17.0.18 is from January 2023, while the
latest 17.0 (17.0.23) is from July 2023.

Mark
--
Mark Rotteveel

[Vlad Khorsun]

10.10.2023 13:33, Adriano dos Santos Fernandes:

> On 10/10/2023 07:27, Vlad Khorsun wrote:
>>
>>   I never use Docker for development (as I don't need it and happy with
>> it) and
>> see no direct relation of this with our agreement on official compiler.
>> Such
>> relations should be at least described somewhere.
>>
>
> Sorry, but who is forcing you to use docker?

It was not about forcing me to use docker. It was about relation between
agreed official installer and some Dockerfile under builds/docker folder
that I am, personally, never look at as I don't need to look at it. Is it
more clear now ?

> I suppose nobody, right?

Thank You !

> I also suppose that you can open your VS 2022 or VS 2019, and develop
> Firebird v5, right?

Doing it every day.

> So what you are talking about?

See above.

> I suppose you understand that automated build environment do not raise
> by magic and some code defines it, right?

Sure.

> And I suppose you remember all of this was discussed in firebird lists
> and pull requests, right?

No. Could you show me discussing it ? You took the role to arrange it
and I'm thankful for this. With it you have the liberty to do it as you
consider right, and that's fair. But who do you expect should maintain
this to follow accordingly common agreed rules ?

Do you expect every developer know every detail about things that ever
not related with development directly ? Excuse me, I have what to do.

I don't understand your aggression here. I just asked to describe (even
not to document) non obvious relations.

Regards,
Vlad

[Adriano dos Santos Fernandes]

On 10/10/2023 07:58, Alex Peshkoff wrote:
> On 10/10/23 13:18, Adriano dos Santos Fernandes wrote:
>> On 10/10/2023 06:58, Alex Peshkoff wrote:
>>> const AutoPtr<T> is absolutely unrelated with constness of object T. If
>>> one wants to deal with const T, AutoPtr<const T> should be used.
>>>
>> I totally disagree.
>>
>> For example, const std::vector<T> returns references to const T*.
>
> Certainly. But that's wrong example - container object CONTAINS elements
> of type T, and if it is constant itself that means that all elements
> contained in it are also constants. If we change an element that means
> we changed container, because element is a part of that container. With
> pointer it's absolutely different case - const pointer means only that
> pointer itself can not be changed, changing an object where it points
> does not change a pointer to it. Therefore mentioned later
> propagate_const exists.
>

If we consider a Class1 that have an embedded (not pointer) Class2
field, then const methods of Class1 propagates to class2 member.

So by this definition, every class is a container.

I do not want to strictly discuss "containers" semantics, but by this
example, it's pretty natural to propagate const to smart pointers.

Yes, the std committee did not think the same.

But...

> It was changed when I've found my old bug when worked with a code. There
> is an old joke that "documented bug becomes feature". But here is a
> first known to me example when _undocumented_ bug became feature :D
>
> Well - I agree that even undocumented legacy behavior should better be
> restored.
> Does anyone see problems if I restore bug (undocumented feature) in
> AutoPtr and use std::unique_ptr where something more traditional is needed?
>

I don't considered it a bug. For me it's a feature that make things work
in the expected way in 99% of cases.


Adriano

[Adriano dos Santos Fernandes]

I already pointed it, but I will not search, copy and paste links for
you, sorry.

> You took the role to arrange it
> and I'm thankful for this. With it you have the liberty to do it as you
> consider right, and that's fair. But who do you expect should maintain
> this to follow accordingly common agreed rules ?
>
>   Do you expect every developer know every detail about things that ever
> not related with development directly ? Excuse me, I have what to do.
>
>   I don't understand your aggression here. I just asked to describe (even
> not to document) non obvious relations.
>

There was no aggression. I just can't understand why you switch topics
in the way you do making it appearing that others are doing something
not previously agreed.

About the Dockerfile not being updated as seems to have been agreed,
it's not individual responsibility of nobody, it's a team's problem of
nobody acting or nobody creating a issue in a way it could be remembered.


Adriano

[Dimitry Sibiryakov]

Adriano dos Santos Fernandes wrote 10.10.2023 13:29:
> I do not want to strictly discuss "containers" semantics, but by this
> example, it's pretty natural to propagate const to smart pointers.

IMHO, it is not. If you have a smart pointer - you need to use the object it
points to. If you don't want to change state of the object - you declare it as
std::unique_ptr<const T>. If you want to change state of the object - you
declare it as std::unique_ptr<T>.
I see no way for any code to do any meaningful work with a pointer to an
object of unpredictable const-ness.

--
WBR, SD.

[Alex Peshkoff]

On 10/10/23 14:29, Adriano dos Santos Fernandes wrote:
>> Does anyone see problems if I restore bug (undocumented feature) in
>> AutoPtr and use std::unique_ptr where something more traditional is needed?
>>
> I don't considered it a bug. For me it's a feature that make things work
> in the expected way in 99% of cases.

But what about use of unique_ptr? I ask cause more traditional approach
is also needed sometimes. If you agree - I plan to wait for a few days,
may be someone else see probems with use of STL class here.

[Adriano dos Santos Fernandes]

I already give an example, our statements and expression nodes with
execute() const methods.

NestConst helped *a lot* to convert dsql_nod/jrd_nod things, and it
still helps to avoid introduce state in wrong place (outside impure area).

Not that we should convert, but NestConst there is likely a shared pointer.


Adriano

[Dimitry Sibiryakov]

Adriano dos Santos Fernandes wrote 10.10.2023 13:40:
> I already give an example, our statements and expression nodes with
> execute() const methods.
>

> NestConst helped*a lot* to convert dsql_nod/jrd_nod things, and it

> still helps to avoid introduce state in wrong place (outside impure area).

So it is just a messy helper for a messy incomplete code migration. Ok...

--
WBR, SD.

[Adriano dos Santos Fernandes]

On 10/10/2023 08:38, Alex Peshkoff wrote:
> But what about use of unique_ptr? I ask cause more traditional approach
> is also needed sometimes. If you agree - I plan to wait for a few days,
> may be someone else see probems with use of STL class here.

I see no problem.

I already switch our own Nullable to std::optional.

And actually in ISQL, I'm using stl more aggressively (variants,
strings) in a new frontend parser.

Due to pools, our classes are much more difficult to use (and slow, due
to no move semantics).


Adriano

[Adriano dos Santos Fernandes]

You are free (accordinly to the license, of course) to use v1.5 code
base in your products haha.


Adriano

[Paul Reeves]

Well Beta 1 was in March so if 17.0.18 was from January then it was probably
just a single point release behind. (But it is pure luck if it was that close
- it wasn't intentional on my part.)

This brings us to another subject. Microsoft's release schedule for Visual
Studio is insane, imo. The basic idea of recommending reference compilers for
each major version of Firebird is OK, but with MS it is now a moving target.
How many releases of VS 2022, aka v17 do you think there will be over the
five years or so FB5?

I believe the changes are documented somewhere, but most of them are
irrelevant to us. We are only interested in the compiler and the run-time
libraries.

To do this properly we now need to track every point release of Visual Studio
and check if there is an important change that affects Firebird. Who has the
time for that?

But if I recall correctly even github doesn't change its versions of Visual
Studio as frequently as Microsoft releases it.

[Vlad Khorsun]

10.10.2023 14:36, Adriano dos Santos Fernandes:

>>> And I suppose you remember all of this was discussed in firebird lists
>>> and pull requests, right?
>>
>>   No. Could you show me discussing it ?
>
> I already pointed it, but I will not search, copy and paste links for
> you, sorry.

You can't find where I'm discussed "all of this", because I didn't.

All I found now in the list is your message "Build environments with Docker"
two years ago. And only because *now* I know what to search for (docker).

>> You took the role to arrange it
>> and I'm thankful for this. With it you have the liberty to do it as you
>> consider right, and that's fair. But who do you expect should maintain
>> this to follow accordingly common agreed rules ?
>>
>>   Do you expect every developer know every detail about things that ever
>> not related with development directly ? Excuse me, I have what to do.
>>
>>   I don't understand your aggression here. I just asked to describe (even
>> not to document) non obvious relations.
>>
>
> There was no aggression. I just can't understand why you switch topics
> in the way you do making it appearing that others are doing something
> not previously agreed.

Pity that you got such impression, but I can't look into your head. And I nor
switched the topics nor blamed you. All I said was that I surprised that official
compiler version is dependent in some way from something with docker inside and
nobody knows about it.

> About the Dockerfile not being updated as seems to have been agreed,
> it's not individual responsibility of nobody, it's a team's problem of
> nobody acting or nobody creating a issue in a way it could be remembered.

I always thought that every team member have certain responsibility (and good
will) to do some tasks, especially when he is the only one who does this or that
part. I was wrong, will try to remember it.


Vlad

[Adriano dos Santos Fernandes]

Em ter., 10 de out. de 2023 12:26, Vlad Khorsun <fbv...@gmail.com> escreveu:

   I always thought that every team member have certain responsibility (and good
will) to do some tasks, especially when he is the only one who does this or that
part. I was wrong, will try to remember it.

I will not reply to your attacks anymore. Nor to your memory lapses.

My personal email is there open for you if you want to attack me.

Adriano

[Adriano dos Santos Fernandes]

On 10/10/2023 06:36, 'Dimitry Sibiryakov' via firebird-devel wrote:

> Alex Peshkoff wrote 10.10.2023 11:33:
>>> and there is no std-compatible allocator for Firebird pools AFAIK.
>>>
>>
>> Suggest one :)
>

>   I would rather suggest to drop pools. They demonstrated performance
> increase 20 years ago but since then C runtime improved a lot.
>

Would like to suggest the same. Our code is terrible and difficult to
write due to them.

But what about monitoring?

A possible replacement would be to deep scan roots of monitorable
objects, but it will require a lot of work and may be very imprecise.


Adriano

[Alex Peshkoff]

On 10/11/23 13:03, Adriano dos Santos Fernandes wrote:
> On 10/10/2023 06:36, 'Dimitry Sibiryakov' via firebird-devel wrote:
>> Alex Peshkoff wrote 10.10.2023 11:33:
>>>> and there is no std-compatible allocator for Firebird pools AFAIK.
>>>>
>>> Suggest one :)
>>   I would rather suggest to drop pools. They demonstrated performance
>> increase 20 years ago but since then C runtime improved a lot.
>>
> Would like to suggest the same. Our code is terrible and difficult to
> write due to them.
>
> But what about monitoring?

Also what about 'drop by pool'? I remeber someone (Vlad?) tried to
release requests not using drop by pool - performance loss for short
requests was about 20%.

I agree that it was long ago, but before deciding it will be good idea
to repeat such experiment.

[Adriano dos Santos Fernandes]

On 11/10/2023 07:10, Alex Peshkoff wrote:
>
> Also what about 'drop by pool'? I remeber someone (Vlad?) tried to
> release requests not using drop by pool - performance loss for short
> requests was about 20%.
>
> I agree that it was long ago, but before deciding it will be good idea
> to repeat such experiment.
>

We first need to reclaim resources that interfere with concurrent
requests, like locks, etc.

The memory can be released in background thread if it's a problem.


Adriano

[Alex Peshkoff]

On 10/11/23 13:15, Adriano dos Santos Fernandes wrote:
> On 11/10/2023 07:10, Alex Peshkoff wrote:
>> Also what about 'drop by pool'? I remeber someone (Vlad?) tried to
>> release requests not using drop by pool - performance loss for short
>> requests was about 20%.
>>
>> I agree that it was long ago, but before deciding it will be good idea
>> to repeat such experiment.
>>
> We first need to reclaim resources that interfere with concurrent
> requests, like locks, etc.

It's already done currently with delete by pool.

> The memory can be released in background thread if it's a problem.
>

Before doing something we should check does this problem persist.

[Mark Rotteveel]

On 10/10/2023 02:09, Adriano dos Santos Fernandes wrote:
> On 09/10/2023 09:42, Alex Peshkoff wrote:
>> On 10/9/23 12:49, Adriano dos Santos Fernandes wrote:
>>> as later standardized in C++20
>>
>> a bit related - are we going to switch to C++20 in fb6?
>>
>
> What I would like is to switch compiler options to C++20 but commit to
> C++17, with selected C++20 features per agreement depending on
> usefulness and platforms and compilers supports.
>
> We did this with C++14 / C++17 in v5 and it worked well.
>
> BTW, I think we should upgrade compilers.
>
> In Windows to latest VS 2022 version and in Linux to latest GCC 11 or 12.

As far as I can tell, this switch was never made: everything is still
set to C++17 both in MSVC and makefiles (and for some example projects,
even the Visual Studio default, which is C++14 for VS 2022, or C++11 in
their makefiles).

Mark
--
Mark Rotteveel

[Adriano dos Santos Fernandes]

Yes.

Only the compilers were updated.

That discussion has 2 years, so I would change "commit to C++17, with
selected C++20 features per agreement" as the same thing we did later
when changed to C++17. That would be, any C++20 features in principle
would be allowed if it works in our CI.


Adriano

[Dmitry Yemanov]

11.07.2025 03:15, Adriano dos Santos Fernandes wrote:
>
>>> What I would like is to switch compiler options to C++20 but commit to
>>> C++17, with selected C++20 features per agreement depending on
>>> usefulness and platforms and compilers supports.
>>>
>>> We did this with C++14 / C++17 in v5 and it worked well.
>>>
>>> BTW, I think we should upgrade compilers.
>>>
>>> In Windows to latest VS 2022 version and in Linux to latest GCC 11 or 12.
>>
>> As far as I can tell, this switch was never made: everything is still
>> set to C++17 both in MSVC and makefiles (and for some example projects,
>> even the Visual Studio default, which is C++14 for VS 2022, or C++11 in
>> their makefiles).
>>
>
> Yes.
>
> Only the compilers were updated.
>
> That discussion has 2 years, so I would change "commit to C++17, with
> selected C++20 features per agreement" as the same thing we did later
> when changed to C++17. That would be, any C++20 features in principle
> would be allowed if it works in our CI.

IMHO: everything from C++20 should be allowed by default (and -std=c++20
is used), exceptions to this rule (if any) are explicitly prohibited in
/doc/modern_cpp.md.


Dmitry

[Adriano dos Santos Fernandes]

I'm looking at this. There is some code breaking when the switch is made.


Adriano