Wednesday, January 22, 2020

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

aminer68@gmail.com: Jan 22 11:12AM -0800

Hello,
 
 
Read this interesting webpage:
 
Reusable Software? Just Don't Write Generic Code
 
http://josdejong.com/blog/2015/01/06/code-reuse/
 
 
Thank you,
Amine Moulay Ramdane.
James Kuyper <jameskuyper@alumni.caltech.edu>: Jan 22 12:07AM -0500

On 1/21/20 4:08 PM, Daniel wrote:
>> misuse, might be precisely the thing that he finds objectionable about
>> macros?
 
> What is there in C++ that _doesn't_ invite misuse?
 
Somethings invite misuse more strongly than others. He was expressing
his judgement that macros invite abuse too strongly.
"Öö Tiib" <ootiib@hot.ee>: Jan 21 11:21PM -0800

On Tuesday, 21 January 2020 23:08:36 UTC+2, Daniel wrote:
 
> What is there in C++ that _doesn't_ invite misuse? Even features introduced
> comparatively late collide with each other, e.g. uniform initialization and
> initializer lists, or with features of the world, e.g. `std::error_category::operator==` and DLL's and shared libraries. It is in the nature of the language.
 
Unfortunately yes, there are piles of bear traps in C++.
Loose initialization semantics was what I felt to be worst about
C++11 (that was otherwise great progress). But the issue is local to
concrete initialization of variables óf concrete type.
 
Macros like "min()" and "max()" from windows.h however screw up any
min and max. It does not matter if it is std::max(), std::numeric_limits<int>::max() or thatlib::suchstruct::max().
Now and then someone trying to run some (perfectly well-formed
and portable) code on windows wastes some time with that
nuisance, globally, ... and there are nothing to do about it.
Bonita Montero <Bonita.Montero@gmail.com>: Jan 22 08:32AM +0100

I recently had the problem that I wanted to have a constant which is
size_t wide and where the highest bit is set. I simply solved it that
way (I assume ptrdiff_t as wide as size_t, but this should be common
today on all platforms):
std::size_t const SIZE_T_MSB = std::numeric_limits<ptrdiff_t>::min();
A guarantee from the standard that signed values are 2's-complement
woud be nice for that.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 22 09:23AM +0100

On 22.01.2020 08:32, Bonita Montero wrote:
> std::size_t const SIZE_T_MSB = std::numeric_limits<ptrdiff_t>::min();
> A guarantee from the standard that signed values are 2's-complement
> woud be nice for that.
 
C++20 will give you that guarantee.
 
But e.g. `size_t(-1) - size_t(-1)/2` does the job with just C++98
guarantees.
 
Every time I discover a vastly simpler way of doing something, so that I
prove myself stupid, I feel more optimistic since evidently my mind is
still working.
 
 
- Alf
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jan 22 01:51AM -0800

Öö Tiib <ootiib@hot.ee> writes:
[...]
> Now and then someone trying to run some (perfectly well-formed
> and portable) code on windows wastes some time with that
> nuisance, globally, ... and there are nothing to do about it.
 
You mean nothing other than
#undef min
#undef max
?
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
David Brown <david.brown@hesbynett.no>: Jan 22 11:28AM +0100

On 22/01/2020 10:51, Keith Thompson wrote:
> #undef min
> #undef max
> ?
 
That would work, unless there is something in the code that uses these
macros. (Presumably there is some reason for them being in windows.h in
the first place, and some code uses them.)
 
But it must surely be possible to include "windows.h", then any other
windows-specific headers (that might rely on the windows.h definition of
the macros), then do the undef's, then include standard C++ headers,
application headers, and the main code. It might be a bit ugly -
personally I dislike anything that forces a particular ordering on
include files - but I can't think off hand of any reason it wouldn't work.
Bonita Montero <Bonita.Montero@gmail.com>: Jan 22 11:52AM +0100

> application headers, and the main code. It might be a bit ugly -
> personally I dislike anything that forces a particular ordering on
> include files - but I can't think off hand of any reason it wouldn't work.
 
If you include <Windows.h> and don't want min / max to be defined you
have to #define NOMINMAX before including <Windows.h>.
boltar@nowhere.org: Jan 22 11:26AM

On 21 Jan 2020 20:01:32 GMT
>> cross platform development.
 
>How about those of us who had to do it, and hated it?
 
>By the way, even for that scenario, the preprocessor is overused.
 
How? If an API call isn't supported on a given platform you have no choice
but to ifdef.
 
>See the "#ifdefs considered harmful" paper.
 
I have paint to watch drying instead. No doubt it comes from the same ivory
tower that claims gotos should never be used.
"Öö Tiib" <ootiib@hot.ee>: Jan 22 04:47AM -0800

On Wednesday, 22 January 2020 12:28:11 UTC+2, David Brown wrote:
> application headers, and the main code. It might be a bit ugly -
> personally I dislike anything that forces a particular ordering on
> include files - but I can't think off hand of any reason it wouldn't work.
 
Issue is manifesting as obscure compiler error messages in
some standard library implementation file included by <limits>
that most programmers who use C++ are not skilled enough
to write themselves.

Figuring out that it is because of #include <windows.h> in
header (that they also likely did not write) takes some time,
swapping the header files, adding #undefs or adding -D
NOMINMAX to command line is trivial.
 
Therefore macros can be used and are used in practice
by major platform vendor to make things painful here,
nuisance there and sucky at third place.
 
Motivation of platform vendor is understandable, it
wants to herd programmers to use C# on their platform.
 
But why should it cause love towards macros to grow
among C++ programmers?
Bonita Montero <Bonita.Montero@gmail.com>: Jan 22 02:20PM +0100

> But e.g. `size_t(-1) - size_t(-1)/2` does the job with just C++98
> guarantees.
 
I think it would be better to write (size_t)(ptrdiff_t)-1 because
the conversion of signed ints to size_t is UB when the int is nega-
tive. I.e. the compiler could first make the value unsigned and then
extend the value that you might get 0x00000000FFFFFFFFu on a 64-bit
-machine. With the above cast to ptrdiff_t you have at least the
guarantee that the value is widened with its sign.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jan 22 01:37PM

On Wed, 22 Jan 2020 14:20:08 +0100
> extend the value that you might get 0x00000000FFFFFFFFu on a 64-bit
> -machine. With the above cast to ptrdiff_t you have at least the
> guarantee that the value is widened with its sign.
 
size_t(-1) has defined behaviour in C++, if that is your point. The
representation depends on the size and signedness of the destination,
not the source:
 
"A prvalue of an integer type can be converted to a prvalue of another
integer type ... . If the destination type is unsigned, the resulting
value is the least unsigned integer congruent to the source integer
(modulo 2 n where n is the number of bits used to represent the
unsigned type). [ Note: In a two's complement representation, this
conversion is conceptual and there is no change in the bit pattern (if
there is no truncation). — end note ]"
 
size_t(-1) will always give you all bits set, whatever the signed
representation of -1 (bits will be altered if necessary).
Christian Gollwitzer <auriocus@gmx.de>: Jan 22 08:04PM +0100

> I have paint to watch drying instead.
Nice idiom
 
> No doubt it comes from the same ivory
> tower that claims gotos should never be used.
 
Ivory tower, for sure? We have while, for, break, continue, return, and
exceptions. All these compile to some sort of goto in machine code.
 
What good reasons are left for a literal goto? I can see it in C for
error handling (because it lacks exceptions) - in C++ there is hardly a
good reason IMHO.
 
Christian
boltar@nowhere.org: Jan 22 09:58AM

On Tue, 21 Jan 2020 19:25:06 +0200
 
>https://godbolt.org/ shows that this compiles fine with clang 6.0.0 and
>later. Clang 5.0.0 indeed fails - it looks like it's time to upgrade,
>the current version is 9.0.0.
 
They can say it compiles fine all they like, I'm telling you it doesn't:
 
fenris$ clang -v
Apple LLVM version 10.0.1 (clang-1001.0.46.4)
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
fenris$ cat t.c
#define GLSL_COMMON_FUNC R"#(
float func(float f) {
return 0.0;
>}
>)#"
 
int main()
{
return 0;
}
fenris$ cc t.c
t.c:1:27: warning: missing terminating '"' character [-Winvalid-pp-token]
#define GLSL_COMMON_FUNC R"#(
^
t.c:4:1: error: expected expression
>}
^
t.c:4:2: error: expected expression
>}
^
t.c:5:1: error: expected identifier or '('
>)#"
^
t.c:5:4: warning: missing terminating '"' character [-Winvalid-pp-token]
>)#"
^
2 warnings and 3 errors generated.
fenris$ mv t.c t.cc
fenris$ c++ t.cc
t.cc:1:27: warning: missing terminating '"' character [-Winvalid-pp-token]
#define GLSL_COMMON_FUNC R"#(
^
t.cc:4:1: error: expected expression
>}
^
t.cc:4:2: error: expected expression
>}
^
t.cc:5:1: error: expected unqualified-id
>)#"
^
t.cc:5:4: warning: missing terminating '"' character [-Winvalid-pp-token]
>)#"
^
2 warnings and 3 errors generated.
guinness.tony@gmail.com: Jan 22 02:11AM -0800

> >)#"
> ^
> 2 warnings and 3 errors generated.
 
It does if you use the C++ compiler (you're using the C compiler, above).
 
C doesn't have raw string literals; C++ does.
boltar@nowhere.org: Jan 22 10:24AM

On Wed, 22 Jan 2020 02:11:24 -0800 (PST)
>> ^
>> 2 warnings and 3 errors generated.
 
>It does if you use the C++ compiler (you're using the C compiler, above).
 
Are you blind? Try looking a bit harder.
Paavo Helde <myfirstname@osa.pri.ee>: Jan 22 01:28PM +0200

> Target: x86_64-apple-darwin18.7.0
> Thread model: posix
> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
[...]
> fenris$ c++ t.cc
 
And how is this 'c++' program related to the 'clang' program you used
for -v?
 
>> )#"
> ^
> 2 warnings and 3 errors generated.
 
Your example works fine with my clang:
 
gemma$ clang++ -v
clang version 7.0.1 (tags/RELEASE_701/final 349238)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/7
Found candidate GCC installation: /usr/lib64/gcc/x86_64-suse-linux/7
Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/7
Candidate multilib: .;@m64
Selected multilib: .;@m64
gemma$ cat test1.cpp
#include <iostream>
 
#define GLSL_COMMON_FUNC R"#(
float func(float f) {
return 0.0;
}
)#"
 
int main()
{
std::cout << GLSL_COMMON_FUNC;
}
gemma$ clang++ test1.cpp
gemma$ ./a.out
 
float func(float f) {
return 0.0;
}
Juha Nieminen <nospam@thanks.invalid>: Jan 22 12:03PM

> fenris$ cat t.c
> fenris$ cc t.c
> t.c:1:27: warning: missing terminating '"' character [-Winvalid-pp-token]
 
You are compiling as C, not as C++.
boltar@nowhere.org: Jan 22 12:07PM

On Wed, 22 Jan 2020 13:28:08 +0200
>> fenris$ c++ t.cc
 
>And how is this 'c++' program related to the 'clang' program you used
>for -v?
 
fenris$ ls -l /usr/bin/c++
lrwxr-xr-x 1 root wheel 7 27 Sep 2018 /usr/bin/c++ -> clang++
 
 
>float func(float f) {
> return 0.0;
>}
 
fenris$ c++ test1.cpp
test1.cpp:3:27: warning: missing terminating '"' character [-Winvalid-pp-token]
#define GLSL_COMMON_FUNC R"#(
^
test1.cpp:7:1: error: expected unqualified-id
)#"
^
test1.cpp:7:3: warning: missing terminating '"' character [-Winvalid-pp-token]
)#"
^
2 warnings and 1 error generated.
fenris$
 
Perhaps Apples version of Clang is different in some way, but regardless, it
doesn't compile.
"Öö Tiib" <ootiib@hot.ee>: Jan 22 05:33AM -0800


> Perhaps Apples version of Clang is different in some way, but regardless, it
> doesn't compile.
 
Can't reproduce on Apple.
 
Perhaps you just call wrong compiler or in C mode
or miss -std=c++11 or better from command line or
some other such typical noob error.
 
C++ has some baby proof locks on all platforms.
With it is too easy to shoot one's leg off or the like
but babies lose interest if it does not compile or
link or the like.
boltar@nowhere.org: Jan 22 04:03PM

On Wed, 22 Jan 2020 05:33:00 -0800 (PST)
>With it is too easy to shoot one's leg off or the like
>but babies lose interest if it does not compile or
>link or the like.
 
Oh do go fuck yourself you patronising little tit.
Manfred <noname@add.invalid>: Jan 22 06:59PM +0100

>> for -v?
> fenris$ ls -l /usr/bin/c++
> lrwxr-xr-x 1 root wheel 7 27 Sep 2018 /usr/bin/c++ -> clang++
 
You may want to check with
$ which c++
 
instead of ls, and
$ c++ -v
 
>> return 0.0;
>> }
> fenris$ c++ test1.cpp
 
why not
$ clang++ test1.cpp
 
 
> fenris$
 
> Perhaps Apples version of Clang is different in some way, but regardless, it
> doesn't compile.
 
It compiles fine here too with clang 8.0.0, but fails with gcc 9.2
 
For some reason your compiler behaves differently than expected. You may
want to know why (more than complaining about it).
"Öö Tiib" <ootiib@hot.ee>: Jan 22 10:50AM -0800

> >but babies lose interest if it does not compile or
> >link or the like.
 
> Oh do go fuck yourself you patronising little tit.
 
You think that vulgar language makes you to look more
immature and so fits better with being a rookie? :D
Paavo Helde <myfirstname@osa.pri.ee>: Jan 22 05:01PM +0200

Please consider:
 
#include <new>
 
template <typename T, typename U>
class A {};
 
template <typename T>
using B = A<T, int>;
 
template <typename T>
void foo(B<T>* x) {
x->~B<T>(); // this line failing with clang
}
 
int main() {
alignas(sizeof(B<int>)) char buff[sizeof(B<int>)];
B<int>* p = new (buff) B<int>;
foo(p);
}
 
gcc and msvc compile this just fine. However, clang refuses:
 
test1.cpp:11:6: error: no member named 'B' in 'A<int, int>'
x->~B<T>();
^
test1.cpp:17:2: note: in instantiation of function template
specialization 'foo<int>' requested here
foo(p);
^
1 error generated.
 
Who is right? And if clang, then how to write an explicit B<T>
destructor call without relying on how B<T> happens to be defined?
boltar@nowhere.org: Jan 22 10:02AM

On Tue, 21 Jan 2020 17:35:45 +0000
>>> stand for? Talk about blinkered.
 
>> What is it you stand for exactly?
 
>Women's rights and gay rights.
 
Wow, you're a real woke hero. But you forgot tranny and gender fluid (whatever
the fuck that means) rights too. Come on, embrace the vibrant diversity and
get with the program.
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)