Thursday, August 31, 2023

Digest for comp.lang.c++@googlegroups.com - 24 updates in 4 topics

Megumin <chrisramirez0227@gmail.com>: Aug 30 10:52PM -0700

After researching I found something that seems quite correct but I ain't implement it yet.(for this is going to be running on a hardware which can process one operation for 1024 numbers at once so using indefinite loops is not recommended)
float temp = y;
while((temp<<1)<x)temp<<=1;
while(x>y){
if(x>temp)x-=temp;
temp/=2;
}
no matter what thank you all for your insights.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 31 11:00AM +0200

Am 31.08.2023 um 07:52 schrieb Megumin:
> After researching I found something that seems quite correct but I ain't implement it yet.(for this is going to be running on a hardware which can process one operation for 1024 numbers at once so using indefinite loops is not recommended)
> float temp = y;
> while((temp<<1)<x)temp<<=1;
 
Trying to shift floats ?
 
Ben Bacarisse <ben.usenet@bsb.me.uk>: Aug 31 09:48PM +0100


> After researching I found something that seems quite correct but I
> ain't implement it yet.
 
Have you tried:
 
x - (int)(x/y) * y
 
? Obviously you might be worried about corner cases and accuracy, but
that is at least a starting point.
 
> if(x>temp)x-=temp;
> temp/=2;
> }
 
This is not valid C or C++. If can point to where you found it, maybe
we can help make some sense of what it is trying to achieve?
 
--
Ben.
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Aug 31 02:37PM -0700

> temp/=2;
> }
> no matter what thank you all for your insights.
 
Suggestion: Always compile code before posting it.
 
The "<<" operator cannot be applied to floating-point operands.
 
And indentation makes code much more legible.
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
Tim Rentsch <tr.17687@z991.linuxsc.com>: Aug 30 05:45PM -0700

>>> and I imagine a bit can be shaved off the time.
 
>> Thank you for this. Would you mind posting your code?
 
> Hmm... It's a bit of a mess... but sure. [...]
 
It looks quite okay. I haven't yet had time to look at it
closely but I look forward to doing so.
 
>> you have a reference for the Atkin/Bernstein algorithm (or even
>> better, code?)?
 
> Well, there's this: https://en.wikipedia.org/wiki/Sieve_of_Atkin
 
Excellent! And this page has a link to DJ Bernstein's fast
primes code, which is stunningly swift.
 
Thank you for both.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Aug 31 03:18AM +0100


>> Hmm... It's a bit of a mess... but sure. [...]
 
> It looks quite okay. I haven't yet had time to look at it
> closely but I look forward to doing so.
 
About 20% of the time was spent counting the primes, so I added a
population count function to the bitset operations. And there's an
obvious halving one can do on the upper bound of the first loop. That
brought the time down to about 28 seconds.
 
 
>> Well, there's this: https://en.wikipedia.org/wiki/Sieve_of_Atkin
 
> Excellent! And this page has a link to DJ Bernstein's fast
> primes code, which is stunningly swift.
 
I haven't looked at it yet. It would probably have put me off!
 
> Thank you for both.
 
You're welcome.
 
--
Ben.
Muttley@dastardlyhq.com: Aug 31 08:22AM

On Wed, 30 Aug 2023 18:31:32 +0200
>> Are you posting this code for lols?
 
>I often concatenate a small number of statements with the comma-operator
>to save screen space. I never had any issues with that. That's just a
 
To save space? Seriously??
 
>matter of personal taste. If you're noticing this until now, I'm going
 
Its not just personal taste, it makes the code harder to parse for anyone
who has to maintain it and could easily lead to logical errors if someone
modifies it and forgets to replace the ; with a , at the end.
 
>But that's just the syntax issue. My code is also superior in terms of
>safety (iterator debuggin) and performance (+2/3 more performance with
>g++ 12 and a Sklake-CPU).
 
Yes, we know how wonderful your code is after you seem to spend multiple days
on some trivial task. Obviously no one else could ever manage what you did,
you're a coding god.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 31 11:00AM +0200


> To save space? Seriously??
 
It's my taste.
 
> Its not just personal taste, it makes the code harder to parse for anyone
> who has to maintain ...
 
Not true, you just feel unsecure with that for whaterver reason.
 
> Yes, we know how wonderful your code is after you seem to spend multiple days
> on some trivial task. ...
 
The task is not trivial if you consider my solution.
You won't manage to have it that fast.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 31 11:52AM +0200


> Yes, we know how wonderful your code is after you seem to spend multiple days
> on some trivial task. Obviously no one else could ever manage what you did,
> you're a coding god.
 
I just benchmarked my code with an upper bound of 1E3 against your code
on a Skylake CPU with g++ 12 and -march=native. My code runs about 0.9s,
your code takes 5.26s. Any questions ?
scott@slp53.sl.home (Scott Lurndal): Aug 31 02:43PM


>>I often concatenate a small number of statements with the comma-operator
>>to save screen space. I never had any issues with that. That's just a
 
>To save space? Seriously??
 
cfront used to generate extensive comma laden expressions. It did
cause problems with PCC's temporary register allocation algorithms
that I had to fix back around 1989.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 31 04:57PM +0200

Am 31.08.2023 um 16:43 schrieb Scott Lurndal:
 
> cfront used to generate extensive comma laden expressions. It did
> cause problems with PCC's temporary register allocation algorithms
> that I had to fix back around 1989.
 
There's for sure no compiler that generates different code whether
you youse individual ;-separated statements or one comma-separated
statement as both are sequence points.
Muttley@dastardlyhq.com: Aug 31 03:22PM

On Thu, 31 Aug 2023 11:52:09 +0200
 
>I just benchmarked my code with an upper bound of 1E3 against your code
>on a Skylake CPU with g++ 12 and -march=native. My code runs about 0.9s,
>your code takes 5.26s. Any questions ?
 
Yes , do you have a life? My code took about 20 mins to write , you seem to
have been working on yours for over a week now.
Muttley@dastardlyhq.com: Aug 31 03:23PM

On Thu, 31 Aug 2023 11:00:06 +0200
 
>> Its not just personal taste, it makes the code harder to parse for anyone
>> who has to maintain ...
 
>Not true, you just feel unsecure with that for whaterver reason.
 
You sound like the python devs who claim there's no problem with significant
whitespace with indentation.
Muttley@dastardlyhq.com: Aug 31 03:25PM

On Thu, 31 Aug 2023 14:43:34 GMT
>>>to save screen space. I never had any issues with that. That's just a
 
>>To save space? Seriously??
 
>cfront used to generate extensive comma laden expressions. It did
 
I don't even understand why C/C++ allows comma seperation of calls in a block.
It should be restricted to a few specific locations such as inside for().
Bonita Montero <Bonita.Montero@gmail.com>: Aug 31 05:28PM +0200


> You sound like the python devs who claim there's no problem with significant
> whitespace with indentation.
 
You're too compulsive for that world.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 31 05:32PM +0200

>> your code takes 5.26s. Any questions ?
 
> Yes , do you have a life? My code took about 20 mins to write , you seem to
> have been working on yours for over a week now.
 
You complained about my code and I explained why it was more complex.
You probably have nothing more to say about that. With the questions
you usually ask about C++, I assume that you would not be able to
write such secure and performance code.
Writing performant code is part of my job. I write software for high
frequency trading, so you have to think about which constructs result
in which code and how efficient it is.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 31 05:33PM +0200


> I don't even understand why C/C++ allows comma seperation of calls in a block.
 
I think you would change the world that there are less annoyances for
you.
Muttley@dastardlyhq.com: Aug 31 03:44PM

On Thu, 31 Aug 2023 17:32:15 +0200
>Writing performant code is part of my job. I write software for high
>frequency trading, so you have to think about which constructs result
>in which code and how efficient it is.
 
HFC is far more impacted by network delays than any minor inefficiencies in
the software. Its highly I/O bound.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 31 05:50PM +0200


> HFC is far more impacted by network delays than any minor inefficiencies in
> the software. Its highly I/O bound.
 
Read the Wikipedia article about HFC then you won't need to elaborate
everything by your own ideas.
scott@slp53.sl.home (Scott Lurndal): Aug 31 04:10PM


>There's for sure no compiler that generates different code whether
>you youse individual ;-separated statements or one comma-separated
>statement as both are sequence points.
 
Are you familiar with the term non-sequitur?
 
I don't believe code generation was ever referred to in the post
you replied to, and therefore your reply is non-responsive.
scott@slp53.sl.home (Scott Lurndal): Aug 31 04:12PM


>> I don't even understand why C/C++ allows comma seperation of calls in a block.
 
>I think you would change the world that there are less annoyances for
>you.
 
pot kettle black
Ben Bacarisse <ben.usenet@bsb.me.uk>: Aug 31 09:33PM +0100


> I just benchmarked my code with an upper bound of 1E3 against your code
> on a Skylake CPU with g++ 12 and -march=native. My code runs about 0.9s,
> your code takes 5.26s. Any questions ?
 
Is the 1E3 a typo? And if not, does it mean 1000 as I would interpret
it? A prime sieve up to 1000 should be almost un-measurably fast.
 
--
Ben.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 31 08:59PM +0200

I wrote a small Win32 tool that combines time from Unix, start
from Windows and runas from Windows in one. For this I just needed
a function that processes the number of clock cycles spent by the
process into a string. I wanted to use iterator debugging as much
as possible so that the whole thing is as good as safe from out
-of-bound errors. Here is the function:
 
string formatClockCycles( uint64_t clockCycles, char separator )
{
char digits[32];
auto [end, ec] = to_chars( digits, std::end( digits ), clockCycles );
string_view svDigits( digits, end );
size_t dots = (svDigits.length() - 1) / 3;
string_view::iterator itDigits = svDigits.end();
string dottified;
dottified.resize( svDigits.length() + dots, '*' );
string::iterator itRet = dottified.end();
for( ; dots--; itDigits -= 3, itRet -= 4 )
copy( itDigits - 3, itDigits, itRet - 3 ),
itRet[-4] = separator;
copy( svDigits.begin(), itDigits, dottified.begin() );
return dottified;
}
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Aug 30 11:18PM -0400

Bonita Montero wrote:
>> backward-compatible changes to the type hierarchy **given in the
>> problem, not "needed by Visitor"**, ideally, no changes at all.
 
> You simply don't understand what I wrote.
 
Of course if you say so.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at No comments:

Wednesday, August 30, 2023

Digest for comp.lang.c++@googlegroups.com - 7 updates in 2 topics

Bonita Montero <Bonita.Montero@gmail.com>: Aug 30 01:01PM +0200

I implemented Alf's code according to my taste. The code has
about 40% the performance of my code if I don't output a file
with the numbers on Sklyake CPU with g++ 12 and -march=native.
 
#include <iostream>
#include <vector>
#include <charconv>
#include <fstream>
#include <cmath>
#include <cstring>
 
using namespace std;
 
int main( int argc, char **argv )
{
constexpr size_t BUF_SIZE = 0x100000;
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();
vector<bool> primes( end, true );
ofstream ofs;
string printBuf;
if( argc < 3 || *argv[2] )
ofs.exceptions( ofstream::failbit | ofstream::badbit ),
ofs.open( argc >= 3 ? argv[2] : "primes.txt", ofstream::trunc ),
printBuf.reserve( BUF_SIZE + 31 );
size_t sqr = (ptrdiff_t)ceil( sqrt( (ptrdiff_t)end ) );
for( size_t p = 2; p < end; ++p )
{
while( !primes[p] )
if( ++p == end )
goto end;
if( p < sqr )
{
size_t m = p * p;
do
primes[m] = false;
while( (m += p) < end );
}
if( !ofs.is_open() )
continue;
char strPrime[32];
auto [ptr, ec] = to_chars( strPrime, std::end( strPrime ), p );
if( (bool)ec ) [[unlikely]]
throw system_error( (int)ec, generic_category(), "converson failed" );
*ptr++ = '\n';
printBuf += string_view( strPrime, ptr );
if( printBuf.size() >= BUF_SIZE )
ofs << printBuf,
printBuf.resize( 0 );
}
end:
if( ofs.is_open() )
ofs << printBuf;
}
Muttley@dastardlyhq.com: Aug 30 03:38PM

On Wed, 30 Aug 2023 13:01:16 +0200
> ofs.exceptions( ofstream::failbit | ofstream::badbit ),
> ofs.open( argc >= 3 ? argv[2] : "primes.txt", ofstream::trunc ),
> printBuf.reserve( BUF_SIZE + 31 );
 
Commas as statement seperators instead of using a bracketed block? Are you
posting this code for lols?
Bonita Montero <Bonita.Montero@gmail.com>: Aug 30 06:31PM +0200

>> printBuf.reserve( BUF_SIZE + 31 );
 
> Commas as statement seperators instead of using a bracketed block?
> Are you posting this code for lols?
 
I often concatenate a small number of statements with the comma-operator
to save screen space. I never had any issues with that. That's just a
matter of personal taste. If you're noticing this until now, I'm going
to assume that you haven't really looked at the previous code.
But that's just the syntax issue. My code is also superior in terms of
safety (iterator debuggin) and performance (+2/3 more performance with
g++ 12 and a Sklake-CPU).
Bonita Montero <Bonita.Montero@gmail.com>: Aug 30 07:02PM +0200

Am 29.08.2023 um 20:34 schrieb Bonita Montero:
 
> size_t g = countr_zero( pSieve->w & (word_t)-1 << p % BITS );
 
size_t g = countr_zero( (word_t)(pSieve->w & (word_t)-1 << p % BITS) );
 
 
OMG, an integral promotion error.
If word_t is defined < unsigned the results are wrong.
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Aug 29 09:44PM -0400

> 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.
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Aug 29 10:14PM -0400

Bonita Montero wrote:
>> solve a valid visitor problem.
 
> Either I didn't describe the difference to what you imagine correctly
> or you just didn't understand me.
None of the above it is just you are not trying to read.
 
> 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.
No. Visitor needs no types. The **problems that Visitor solves** include
data structures of multiple types. The applicability of Visitor is
exactly when the programmer is limited to small backward-compatible
changes to the type hierarchy **given in the problem, not "needed by
Visitor"**, ideally, no changes at all.
 
Try to read what's written, not what you want to see.
 
I will try one more time, in negative terms, in case it makes it easier
for you to comprehend:
 
No type hierarchy in the problem -- no need in Visitor in the solution.
 
Now, "a base class with a virtual method to derive from" are just
possible implementation details for the type hierarchy, so not 100%
needed. The type hierarchy could be a variant or another type hierarchy
where the dynamic type is detectable at run-time. There must be,
however, a comprehensive type hierarchy for the Visitor to be useful.
 
What you are trying to demonstrate, on the other hand, is called a
"higher-order function" in functional programming. And, no, it does not
need a new name because it already has an industry-standard name.
 
Bonita Montero <Bonita.Montero@gmail.com>: Aug 30 06:13AM +0200

Am 30.08.2023 um 04:14 schrieb Pavel:
 
> exactly when the programmer is limited to small backward-compatible
> changes to the type hierarchy **given in the problem, not "needed by
> Visitor"**, ideally, no changes at all.
 
You simply don't understand what I wrote.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at No comments:

Monday, August 28, 2023

Digest for comp.lang.c++@googlegroups.com - 13 updates in 2 topics

Ben Bacarisse <ben.usenet@bsb.me.uk>: Aug 28 12:49AM +0100

>> tests. Shouldn't take too long.
 
> Took 14 minutes to find those 203280221 primes single threaded
> on i7-8550U.
 
What do you mean by find? Do you include printing them out because that
will depend rather more on the OS.
 
I wanted to try a newer algorithm, so I coded up a rather naive version
of Atkin & Bernstein's sieve in C. It needs some tidying and I imagine
a bit can be shaved off the time.
 
It can generate a bitmap of the 203280221 primes and then count them in
about 40 seconds on an i5-8265U CPU @ 1.60GHz (single threaded). It
takes about 55 seconds to write them (in decimal) to a file. The result
is over 2GB:
 
$ wc primes
203280221 203280221 2178719347 primes
 
--
Ben.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 28 06:15AM +0200

I optimized the code somewhat further:
 
#include <iostream>
#include <vector>
#include <charconv>
#include <string_view>
#include <algorithm>
#include <fstream>
#include <cctype>
#include <cstring>
#include <bit>
#include "ndi.h"
 
#if defined(_MSC_VER)
#pragma warning(disable: 26495) // uninitialized member
Posted by at No comments:

Saturday, August 26, 2023

Digest for comp.lang.c++@googlegroups.com - 1 update in 1 topic

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Aug 26 03:33PM -0700

On 8/23/2023 11:37 AM, Daniel wrote:
 
>> Bonita, you have a lot of experience wrt verbal assaults, right?
 
> How would you know? You don't seem to have _any_ experience of it
> yourself :-) Alf neither.
 
:^)
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at No comments:

Digest for comp.lang.c++@googlegroups.com - 25 updates in 3 topics

wij <wyniijj5@gmail.com>: Aug 26 03:01AM -0700

constexpr const char K1[]="abc";
constexpr const char K2[]="efg";
constexpr const char K3[]= ??? // "abcefg" expected
 
I'd like K3 to be "abcefg", how should I do?
"Öö Tiib" <ootiib@hot.ee>: Aug 26 03:44AM -0700

On Saturday, 26 August 2023 at 13:01:52 UTC+3, wij wrote:
> constexpr const char K2[]="efg";
> constexpr const char K3[]= ??? // "abcefg" expected
 
> I'd like K3 to be "abcefg", how should I do?
 
You can not make any functions that return char array (or whatever other
raw array) so there are no way. Raw arrays can't be passed by value in C++.
You can make std::array compile time as it can be passed.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 26 12:51PM +0200

Am 26.08.2023 um 12:01 schrieb wij:
> constexpr const char K2[]="efg";
> constexpr const char K3[]= ??? // "abcefg" expected
 
> I'd like K3 to be "abcefg", how should I do?
 
Not quite what you're looking for, but would you be happy with it?
 
#include <string_view>
 
constexpr char const *concatted = "abcdefg";
constexpr std::string_view
first( concatted, 3 ),
second( concatted + 3, 3 );
Bonita Montero <Bonita.Montero@gmail.com>: Aug 26 01:15PM +0200

Am 26.08.2023 um 12:51 schrieb Bonita Montero:
> constexpr std::string_view
>     first( concatted, 3 ),
>     second( concatted + 3, 3 );
 
Or more C++-ish:
 
constexpr std::string_view
concatted( "abcdefg" ),
first( concatted.data(), 3 ),
second( concatted.data() + 3, 3 );
wij <wyniijj5@gmail.com>: Aug 26 06:17AM -0700

On Saturday, August 26, 2023 at 6:44:44 PM UTC+8, Öö Tiib wrote:
> You can not make any functions that return char array (or whatever other
> raw array) so there are no way. Raw arrays can't be passed by value in C++.
> You can make std::array compile time as it can be passed.
 
I saw an example made for C++11, it looked strange... I don't have any idea:
(can I make the initialization of str3 successful?)
 
//-------------
// copy from https://juejin.cn/s/c%2B%2B%20concat%20constexpr%20string%20literals
//
#include <iostream>
 
constexpr const char* operator+(const char* lhs, const char* rhs) {
int size_lhs = 0, size_rhs = 0;
while (lhs[size_lhs] != '\0') ++size_lhs;
while (rhs[size_rhs] != '\0') ++size_rhs;
 
char* result = new char[size_lhs + size_rhs + 1];
int i = 0;
for (; i < size_lhs; ++i) result[i] = lhs[i];
for (int j = 0; j < size_rhs; ++j, ++i) result[i] = rhs[j];
result[i] = '\0';
 
return result;
}
 
int main() {
constexpr const char* str1 = "hello";
constexpr const char* str2 = " world";
constexpr const char* str3 = str1 + str2;
std::cout << str3 << std::endl;
return 0;
}
Bonita Montero <Bonita.Montero@gmail.com>: Aug 26 03:22PM +0200

Am 26.08.2023 um 15:17 schrieb wij:
 
> result[i] = '\0';
 
> return result;
> }
 
Why do you make a function calling new constexpr ?
wij <wyniijj5@gmail.com>: Aug 26 06:33AM -0700

On Saturday, August 26, 2023 at 9:22:18 PM UTC+8, Bonita Montero wrote:
 
> > return result;
> > }
> Why do you make a function calling new constexpr ?
 
1. I am not familiar with "constexpr"
2. The example is found on https://juejin.cn/s/c%2B%2B%20concat%20constexpr%20string%20literals , not made by me
3. I want the initialization effect like the str3 in the example
Bonita Montero <Bonita.Montero@gmail.com>: Aug 26 03:57PM +0200

Am 26.08.2023 um 15:33 schrieb wij:
 
> 1. I am not familiar with "constexpr"
 
There are three constexprs:
3. If you declare a function constexpr the compiler is requested
to compile-time evaluate the function if possible. If you have a
dynamic memory allocation that couldn't be compile-time evaluateable.
1. If you declare a variable constexpr the value assigned to it must
be compile-time evaluateable. Functions used to initialize the variable
must be constexpr and actually compile-time evaluatable.
2. If you have an if constexpr( expr ) expr must be compile-time
evaluateable. Functions called by expr must be also compie-time
evaluateable like with 2.
"Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Aug 26 10:04PM +0200

On 2023-08-26 12:01 PM, wij wrote:
> constexpr const char K2[]="efg";
> constexpr const char K3[]= ??? // "abcefg" expected
 
> I'd like K3 to be "abcefg", how should I do?
 
It depends on your requirements.
 
If you're free to use the preprocessor you can do simply
 
 
#define K1 "abc"
#define K2 "efg"
#define K3 K1 K2
 
constexpr auto& k1 = K1;
constexpr auto& k2 = K2;
constexpr auto& k3 = K3;
 
 
Easy peasy. :-)
 
- Alf
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Aug 26 12:55AM -0400

Öö Tiib wrote:
>> 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
> 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?
 
> 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.
 
> ... 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?
 
>> 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.
 
>> 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?
 
> Especially if you want (some of) same classes to be used in other project
> that does not communicate with said end-points at all.
what is "end-points"? I am addressing every your point but your
"responses" don't even refer to mine. Can you keep to the point and not
go on tangents please?
 
I will make last honest effort to structure this discussion to something
legible: do you agree that we disagree on the following points:
 
1. That my examples demonstrate adding an op to a correctly built
Visitor pattern, assuming verbally described scaffolding (I say yes, you
say no)
 
2. That any correct implementation of a Visitor pattern in C++ shall use
that specific implementation of DD that GoF and Wikipedia happen to use.
(I say no, you say yes)
 
?
 
It is the implication of my opinions on #1 and #2 above that Visitor can
be tought on smaller and more to-the-point examples. But we don't need
to argue about this until we put to bed #1 and #2. Agree?
 
>>> case over type, so that kind of victory wasn't achieved.
 
>> There is no such thing as "coupling in general".
 
> Where I said the quoted text "coupling in general"? What you mean by it?
You mentioned coupling without specifying what particular coupling you
meant in what particular code so it is impossible for me to guess what
you mean. Therefore I reasonably called your reference to coupling as
reference to "coupling in general".
 
> And why you switch to visitors when discussing benefits of virtual
> methods?
It was you who went on tangent about virtual functions asking me to
think why "virtual methods were added" and then provided incorrect
answer to your own question. I simply corrected that incorrect answer of
yours.
 
> visitor only once to every class visited, no need to add 3 virtual methods to
> generate XML for 3 different endpoints. But can't simplify from there,
> otherwise the pattern is broken.
Another bareword. How exactly this breaks the pattern? Does operation
start to behave not as specified? -- IMO, no. Do we introduce extra
participant to the pattern to "save" the desired behavior by adding
extra entity? -- IMO, no. Do we force a compilation unit depend on more
entities? -- IMO, no. So, what exactly do we break?
 
>> further operations adds zero dependencies, don't require recompilation.
 
> No class needs to be recompiled when 4th server needing obscure
> abomination of JSON is added.
When did I say the opposite? I just counted the number of dependencies
(that have to be there from the outset). Every type in the hierarchy
becomes dependent on any other type because its accept method depends on
AbstractVisitor and it has methods dependent on every type in the
hierarchy, at least its forward declaration. This may be also true for
my approach if specific type implementation is dispatched with virtual
cast function (because we need to define them at the base class) or not
if we use typeid or enum or pattern matching.
 
> you, you are not NYSE that financial institutions themselves have to care how
> to be conformant with. You are probably sucking the client-side butt holes of
> theirs.
See below why you are likely NYSE if you care about supporting different
financial institutions.
> banks (even in multiple countries)? I suggest urgently to read up on
> Silicon Valley Bank, Signature Bank, First Republic Bank and Heartland
> Tri-State Bank ... your bank may be next.
Is your purpose to throw as many tangents as needed to get me confused?
If I have account in a couple of banks, am I suppose to write a program
to do my banking?
 
>>>> calling combinations of virtual functions *from within the top-level
>>>> method implementing the operation*)
 
>>> That is not use-case of visitor pattern.
Bareword again. Nowhere in Visitor pattern rationale and motivation does
it say that it should only be used when the behavior of an op on
different hierarchy types should not have commonalities. All it says
that operations are unrelated one to another.
 
One actually has to expect there will be commonalities on applying an op
to objects of different types of the hierarchy; else why are these types
are in this same hierarchy?
 
>> many operations. I do not intend to repeat this again unless you provide
>> good reasoning.
 
> I did, you just do not read.
I read everything your wrote.
 
>> articles use same "Asteroid-Spaceship" example (DD) to exemplify either.
 
> Wikipedia is correct, but multiple dispatch is way over head when you can't
> apparently figure what is double dispatch ... so go not into multiple.
Who does not read here? Trying once again: WIKIPEDIA C++ EXAMPLES ON MD
ACTUALLY DEMONSTRATE DD. How can a simple example of MD that is DD be
over head if you insist that another example of DD (actually,
implemented in a messier manner) has to be understood first?
 
>> there is usually more functions to write; but otherwise, nothing too
>> exciting.
 
> You can't understand rectangle yet so parallelepiped is way too early.
Now your are convincing.
>> Visitor pattern in C++" is boring and error-prone enough (see above
>> about maintenance) to not be the first choice in explaining Visitor.
 
> Then you are out of luck
hah?
> as you talk about something that is not visitor
> pattern.
I do not talk about a particular implementation of it that you are so
fond of, correct.
 
> function. The visitor takes the instance reference as input, and implements
> the goal through **double dispatch**."
 
> You argue with that and GoF not me.
where? You should have emphasized the word "appropriate" rather than
"all". Double dispatch is correctly emphasized, but your fondness to one
particular kind of it does not mean there is no others.
 
> programming language. Don't confuse unrelated paradigms into
> visitor that is pattern of object-oriented programming and uses double
> dispatch.
They are only unrelated in your mind. Design patterns are not libraries,
they can be implemented in different ways and in different paradigms.
 
> dc.drawRedRectangle(br);
> }
 
> Can easily transform into free function if Shape is bad place.
 
You do repeat.. my code. Where is your beloved DD now? All of a sudden
you are checking the shape type with isConfexPolygon(). Makes sense, you
are beginning to get it. Although it is unclear why assert(isOval()); is
not supposed to fire so you have some work to do.
 
>> particular implementation as ff it were the definition.
 
> It is multiple dispatch, but do not go there as multiple dispatch you can't
> grasp yet.
very convincing. hominem unius libri timeo
 
>> and textures from an example on visitor? You are welcome to provide your
>> own code (the above does not work).
 
> It was doing exactly same as your posted code.
What is that "it"? One more nonsense and plonk your posts.
 
>> expect, not providing a single complete counterexample for the same problem.
 
> The visitor pattern examples are present in GoF book and in Wikipedia
> article. You argue with those, what is the point of me adding one more?
[plonked]
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Aug 26 01:05AM -0400

Bonita Montero wrote:
 
> 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.
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Aug 26 01:17AM -0400

Michael S wrote:
 
> 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
Bonita Montero <Bonita.Montero@gmail.com>: Aug 26 09:24AM +0200

Am 26.08.2023 um 07:05 schrieb Pavel:
 
> 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.
Muttley@dastardlyhq.com: Aug 26 08:01AM

On Sat, 26 Aug 2023 09:24:35 +0200
>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.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 26 11:29AM +0200

> 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.
Muttley@dastardlyhq.com: Aug 26 03:00PM

On Sat, 26 Aug 2023 11:29:34 +0200
>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++.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 26 05:08PM +0200


> 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++.
Muttley@dastardlyhq.com: Aug 26 03:15PM

On Sat, 26 Aug 2023 17:08:15 +0200
>> 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.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 26 05:24PM +0200


> 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.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 26 05:26PM +0200


> 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.
Muttley@dastardlyhq.com: Aug 26 03:36PM

On Sat, 26 Aug 2023 17:24:00 +0200
>> 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.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 26 05:39PM +0200

>> -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.
 
Muttley@dastardlyhq.com: Aug 26 08:03AM

On Fri, 25 Aug 2023 18:18:09 +0200
 
>>> Comment it and show that you understand it.
 
>> Sorry pal, ...
 
>That's what I expected.
 
The arrogance that you expect people to have to figure out your code then
comment on it is quite breathtaking.
 
>> If you work for a fintec then I pity the devs who will have to maintain
>> your code in the future. More than likely they'll toss it and start again.
 
>The company I work for has more skilled staff like you.
 
Ah, you think you're so much better than everyone else there. What a surprise.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 26 10:16AM +0200

>>> your code in the future. More than likely they'll toss it and start again.
 
>> The company I work for has more skilled staff like you.
 
> Ah, you think you're so much better than everyone else there. What a surprise.
 
Stick with your C code and continue to ask beginner's C++ questions.
Muttley@dastardlyhq.com: Aug 26 08:27AM

On Sat, 26 Aug 2023 10:16:48 +0200
 
>> Ah, you think you're so much better than everyone else there. What a
>surprise.
 
>Stick with your C code and continue to ask beginner's C++ questions.
 
Do carry on with your pompous assery, I'll get some popcorn :)
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at No comments:

Wednesday, August 23, 2023

Digest for comp.lang.c++@googlegroups.com - 2 updates in 1 topic

Daniel <danielaparker@gmail.com>: Aug 23 11:37AM -0700

On Wednesday, August 23, 2023 at 2:21:18 PM UTC-4, Chris M. Thomasson wrote:
 
> Bonita, you have a lot of experience wrt verbal assaults, right?
 
How would you know? You don't seem to have _any_ experience of it
yourself :-) Alf neither.
 
Daniel
scott@slp53.sl.home (Scott Lurndal): Aug 23 06:51PM


>> Its a type of paging.
 
>Paging is synchronous, i.e. the thread which pages is stopped until
>the page is fetched.
 
Actually, sometimes the operating system will anticipate a future
page fault and preload the page. Particularly on POSIX systems
that support the madvise(2) or posix_madvise(2) system call(s).
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at No comments:

Digest for comp.programming.threads@googlegroups.com - 1 update in 1 topic

Syed Faraz <syed.faraz@alchemdia.co>: Aug 23 01:14AM -0700

Nice post, it is useful for me. It is very informative. Thanks
I also found some great discount coupons that you can try.
https://gogetdeals.co.uk/
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.programming.threads+unsubscribe@googlegroups.com.
Posted by at No comments:

Tuesday, August 22, 2023

Digest for comp.lang.c++@googlegroups.com - 3 updates in 1 topic

Muttley@dastardlyhq.com: Aug 22 06:18PM

On Tue, 22 Aug 2023 20:13:17 +0200
>> cache is a total irrelevance as far as time taken is concerned.
 
>No one uses software that actually pages to disk.
>Paging is just for that the softwar doesn't crash.
 
I suggest you go and google how operating system virtual memory works.
 
>> As I said, it depends on the hardware. Try both on a Z80 and see what
>happens.
 
>Your code wasn't intended for a Z-80.
 
What was it intended for then given it was written in basic C?
 
>> Thanks for proving you're as arrogant as I thought.
 
>When you're good in sth. you often appear arrogant.
 
"sth"?
 
>> longer I suspect a lot of people on this group have been doing it a lot
>> longer than you.
 
>Maybe, but at this level.
 
At your level? Absolutely.
scott@slp53.sl.home (Scott Lurndal): Aug 22 06:24PM


>Given millions of 8 and 16 bit processors are still designed and produced for
>embedded systems that statement is nonsense and ARM based systems can use
>whatever parts they want in the CPU.
 
ARM based multicore systems generally use CMN-400/500/600/700 IP (from ARM)
as the processor interconnect.
 
https://developer.arm.com/Processors/CoreLink%20CMN-600
 
And all those 8 and 16-bit processors are single core, so your
statement above, which references "no matter how many cores"
doesn't apply to them.
 
>>mesh/ring structures into the I/O side (e.g. one host bridge per
>>PCI Express root port, one or more for on-chip accelerators, etc).
 
>Thats nice, but CPU > x86.
 
What does that mean? Every major multicore processor currently
shipping (including Apple M7+) operate as described above.
Including most mid-range and high-end application specific
system-on-chips (SoC), including those using the ARM
architecture.
 
The proceedings from https://hotchips.org/ over the last two
decades describe the state of the art.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 22 08:50PM +0200


>> No one uses software that actually pages to disk.
>> Paging is just for that the softwar doesn't crash.
 
> I suggest you go and google how operating system virtual memory works.
 
Swapping is for stability and not for performance.
No one considers running applications actually swapping.
 
> What was it intended for then given it was written in basic C?
 
You didn't write that on a Z-80.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at No comments:
Subscribe to: Posts (Atom)