Tuesday, October 3, 2017

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

Jerry Stuckle <jstucklex@attglobal.net>: Oct 02 08:43PM -0400

On 10/2/2017 8:00 PM, Stefan Ram wrote:
> the default behavior in C++?
 
> (Is it possible than processors have instructions to
> truncate, but not to round? And if so, why?)
 
All languages truncate unless you take specific actions to do otherwise.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
David Brown <david.brown@hesbynett.no>: Oct 03 08:55AM +0200

On 03/10/17 02:00, Stefan Ram wrote:
 
> But in everyday life in Germany, rounding is the usual
> approach when reducing the number of places after the
> digital point.
 
It is C++ programming, not everyday life. A "string" in everyday life
is entirely different from a "string" in programming.
 
 
> So how can one explain to non-programmers why truncation is
> the default behavior in C++?
 
Take a bottle of wine and some glasses, then fill the glasses to the
top. How many full glasses of wine do you have? Is the bar customer
going to be happy with 0.8 of a glass? There are lots of real-world
situations where 6.8 is just 6 with a bit left over.
 
fir <profesor.fir@gmail.com>: Oct 03 01:51AM -0700

W dniu wtorek, 3 października 2017 02:43:12 UTC+2 użytkownik Jerry Stuckle napisał:
> > the default behavior in C++?
 
> > (Is it possible than processors have instructions to
> > truncate, but not to round? And if so, why?)
 
this seems not so easy question
 
more weirdly c does not only truncates but it truncates to zero on both plus and minus which my just make additional errors
 
some may also consider preserverance of
 
(int) a-b == (int) a - (int) b
 
 
othervise i think the reason is maybe that f2i cast is probably only thinked as a final cast not expected to be used in mixed calculations (same as round should be not expected and as a final cast cut is more useful)
 
hovever if so the rules to promote to float should be maybe more aggresive and in facyt in normal c it seems they are maybe not so agresive and it brings a
problem of needing to put additional parentheses often (i dont exactly remember them and if that what i just wrote (as a hipothesis) is tru, but maybe)
fir <profesor.fir@gmail.com>: Oct 03 02:30AM -0700

W dniu wtorek, 3 października 2017 10:52:10 UTC+2 użytkownik fir napisał:
 
> othervise i think the reason is maybe that f2i cast is probably only thinked as a final cast not expected to be used in mixed calculations (same as round should be not expected and as a final cast cut is more useful)
 
> hovever if so the rules to promote to float should be maybe more aggresive and in facyt in normal c it seems they are maybe not so agresive and it brings a
> problem of needing to put additional parentheses often (i dont exactly remember them and if that what i just wrote (as a hipothesis) is tru, but maybe)
 
consider for example
 
int a = 1;
int b= 2;
float c = 1.2;
 
float d = a/b*c;
 
or
 
float d = (3+ a/b)*c;
 
how it should work? (here and all of that cases of mixed expresions) should a/b be promoted to float by default or not?
fir <profesor.fir@gmail.com>: Oct 03 02:45AM -0700

W dniu wtorek, 3 października 2017 11:30:19 UTC+2 użytkownik fir napisał:
 
> or
 
> float d = (3+ a/b)*c;
 
> how it should work? (here and all of that cases of mixed expresions) should a/b be promoted to float by default or not?
 
note here in such mixed sepressiion probably only div is probalematic,
on one side c does it good - it is it allows integer arithmetic in such expressions
on other side it generates problems
as coder must explicitely care for all such divs
 
side question, if
 
int a = 5;
int b = 7;
 
is
 
float c = float(a)/ b;
 
different (faster?) then
 
float c = a/(float)b;
 
or
float c = float(a)/(float)b;
 
?
Paavo Helde <myfirstname@osa.pri.ee>: Oct 03 01:26PM +0300

On 3.10.2017 12:30, fir wrote:
 
> or
 
> float d = (3+ a/b)*c;
 
> how it should work? (here and all of that cases of mixed expresions) should a/b be promoted to float by default or not?
 
I think fir is up to something here and one of the reasons of the
current behavior might indeed be to have some consistency regarding
integer division, so that int(8.0/3.0) would give the same result as
int(8.0)/int(3.0).
 
Whether the result of 8/3 should be an integer or a floating-point
number is another topic, greatly studied in Python2/Python3 wars if I
have understood correctly.
 
Cheers
Paavo
Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 03 11:07AM

On Tue, 2017-10-03, David Brown wrote:
...
> Take a bottle of wine and some glasses, then fill the glasses to the
> top. How many full glasses of wine do you have? Is the bar customer
> going to be happy with 0.8 of a glass?
 
I'd be -- I'd just spill wine on my clothes if the glass was really
full. Especially if it wasn't my first glass.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
red floyd <dont.bother@its.invalid>: Oct 02 05:04PM -0700

On 10/2/2017 12:37 PM, Chris M. Thomasson wrote:
>> feeding the trolls and making them post more and more and more, welcome
>> to my KILLFILE.
 
> Just joking around wrt the IPU and FSM.
 
As was I. Sorry guys.
Juha Nieminen <nospam@thanks.invalid>: Oct 03 06:44AM

> (6) As a general focus in life: Look to improve the lives
> of those around you by your labor time, thinking, goals,
> and activities.
 
I find it rather telling that honesty is among those. Which is quite
telling given how dishonest you are.
fir <profesor.fir@gmail.com>: Oct 03 02:13AM -0700

W dniu wtorek, 3 października 2017 > I find it rather telling that honesty is among those. Which is quite
> telling given how dishonest you are.
 
obviously dickhead rick is idiot badass that radiates with rays of utter stupidity
which is harmfull
 
but there is secondary problem people who read that, gets angry and answers to that making overeal increased focus to that devastating crap (i know it also is including me)
 
at least i would propose one rule here
 
1) if you answer to craphed rick do not quotate his trash in your ovn answer, just cut to zero not polluting eyes of people who filtered it out
 
i would also advice
 
2) dont answer to other answer of our craphed even if it is ontopic (becouse if you do so it will flod more of braindead trash soon) --- (his ontopic propositions are obviously also only examples of his utter cretinism nothing more)
 
 
 
dick is real deadly as human brain has some specyfic that is if you focus on A you unfocus on B & C and if it is such heavy crap it is just simple devastating,
it just smashes normal inteligence out especially effectively and thats needs utter defence ;c
fir <profesor.fir@gmail.com>: Oct 03 02:19AM -0700

ps obviously i agree that dickhead rick is cheater
 
this moron expect people to drop criticism and take all what he says as a true becouse he says so even if it is false and he is just idiot (as he obviously is)..
asetofsymbols@gmail.com: Oct 03 12:35AM -0700

Perhaps I have to change something because
This
F(i=0,ooo<<"la=[";i<la.sz;++i)
ooo<<la[i]<<" ";
ooo<<"]\n";
should be ok,
 
But this
F(i=0,ooo<<"la=[";i<=la.sz;++i)
ooo<<la[i]<<" ";
ooo<<"]\n";
Should create one indefinite long linked list (and so ended the memory resource)
Reinhardt Behm <rbehm@hushmail.com>: Oct 03 03:48PM +0800

> ooo<<"]\n";
> Should create one indefinite long linked list (and so ended the memory
> resource)
 
What does this trash mean?
There is only one reasonable change:
rm *
 
--
Reinhardt
legalize+jeeves@mail.xmission.com (Richard): Oct 03 12:28AM

[Please do not mail me a copy of your followup]
 
slp53@pacbell.net spake the secret code
 
>Or just write code that performs correctly and optimally using any feature of
>C++ (including those inherited from C) instead of relying on some
>dogmatic approach to C++ programming.
 
The reason to avoid malloc/free isn't dogma, it is the accumulated
experience of people making stupid mistakes when they use malloc and
free along with raw pointers directly instead of using standard
containers and smart pointers.
 
>And avoid using smart pointers when you care about performance.
 
This doesn't make any sense to me. How is using std::unique_ptr to
declare ownership going to make things slower? Someone has to release
the memory when ownership is released and that's what unique_ptr
brings to the table. Performance in a modern machine is dominated by
cache misses more than microinstructions around obtaining the
underlying raw pointer from a smart pointer.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Barry Schwarz <schwarzb@dqel.com>: Oct 02 07:11PM -0700

On Mon, 2 Oct 2017 12:47:48 -0700, "Chris M. Thomasson"
>a counter for each allocation, and decrements for each deallocation.
 
>If this counter is not zero when the program terminates, there is a
>leak. Stupid simple and naive, but it can help, in a sense.
 
But something other than the allocator must examine the counter. The
allocator is not reporting leaks. It is providing data that will
allow another function to determine if a leak is present. And in this
case, it will provide the quantity of leaks but no data about any of
them.
 
--
Remove del for email
asetofsymbols@gmail.com: Oct 02 10:13PM -0700

Barry Schwarz wrote:
On Mon, 2 Oct 2017 12:47:48 -0700, "Chris M. Thomasson"
>a counter for each allocation, and decrements for each deallocation.
 
>If this counter is not zero when the program terminates, there is a
>leak. Stupid simple and naive, but it can help, in a sense.
 
 
But something other than the allocator must examine the counter. The
allocator is not reporting leaks. It is providing data that will
allow another function to determine if a leak is present. And in this
case, it will provide the quantity of leaks but no data about any of
them.
------------
Some data of the heap list that use malloc it seems global data accessible in one assembly file to one function
name as freeList(void); at end of program freeList() is called
it print all relative memory info;
free to the sys, memory
allocate for build the heap list.
Function as malloc/free/realloc/freeList are function of one .dll from assembly language
Paavo Helde <myfirstname@osa.pri.ee>: Oct 03 09:42AM +0300

On 3.10.2017 5:11, Barry Schwarz wrote:
>> leak. Stupid simple and naive, but it can help, in a sense.
 
> But something other than the allocator must examine the counter. The
> allocator is not reporting leaks.
 
Oh, I see you are into word games. No problem, the allocator can easily
report its statistics to console when asked to allocate size_t(-1), for
example. Just kidding ;-)
Jerry Stuckle <jstucklex@attglobal.net>: Oct 02 08:42PM -0400

> For me "error object" is one special object (among all objects can be in its type)
 
> one real object with its memory etc all ok, only differ with a bit on, or one its member for example int ==1
 
Nope. This is an fstream object with a state that indicates an error.
It is not an error object.
 
> should be the object with x.e==1
> (if it is 0 than all ok)
> And so on
 
It makes no difference. It is an fstream object - as defined in the
source code. The fact there was an open error does not change that.
 
And in OO, a properly defined object will only allow valid operations;
it will not allow invalid operations. For instance, writing to an
fstream which has not been opened will also cause an error.
 
You REALLY need to understand proper OO design and terminology. It is
obvious you don't (as well as having a crappy programming style that no
project manager in his right mind would accept).
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
asetofsymbols@gmail.com: Oct 02 10:19PM -0700

I call it "error object" because a name other to indicate it, to describe it, its way of to be: I don't know... It is not one malfunction object or one object has less memory it has to have
it has one bit on or one element ==1
or it is one value of one range,
used to indicate that object is result of one error operation
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 02 08:19PM -0400

On 10/02/2017 07:48 PM, Stefan Ram wrote:
> "value-initialize"?
 
> (What it actually does [simplified] is to default-initialize
> or zero-initialize something.)
 
It initializes something with a value (either a default assigned value
or a zero) ... right?
 
--
Thank you, | Indianapolis, Indiana | God is love -- 1 John 4:7-9
Rick C. Hodgin | http://www.libsf.org/ | http://tinyurl.com/yaogvqhj
-------------------------------------------------------------------------
Software: LSA/C, Debi, RDC, CAlive, ES/2, VJr, VFrP, Logician, C90/99
Hardware:
Aroxda Desktop CPU -- 40-bit multi-core 80386 with many extensions
Arxita Embedded CPU -- Low power, low pin count 80386 w/128 registers
Arlina Compute FPGA -- Scalable compute cores, large GPIO pin count
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 03 04:33AM +0200

On 10/3/2017 1:48 AM, Stefan Ram wrote:
> "value-initialize"?
 
> (What it actually does [simplified] is to default-initialize
> or zero-initialize something.)
 
I don't know but you can ask Andrew Koenig. He proposed it.
 
 
Cheers!,
 
- Alf
ram@zedat.fu-berlin.de (Stefan Ram): Oct 02 11:48PM

Why is the verb "to value-initialize" (11.6p8) called
"value-initialize"?
 
(What it actually does [simplified] is to default-initialize
or zero-initialize something.)
ram@zedat.fu-berlin.de (Stefan Ram): Oct 03 12:00AM

A participant of my C++ course asked why
 
int i = 6.8;
 
truncates and does not round.
 
For me, as a programmer, the answer is: It is simpler and
one needs it more often than rounding.
 
But in everyday life in Germany, rounding is the usual
approach when reducing the number of places after the
digital point.
 
So how can one explain to non-programmers why truncation is
the default behavior in C++?
 
(Is it possible than processors have instructions to
truncate, but not to round? And if so, why?)
ram@zedat.fu-berlin.de (Stefan Ram): Oct 03 12:23AM

>istringstream iss("a");
>iss.get();
 
The failbit indicates that an input operation failed
to read the expected characters.
 
This can only happen if you do one more call to »get«.
Shiyao MA <i@introo.me>: Oct 02 05:09PM -0700

or the following code:
 
#include <iostream>
#include <sstream>
 
using namespace std;
 
int main() {
istringstream iss("a");
iss.get();
cout << iss.tellg() << endl; // 1
cout << iss.fail() << endl; // 0
}
I'd expect the result be -1,1 not 1, 0.
 
tellg will first construct a sentry and then check fail().
 
according to http://eel.is/c++draft/istream::sentry#2
If is.rdbuf()->sbumpc() or is.rdbuf()->sgetc() returns traits​::​eof(), the function calls setstate(failbit | eofbit) (which may throw ios_­base​::​failure).
 
 
so fail() should be true, and tellg should return -1.
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)