Tuesday, February 23, 2016

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

Cholo Lennon <chololennon@hotmail.com>: Feb 23 12:01PM -0300

What's your opinion about these statistics of C++?
 
http://blog.jetbrains.com/clion/2015/07/infographics-cpp-facts-before-clion/
 
Some of them seem weird to me (like gcc usage on Windows)
 
 
Regards
 
--
Cholo Lennon
Bs.As.
ARG
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 23 12:46AM +0100

On 22.02.2016 23:39, Richard wrote:
>> };
 
> For this to be visible as the string "Ann\0" in memory, doesn't this
> assume a certain byte order for integral types?
 
I think Paavo's code is way too portable, so:
 
#include <iostream>
#include <string>
#include <stdint.h>
using namespace std;
 
constexpr
auto adjoined( uint64_t const a, uint64_t const b )
-> uint64_t
{ return (a << 32) | b; }
 
enum constants: uint64_t { Ann = 'nnA', Betty = adjoined( 'y',
'tteB' ) };
 
auto str_from_id( uint64_t const x )
-> std::string
{ return reinterpret_cast<const char*>( &x ); }
 
auto main() -> int
{
uint64_t const arr[] = {Ann, Betty};
for( auto const x: arr ) switch( x )
{
case Ann:
cout << "A " << str_from_id( x ) << "\n";
break;
case Betty:
cout << "B " << str_from_id( x ) << "\n";
break;
}
}
 
 
This avoids using newfangled stuff like C++11 user defined literals, and
leverages the good old C syntax that BEEN THERE FOR A REASON since,
well, since the 1970s!
 
After all, what could possibly go wrong?
 
 
Cheers!,
 
- Alf
Jerry Stuckle <jstucklex@attglobal.net>: Feb 22 07:54PM -0500

On 2/22/2016 6:16 PM, Öö Tiib wrote:
> endianness compile time. Any type punning is forbidden in 'constexpr'
> functions. For practical purposes Boost header file endian.hpp covers
> endianness for large amount of platforms.
 
Wrong again. But then I wouldn't expect a troll to understand.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 23 02:26AM +0100

On 23.02.2016 01:54, Jerry Stuckle wrote:
>> functions. For practical purposes Boost header file endian.hpp covers
>> endianness for large amount of platforms.
 
> Wrong again.
 
Öö Tiib is correct. There are no known tricks, and absolutely no
standard or well known ones. The [1] C FAQ mentions a possible trick,
 
'ABCD' == 0x41424344
 
but clarifies that
 
"this isn't reliable, either"
 
E.g., reportedly some [2] Solaris/SPARC compilers differ in the result
of that expression (or similar expression), on the same platform.
 
 
> But then I wouldn't expect a troll to understand.
 
Again, here you're wrong, possibly a case of mistaken identity.
 
 
Cheers & hth.,
 
- Alf
 
[1] <url: http://www.c-faq.com/cpp/ifendian.html>
[2] <url: http://stackoverflow.com/a/4275412/464581>
Jerry Stuckle <jstucklex@attglobal.net>: Feb 22 08:35PM -0500

On 2/22/2016 8:26 PM, Alf P. Steinbach wrote:
 
> - Alf
 
> [1] <url: http://www.c-faq.com/cpp/ifendian.html>
> [2] <url: http://stackoverflow.com/a/4275412/464581>
 
Wrong again. There are ways, using unions. But I'm not going to get
into an argument with a troll.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
legalize+jeeves@mail.xmission.com (Richard): Feb 23 02:31AM

[Please do not mail me a copy of your followup]
 
Jerry Stuckle <jstucklex@attglobal.net> spake the secret code
 
>But I'm not going to get into an argument with a troll.
 
Calling anyone who disagrees with you in the slightest a "troll" is
stupid. *PLONK*
 
Alf has been a long time contributor to raising the signal of this
newsgroup out of the noise.
 
If Alf is a troll, then there are no people on this planet discussing
C++ that aren't trolls.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 23 03:34AM +0100

On 23.02.2016 02:35, Jerry Stuckle wrote:
>>>> endianness for large amount of platforms.
 
>>> Wrong again.
 
> Wrong again. There are ways, using unions.
 
That's formally UB and won't compile with recent clang.
 
A similar trick based on pointer arithmetic, `Ptr_b() + (a - Ptr_a())`,
won't compile either: the modern compilers are just too good at
implementing the IMHO too restrictive language standard.
 
E.g. the standard could have allowed casting to pointer to same size
fundamental type, and that would have allowed user defined strongly
typed string literals. Which I would like. But alas, it doesn't.
 
 
> But I'm not going to get into an argument with a troll.
 
You're not here for learning, that much is clear.
 
 
Cheers, you idiot, :)
 
- Alf
Jerry Stuckle <jstucklex@attglobal.net>: Feb 22 09:38PM -0500

On 2/22/2016 9:34 PM, Alf P. Steinbach wrote:
 
>>>> Wrong again.
 
>> Wrong again. There are ways, using unions.
 
> That's formally UB and won't compile with recent clang.
 
Wrong again.
 
> A similar trick based on pointer arithmetic, `Ptr_b() + (a - Ptr_a())`,
> won't compile either: the modern compilers are just too good at
> implementing the IMHO too restrictive language standard.
 
Again, wrong.
 
 
> You're not here for learning, that much is clear.
 
> Cheers, you idiot, :)
 
> - Alf
 
And, of course, everything I find on the internet is the truth, the
whole truth, and nothing but the truth. So help me Google.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Jerry Stuckle <jstucklex@attglobal.net>: Feb 22 09:42PM -0500

On 2/22/2016 9:31 PM, Richard wrote:
> newsgroup out of the noise.
 
> If Alf is a troll, then there are no people on this planet discussing
> C++ that aren't trolls.
 
You're right. I'm not here to learn from idiots or trolls. And I don't
care how long someone has been "contributing" to a group - newsgroup,
forum or whatever. His *current* "contributions" define whether he is a
troll or not.
 
Just because I'm new here does *not* mean I haven't been programming in
C++ for a while. In fact, it's been about 28 years. And whether *you*
think I know what I'm talking about or not is immaterial to me.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Google <google@google.com>: Feb 22 07:36PM -0800

On Mon, 22 Feb 2016 21:38:02 -0500, Jerry Stuckle
 
>And, of course, everything I find on the internet is the truth, the
>whole truth, and nothing but the truth. So help me Google.
 
AI0K
JERRY D STUCKLE
9920 BRIXTON LN
BETHESDA, MD 20817-1501
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 23 04:59AM +0100

On 23.02.2016 03:42, Jerry Stuckle wrote:
> On 2/22/2016 9:31 PM, Richard wrote:
 
>> *PLONK*
 
> Whether *you* think …
 
Richard can't hear you when you post with that mail address, unless
someone quotes you, because he's told his newsreader to ignore any
posting of yours. That's [1] what the word "plonk" means. Another way to
phrase it, based on a particular now archaic technology, is that you've
been added to his "killfile" (a kind of spam filter).
 
Signaling the killfile action with a "plonk" is a courtesy to let you
know that he will not see your postings, so that you can avoid fruitless
efforts to engage him – like the posting I'm replying to.
 
Originally the term "plonk" was very derogatory, evoking associations to
"the sound of something solid landing" (and you can guess where). But
there was also "plink" for a much more light-weight something landing,
so "plonk" paradoxically also indicated some measure of respect. But
during the late 1990s the meaning of "plonk" evolved to a more neutral
one of just hey, our interactions have become irreparably ungood, I'm
opting out of it and I will not even see your postings.
 
 
Cheers & hth.,
 
- Alf
 
 
Notes:
[1] <url: http://www.hacker-dictionary.com/terms/plonk>
woodbrian77@gmail.com: Feb 22 08:48PM -0800

On Monday, February 22, 2016 at 8:38:12 PM UTC-6, Jerry Stuckle wrote:
 
> And, of course, everything I find on the internet is the truth, the
> whole truth, and nothing but the truth. So help me Google.
 
How about
 
https://duckduckgo.com
 
? They don't track you and in my opinion are more
trustworthy than Google.
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
Paavo Helde <myfirstname@osa.pri.ee>: Feb 23 10:01AM +0200

On 23.02.2016 0:39, Richard wrote:
>> };
 
> For this to be visible as the string "Ann\0" in memory, doesn't this
> assume a certain byte order for integral types?
 
Yes, you are right. The problem with endianness is that the bytes are
not guaranteed to be in a strictly monotonic order. Others are claiming
that there is no standard and reliable way to find the endianness out at
compile time (for constexpr). However, I started to think isn't it
possible to reuse the user literal mechanism itself, even if it is not
good for finding out the actual endianness it should be good for the
user literals themselves.
 
(Warning: I do not have access to any big- or mixed-endian machines for
testing, so this may contain bugs, and certainly it can be simplified):
 
#include <iostream>
#include <string>
#include <stdint.h>
 
constexpr uint64_t operator""_idraw(const char* p, size_t n) {
return static_cast<unsigned char>(*p) | (n>0 ? operator""_idraw(p+1,
n-1): uint64_t(0))<<8;
}
 
constexpr uint64_t Fill64(uint64_t c) {
return c | c<<8 | c<<16 | c<<24 | c<<32 | c<<40 | c<<48 | c<<56;
}
 
constexpr uint64_t SelectByte(int pos) {
return
pos==0 ? "\xff"_idraw :
(pos==1 ? "\x00\xff"_idraw :
(pos==2 ? "\x00\x00\xff"_idraw :
(pos==3 ? "\x00\x00\x00\xff"_idraw :
(pos==4 ? "\x00\x00\x00\x00\xff"_idraw :
(pos==5 ? "\x00\x00\x00\x00\x00\xff"_idraw :
(pos==6 ? "\x00\x00\x00\x00\x00\x00\xff"_idraw :
(pos==7 ? "\x00\x00\x00\x00\x00\x00\x00\xff"_idraw : 0)))))));
}
 
constexpr uint64_t IdFromString(const char* p, size_t n, int pos) {
return (Fill64(static_cast<unsigned char>(*p)) & SelectByte(pos)) |
(n>0 ? IdFromString(p+1, n-1, pos+1) : uint64_t(0));
}
 
constexpr uint64_t operator""_id(const char* p, size_t n) {
return IdFromString(p, n, 0);
}
 
enum constants: uint64_t {
Ann = "Ann"_id,
Betty = "Betty"_id,
};
 
std::string StrFromId(uint64_t x) {
std::string s(reinterpret_cast<const char*>(&x), 8);
return s.substr(0, s.find(char(0)));
}
 
 
int main() {
 
uint64_t arr[] = {Ann, Betty, "Caroline"_id, "Delilah"_id};
 
for(auto x: arr) {
switch(x) {
case Ann:
std::cout << "A " << StrFromId(x) << "\n";
break;
case Betty:
std::cout << "B " << StrFromId(x) << "\n";
break;
case "Caroline"_id:
std::cout << "C " << StrFromId(x) << "\n";
break;
case "Delilah"_id:
std::cout << "D " << StrFromId(x) << "\n";
break;
}
}
}
David Brown <david.brown@hesbynett.no>: Feb 23 09:16AM +0100

On 23/02/16 02:35, Jerry Stuckle wrote:
>> standard or well known ones. The [1] C FAQ mentions a possible trick,
 
> Wrong again. There are ways, using unions. But I'm not going to get
> into an argument with a troll.
 
I would like to know of a reliable, standard way of identifying
endianness at compile time. Bonus points if it works in C too. I don't
believe such a method exists, but you state it with such confidence.
There are plenty of ways of detecting endianness at run-time, and for
many of them compilers can typically optimise the check and
pre-calculate it:
 
#define I_AM_LITTLE (((union { unsigned x; unsigned char c; }){1}).c)
 
But such checks are not constant expressions - you cannot use the result
in things like static initialisers, constexpr expressions, static
asserts, #if directives, etc.
 
Most toolchains have some sort of pre-defined compiler macros or a
header file with macros that can be used to determine endianness (like
gcc's __BYTE_ORDER__ and __ORDER_LITTLE_ENDIAN__, so there are plenty of
implementation-specific methods.
 
A compile-time constant expression that relies on nothing beyond the
standards would be fascinating - please post it here.
David Brown <david.brown@hesbynett.no>: Feb 23 09:25AM +0100

On 23/02/16 04:36, Google wrote:
> <jstucklex@attglobal.net> wrote:
 
>> And, of course, everything I find on the internet is the truth, the
>> whole truth, and nothing but the truth. So help me Google.
 
<snip>
 
I don't know who posted this, but it is inappropriate behaviour. It is
fine to condemn a posters style, and it is fine to be so frustrated with
childish posts that you killfile them. But it is /not/ fine to post
personal information, even if it is already available to anyone with a
web browser.
 
In a Usenet group, you accept people as they come, or you argue with
them, or you ignore them. Posts like this are harassment.
Juha Nieminen <nospam@thanks.invalid>: Feb 23 09:18AM

> That is to say, it consists of a 64 bit number which is also a string of up to seven
> characters, used for passing about human-readable ids that the machine can
> process as integers.
 
Given that 64 bits is 8 bytes, it is physically impossible to represent a
64-bit value with 7 characters. (The fact that you want it to be readable
reduces the range even more.)
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
malcolm.mclean5@btinternet.com: Feb 23 03:15AM -0800

On Tuesday, February 23, 2016 at 9:18:17 AM UTC, Juha Nieminen wrote:
 
> Given that 64 bits is 8 bytes, it is physically impossible to represent a
> 64-bit value with 7 characters. (The fact that you want it to be readable
> reduces the range even more.)
 
We're not representing 64 bit values with 7-character string, we're representing
7 character strings as 64 bit values.
Jerry Stuckle <jstucklex@attglobal.net>: Feb 23 08:32AM -0500

On 2/22/2016 10:59 PM, Alf P. Steinbach wrote:
> posting of yours. That's [1] what the word "plonk" means. Another way to
> phrase it, based on a particular now archaic technology, is that you've
> been added to his "killfile" (a kind of spam filter).
 
So what? I know what plonk means. And quite frankly, I don't give a damn.
 
> Signaling the killfile action with a "plonk" is a courtesy to let you
> know that he will not see your postings, so that you can avoid fruitless
> efforts to engage him – like the posting I'm replying to.
 
Again, I don't really give a damn.
 
 
> - Alf
 
> Notes:
> [1] <url: http://www.hacker-dictionary.com/terms/plonk>
 
Gee, we used that way back in the early 80's when usenet was in its
infancy. And it wasn't positive then, either.
 
But then I also look at where it's coming from. So frankly, my dear, I
don't give a damn.
 
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Jerry Stuckle <jstucklex@attglobal.net>: Feb 23 08:33AM -0500

On 2/23/2016 3:25 AM, David Brown wrote:
> web browser.
 
> In a Usenet group, you accept people as they come, or you argue with
> them, or you ignore them. Posts like this are harassment.
 
It's just what is expected from the trolls here. And this one is a very
dumb troll, at that.
 
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
David Brown <david.brown@hesbynett.no>: Feb 23 03:43PM +0100

On 23/02/16 14:33, Jerry Stuckle wrote:
>> them, or you ignore them. Posts like this are harassment.
 
> It's just what is expected from the trolls here. And this one is a very
> dumb troll, at that.
 
Trolls, no matter what reasonable and common definition you use, have
been very rare in this group (your opinion on who is or is not a troll
matters little when it is so contrary to the rest of the group).
Amongst the mostly on-topic and helpful posts, we get some pointless
posts, some irritating posts, and occasionally rude posts, but seldom
trolling posts.
 
No, the post here was /not/ what I expect from people in this group -
that is why I react against it. I don't think it really counts as
trolling either. I am not sure /what/ it counts as, but I don't like it.
Jerry Stuckle <jstucklex@attglobal.net>: Feb 22 07:53PM -0500

On 2/22/2016 6:09 PM, Öö Tiib wrote:
> seems that Visual C++ 4.00 were first that had namespaces (released at
> end of 1995). Borland C++ 5.0 released 1996 had also namespaces. So
> those were impossible to use in the early 90's without time machine.
 
Yea, right. Just the response I would expect from an ignorant troll.
 
<plonk!>
 
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
"Öö Tiib" <ootiib@hot.ee>: Feb 22 11:23PM -0800

On Tuesday, 23 February 2016 02:53:35 UTC+2, Jerry Stuckle wrote:
> > those were impossible to use in the early 90's without time machine.
 
> Yea, right. Just the response I would expect from an ignorant troll.
 
> <plonk!>
 
How silly of you to spit poison there. Everybody do mistakes but
those who insult others instead of admitting their error look desperate
and pathetic.
bartekltg <bartekltg@gmail.com>: Feb 23 10:55AM +0100

On 21.02.2016 22:05, Alf P. Steinbach wrote:
 
> There is no standard library header <math> and never has been.
 
> There is a C++ standard library header <complex>. It's different from
> <ccomplex> and <complex.h>.
 
It has changed ;-)
 
"26.4.11 Header <ccomplex> [ccmplx]
1 The header behaves as if it simply includes the header <complex>."
 
 
BTW, since, I think, c++11 there is a binary compatibility with C
complex. I think this is because of :
 
"
26.4:
...
If z is an lvalue expression of type cv std::complex<T> then:
(4.1) — the expression reinterpret_cast<cv T(&)[2]>(z) shall be well-formed,
(4.2) — reinterpret_cast<cv T(&)[2]>(z)[0] shall designate the real part
of z, and
(4.3) — reinterpret_cast<cv T(&)[2]>(z)[1] shall designate the imaginary
part of z.
Moreover, if a is an expression of type cv std::complex<T>* and the
expression a[i] is well-defined for an
integer expression i, then:
(4.4) — reinterpret_cast<cv T*>(a)[2*i] shall designate the real part of
a[i], and
(4.5) — reinterpret_cast<cv T*>(a)[2*i + 1] shall designate the
imaginary part of a[i].
"
 
 
> version since 1999, can't be told to do that, and are IMPORTANT?
 
> Maybe this problem is more of a people & politics problem than a
> technical one?
 
 
I think the problem is with libraries based on fortran (with C
interface). Then reinterpreted cast is needed, but at least
should work.
 
bast
Bartekltg
Juha Nieminen <nospam@thanks.invalid>: Feb 23 09:14AM

>> TDD and classic refactoring are in conflict.
 
> Explaining the conflict would be more usefull than just asserting that
> there is a conflict.
 
I can't even begin to imagine how there is a conflict. Seems pretty
straightforward to me: If you need to change something in the code
(from TDD's point of view usually something that affects a public
interface), you first change the test, then you change the code.
I honestly cannot see what the "conflict" is...
 
Refactoring that's internal to a class/module (ie. does not affect
external behavior) often doesn't even need changing the tests.
 
Especially in the latter case it sounds more to me that TDD aids
in refactoring because you immediately have a basic set of tests
to make sure that your changes didn't break anything. (Sure, TDD
doesn't test it 100%, but even the basic tests help quite a lot.)
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Ian Collins <ian-news@hotmail.com>: Feb 23 10:21PM +1300

Juha Nieminen wrote:
> in refactoring because you immediately have a basic set of tests
> to make sure that your changes didn't break anything. (Sure, TDD
> doesn't test it 100%, but even the basic tests help quite a lot.)
 
It certainly does aid in refactoring. I don't know from where he
conjures up his nonsense, some odd fortune cookies maybe?
 
--
Ian Collins
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)