Thursday, November 13, 2014

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

comp.lang.c++@googlegroups.com Google Groups
Unsure why you received this message? You previously subscribed to digests from this group, but we haven't been sending them for a while. We fixed that, but if you don't want to get these messages, send an email to comp.lang.c+++unsubscribe@googlegroups.com.
JiiPee <no@notvalid.com>: Nov 13 08:08AM

On 30/10/2014 21:48, Rick C. Hodgin wrote:
 
>> What do you think *tnX++ is doing?
> Increasing the int pointed to by tnX. I see from your cue below,
> and in looking at the disassembly, that it is not, hence the warning.
 
The name of the function can help though. For example if you change the
function to:
 
incrementByOne(tnLevel);
 
then its pretty clear that tnLevel will be changed by ref, isnt it?
 
Also, why cannot you use just a return value in this case:
 
int test_function(int tnX)
{
return ++tnX;
}
 
tnLevel = test_function(tnLevel);
 
? And if its an inline function there should be no overhead isn't it?
JiiPee <no@notvalid.com>: Nov 13 08:19AM

On 31/10/2014 10:41, David Brown wrote:
> the calculation in order to avoid such risks.
 
> The best solution, IMHO,
> is to write "(*tnX)++;".
 
totally agree. Why make things look difficult... we are humans so lets
help us :).
 
 
> pointer (which is common in C, and uncommon though still legal in C++),
> then he could not possibly have made the same mistake. Using C++ style
> coding in a C++ program would have avoided this error.
 
I do C++ programmer. I would never use pointer in that kind of
situation, exatcly because of this kind of problems plus its more
"natural" for me to use ref or by value. But by reference changin must
be very careful indeed imo that the function name is clear that its
gonna change the variable. And I would consider returning the result
actually (inline function maybe).
 
> risks of other errors (such as the one Christopher made in his C++
> examples). But /this/ particular error would have been avoided if Rick
> had used C++ references.
 
But this is exatcly the reason we use many other things as well, like
"const" to make sure the content is not changed by accident. Yes,
reference makes the code a bit more difficult to read but which one is
more dangerous? But as I said, its very important imo that the function
name is like: "increaseThisVariable(...)", so the intent is seen clearly
from calling side.
 
Ike Naar <ike@iceland.freeshell.org>: Nov 13 04:26PM

> int test_function(int tnX)
> {
> return ++tnX;
 
return tnX+1; /* no unnecessary side effect */
 
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 13 05:07PM

On 12/11/2014 14:09, Rick C. Hodgin wrote:
 
> I'm writing RDC, not C. Under -strict=c constraints, it will work as C
> compilers do today.
 
> In RDC form (the default) it will work as I am defining.
 
Is RDC an abbreviation for "Really Dumb C" or "Really Dangerous C"
because your approach is both dumb and dangerous but hopefully nobody
writing safety critical software would touch your demented language with
a barge pole.
 
/Flibble
JiiPee <no@notvalid.com>: Nov 13 05:45PM

On 13/11/2014 16:26, Ike Naar wrote:
>> {
>> return ++tnX;
> return tnX+1; /* no unnecessary side effect */
 
Ins't the assembly code the same for both? Thats what I would think.
Compiler not very wise if cannot do that :). I would prefer ++tnX to be
consistant in code (because its used everywhere else as well).
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Nov 13 10:09AM -0800

On Thursday, November 13, 2014 12:07:26 PM UTC-5, Mr Flibble wrote:
> writing safety critical software would touch your demented language with
> a barge pole.
 
> /Flibble
 
RDC stands for Rapid Development Compiler. It removes some of the
mechanical syntax requirements for data access, and introduces ways
to access the same data in different ways to allow a wide array of
processing. It is generally very very C-like, but there are some
notable exceptions. RDC also introduces the class into C-like code,
so that some of the desirable encapsulating features of C++ are
there, but without the complexity.
 
I plan on eventually getting a fully C-compliant version completed
as well (probably C99). But, that's a later goal because it's not
a great priority for me. There aren't that many things different
between RDC and C such that I would need to spend so much time
writing a fully compliant compiler today. It would be faster to
change the small handful of things in my code that need changed to
allow my own code to compile in my own compiler, and move forward
from there.
 
We'll see though. All of these plans are subject to the Lord's will.
I can only set goals. It is only He who gives me the ability to
follow through on those goals. He may well have other plans for my
life. Time will tell.
 
Best regards,
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Nov 13 10:17AM -0800

On Thursday, November 13, 2014 12:45:24 PM UTC-5, JiiPee wrote:
 
> Ins't the assembly code the same for both? Thats what I would think.
> Compiler not very wise if cannot do that :). I would prefer ++tnX to be
> consistant in code (because its used everywhere else as well).
 
When optimized they would probably produce the same. Without
optimization the return ++tnX has a read, add, write, and possibly
another read to obtain the return value. Without optimization,
the return tnX + 1 has one read, and one add to obtain the return
value.
 
return tnX + 1;
 
This would definitely be better on unoptimized code.
 
Best regards,
Rick C. Hodgin
Ike Naar <ike@iceland.freeshell.org>: Nov 13 06:23PM


> Ins't the assembly code the same for both? Thats what I would think.
> Compiler not very wise if cannot do that :). I would prefer ++tnX to be
> consistant in code (because its used everywhere else as well).
 
It seems a bit unnatural to use the version with side effect if
the side effect is not needed.
 
Can you explain why you prefer ++tnX (or tnX++) over tnX+1 ?
JiiPee <no@notvalid.com>: Nov 13 06:26PM

On 13/11/2014 18:17, Rick C. Hodgin wrote:
 
> This would definitely be better on unoptimized code.
 
> Best regards,
> Rick C. Hodgin
 
ok, good to know. Well then I would still use myself ++tnX and just
remember in debuggin mode this issue. But its a taste issue I guess....
 
Without much thinking, don't we have the same proglem in other than
return-value code as well? Like:
 
int i=7;
int x=9;
...
x = ++i;
 
is here also
 
x = i + 1;
 
less assembly code in debuggin mode? Don't we have the same issue here
as well?
JiiPee <no@notvalid.com>: Nov 13 06:28PM

On 13/11/2014 18:23, Ike Naar wrote:
> It seems a bit unnatural to use the version with side effect if
> the side effect is not needed.
 
> Can you explain why you prefer ++tnX (or tnX++) over tnX+1 ?
 
Like I said, I prefer it because I use it everywhere else in my code as
well. I never do tnX+1 style in my code. For example in loops i do:
 
for (int i ....; ++i)
 
I do not do:
 
for (int i ....; i=i+1)
 
So I want to use the same style everywhere, thats why....Its better for
me as a human to read the code. Or do you have a special reason why
elsewhere better to use ++i and here i=i+1?
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Nov 13 10:37AM -0800

On Thursday, November 13, 2014 1:26:05 PM UTC-5, JiiPee wrote:
> int x=9;
> ...
> x = ++i;
 
Unoptimized ssembly:
mov eax,i
inc eax
mov i,eax
mov x,eax
 
> is here also
 
> x = i + 1;
 
Unoptimized assembly:
mov eax,i
inc eax
mov x,eax
 
> less assembly code in debuggin mode? Don't we have the same issue here
> as well?
 
Yes, but the result of the second one is i is not incremented. The
requirements of incrementing i may be a constraint in the source code.
If not, then it can be optimized away layer.
 
Best regards,
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Nov 13 10:40AM -0800

On Thursday, November 13, 2014 1:28:52 PM UTC-5, JiiPee wrote:
 
> Like I said, I prefer it because I use it everywhere else in my code as
> well. I never do tnX+1 style in my code. For example in loops i do:
 
> for (int i ....; ++i)
 
Unoptimized assembly:
mov eax,i
inc eax
mov i,eax
 
> I do not do:
 
> for (int i ....; i=i+1)
 
Unoptimized assembly:
mov eax,i
inc eax
mov i,eax
 
> So I want to use the same style everywhere, thats why....Its better for
> me as a human to read the code. Or do you have a special reason why
> elsewhere better to use ++i and here i=i+1?
 
An optimizing compiler might use ecx for a register for the loop if
possible, or it may simply issue "inc i" which would translate to
"inc dword ptr ss:[ebp+N]" to increment the 32-bit integer value of
N on the stack at whatever location it's assigned. It would depend
on how soon after the increment i is needing to be used again. If
it's not immediately thereafter, using the inc i form would probably
be more desirable as the CPU has time to write the results in another
pipe, and non-temporally.
 
Best regards,
Rick C. Hodgin
JiiPee <no@notvalid.com>: Nov 13 06:42PM

On 13/11/2014 18:37, Rick C. Hodgin wrote:
> Yes, but the result of the second one is i is not incremented. The
> requirements of incrementing i may be a constraint in the source code.
> If not, then it can be optimized away layer.
 
Oh now I got your point :). Ye, we increament the variable as well.
True....now I agree that +1 version is indeed better here. Am slow today :).
JiiPee <no@notvalid.com>: Nov 13 06:45PM

On 13/11/2014 18:40, Rick C. Hodgin wrote:
> pipe, and non-temporally.
 
> Best regards,
> Rick C. Hodgin
 
interesting, i need to learn to get the assembly code also to see these
(is it some easy command on gcc?). But I just got the whole thing... I
did not see the increment issue of the variable. So +1 is better in the
original issue..
JiiPee <no@notvalid.com>: Nov 13 06:05PM

On 02/11/2014 17:09, Paavo Helde wrote:
> casting.
 
> Cheers
> Paavo
 
Thanks, I tested the uint version, and no errors.
JiiPee <no@notvalid.com>: Nov 13 06:12PM

On 03/11/2014 08:16, Paavo Helde wrote:
> the best choice in all situations.
 
> In particular, sprintf() is defined as a locale-dependent function, with
> all the legacy and drawbacks associated with it.
 
Ok, but am not talking about sprintf here, am talking about our IntToStr
function. If I was to do this library (which am actually doing I think..
I have my own "ctools" library where I add all kind of beneficial
functions/tools I use in my projects.. then just add this file to my
projects... so gonna add this one there as well)., then I would put a
compile time flag, maybe a template, to tell what kind of version I want
the super fast or fast.
JiiPee <no@notvalid.com>: Nov 13 06:21PM

On 03/11/2014 06:04, Paavo Helde wrote:
> Don't be so sure it will be faster, memory access is often the bottleneck
> nowadays. It might even happen that the whole program slows down because
> IntToStr() is pushing some useful data out of the caches.
 
Would be interesting to test your "theory"... I would like to do it. But
I would need an example code from you where you think it would be
slower. We could test this.
 
But the 40000 trade off - its only allocated once in a program because
its a static array. and for me 40000 is not much memory waste, as I do
normal pc program mostly. its like 0.001 % of the RAM memory if having 3
GIG memory.
JiiPee <no@notvalid.com>: Nov 13 09:33AM

I have been thinking of buying a new book (or 2 books) to learn
everything about C++11 (preferably including 14 but its not essential as
14 can be learned elsewhere I think as its not that different to 11).
 
So is there any thick one book which cover all the C++ features,
inluding C++11. Is it going to be Bjarnes "The C++ Programming Language
(4th Edition)"? It is a really good book, but is there a better one? Or
another one beside it? I have its Third edition from 1996, but obviously
its very different I guess, so worth of buying?
 
I would prefer to have one book covering all, but I guess I need two
maybe. So what would be a good pair of two books to cover all C++11
language topics?
 
And they do not need to cover fully standard library as I know there is
a special book for it. I was thinking more like learning very well C++
core stuff.
 
Or its not possible to cover all C++ in couple of books?
Stephen <touc82@gmail.com>: Nov 13 11:22AM

On 13/11/14 09:33, JiiPee wrote:
> a special book for it. I was thinking more like learning very well C++
> core stuff.
 
> Or its not possible to cover all C++ in couple of books?
 
I have the 2nd edition of Bjarnes "The C++ Programming Language" and
it's hard work. The detail is in there, but his writing style does not
gel with me. I'm assuming the later versions are better, maybe.
 
I'm returning to C++ after a decade away and wanted a book with C++11
features and choose "C++ Primer", 5th Edition by Lippman, Lajoie and
Moo. It's an excellent book running to 900+ pages and seems to cover the
whole language upto and including C++11. You may want/need Bjarnes book
as a standby for some features but try the primer book first.
 
For the STL I'm using "The C++ Standard Library" by Josuttis. Again,
it's a heavy weight book, easy to read and covers the latest version of
the library. Although it is printed on paper slightly thinner that
toilet paper !
 
Stephen
JiiPee <no@notvalid.com>: Nov 13 11:33AM

On 13/11/2014 11:22, Stephen wrote:
> of the library. Although it is printed on paper slightly thinner that
> toilet paper !
 
> Stephen
 
Ok the thing is that I am looking for as detailed book as possible,
because I know the basics. I want to go a bit deeper.
 
"The C++ Standard Library" by Josuttis.
Yes, am also planning to buy that. And now they have c++11 version of
it. But thats what am after now.... heavy weight. So I also want a heavy
weight C++11 language book.
 
Would be nice to have a book having details what happens in memory when
using different features etc. But not sure if that book exists. But I
like Bjarnes detailed writing.
 
I ll check that "C++ Primer"... would be good if could first read it in
a library before buying.
JiiPee <no@notvalid.com>: Nov 13 11:40AM

On 13/11/2014 09:33, JiiPee wrote:
> I have been thinking of buying a new book (or 2 books) to learn
> everything about C++11 (preferably including 14 but its not essential
> as 14 can be learned elsewhere I think as its not that different to 11).
 
Seems like Mayers "Effective Modern C++" coming this month might be
good. He seems to go to details a lot.
Robert Hutchings <rm.hutchings@gmail.com>: Nov 13 09:25AM -0600

On 11/13/2014 7:58 AM, Stefan Ram wrote:
 
> C and C++ are abstract languages. You can't even say how
> many bits an int object has. If you want to know what
> happens in memory, use assembler.
 
You can download a preview copy Scott Meyers' new book here:
http://cdn.oreillystatic.com/oreilly/booksamplers/9781491903995_sampler.pdf
JiiPee <no@notvalid.com>: Nov 13 05:58PM

On 13/11/2014 15:25, Robert Hutchings wrote:
> You can download a preview copy Scott Meyers' new book here:
> http://cdn.oreillystatic.com/oreilly/booksamplers/9781491903995_sampler.pdf
 
Yes thats good, have to check a bit that. But I have listened a lot
Scott videos, so am pretty confident he has some good stuff there.
ram@zedat.fu-berlin.de (Stefan Ram): Nov 13 01:58PM

>Ok the thing is that I am looking for as detailed book as possible,
 
If you ask the ISO very nicely and kindly, they might be
willing to sell you a copy of »International Standard
ISO/IEC 14882:2014(E) Programming Language C++«.
 
While you're at it, you also need to order the normative
references of ISO/IEC 14882:2014(E) to have all the details:
 
- ISO/IEC 2382 (all parts), Information technology -
Vocabulary
 
- ISO/IEC 9899:1999, Programming languages - C
 
- ISO/IEC 9899:1999/Cor.1:2001(E), Programming
languages - C, Technical Corrigendum 1
 
- ISO/IEC 9899:1999/Cor.2:2004(E), Programming
languages - C, Technical Corrigendum 2
 
- ISO/IEC 9899:1999/Cor.3:2007(E), Programming
languages - C, Technical Corrigendum 3
 
- ISO/IEC 9945:2003, Information Technology -
Portable Operating System Interface (POSIX)
 
- ISO/IEC 10646-1:1993, Information technology
-Universal Multiple-Octet Coded Character Set (UCS)
- Part 1: Architecture and Basic Multilingual Plane
 
- ISO/IEC TR 19769:2004, Information technology -
Programming languages, their environments and system
software interfaces - Extensions for the programming
language C to support new character data types

>having details what happens in memory when using different
>features
 
C and C++ are abstract languages. You can't even say how
many bits an int object has. If you want to know what
happens in memory, use assembler.
legalize+jeeves@mail.xmission.com (Richard): Nov 12 11:56PM

[Please do not mail me a copy of your followup]
 
red floyd <no.spam@its.invalid> spake the secret code
 
>As Paavo said, either static or const in this case provides internal
>linkage, so they are not visible outside the translation unit.
 
Agreed for static. Not so sure about const, but ISTR that there is
some default linkage implications for const.
 
>The namespace is a red herring, as is the fact that it's in a header.
 
Here's how I look at it: constants declared in a header are meant to
be referenced from multiple translation units and the constant should
follow ODR. When you declare things static in the header, you end up
with one definition per translation unit and depending on how often
this header is included, you can end up with tons of data bloat.
 
By declaring constants 'extern const' in a header and defining them in
a single translation unit, I was able to shave a couple megabytes off
the size of an application.
 
The advice being violated here is that your header contains
DEFINITIONS and not DECLARATIONS.
--
"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>
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)