Sunday, January 24, 2021

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

"Öö Tiib" <ootiib@hot.ee>: Jan 24 12:50AM -0800

You just do not know C++ and On Saturday, 23 January 2021 at 19:11:12 UTC+2, Bonita Montero wrote:
> > you aren't very familiar with C++.
> Metaprogramming via macros is ugly because it is non-debuggable.
> So it should be avoided.
 
You apparently are unfamiliar with C++ programming language that
is relatively ugly engineering tool. Also you likely have no much
programming experience as it does not matter how ugly some code
is when same can't be done in some other way.
 
Your "non-debuggable" argument is also nonsense as debugging and
giving feedback about bugs is teethless without preprocessor. What
is code file name, function name, source code line number, time of
compiling ... all of that is available only from preprocessor in C++.
Bonita Montero <Bonita.Montero@gmail.com>: Jan 24 10:57AM +0100

> You apparently are unfamiliar with C++ programming language that
> is relatively ugly engineering tool. ...
 
C++ isnt gerally ugly, but metaprogramming via macros is ugly for
sure.
 
> programming experience as it does not matter how ugly some code
> is when same can't be done in some other way.
 
>ou cannot think logically. Because the opinion about whether
something is ugly has nothing to do with the experience with
a language.
And I've got a lot of experience with C++; I'm using C++ since
the beginning of the 90s.
 
> giving feedback about bugs is teethless without preprocessor. What
> is code file name, function name, source code line number, time of
> compiling ... all of that is available only from preprocessor in C++.
 
A single macro is debugged in one step - you can't step inside
it. That's huge problem.
"Öö Tiib" <ootiib@hot.ee>: Jan 24 03:06AM -0800

On Sunday, 24 January 2021 at 11:58:06 UTC+2, Bonita Montero wrote:
> > is relatively ugly engineering tool. ...
 
> C++ isnt gerally ugly, but metaprogramming via macros is ugly for
> sure.
 
Every mature C++ library starting from implementations of standard
library of C++ is literally packed full of preprocessor usage.
It is because same can't be made without preprocessor. So if
preprocesor is ugly then C++ is ugly. Q.E.D.
 
> a language.
> And I've got a lot of experience with C++; I'm using C++ since
> the beginning of the 90s.
 
You talk about different activity. For you "programming" is
"writing code", for me it is "making software that people use".
You can choose what you write or not when the only goal is just to
write it. When the goal is to achieve useful software then
you have to pursue the needed effect regardless of how "ugly"
the code is. So your lack of experience makes you to say
nonsense.
 
> > compiling ... all of that is available only from preprocessor in C++.
> A single macro is debugged in one step - you can't step inside
> it. That's huge problem.
 
Same applies here. You are talking like from different universe.
For you "debugging" is "stepping in code with debugger".
For me it is "removing defects from software". I very rarely have
to step in code for anything and if I need then it is usually because
of being written by such debugger steppors. Good code uses unit
tests to verify its correctness and what C++ unit test framework
out there does not use preprocessor?
Bonita Montero <Bonita.Montero@gmail.com>: Jan 24 01:01PM +0100

> Every mature C++ library starting from implementations of standard
> library of C++ is literally packed full of preprocessor usage.
 
No, macros aren by far not used so often as in C.
 
> you have to pursue the needed effect regardless of how "ugly"
> the code is. So your lack of experience makes you to say
> nonsense.
 
I've not a lack of experience but a better taste than you.
 
> For you "debugging" is "stepping in code with debugger".
 
No, stepping into is an important part part of debugging.
And you can't debug macros because of what I said.
"daniel...@gmail.com" <danielaparker@gmail.com>: Jan 24 08:49AM -0800

On Sunday, January 24, 2021 at 3:50:42 AM UTC-5, Öö Tiib wrote:
On Saturday, 23 January 2021 at 19:11:12 UTC+2, Bonita Montero wrote:
 
> > > of metaprogramming is only available using preprocessor.
 
> > Metaprogramming via macros is ugly because it is non-debuggable.
 
> Your "non-debuggable" argument is also nonsense
 
No, it isn't. Well designed macros that support metaprogramming
may be easy enough for a user to work with, without making mistakes,
but if the user actually did mistakenly omit a right parenthesis or
add an extra argument, any compiler error message would likely be
incomprehensible.
 
> giving feedback about bugs is teethless without preprocessor. What
> is code file name, function name, source code line number, time of
> compiling ... all of that is available only from preprocessor in C++.
 
Irrelevant to the specific point about macros for metaprogramming.
 
Öö Tiib also wrote:
 
> Perhaps you aren't very familiar with C++.
 
> You apparently are unfamiliar with C++ programming language
 
> You likely have no much programming experience
 
Have you noticed that when someone has the audacity to disagree
with one of your points of view, sometimes you respond with
disparaging comments about that person, and sometimes you
don't? Depending on who it is?
 
Daniel
Bonita Montero <Bonita.Montero@gmail.com>: Jan 24 05:59PM +0100

> but if the user actually did mistakenly omit a right parenthesis or
> add an extra argument, any compiler error message would likely be
> incomprehensible.
 
Compiler-errors aren't such a big issue, but you can't debug the
code inside a macro.
"daniel...@gmail.com" <danielaparker@gmail.com>: Jan 24 09:46AM -0800

On Sunday, January 24, 2021 at 12:00:10 PM UTC-5, Bonita Montero wrote:
> > incomprehensible.
> Compiler-errors aren't such a big issue, but you can't debug the
> code inside a macro.
 
But if the alternative to using the macro was to write a great deal of repetitive
boilerplate code, the likelihood of a run time error could be greater. I've never
actually experienced a run-time issue as a result of using a macro that
generated boilerplate code. But I concede it could happen. But why can't
you debug that? At this point you'd just be stepping through code, the
macro is gone.
 
Daniel
Richard Damon <Richard@Damon-Family.org>: Jan 24 01:17PM -0500

On 1/24/21 11:59 AM, Bonita Montero wrote:
>> incomprehensible.
 
> Compiler-errors aren't such a big issue, but you can't debug the
> code inside a macro.
 
I believe there are IDE's that will let you step through the macro
expansion to 'debug' them. You can also step through the assembly code
generated if it is an execution problem.
Bonita Montero <Bonita.Montero@gmail.com>: Jan 24 07:25PM +0100

> as a result of using a macro that generated boilerplate code. But I
> concede it could happen. But why can't you debug that? At this point
> you'd just be stepping through code, the macro is gone.
 
The cases where you need to write code into a macro are very rare.
I had it as a macro which defines different exception-classes; the
parameters were the name of the exception-class (later determined
via RTTI to be handled to the client), the superclass of the excep-
tion-class, the exception-id (just integer, also later handled to
the client) and the string for the .what-method (also handled to
the client). That was a bit more convenient as to define an excep-
tion-class for each use.
Bonita Montero <Bonita.Montero@gmail.com>: Jan 24 07:26PM +0100

> I believe there are IDE's that will let you step through the macro
> expansion to 'debug' them. You can also step through the assembly
> code generated if it is an execution problem.
 
Then you've to switch to the disassemly view.
But usually you can't step inside a macro.
"daniel...@gmail.com" <danielaparker@gmail.com>: Jan 24 10:51AM -0800

On Sunday, January 24, 2021 at 1:26:44 PM UTC-5, Bonita Montero wrote:
> > code generated if it is an execution problem.
> Then you've to switch to the disassemly view.
> But usually you can't step inside a macro.
 
Point taken. But I don't use the debugger very much :-)
 
Daniel
Ian Collins <ian-news@hotmail.com>: Jan 25 08:00AM +1300

On 25/01/2021 07:17, Richard Damon wrote:
 
> I believe there are IDE's that will let you step through the macro
> expansion to 'debug' them. You can also step through the assembly code
> generated if it is an execution problem.
 
CLion supports inspecting and stepping through macros.
 
--
Ian.
Richard Damon <Richard@Damon-Family.org>: Jan 24 03:16PM -0500

On 1/24/21 1:26 PM, Bonita Montero wrote:
>> code generated if it is an execution problem.
 
> Then you've to switch to the disassemly view.
> But usually you can't step inside a macro.
 
I could say that if you can't switch to the disassembly view to see what
is happening, can you really say that you are a fully competent programmer?
"daniel...@gmail.com" <danielaparker@gmail.com>: Jan 24 12:49PM -0800

On Sunday, January 24, 2021 at 3:16:36 PM UTC-5, Richard Damon wrote:
> > But usually you can't step inside a macro.
 
> I could say that if you can't switch to the disassembly view to see what
> is happening, can you really say that you are a fully competent programmer?
 
Is there something in Bonita's posts that suggest Bonita is not able to
switch to the disassembly view? I have a different impression from reading
other posts, where disassembly code is discussed. But there are lots of things
that we can do, but would prefer not to have to do.
 
Daniel
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 24 01:01PM -0800

On 1/24/2021 12:16 PM, Richard Damon wrote:
>> But usually you can't step inside a macro.
 
> I could say that if you can't switch to the disassembly view to see what
> is happening, can you really say that you are a fully competent programmer?
 
Well, now this reminds me of a time where a programmer, that was fluent
in x86, had to debug something. Well, he ran a mutation of his code on a
SPARC and had a deadlock. The mutation "seemingly" ran fine on a x86.
However, he only knew x86! So disassembly can mess one up if they do not
understand another architecture. Back then, I could read SPARC asm. I
knew some PPC as well. I will never forget when he asked me what the
MEMBAR instruction was all about.
Bonita Montero <Bonita.Montero@gmail.com>: Jan 24 05:49AM +0100

> Afaict, C++17 allows for over alignment. Why do you think they did that?
 
It's not necesary.
 
> I understand that, but I am really interested in keeping this as
> standard as possible. ..
 
For what purpose do you need that over-alignment ?
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 23 09:25PM -0800

On 1/23/2021 8:49 PM, Bonita Montero wrote:
>> Afaict, C++17 allows for over alignment. Why do you think they did that?
 
> It's not necesary.
 
Its really helpful.
 
 
>> I understand that, but I am really interested in keeping this as
>> standard as possible. ..
 
> For what purpose do you need that over-alignment ?
 
Did you read my posts in this thread?
Bonita Montero <Bonita.Montero@gmail.com>: Jan 24 10:51AM +0100

>>> standard as possible. ..
 
>> For what purpose do you need that over-alignment ?
 
> Did you read my posts in this thread?
 
Ok, you dont't have a purpose as everyone else here.
 
It's simply if you have such an alignment it's while you have
a much larger block to allocate and you have to put information
along with this structure offsetted someone else. But it yo do
thay you don't use new, but something like VirtualAlloc() or
mmap() or something like the kernel-facilities, wgich micht
also pin the page physically.
So there's no need for such a large alignment.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 24 12:45PM -0800

On 1/24/2021 1:51 AM, Bonita Montero wrote:
> thay you don't use new, but something like VirtualAlloc() or
> mmap() or something like the kernel-facilities, wgich micht
> also pin the page physically.
 
C++17 now gives a compiler the ability to support over alignment. I like
that.
 
 
> So there's no need for such a large alignment.
 
There are many reasons to use a "large" alignment.
 
Its nice that there is a way to create these things in standard C++.
Also, over alignment is useful wrt, say, a cacheline. Iirc, when
hyperthreading first came out one would use 128 byte cachelines, split
in two. Back then there was no way to get this without some hacks. Then
there was the 64k aliasing issue in a threads stack. So we had to use
alloca or something to offset the stack. This is back when I used to
read all of the Intel docs.
 
https://www.jaist.ac.jp/iscenter-new/mpc/altix/altixdata/opt/intel/vtune/doc/users_guide/mergedProjects/analyzer_ec/mergedProjects/reference_olh/pentium4_hh/advice4_hh/avoiding_64k_aliasing.htm
 
Humm... I really should recreate one of my older memory allocators that
relied on these large alignments. The neat part, at least to me, is the
alignment aspect can use standard C++. Rounding down to a boundary was
key to performance.
 
Also, keep in mind that there are bits to play with in these type of
"large" alignments. Exotic algorithms can use these.
Brian Wood <woodbrian77@gmail.com>: Jan 24 07:30AM -0800

On Friday, January 8, 2021 at 11:14:06 AM UTC-6, Brian Wood wrote:
> https://github.com/Ebenezer-group/onwards/commit/c08c0fce367dc01462b5a16d7799b6ecff5f3393
 
> I'm not saying stop using unique_ptr, but in this case I think
> it was a good move.
 
Are there places where you suggest I switch from
using int to size_t
 
https://github.com/Ebenezer-group/onwards
? Tia
 
 
Brian
Ebenezer Enterprises
https://webEbenezer.net.
Bonita Montero <Bonita.Montero@gmail.com>: Jan 24 05:29PM +0100

> In this change I stopped using unique_ptr and the size of
> this program decreased over 1%.
 
Wo cares about code-size of C++-programs ?
Look at table-driven exception-handling - fast but
generates a lot of "bloat" - which no one cares for.
Brian Wood <woodbrian77@gmail.com>: Jan 24 11:06AM -0800

On Sunday, January 24, 2021 at 10:30:00 AM UTC-6, Bonita Montero wrote:
> Wo cares about code-size of C++-programs ?
> Look at table-driven exception-handling - fast but
> generates a lot of "bloat" - which no one cares for.
 
Do you mean no one cares about the bloat? When
you say, "no one cares for", it can mean -- no one wants
that. Anyway, when you are an entrepreneur, you have
to care about things that some people don't care about.
 
Brian
Manfred <noname@invalid.add>: Jan 24 06:24PM +0100

On 1/23/21 11:45 PM, Jorgen Grahn wrote:
 
> Ok, but note that I wasn't really writing about what's right regarding
> getters: it was just an example of where people have preferences they
> cannot change.
 
So was I.
 
>> But I admit this may look confusing to some - when working in teams I
>> follow their coding standards, obviously.
 
> I do too, but I cannot force myself to like it, and it's a handicap.
 
To like something of this stuff is strictly related to understanding its
rationale.
So, it helps if the style does make some sense - it has a reasonable
rationale - together with being able to understand someone else's
viewpoint. Which can happen to be an interesting anthropology exercise.
 
Then there is always the weird case (e.g. "do not use smart pointers"),
where it helps to discuss it with the boss.
 
Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: Jan 24 04:50PM

Hi!
 
Making a C++ RDBMS, "neodb", that will be used by neoGFX:
 
// todo: use gtest
#include <neodb/file_database.hpp>
#include <neodb/memory_database.hpp>
 
using namespace neodb;
 
void test_file_database()
{
file_database database{ "/tmp/accounts.db" };
 
create_table<primary_key<string>>(
database,
"Companies"_s,
"Company Name"_s);
 
typedef int32_t currency;
 
create_table<primary_key<int32_t>, foreign_key<string>, currency>(
database,
"Invoices"_s,
"Invoice Number"_s,
as_foreign_key<string>{ "Company Name"_s, "Companies"_s, "Company Name"_s },
"Total"_s );
}
 
void test_memory_database()
{
memory_database database{ "Players"_s };
 
typedef int64_t score;
 
create_table<primary_key<string>, score>(
database,
"High Scores"_s,
"Player Name"_s,
"Score"_s);
}
 
Message ends.
 
/Flibble
 
--
😎
Bonita Montero <Bonita.Montero@gmail.com>: Jan 24 11:37AM +0100

Can you compile and link this:
 
#include <iostream>
#include <chrono>
#include <cstdint>
 
using namespace std;
using namespace chrono;
 
extern "C"
void pause_loop( uint64_t count );
 
int main()
{
using hrc_tp = time_point<high_resolution_clock>;
uint64_t TURNS = 1'000'000'000;
hrc_tp start = high_resolution_clock::now();
pause_loop( TURNS );
double ns = (int64_t)duration_cast<nanoseconds>(
high_resolution_clock::now() - start ).count() / (double)TURNS;
cout << ns << "ns" << endl;
}
 
PUBLIC pause_loop
 
_TEXT SEGMENT
 
pause_loop PROC
mov rax, rcx
xor rdx, rdx
mov rcx, 100
div rcx
test rax, rax
jz tail
headLoop:
REPEAT 100
pause
ENDM
sub rax, 1
jnz headLoop
tail:
test rdx, rdx
jz byebye
tailLoop:
pause
sub rdx, 1
jnz tailLoop
byebye:
ret
pause_loop ENDP
 
_TEXT ENDS
 
END
 
And run this on your Intel-CPU ?
I can't beliefe that PAUSE inappropriately fast on an Intel-CPU;
on my TR 3990X, it's about 3 clock cycles. It's used in spin-loops
and should be related to the time cacheline needs to travel from
one cache to another, and that's much more than 3 clock cycles.
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:

Post a Comment

Subscribe to: Post Comments (Atom)