Monday, July 2, 2018

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

David Brown <david.brown@hesbynett.no>: Jul 02 08:43AM +0200

On 01/07/18 18:47, Bart wrote:
> bit of AST, doing the same optimisations and the same <max> pattern
> recognition and the conversion into intrinsic versions or into optimised
> code, over and over again.
 
This extra cost - for a macro like "max" - is negligible. You can argue
that the compilation time is the sum of lots of such negligible little
parts, but you cannot reasonably claim that having an operator for max
rather than a macro will make any measurable difference to compile times.
 
And for optimising compilers, there is even less difference - because
these do not turn operators into "optimised code". They turn them into
AST's and other internal structures, combined with surrounding code, and
then optimise those. Pattern matching for turning arithmetic operations
into code sequences comes later, and does not necessarily match up with
the arithmetic operations that you had in the source code. Something
like a "max" operation is quite likely to be split into parts and then
separated by other code to improve processor scheduling.
 
> spend its time on. Implementing 'max' etc efficiently can be done once,
> instead of in N different places in a program, every time it is
> compiled, and for every other programmer and application that uses it.
 
You have that ass-backwards. Once you have a good optimiser, you no
longer have to concern yourself about trying to implement something like
"max" efficiently - the compiler will handle it smoothly already.
Tim Rentsch <txr@alumni.caltech.edu>: Jul 02 01:42AM -0700

>>>> long long : max_llong, unsigned long long : max_ullong, \
>>>> float : max_float, double : max_double, long double : max_ldouble \
>>>> )(a, b)
 
[...]
 
> the binding of the '>' operator is taken at the point at which the
> 'make_max' macro is called and not at the point where that macro is
> defined. [...]
 
I see at least three other criticisms:
 
(1) Doesn't cover all standard types;
 
(2) A bug in one of the types it does cover;
 
(3) Falls down badly in cases where the two arguments have
different types.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Jul 02 12:30AM +0100

You appear to be multi-posting in comp.lang.c and comp.lang.c++.
Multi-posting (as opposed to cross-posting) is generally regarded as bad
netiquette.
 
--
Ben.
Wouter Verhelst <w@uter.be>: Jul 02 09:02AM +0200

On 01-07-18 18:47, Bart wrote:
> bit of AST, doing the same optimisations and the same <max> pattern
> recognition and the conversion into intrinsic versions or into optimised
> code, over and over again.
 
Yeah, that's true, but who cares? If the compiler is slow during compile
time so that it can produce a fast program, I couldn't care less.
 
The resulting program will have the optimized max opcode at every place
where it is needed, and that's what matters -- not how the compiler gets
there, IMO.
 
> spend its time on. Implementing 'max' etc efficiently can be done once,
> instead of in N different places in a program, every time it is
> compiled, and for every other programmer and application that uses it.
 
As far as I'm concerned, the compiler can spend an hour optimizing a
simple "hello world" program if that means that program's runtime is cut
in half. Yes, I'm exaggerating, but you get the point.
 
Given your past statements, I'm sure you disagree with that. That's fine :-)
Tim Rentsch <txr@alumni.caltech.edu>: Jul 02 01:34AM -0700

> macro in C, if that is by using a different technique from the one I
> mentioned. I am still stuck on C89/90 as far as C pre-processors are
> concerned.)
 
There are two parts to this question - the variadic part, and
the polymorphic part.
 
The variadic part is done using preprocessor capabilities added
in C99, and which are also present in C++ (since C++11). A macro
definition of the form
 
#define X( ... ) [etc]
 
or
 
#define XX( parameter-list , ... ) [etc]
 
may use __VA_ARGS__ to refer to all the many arguments covered by
the ellipsis in the macro definition.
 
The polymorphic part is done using the type-selecting capability
provided by _Generic, which was added in C11. A use of _Generic
has a control expression, whose type is used to select from a
set of type-labeled expressions (like a 'switch()' on types),
including an optional 'default:' case in the event that no other
type-case matches.
 
Writing a variadic, polymorphic max function (or min function) is a
non-trivial exercise, along both axes. It isn't too hard to write
something that mostly works in the common cases. It's much harder
to write something that works correctly in some less common but
still important corner cases. I put something together which did a
fair job of covering a lot of the bases (and also would work in C++,
using some '#if __cplusplus' selections), and it ended up being a
fair chunk of code, even after making use of a pre-written macro
for dealing with variadicness. A full solution, covering a full
range of possibilities that the Standard(s) allow, is a significant
exercise.
Keith Thompson <kst-u@mib.org>: Jul 01 12:14PM -0700

> On 01.07.2018 11:08, Bart wrote:
[...]
 
> They corresponded directly, and still correspond, to very common
> processor instructions, and at that time it was more the programmer's
> job, and not the compiler's, to optimize the resulting machine code.
 
[...]
 
> Of course, historically that was ten years or so after development of C
> started, PC 1981 versus plain C 1971. I think the original C development
> was on a PDP-10.
 
Off-by-three error. It was a PDP-7.
 
> I had some limited exposure to the PDP-11, but all I
> remember about the assembly language was that it was peppered with @
> signs (probably indicating macros),
 
No, @ (or parentheses) indicate "deferred" addressing modes.
For example R3 refers to the R3 register, (R3) or @R3 refers to
the memory location whose address is stored in R3.
 
> and that the registers were numbered
> and memory-mapped.
 
Numbered, yes (R0..R7, where R7 is the PC (Program Counter)), but not
memory-mapped.
 
> But I'm pretty sure that if the PDP-11 didn't have
> add to register, I'd remember that. And so, presumably also the PDP-10.
 
If I recall correctly,
 
ADD #42, R0
 
would add 42 to the contents of R0 and store the sum in R0.
 
I'm less familiar with the PDP-7, but I think it also had 2-operand
instructions, where one of the operands was the target.
 
[...]
 
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 02 11:08AM -0700

On Monday, July 2, 2018 at 1:40:41 PM UTC-4, Ben Bacarisse wrote:
> You appear to be multi-posting in comp.lang.c and comp.lang.c++.
> Multi-posting (as opposed to cross-posting) is generally regarded as bad
> netiquette.
 
Who are you replying to?
 
--
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 02 11:43AM -0700

On Monday, July 2, 2018 at 1:40:41 PM UTC-4, Ben Bacarisse wrote:
> netiquette.
 
> --
> Ben.
 
I just saw in a tree view you were replying to me.
 
Yes, when you posted this message:
 
https://groups.google.com/d/msg/comp.lang.c++/Mpf93i0SEzA/ScCYIP24CQAJ
https://groups.google.com/forum/#!original/comp.lang.c++/Mpf93i0SEzA/ScCYIP24CQAJ
 
You had it set to "follow-up" only comp.lang.c even though you had
posted the message to both comp.lang.c and comp.land.c++.
 
I missed that mistake, so I posted my reply to comp.lang.c++ so it
would be in both groups.
 
--
Rick C. Hodgin
Bart <bc@freeuk.com>: Jul 02 07:51PM +0100

On 02/07/2018 08:02, Wouter Verhelst wrote:
>> code, over and over again.
 
> Yeah, that's true, but who cares? If the compiler is slow during compile
> time so that it can produce a fast program, I couldn't care less.
 
Suppose it's unnecessarily slow?
 
> As far as I'm concerned, the compiler can spend an hour optimizing a
> simple "hello world" program if that means that program's runtime is cut
> in half. Yes, I'm exaggerating, but you get the point.
 
Do you really need the maximum possible speed for the 99.9% of builds
where you are only testing or debugging? That would be rather a lot of
wasted hours.
 
But some of these overheads can impinge on build speeds even with
optimisation turned off.
 
--
bart
David Brown <david.brown@hesbynett.no>: Jul 02 09:32PM +0200

On 02/07/18 10:42, Tim Rentsch wrote:
>> defined. [...]
 
> I see at least three other criticisms:
 
> (1) Doesn't cover all standard types;
 
I'm missing bool, which could easily be added. "max" doesn't make sense
for the complex types. Are things like size_t and wchar_t always
typedef'ed (or #define'd) to standard types, or could they be different
types outside the standard integer types? I'm not sure how they would
fit with a _Generic like this - but size_t at least should be there.
 
Any others that I am missing?
 
> (2) A bug in one of the types it does cover;
 
Whoops, so there is. I can't claim it was well-tested code - it was
showing an idea, rather than being recommended real code.
 
 
> (3) Falls down badly in cases where the two arguments have
> different types.
 
Yes, that's a challenge. It will be fine if "a" is at least as big a
type as "b", but not vice versa. The only way I can think of to solve
that problem would be nested _Generic's - perhaps with a utility
_Generic macro for giving a common type for arithmetic operations on two
different types. However it is done, it would be ugly.
Vir Campestris <vir.campestris@invalid.invalid>: Jul 01 10:40PM +0100

On 30/06/2018 19:09, jacobnavia wrote:
> __index, so there is no way to do that C like code with the new syntax.
 
> We lost the index with the new syntax.
 
> Or I am just wrong and I have overlooked something?
 
Use the old syntax. Then you can type i +=2 to skip the alternate ones.
 
Andy
jacobnavia <jacob@jacob.remcomp.fr>: Jul 02 09:29PM +0200

Le 01/07/2018 à 23:40, Vir Campestris a écrit :
> Use the old syntax. Then you can type i +=2 to skip the alternate ones.
 
Why is the index not included as info with the new syntax?
 
Yes, you can figure it out, as several people pointed me to a simple
solution, so its not a big deal.
 
Of course you can do i += 2, but I ws thinking in terms of a filter
going through all records according to some criteria. An easy criteria
was using the index, but that was a very bad example.
 
Thanks
Tim Rentsch <txr@alumni.caltech.edu>: Jul 01 07:07PM -0700


> will compile, but be ineffective - most annoyingly, /silently/
> ineffective (unless you have a compiler that can catch this stuff, and
> you instruct it to do so).
 
Yes! I had exactly this happen to me while I was looking
at alternatives to the original posting.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 01 10:58PM +0200

On 01.07.2018 13:35, Manfred wrote:
> With_stream_detection) is hanging on the obscure '_' member - and one
> has to think about the guarantee that this actually ensures that the
> whole object is kept alive.
 
Well, let me shock you a little. :)
 
#include <iostream>
using namespace std;
 
struct Balalaika
{
char const _ = '-';
Balalaika() { cout << "Start\n"; }
~Balalaika() { cout << "End\n"; }
};
 
auto main()
-> int
{
char const& surely_a_nice_interview_question = Balalaika{}._;
cout << "The middle of main is that in Spain or this all in
vain?\n";
}
 
Cheers!,
 
- Alf
Manfred <noname@invalid.add>: Jul 02 08:42PM +0200

On 7/1/2018 10:58 PM, Alf P. Steinbach wrote:
>         cout << "The middle of main is that in Spain or this all in
> vain?\n";
>     }
 
I know, which requires:
a) n4659 11.6.3 sub(5.2).
b) n4659 15.2 sub6, with its good list of exceptions.
 
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 01 11:09PM +0200

asd
Soviet_Mario <SovietMario@CCCP.MIR>: Jul 02 05:13PM +0200

Il 01/07/2018 19:45, Paavo Helde ha scritto:
 
> First you need to figure out if these were compiler errors
> or linker errors as this will narrow the location of the bug
> (in broad terms, is the problem in .h or in .cpp files).
 
I'm not sure ... I append the full code (it's not long, and
I'm not sure what is essential and what's not).
Actually, I'm not even sure the code is really wrong and I
don't feel sure to exclude some "mismatch" /
misconfiguration somewhere in the IDE.
 
> include MY.CPP in the build properly.
 
> Construct a minimal example demonstrating the problem, post
> the code and the actual error messages.
 
well I'm not able to : I post the code as is :\
If it is too long, no problem, thanks anyway
 
 
HEADER mainwindow.h (autogenerated by QT)
#############################################################
#ifndef MAINWINDOW_H
#define MAINWINDOW_H
 
#include <QMainWindow>
 
namespace Ui {
class MainWindow;
}
 
class MainWindow : public QMainWindow
{
Q_OBJECT
public:
explicit MainWindow(QWidget *parent = 0);
~MainWindow();
private slots:
void on_pushButton_clicked(bool checked);
void on_btnGo_clicked(bool checked);
private:
Ui::MainWindow *ui;
};
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)