On Sunday, August 20, 2023 at 4:55:56 PM UTC+3, wij wrote:
> I found a C++ example https://refactoring.guru/design-patterns/visitor/cpp/example
> but I still don't understand what it tries to say and the example code don't compile.
> Can anyone explain the visitor pattern or better webpages?
> probably making the example compile may help, thanks in advance.

After trying, with limited success, to follow the discussion between Öö Tiib and Pavel,
I am coming to conclusion that continued ignorance about Visitor Pattern is best both
for my blood pressure and for my programming skills.

Am 25.08.2023 um 14:21 schrieb Michael S:

> After trying, with limited success, to follow the discussion between Öö Tiib and Pavel,
> I am coming to conclusion that continued ignorance about Visitor Pattern is best both
> for my blood pressure and for my programming skills.

I'm not ignore it but I wanted to say that it's easier to implement
it not with a separate base and dervied class for the visitor but
with a function<>-object. That would save a lot of work and you get
the same performance.

On Friday, 25 August 2023 at 06:12:09 UTC+3, Pavel wrote:
> Öö Tiib wrote:
> > On Thursday, 24 August 2023 at 08:39:04 UTC+3, Pavel wrote:
> >> Öö Tiib wrote:
> >>> On Tuesday, 22 August 2023 at 05:55:32 UTC+3, Pavel wrote:
> >>>> Öö Tiib wrote:
> >>>>> On Monday, 21 August 2023 at 01:02:21 UTC+3, Pavel wrote:
> >>>>>> Öö Tiib wrote:
> >>>>>>> On Sunday, 20 August 2023 at 21:13:01 UTC+3, Pavel wrote:
> >>>>>>>
> >>>>>>>> 1. Ensure all objects have a common base class (say, it's B)
> >>>>>>>
> >>>>>>> Not needed.
> >>>>>>>
> >>>>>>>> 2. create an abstract class Visitor with an abstract method doOp with an
> >>>>>>>> arg of type [ref to] B.
> >>>>>>>
> >>>>>>> Nope, pile of overloads of doOp one for each type processed.
> >>>>>>
> >>>>>> This would render the pattern useless as has no advantage over adding a
> >>>>>> virtual method to do the op. The rationale of the pattern is to permit
> >>>>>> coding one op in one place.
> >>>>>>
> >>>>> The Visitor class is that "one place"; doing same operation lets say printing
> >>>>> of 50 types in one function results with huge function that is headache
> >>>>> not advantage. Separate functions are testable and maintainable.
> >>>>>
> >>>>>>> Otherwise
> >>>>>>> how you process different types differently?
> >>>>>> I explained this in the problem statement. "Given [a ref to] any such
> >>>>>> object, you are able to
> >>>>>> compute its type and/or call a virtual method".
> >>>>>
> >>>>> IOW you do huge switch typeid ... case static_ cast or have the virtual
> >>>>> method (over what we were "gaining advantage") already there?
> >>>>
> >>>> Even a switch with 30 cases is no worse than 30 methods although switch
> >>>> is not always necessary (try to read the above instead of imagining)..
> >>>>
> >>> Visitor is typically used to search, filter, draw or print whole data object
> >>> hierarchy, convert to JSON to XML or to tree in GUI.
> >> correct
> >>> If whole data hierarchy
> >>> is small then you get 30 cases. Switch case is worse than virtual methods.
> >>
> >> *In general* neither is better or worse.
> >
> > Switch case over type is in general worse than virtual functions. Longer
> > function,
> Longer than what? Definitely the one function is shorter than the sum of
> the length of all the element type hierarchy shims plus concrete visitor
> visit overloads.
>
> > bigger cyclomatic complexity,
> with good code organization, no bigger than absolutely necessary.
>
> > harder to understand, with good code organization, actually, easier (see my point below about
> maintenance.
> > harder to
> > form confidence that it is valid,
> see below in maintenance.
>
> > harder to maintain,
> actually, easier to maintain. For using that GoF / wiki DD
> implementation, non-insignificant amount of scaffolding code has to be
> written. Especially in a complex hierarchy, one can easily forget to
> write that accept shim for a couple of classes where it is needed. E.g.
> if in the hierarchy (or a part thereof) is "(B, C, D) > A" (> meaning
> inheritance), imagine the op shall do same on A and D but different on B
> and C. Isn't it easy to forget to add the accept shim to C (even though
> the actual logic visit(C), at which the programmer is likely to focus,
> is written all right).
>
Can't. You can not leak knowledge of particular operation implemented
by VisitorX that happens to be same for A and D into base visitor. Base
visitor has to have all. Something like:
virtual doOp(A& a) {std::abort();}
virtual doOp(B& b) {std::abort();}
virtual doOp(C& c) {std::abort();}
virtual doOp(D& d) {std::abort();}

It is because different operation implemented by VisitorY may be
same for A and B and different for C and D. You can only leave out
handling of D in derived visitor if D is never processed by that visitor,
so std::abort() suits you.

> > harder to test and
> why?
> > also may need more access to implementation details of all types
> > involved, breaking encapsulation.
> How so? All code is written in the op function that has no access to
> internals.
>
You have example where you need short function and then argue against
whole existence of issues why procedural programming was invented in
fifties, structured programming was invented in sixties, object-oriented
programming and double dispatch were invented in seventies. The issues
are still real in real projects, and ignoring these is called code smell.
I can not be expected to teach all that knowledge of decades in one post.
Lets take step by step?

> >
> >> In particular, as I explained
> >> at the beginning, if the operation is decomposed correctly, its behavior
> >> on the objects of different types has to be coherent, similar in some
> >> way (and maybe more similar than different) and, as such, a significant
> >> parts of the context or results of intermediate computations could be
> >> shared.
> >
> > Translating data hierarchy to xml for particular version of particular
> > protocol while supporting several such in parallel?
>
> Imagine {ABCD) type hierarchy above is to be translated to XML and B and
> C have to become XML elements with some non-trivially computable
> attribute atr1 but XML elements produced from A and D don't need it.
>
Because different endpoints (for what you form the XML) want different
data, one wants like you describe ... other does not want atr1 for A and B
.... while third does not want information about D to be ever sent to it.
Now you have 3 different visitors making XML for each endpoint and any
logic in base visitor about first hurts other two.

> > There can be
> > intermediate computations shared but all are typically in in visitor
> > classes or helpers of those. No one wants the classes in hierarchy
> > to know anything about xml whatsoever,
> correct but do not see how it is connected to anything I wrote
> > nothing to talk about
> > particular brand used in particular version of kinds of end-points.
> let's not argue with anything I did not say, it's really irritating, I
> will gladly give you an example, just explain why {ABCD} above is no good..
>
I tried to.

> >
> >> I demonstrated this in my example with red and green borders: a)
> >> a condition by area prevents visitor from operating on objects is
> >> computed from their property that is orthogonal to their dynamic type;
> >> and b) the exact behavior of the operation (red vs green border in the
> >> example) depends on a subset of types (which, in general, is not
> >> necessarily compact in the hierarchy).
> >>
> > Your example did not need visitor pattern.
>
> No example "needs" visitor pattern: any problem solved with visitor can
> be solved in other ways, e.g. just by adding a virtual method to every
> class. But *both* my examples could be perfectly solved with visitor. If
> the one-time scaffolding is in place, I am ready to argue it is a good
> solution.
>
True about adding virtual method, just that adding 3 virtual functions for XML
generation code into every class will clutter code of those classes.
Especially if you want (some of) same classes to be used in other project
that does not communicate with said end-points at all.

> >
> >>> Think why virtual methods were added? To get rid of switch cases over type.
> >> Of course, not. Virtual methods were *used*, with less or greater
> >> success, to replace switch statements in event-processing scenarios
> >> (like window behavior) (with greater success) or in state machines (with
> >> lesser success).
> >>
> >> But, they were *invented* to implement polymorphic behavior and
> >> relatively loose coupling (generally, lesser dependencies) between the
> >> code that calls the method and the code that implements the method.
> >>
> > Same loose coupling is with code that calls function that does switch
> > case over type, so that kind of victory wasn't achieved.
>
> There is no such thing as "coupling in general".

On Friday, 25 August 2023 at 15:21:43 UTC+3, Michael S wrote:
> On Sunday, August 20, 2023 at 4:55:56 PM UTC+3, wij wrote:
> > I found a C++ example https://refactoring.guru/design-patterns/visitor/cpp/example
> > but I still don't understand what it tries to say and the example code don't compile.
> > Can anyone explain the visitor pattern or better webpages?
> > probably making the example compile may help, thanks in advance.
>
> After trying, with limited success, to follow the discussion between Öö Tiib and Pavel,
> I am coming to conclusion that continued ignorance about Visitor Pattern is best both
> for my blood pressure and for my programming skills.
>
Brilliant decision. Over the decades I have couple times seen visitor misused in
manner that turned the part of code base very hard to maintain. Team members
changed 2 story-point estimation into 20 each time someone realised "but hey,
then we need to change logic in ####Visitor." It had defective dispatch and then
it needed maintenance that made it to grow into kind of cancer no one dared to
touch.

Öö Tiib wrote:
> On Friday, 25 August 2023 at 06:12:09 UTC+3, Pavel wrote:
>> Öö Tiib wrote:
>>> On Thursday, 24 August 2023 at 08:39:04 UTC+3, Pavel wrote:
>>>> Öö Tiib wrote:
>>>>> On Tuesday, 22 August 2023 at 05:55:32 UTC+3, Pavel wrote:
>>>>>> Öö Tiib wrote:
>>>>>>> On Monday, 21 August 2023 at 01:02:21 UTC+3, Pavel wrote:
>>>>>>>> Öö Tiib wrote:
>>>>>>>>> On Sunday, 20 August 2023 at 21:13:01 UTC+3, Pavel wrote:
>>>>>>>>>
>>>>>>>>>> 1. Ensure all objects have a common base class (say, it's B)
>>>>>>>>>
>>>>>>>>> Not needed.
>>>>>>>>>
>>>>>>>>>> 2. create an abstract class Visitor with an abstract method doOp with an
>>>>>>>>>> arg of type [ref to] B.
>>>>>>>>>
>>>>>>>>> Nope, pile of overloads of doOp one for each type processed.
>>>>>>>>
>>>>>>>> This would render the pattern useless as has no advantage over adding a
>>>>>>>> virtual method to do the op. The rationale of the pattern is to permit
>>>>>>>> coding one op in one place.
>>>>>>>>
>>>>>>> The Visitor class is that "one place"; doing same operation lets say printing
>>>>>>> of 50 types in one function results with huge function that is headache
>>>>>>> not advantage. Separate functions are testable and maintainable.
>>>>>>>
>>>>>>>>> Otherwise
>>>>>>>>> how you process different types differently?
>>>>>>>> I explained this in the problem statement. "Given [a ref to] any such
>>>>>>>> object, you are able to
>>>>>>>> compute its type and/or call a virtual method".
>>>>>>>
>>>>>>> IOW you do huge switch typeid ... case static_ cast or have the virtual
>>>>>>> method (over what we were "gaining advantage") already there?
>>>>>>
>>>>>> Even a switch with 30 cases is no worse than 30 methods although switch
>>>>>> is not always necessary (try to read the above instead of imagining).
>>>>>>
>>>>> Visitor is typically used to search, filter, draw or print whole data object
>>>>> hierarchy, convert to JSON to XML or to tree in GUI.
>>>> correct
>>>>> If whole data hierarchy
>>>>> is small then you get 30 cases. Switch case is worse than virtual methods.
>>>>
>>>> *In general* neither is better or worse.
>>>
>>> Switch case over type is in general worse than virtual functions. Longer
>>> function,
>> Longer than what? Definitely the one function is shorter than the sum of
>> the length of all the element type hierarchy shims plus concrete visitor
>> visit overloads.
>>
>>> bigger cyclomatic complexity,
>> with good code organization, no bigger than absolutely necessary.
>>
>>> harder to understand, with good code organization, actually, easier (see my point below about
>> maintenance.
>>> harder to
>>> form confidence that it is valid,
>> see below in maintenance.
>>
>>> harder to maintain,
>> actually, easier to maintain. For using that GoF / wiki DD
>> implementation, non-insignificant amount of scaffolding code has to be
>> written. Especially in a complex hierarchy, one can easily forget to
>> write that accept shim for a couple of classes where it is needed. E.g.
>> if in the hierarchy (or a part thereof) is "(B, C, D) > A" (> meaning
>> inheritance), imagine the op shall do same on A and D but different on B
>> and C. Isn't it easy to forget to add the accept shim to C (even though
>> the actual logic visit(C), at which the programmer is likely to focus,
>> is written all right).
>>
> Can't.
??? You forgot to add accept function to C. Then your object of dynamic
type C will be happily dispatched to VisitorX::visitElementA by A::accept.

You can not leak knowledge of particular operation implemented
> by VisitorX that happens to be same for A and D into base visitor. Base
> visitor has to have all. Something like:
> virtual doOp(A& a) {std::abort();}
> virtual doOp(B& b) {std::abort();}
> virtual doOp(C& c) {std::abort();}
> virtual doOp(D& d) {std::abort();}
>
> It is because different operation implemented by VisitorY may be
> same for A and B and different for C and D. You can only leave out
> handling of D in derived visitor if D is never processed by that visitor,
> so std::abort() suits you.
what do argue against?

>
>>> harder to test and
>> why?
>>> also may need more access to implementation details of all types
>>> involved, breaking encapsulation.
>> How so? All code is written in the op function that has no access to
>> internals.
>>
> You have example where you need short function and then argue against
> whole existence of issues why procedural programming was invented in
> fifties, structured programming was invented in sixties, object-oriented
> programming and double dispatch were invented in seventies. The issues
> are still real in real projects, and ignoring these is called code smell.
> I can not be expected to teach all that knowledge of decades in one post.
> Lets take step by step?
You are still to provide an example. For now, there nothing to take
apart step by step except for my code that you are not even trying to
take apart.

>
>>>
>>>> In particular, as I explained
>>>> at the beginning, if the operation is decomposed correctly, its behavior
>>>> on the objects of different types has to be coherent, similar in some
>>>> way (and maybe more similar than different) and, as such, a significant
>>>> parts of the context or results of intermediate computations could be
>>>> shared.
>>>
>>> Translating data hierarchy to xml for particular version of particular
>>> protocol while supporting several such in parallel?
>>
>> Imagine {ABCD) type hierarchy above is to be translated to XML and B and
>> C have to become XML elements with some non-trivially computable
>> attribute atr1 but XML elements produced from A and D don't need it.
>>
> Because different endpoints (for what you form the XML) want different
> data, one wants like you describe ... other does not want atr1 for A and B
> ... while third does not want information about D to be ever sent to it.
> Now you have 3 different visitors making XML for each endpoint and any
> logic in base visitor about first hurts other two.
What does your "Because" refer to? There is no "why" in my text (and no
question mark at all). I thought you disliked walls of words? What are
"endpoints"? I do not understand what "make XML for an endpoint" means.
I likely format XML to whatever output stream the visitor caller
provides. If that stream is an endpoint, what significance it has to
this discussion?

>
>>> There can be
>>> intermediate computations shared but all are typically in in visitor
>>> classes or helpers of those. No one wants the classes in hierarchy
>>> to know anything about xml whatsoever,
>> correct but do not see how it is connected to anything I wrote
>>> nothing to talk about
>>> particular brand used in particular version of kinds of end-points.
>> let's not argue with anything I did not say, it's really irritating, I
>> will gladly give you an example, just explain why {ABCD} above is no good.
>>
> I tried to.
No, your words above do not refer to my argument even grammatically.

>
>>>
>>>> I demonstrated this in my example with red and green borders: a)
>>>> a condition by area prevents visitor from operating on objects is
>>>> computed from their property that is orthogonal to their dynamic type;
>>>> and b) the exact behavior of the operation (red vs green border in the
>>>> example) depends on a subset of types (which, in general, is not
>>>> necessarily compact in the hierarchy).
>>>>
>>> Your example did not need visitor pattern.
>>
>> No example "needs" visitor pattern: any problem solved with visitor can
>> be solved in other ways, e.g. just by adding a virtual method to every
>> class. But *both* my examples could be perfectly solved with visitor. If
>> the one-time scaffolding is in place, I am ready to argue it is a good
>> solution.
>>
> True about adding virtual method, just that adding 3 virtual functions for XML
> generation code into every class will clutter code of those classes.
You are essentially repeating arguments for Visitor from
advantage/drawback statements on my first post. What purpose is this
repetition supposed to serve in this discussion?

Bonita Montero wrote:
> Am 25.08.2023 um 02:02 schrieb Pavel:
>
>> Are you saying that, for whatever cause (like making Visitor more
>> IoC-ish) you are willing to drastically narrow the class of problems
>> that the pattern commonly-known as Visitor is believed to solve?
>
> I suggested a way to make the vistitor pattern implementable with much
> less code and more maintainable. The visitor neither need an addtional
> base-class and implementation class.
Visitor does not need anything, it simply solves a particular class of
problems that happens to include a structure of objects of multiple
types. Your visitor implementation is invalid if it cannot solve a valid
visitor problem.

Michael S wrote:
> On Sunday, August 20, 2023 at 4:55:56 PM UTC+3, wij wrote:
>> I found a C++ example https://refactoring.guru/design-patterns/visitor/cpp/example
>> but I still don't understand what it tries to say and the example code don't compile.
>> Can anyone explain the visitor pattern or better webpages?
>> probably making the example compile may help, thanks in advance.
>
> After trying, with limited success, to follow the discussion between Öö Tiib and Pavel,
> I am coming to conclusion that continued ignorance about Visitor Pattern is best both
> for my blood pressure and for my programming skills.
>
You are right, no good deed goes unpunished. I should have known better.

-Pavel

Am 26.08.2023 um 07:05 schrieb Pavel:

> Visitor does not need anything, it simply solves a particular class
> of problems that happens to include a structure of objects of multiple
> types. Your visitor implementation is invalid if it cannot solve a valid
> visitor problem.

Either I didn't describe the difference to what you imagine correctly
or you just didn't understand me. In the Visitor pattern, the Visitor
needs a base class with a virtual method to derive from, and the derived
object is passed by reference to the Visitor function of the objects
being visited. However, the derived and the base class are superfluous
with functional programming. Since C++11 you can simply request a
function<> object and conveniently you just pass a lambda that when
called, a temporary function<> object is created that represents the
interface to the object that can be visited.

On Sat, 26 Aug 2023 09:24:35 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 26.08.2023 um 07:05 schrieb Pavel:
>
>> Visitor does not need anything, it simply solves a particular class
>> of problems that happens to include a structure of objects of multiple
>> types. Your visitor implementation is invalid if it cannot solve a valid
>> visitor problem.
>
>Either I didn't describe the difference to what you imagine correctly
>or you just didn't understand me. In the Visitor pattern, the Visitor
>needs a base class with a virtual method to derive from, and the derived
>object is passed by reference to the Visitor function of the objects
>being visited. However, the derived and the base class are superfluous
>with functional programming. Since C++11 you can simply request a
>function<> object and conveniently you just pass a lambda that when
>called, a temporary function<> object is created that represents the
>interface to the object that can be visited.

This sort of programming is the equivalent of touchscreens in cars - looks
great and impresses the "Ooo shiny!" crowd but adds little to the main
functionality of the car and just adds needless complexity with more scope for
failure.

Am 26.08.2023 um 10:01 schrieb Muttley@dastardlyhq.com:

> This sort of programming is the equivalent of touchscreens in cars - looks
> great and impresses the "Ooo shiny!" crowd but adds little to the main
> functionality of the car and just adds needless complexity with more scope
> for failure.

My solution is less complexity because you don't need to declare
a base class and a derived class. Just declare the parameter as
a function object and pass a lambda which is automatically crated.
That's for sure at maximally the tenth of the code.
You can have functional programming in C++ since 2011. That's a
long time you didn't notice its potential.

On Sat, 26 Aug 2023 11:29:34 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 26.08.2023 um 10:01 schrieb Muttley@dastardlyhq.com:
>
>> This sort of programming is the equivalent of touchscreens in cars - looks
>> great and impresses the "Ooo shiny!" crowd but adds little to the main
>> functionality of the car and just adds needless complexity with more scope
>> for failure.
>
>My solution is less complexity because you don't need to declare
>a base class and a derived class. Just declare the parameter as
>a function object and pass a lambda which is automatically crated.
>That's for sure at maximally the tenth of the code.
>You can have functional programming in C++ since 2011. That's a
>long time you didn't notice its potential.

People who say you can have functional programming in C++ don't understand
functional programming. Its more than just no cost recursion , its also
polymorphism by *VALUE*. That is not and probably never will be possible in
C++.

Am 26.08.2023 um 17:00 schrieb Muttley@dastardlyhq.com:

> People who say you can have functional programming in C++ don't understand
> functional programming. Its more than just no cost recursion , its also
> polymorphism by *VALUE*. ...

That's what I described and you didn't notice it. A function<>-object
is always polymorphic. I bet you never used function<>-objects in C++.

On Sat, 26 Aug 2023 17:08:15 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 26.08.2023 um 17:00 schrieb Muttley@dastardlyhq.com:
>
>> People who say you can have functional programming in C++ don't understand
>> functional programming. Its more than just no cost recursion , its also
>> polymorphism by *VALUE*. ...
>
>That's what I described and you didn't notice it. A function<>-object
>is always polymorphic. I bet you never used function<>-objects in C++.

Given they're necessary for the STL what do you think?

Which part of "by value" is confusing you? But if you insist on claiming its
possible show us how you'd do polymorphism for a function with a single int
param for say the values 0, 2, 3, 10 -> 100 and a default.

Am 26.08.2023 um 17:15 schrieb Muttley@dastardlyhq.com:
> On Sat, 26 Aug 2023 17:08:15 +0200
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 26.08.2023 um 17:00 schrieb Muttley@dastardlyhq.com:
>>
>>> People who say you can have functional programming in C++ don't understand
>>> functional programming. Its more than just no cost recursion , its also
>>> polymorphism by *VALUE*. ...
>>
>> That's what I described and you didn't notice it. A function<>-object
>> is always polymorphic. I bet you never used function<>-objects in C++.
>
> Given they're necessary for the STL what do you think?
>
> Which part of "by value" is confusing you? But if you insist on claiming its
> possible show us how you'd do polymorphism for a function with a single int
> param for say the values 0, 2, 3, 10 -> 100 and a default.

You can't describe what you want and you don't understand function<>
-objects. Stick with C.

Am 26.08.2023 um 17:15 schrieb Muttley@dastardlyhq.com:
> On Sat, 26 Aug 2023 17:08:15 +0200
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 26.08.2023 um 17:00 schrieb Muttley@dastardlyhq.com:
>>
>>> People who say you can have functional programming in C++ don't understand
>>> functional programming. Its more than just no cost recursion , its also
>>> polymorphism by *VALUE*. ...
>>
>> That's what I described and you didn't notice it. A function<>-object
>> is always polymorphic. I bet you never used function<>-objects in C++.
>
> Given they're necessary for the STL what do you think?
>
> Which part of "by value" is confusing you? But if you insist on claiming its
> possible show us how you'd do polymorphism for a function with a single int
> param for say the values 0, 2, 3, 10 -> 100 and a default.
>

Somehow you are also quite disturbed. I wanted to tell nru that the
visitor pattern in C++ can be greatly simplified with a c++11 function<>
object and you are offended by this mere statement that you have to
explain the possibilities of C++11 as insufficient at this point to
put you above me. The therapist that matches you has yet to be born.

On Sat, 26 Aug 2023 17:24:00 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 26.08.2023 um 17:15 schrieb Muttley@dastardlyhq.com:
>> On Sat, 26 Aug 2023 17:08:15 +0200
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 26.08.2023 um 17:00 schrieb Muttley@dastardlyhq.com:
>>>
>>>> People who say you can have functional programming in C++ don't understand
>>>> functional programming. Its more than just no cost recursion , its also
>>>> polymorphism by *VALUE*. ...
>>>
>>> That's what I described and you didn't notice it. A function<>-object
>>> is always polymorphic. I bet you never used function<>-objects in C++.
>>
>> Given they're necessary for the STL what do you think?
>>
>> Which part of "by value" is confusing you? But if you insist on claiming its
>> possible show us how you'd do polymorphism for a function with a single int
>> param for say the values 0, 2, 3, 10 -> 100 and a default.
>
>You can't describe what you want and you don't understand function<>
>-objects. Stick with C.

Translation: I can't do it because its not possible but don't have the balls
to admit I was wrong.

Go back to writing your next piece of lame shit code to post on here in order
to show off.

Am 26.08.2023 um 17:36 schrieb Muttley@dastardlyhq.com:
> On Sat, 26 Aug 2023 17:24:00 +0200
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 26.08.2023 um 17:15 schrieb Muttley@dastardlyhq.com:
>>> On Sat, 26 Aug 2023 17:08:15 +0200
>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>> Am 26.08.2023 um 17:00 schrieb Muttley@dastardlyhq.com:
>>>>
>>>>> People who say you can have functional programming in C++ don't understand
>>>>> functional programming. Its more than just no cost recursion , its also
>>>>> polymorphism by *VALUE*. ...
>>>>
>>>> That's what I described and you didn't notice it. A function<>-object
>>>> is always polymorphic. I bet you never used function<>-objects in C++.
>>>
>>> Given they're necessary for the STL what do you think?
>>>
>>> Which part of "by value" is confusing you? But if you insist on claiming its
>>> possible show us how you'd do polymorphism for a function with a single int
>>> param for say the values 0, 2, 3, 10 -> 100 and a default.
>>
>> You can't describe what you want and you don't understand function<>
>> -objects. Stick with C.
>
> Translation: I can't do it because its not possible but don't have the balls
> to admit I was wrong.

Of course I can't do that because your requirements are too diffuse.

>
> Go back to writing your next piece of lame shit code to post on here in order
> to show off.
>

Tiib <ootiib@hot.ee> writes:

> Double dispatch was first perhaps described by Dan Ingalls in
> seventies

Do you have a reference for that?

> in context of SmallTalk ... [...]

It's Smalltalk, not SmallTalk.

On Sunday, 27 August 2023 at 07:26:52 UTC+3, Tim Rentsch wrote:
> Tiib <oot...@hot.ee> writes:
>
> > Double dispatch was first perhaps described by Dan Ingalls in
> > seventies
>
> Do you have a reference for that?
>
No ... GitHub contains one from eighties; can be I misremembered:
<https://algoritmos-iii.github.io/assets/bibliografia/simple-technique-for-handling-multiple-polymorphism.pdf>

> > in context of SmallTalk ... [...]
>
> It's Smalltalk, not SmallTalk.

On Sunday, August 20, 2023 at 10:22:48 PM UTC+8, Öö Tiib wrote:
>...
> Unsure ... people's mind does not grasp double dispatch too well.

This is because people's mind is not depending on such academical concept 'double dispatch'.
I think many people might be interested in the visitor pattern. So, this is my
understanding from a usecase of virtual class, e.g.

class class Element {
public:
virtual void act(Actor &a) = 0; // act==accept
};

class ThingA : public Element { /* omitted */ }
class ThingB : public Element { /* omitted */ }
class ThingC : public Element { /* omitted */ }

int main() {
// The usecase of Element family should normally for something like the list[] below:
Element *list[3]= { new ThingA, new ThingB, new ThingC };

// By now, because only the act(..) member is available, the common usage
// pattern is like the following tow 'for' loops:

for(int i=0; i<3; ++i) { // Ask elements in list[] to do someting (SomeAct1)
list[i]->act(SomeAct1);
}

for(int i=0; i<3; ++i) { // Ask elements in list[] to do someting (SomeAct2)
list[i]->act(SomeAct2);
}

// That something SomeAct1,SomeAct2 are derived from Visitor and defined by user
// This is main point of Visitor Pattern, separates the implement of Element and SomeAct.
}

On Sunday, 27 August 2023 at 23:13:36 UTC+3, wij wrote:
> On Sunday, August 20, 2023 at 10:22:48 PM UTC+8, Öö Tiib wrote:
> >...
> > Unsure ... people's mind does not grasp double dispatch too well.
>
> This is because people's mind is not depending on such academical concept 'double dispatch'.
> I think many people might be interested in the visitor pattern. So, this is my
> understanding from a usecase of virtual class, e.g.
>
Yes, your understanding of use-case is correct, just that the data hierarchy
of a program is usually not a flat list. It is usually something like tree or directed
graph without cycles.

For example list of devices (of different types), every device has list of parameters
(of different types) and list of optional submodules/peripherals connected (of
different types) that may also have options and parameters.

Also visitor is usually used when it is not about operation on one element but needs
to do some operation over all that tree or some subtree of it.

So for above example about devices the visitors can be like that ...
One visitor wants to visit all that data to find out total current and maximum power
consumption of configuration of devices.
Second visitor wants to figure on what temperatures the devices and peripherals
operate.
Third wants to find what kind of backup devices need to be in warehouse for
urgently fix the setup.
Fourth wants to store all current configurable parameter values of the set.
Fifth wants to compose command sequence to turn all the devices off in
fastest and safest manner.

Tiib <ootiib@hot.ee> writes:

> On Sunday, 27 August 2023 at 07:26:52 UTC+3, Tim Rentsch wrote:
>
>> Tiib <oot...@hot.ee> writes:
>>
>>> Double dispatch was first perhaps described by Dan Ingalls in
>>> seventies
>>
>> Do you have a reference for that?
>
> No ... GitHub contains one from eighties; can be I misremembered:
> <https://algoritmos-iii.github.io/assets/bibliografia/
> simple-technique-for-handling-multiple-polymorphism.pdf>

Thank you, that's a good reference.

On Monday, August 28, 2023 at 3:14:04 PM UTC+8, Öö Tiib wrote:
> On Sunday, 27 August 2023 at 23:13:36 UTC+3, wij wrote:
> > On Sunday, August 20, 2023 at 10:22:48 PM UTC+8, Öö Tiib wrote:
> > >...
> > > Unsure ... people's mind does not grasp double dispatch too well.
> >
> > This is because people's mind is not depending on such academical concept 'double dispatch'.
> > I think many people might be interested in the visitor pattern. So, this is my
> > understanding from a usecase of virtual class, e.g.
> >
> Yes, your understanding of use-case is correct, just that the data hierarchy
> of a program is usually not a flat list. It is usually something like tree or directed
> graph without cycles.
>
> For example list of devices (of different types), every device has list of parameters
> (of different types) and list of optional submodules/peripherals connected (of
> different types) that may also have options and parameters.
>
> Also visitor is usually used when it is not about operation on one element but needs
> to do some operation over all that tree or some subtree of it.
>
> So for above example about devices the visitors can be like that ...
> One visitor wants to visit all that data to find out total current and maximum power
> consumption of configuration of devices.
> Second visitor wants to figure on what temperatures the devices and peripherals
> operate.
> Third wants to find what kind of backup devices need to be in warehouse for
> urgently fix the setup.
> Fourth wants to store all current configurable parameter values of the set.
> Fifth wants to compose command sequence to turn all the devices off in
> fastest and safest manner.

I am writing a stave music parser program. Stave music is actually a small
script language similar to average programming language, there is conditional
control flow and stave's 'environment' need to be traced. I am happy the
visitor pattern is learnt and used immediately. The parser part is reduced form
complex 10k lines of codes to 2k simple codes and done fast, just these several days.

In my case, the list[] array structure is enough since this part of program is
just a parser. The tree,graph,... structure of the 'Element' is left for user
to interpret (the visitor can be a printer or different sound devices).

I think that's my final solution. Currently I store the bits in
size_ts and I look up the next set bit with countr_zero which maps
to TZCNT on x64 and according to some small code on godbolt ARM
also has a proper instruction for that.
Resettig the bits for the composites is done by a rotating bit-mask.
If the prime is less than size_t * 8 there's a special case optimi-
zation.

#include <iostream>
#include <vector>
#include <charconv>
#include <string_view>
#include <algorithm>
#include <fstream>
#include <cctype>
#include <cstring>
#include <bit>

#if defined(_MSC_VER)
#pragma warning(disable: 26495) // uninitialized member
#endif
#if defined(__llvm__)
#pragma clang diagnostic ignored "-Wdangling-else"
#endif

using namespace std;

int main( int argc, char **argv )
{ constexpr size_t BUF_SIZE = 0x100000;
try
{
size_t end;
if( argc < 2 )
return EXIT_FAILURE;
char const *sizeStr = argv[1];
bool hex = sizeStr[0] == '0' && (sizeStr[1] == 'x' || sizeStr[1] == 'X');
sizeStr += 2 * hex;
if( from_chars_result fcr = from_chars( sizeStr, sizeStr + strlen(
sizeStr ), end, !hex ? 10 : 16 ); (bool)fcr.ec || *fcr.ptr )
return EXIT_FAILURE;
if( !++end )
throw bad_alloc();
using word_t = size_t;
constexpr size_t BITS = sizeof(word_t) * 8;
size_t bEnd = (end + BITS - 1) & -(ptrdiff_t)BITS;
if( bEnd < end )
throw bad_alloc();
union ndi_word_t { word_t w; ndi_word_t( word_t w ) : w( w ) {} };
using bit_vec = vector<ndi_word_t>;
using bit_it = bit_vec::iterator;
bit_vec sieve( (end + BITS - 1) / BITS, (word_t)0xAAAAAAAAAAAAAAAAu );
ofstream ofs;
union ndi_t { char c; ndi_t() {} };
using ndi_vec = vector<ndi_t>;
constexpr size_t AHEAD = 32;
ndi_vec printBuf;
ndi_vec::iterator bufBegin, bufEnd, bufFlush;
if( argc < 3 || *argv[2] )
{
ofs.exceptions( ofstream::failbit | ofstream::badbit );
ofs.open( argc >= 3 ? argv[2] : "primes.txt", ofstream::trunc );
printBuf.resize( BUF_SIZE + AHEAD - 1 );
bufBegin = printBuf.begin();
bufEnd = bufBegin;
bufFlush = bufBegin + BUF_SIZE;
}
auto print = [&]() { ofs << string_view( &to_address( bufBegin )->c,
&to_address( bufEnd )->c ); };
bit_it const pSieveEnd = sieve.end();
size_t sqr = (ptrdiff_t)ceil( sqrt( (ptrdiff_t)end ) );
for( size_t p = 2; p < end; )
{
if( ofs.is_open() )
{
auto [ptr, ec] = to_chars( &bufEnd->c, &to_address( bufEnd + (AHEAD
- 1) )->c, p );
if( (bool)ec ) [[unlikely]]
throw system_error( (int)ec, generic_category(), "converson failed" );
bufEnd = ptr - &bufBegin->c + bufBegin; // NOP
bufEnd++->c = '\n';
if( bufEnd >= bufFlush )
ofs << string_view( &to_address( bufBegin )->c, &to_address( bufEnd
)->c ),
bufEnd = bufBegin;
}
if( ++p == end ) [[unlikely]]
break;
for( bit_it pSieve = sieve.begin() + p / BITS; ; )
{
size_t g = countr_zero( pSieve->w & (word_t)-1 << p % BITS );
p = (p & -(ptrdiff_t)BITS) + g;
if( g != BITS )
break;
if( ++pSieve == pSieveEnd )
goto end;
}
bit_it pSieve = sieve.begin();
if( size_t m = p * p; p < sqr )
if( p >= BITS ) [[likely]]
{
word_t mask = rotl( (word_t)-2, m % BITS );
do
pSieve[m / BITS].w &= mask,
mask = rotl( mask, (int)p % BITS ),
m += p;
while( m < end );
}
else
{
pSieve += m / BITS;
word_t mask = rotl( (word_t)-2, m % BITS );
do
{
word_t punch = -1, oldMask;
do
punch &= mask,
oldMask = mask,
mask = rotl( mask, (int)p );
while( mask < oldMask );
pSieve->w &= punch;
} while( ++pSieve != pSieveEnd );
}
}
end:
if( ofs.is_open() )
print();
return EXIT_SUCCESS;
}
catch( bad_alloc const & )
{
cout << "out of memory" << endl;
}
catch( ios_base::failure const & )
{
cout << "I/O error" << endl;
}
catch( system_error const &se )
{
cout << se.what() << endl;
}
}

Muttley@dastardlyhq.com wrote:
> On Sat, 26 Aug 2023 11:29:34 +0200
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 26.08.2023 um 10:01 schrieb Muttley@dastardlyhq.com:
>>
>>> This sort of programming is the equivalent of touchscreens in cars - looks
>>> great and impresses the "Ooo shiny!" crowd but adds little to the main
>>> functionality of the car and just adds needless complexity with more scope
>>> for failure.
>>
>> My solution is less complexity because you don't need to declare
>> a base class and a derived class. Just declare the parameter as
>> a function object and pass a lambda which is automatically crated.
>> That's for sure at maximally the tenth of the code.
>> You can have functional programming in C++ since 2011. That's a
>> long time you didn't notice its potential.
>
> People who say you can have functional programming in C++ don't understand
> functional programming. Its more than just no cost recursion , its also
> polymorphism by *VALUE*. That is not and probably never will be possible in
> C++.
>
Hard to believe but they were thinking of it as recently as Sep 2020,
see https://wg21.link/p1371r3

But of course, on mutable objects, pattern mathcing loses some 90% of
its use.