Tuesday, May 19, 2015

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

Lynn McGuire <lmc@winsim.com>: May 19 03:11PM -0500

"Criticizing the Rust Language, and Why C/C++ Will Never Die"
http://www.viva64.com/en/b/0324/
 
Lynn
blackball <bugway@gmail.com>: May 19 03:15AM -0700

On Friday, May 15, 2015 at 8:44:29 AM UTC+2, Juha Nieminen wrote:
 
> Changing that to a constexpr function, however, doesn't seem so trivial
> (unless I'm missing something obvious). Any ideas?
 
> --- news://freenews.netfront.net/ - complaints: news@netfront.net ---
 
Using the C way:
 
#define IS_BIG_ENDIAN (*((uint16_t *)"\0\xff") < 0x100)
Ben Bacarisse <ben.usenet@bsb.me.uk>: May 19 12:28PM +0100

>> unsigned char* ptr = (unsigned char*)&value;
>> return *ptr == 1;
>> }
<snip>
 
> Using the C way:
 
> #define IS_BIG_ENDIAN (*((uint16_t *)"\0\xff") < 0x100)
 
That's not the C way because it's not guaranteed to work (the type
uint16_t might not exist and the string need not be property aligned for
the pointer conversion) but, perhaps more to the point, it's not
guaranteed to be evaluated at compile time. (If I were replying to the
run-time example, I'd go with a compound literal union.)
 
The best was to make a test a compile-time test is to use what C calls
an integer constant expression, but I can't think of a way to write one
that expresses the endianality of the environment.
 
--
Ben.
scott@slp53.sl.home (Scott Lurndal): May 19 01:21PM

>> that the new ARM64 processor is capable of operating in either
>> (or both) endiannesses.
 
>That might be interesting if it were a big-endian only device.
 
It can be big-endian, little-endian, or both. The point is that
there is sufficient demand for new big-endian systems that a brand-spanking-new
architecture (AArch64) chose to include biendianness in the
architecture. if you think that choice was made arbitrarily, or
that that choice had no impact on the development of the
architecture or the implementations, then you have no idea
of what it takes to build a processor.
legalize+jeeves@mail.xmission.com (Richard): May 19 03:45PM

[Please do not mail me a copy of your followup]
 
Ben Bacarisse <ben.usenet@bsb.me.uk> spake the secret code
 
>The best was to make a test a compile-time test is to use what C calls
>an integer constant expression, but I can't think of a way to write one
>that expresses the endianality of the environment.
 
I think I prefer the CMake way: simply execute a program at build time
that gives you the answer and use this to generate a header with the
necessary symbol defined.
--
"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>
scott@slp53.sl.home (Scott Lurndal): May 19 04:47PM


>I think I prefer the CMake way: simply execute a program at build time
>that gives you the answer and use this to generate a header with the
>necessary symbol defined.
 
Does that work when you're cross compiling for a different architecture
than that of the host?
legalize+jeeves@mail.xmission.com (Richard): May 19 05:36PM

[Please do not mail me a copy of your followup]
 
slp53@pacbell.net spake the secret code
>>necessary symbol defined.
 
>Does that work when you're cross compiling for a different architecture
>than that of the host?
 
When cross compiling you describe the target system with a toolchain
file and the methods described on the wiki.
<http://www.vtk.org/Wiki/CMake_Cross_Compiling>
 
For endian-ness, this is probably more trouble than it is worth if you
need to support cross compiling. But system introspection is often
much more than a single boolean that is easily answered from the
command-line when you initiate a build of the code.
--
"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>
asetofsymbols@gmail.com: May 19 09:54AM -0700

If i have:
template<class T> class per{
// ....
per(){++v; /*...*/ }
static int v;
};
 
How access and define v?
 
v would be a global value only 32
Bit
One for the class
that can be accessed only from
function of 'per' and objects of
'per' type...
asetofsymbols@gmail.com: May 19 09:59AM -0700

Class in subject line...
It seems this compile:
template<class T> class per{
// ....
per(){++v; /*...*/ }
static int v;
};
int per<int>::v=0;
 
Would be right even if type T
is different from int?
Victor Bazarov <v.bazarov@comcast.invalid>: May 19 01:06PM -0400

> int per<int>::v=0;
 
> Would be right even if type T
> is different from int?
 
No. You need to define it as a template, if you want every 'per'
instantiation to have it:
 
template<class T> int per<T>::v = 0;
 
And do it in the header. The compiler/linker will take care of creating
only one object per instantiation.
 
V
--
I do not respond to top-posted replies, please don't ask
asetofsymbols@gmail.com: May 19 10:17AM -0700

Thank you
udtelco@gmail.com: May 18 05:31PM -0700


> V
> --
> I do not respond to top-posted replies, please don't ask
 
Victor - I'd be particularly curious in your response to the OP, if any.
 
Thank you
Juha Nieminen <nospam@thanks.invalid>: May 19 03:07AM

> Remove:
> globals
 
Globals like std::cout? Then how would you implement that?
 
In fact, main() is a global too.
 
> C
 
So no longer would you be able to define functions, create for and while
loops, conditionals... What would be left? Template metaprogramming?
 
As for the standard library functions inherited from C, some of them
are pretty handy, and sometimes more efficient than the C++ equivalents
(such as for example fread().)
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Christian Gollwitzer <auriocus@gmx.de>: May 19 08:47AM +0200

Am 18.05.15 um 20:39 schrieb Jason C. McDonald:
> ?? (for absolutely beginners)
> !! (for quick-and-dirty programming by people who reject all standards)
> !%#*&@^ (for irritating the heck out of people)
 
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.
 
Christian
Sam <sam@email-scan.com>: May 19 06:01AM -0500


> Who is "he", and what's bothering you so much about this question ? And do
> you always stick an attachment into your contribution to this global museum
> of wisdom and tolerance ?
 
Yes, I do. This so-called "attachment" is called a "PGP digital signature".
You might be surprised that the Internet standard for digital signatures,
RFC 2015, was published in 1996. You might want to try to upgrade your
Usenet client to something more modern that was written this side of the
century mark. Oh, I see that you're using the confusing Google Groups to
read Usenet, and you may not even know what Usenet is. Oh, well, I guess you
can file a bug report with Google, then; and then marvel at the fact that
properly-written Usenet clients will know automatically what to do with this
so-called "attachment", without bothering the easily-confused user.
 
But I digress. The question remains on the table: when is this homework
assignment due, can you try answering that?
Victor Bazarov <v.bazarov@comcast.invalid>: May 19 07:58AM -0400

>> --
>> I do not respond to top-posted replies, please don't ask
 
> Victor - I'd be particularly curious in your response to the OP, if any.
 
I am a mere user of the language. What's there I like, what's not there
I don't miss. I don't get frustrated by lack of a feature or by
supposed complexity. We are not artificially limited by a single
language in our real-world endeavours, so if something is not in one,
take the other, if it is more suited. Life's too short.
 
Besides, I currently work coding applications (not hardware, not
network, not libraries) so my focus is mostly on the algorithms,
formulas, workflow. The language for me is but a set of tools, and as
far as C++ goes, it's pretty complete and well-rounded for my purposes.
 
See Jorgen Grahn's reply. ;-)
 
And, sorry to disappoint, if so... :-/
 
V
--
I do not respond to top-posted replies, please don't ask
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)