Saturday, January 14, 2017

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

Paul <pepstein5@gmail.com>: Jan 14 07:05AM -0800

The below code works just fine to output 3. However, I'm uncomfortable about
defining y in terms of x in the same expression that defines x.
The code assumes that int x = 7, y = f(x); is equivalent to
int x = 7; int y = f(x);
 
Are they in fact equivalent? Is it a rule of C++ that
something1 , something2, ... always results in evaluating something1
before something2 etc. etc ?
I know that the comma operator works that way, but the below isn't
the comma operator.
 
Thanks,
Paul
 
 
int f(int)
{
return 3;
}
 
int main()
{
int x = 7, y = f(x);
std::cout << y;
}
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 14 04:17PM +0100

On 14.01.2017 16:05, Paul wrote:
> int x = 7, y = f(x);
> std::cout << y;
> }
 
Your ¹instinct that it's safer to use separate declarations is correct.
 
The declaration you have, with multiple declarators, is /technically/
correct, but it's easy to get wrong. And one can easily get confused
about types. E.g.
 
int const x = 1, y = 2;
 
Well, is `y` `const` or not?
 
 
Cheers!,
 
- Alf
 
¹ Women have intuition, while men have instinct. It's the same really.
Paul <pepstein5@gmail.com>: Jan 14 07:32AM -0800

On Saturday, January 14, 2017 at 3:18:14 PM UTC, Alf P. Steinbach wrote:
> about types. E.g.
 
> int const x = 1, y = 2;
 
> Well, is `y` `const` or not?
 
According to the WellWhyDontYouJustTryItAndSee rules, it can be observed
that y is const in your example. However, this surprised me.
I assumed it was akin to the old chestnut int* x = 0, y = 0; Here y
is an int, not a pointer.
 
Paul
Ben Bacarisse <ben.usenet@bsb.me.uk>: Jan 14 08:49PM


> On Saturday, January 14, 2017 at 3:18:14 PM UTC, Alf P. Steinbach wrote:
<snip>
> that y is const in your example. However, this surprised me.
> I assumed it was akin to the old chestnut int* x = 0, y = 0; Here y
> is an int, not a pointer.
 
There's a style in C++ of gluing parts of the declarator onto the type
(int*, char& and so on). I've never got on with that because the * is,
syntactically, associated with the name, not the "base type" (if you
know what I mean). To me it's not (written to give some idea of timing)
"intstar x initially 0 and y initially 0" but "int... starx initially
zero and y initially zero". "int* x;" looks almost as odd to me as
"return* y;"
 
I get that it's the done thing in C++ (it carries BS's seal of approval)
but I can't get one with it.
 
Things are messier with const since that keyword can appear in either
place.
 
int const *x, *const y;
 
but I've been using C and C++ for so long that with helpful spacing even
these are clear to me. (Here y is const but x is not. Both point to
const int.)
 
--
Ben.
"Chris M. Thomasson" <invalid@invalid.invalid>: Jan 13 03:34PM -0800

On 1/11/2017 10:17 AM, JiiPee wrote:
> but other ways. What would be the best way for the function to report
> about "dividing by zero" case? How would you do it?
 
> I kind of agree with Bjarne here.... do you?
 
FWIW, in my current line of working with floating point divide-by-zero
conditions is that they should be detected _before_ any execution that
would produce the deadly nan, during iteration. So, I check a value v
for zero, if v is zero I make a log in a report and set v to the current
epsilon of the iteration before the divide operation is allowed to be
realized, therefore avoiding divide-by-zero inserting a nan into an
iteration and basically destroying any subsequent iterations.
JiiPee <no@notvalid.com>: Jan 14 12:14AM

On 13/01/2017 23:34, Chris M. Thomasson wrote:
> FWIW, in my current line of working with floating point divide-by-zero
> conditions is that they should be detected _before_ any execution that
> would produce the deadly nan, during iteration.
 
 
Another question is that what should happen if somebody forgets to check
that divide by zero before calling average. In your case seems like tha
program crashes?
"Chris M. Thomasson" <invalid@invalid.invalid>: Jan 13 04:56PM -0800

On 1/13/2017 4:14 PM, JiiPee wrote:
 
> Another question is that what should happen if somebody forgets to check
> that divide by zero before calling average. In your case seems like tha
> program crashes?
 
No crash. However, the div-by-zero cases get detected, logged, and then
epsilon is divided instead of a zero case, and the iteration can
continue on its merry way, without spreading nan's like a damn virus.
 
The resulting log can be examined, and the renderings wrt replacing
div-by-zero via epsilon can be useful as well.
"Chris M. Thomasson" <invalid@invalid.invalid>: Jan 13 05:35PM -0800

On 1/13/2017 6:23 AM, David Brown wrote:
>> than put an address which points to an object which does not exist. When
>> debugging, NULL value is easier to spot than some valid/invalid object
>> address value.
[...]
> Any value you return for a function which received invalid data /will/
> be wrong.
[...]
 
What about the "deadlier" case of "kind of" totally wrong? IMVHO, best
to try and "spot/detect" these things before said nasal demons splatter
on proverbial Murphy's law shi% storm rising. A plot with nans tends to
be "easy" to "visually" spot for the rendering tends to resemble the
background color: Damn it!
 
;^o
"Chris M. Thomasson" <invalid@invalid.invalid>: Jan 13 05:46PM -0800

On 1/13/2017 4:56 PM, Chris M. Thomasson wrote:
> continue on its merry way, without spreading nan's like a damn virus.
 
> The resulting log can be examined, and the renderings wrt replacing
> div-by-zero via epsilon can be useful as well.
 
A possible rational for replacing zero with "very close to zero" can be:
 
Well, is was close to zero anyway, and we have a log to see why it got
that close for the iteration in question anyway.
 
;^)
JiiPee <no@notvalid.com>: Jan 14 01:51AM

On 14/01/2017 00:56, Chris M. Thomasson wrote:
> No crash. However, the div-by-zero cases get detected, logged, and
> then epsilon is divided instead of a zero case, and the iteration can
> continue on its merry way, without spreading nan's like a damn virus.
 
 
no I am talking about the situation where you DO NOT check the zero case
but just call that function WITHOUT check. Then it crashes, if the
function does no checks.
"Chris M. Thomasson" <invalid@invalid.invalid>: Jan 13 06:09PM -0800

On 1/13/2017 5:51 PM, JiiPee wrote:
 
> no I am talking about the situation where you DO NOT check the zero case
> but just call that function WITHOUT check. Then it crashes, if the
> function does no checks.
 
Without checking for div-by-zero, and just let it "fly"... Humm...
 
Well, beware of the infectious nan's that will most likely be cast
throughout subsequent iterations from point crap, of exotic experimental
algorithms in the complex plane. I personally like to be able to log
patient zero, or iteration zero if you will. The infecting agents
point/iteration of origin, so to speak. Nan or infinity, they both
posses the ability to simply ruin/destroy the damn fractal renderings!
Nans, lol, watch this:
 
https://youtu.be/-EaHLaZbMFs
 
;^)
Gareth Owen <gwowen@gmail.com>: Jan 14 11:21AM

> for zero, if v is zero I make a log in a report and set v to the
> current epsilon of the iteration before the divide operation is
> allowed to be realized
 
So, instead of getting NaN as answer, you get the wrong answer?
Or is this just for 0./0. (since 1/0. is Inf)?
 
Of course, if it very much depends on the algorithm you're iterating over
David Brown <david.brown@hesbynett.no>: Jan 14 06:08PM +0100

On 13/01/17 21:25, Ben Bacarisse wrote:
>> bottles?
 
> The average here would over time (the result being bottles/week or
> ml/day or whatever). The zero quantity is on the top of the division.
 
Yes, I know. I was merely trying to give an give an example of why
picking a value to return for bad input is going to be wrong sometimes,
no matter what value you pick. And while max_double or 99999999999999
might be good as an "obviously bad" value in some circumstances, it
might be used with bad results in other circumstances.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Jan 14 08:30PM


> Yes, I know. I was merely trying to give an give an example of why
> picking a value to return for bad input is going to be wrong
> sometimes, no matter what value you pick.
 
Then you've lost me. The input in your example is not wrong -- zero
consumption is perfectly normal, quite unlike an average of nothing.
 
<snip>
--
Ben.
"Chris M. Thomasson" <invalid@invalid.invalid>: Jan 14 12:45PM -0800

On 1/14/2017 3:21 AM, Gareth Owen wrote:
>> current epsilon of the iteration before the divide operation is
>> allowed to be realized
 
> So, instead of getting NaN as answer, you get the wrong answer?
 
In a sense you are correct, however I can review the log and see exactly
how things got to a div-by-zero. This is for rendering pictures, and a
nan or infinity can gum up the works.
 
> Or is this just for 0./0. (since 1/0. is Inf)?
 
Therefore, I try to avoid both nan and infinity. I am worried about
passing sqrt a negative number...
 
 
> Of course, if it very much depends on the algorithm you're iterating over
 
The algorithm is computing a Julia set in reverse. Here is some more
information:
 
https://en.wikipedia.org/wiki/Julia_set#Using_backwards_.28inverse.29_iteration_.28IIM.29
 
I am also computing the Buddha brot using normal forward iteration on
the roots generated by reverse iteration. Nan aside for a moment, these
iterations can escape into infinity. So, I test to see if it goes off
into never never land before I commit the iteration. If it does I log
it, set z to epsilon in the output structure of the function, and return
it to the caller.
 
The main problem is that an iteration uses information from previous
iterations. Nans and/or Infinities can propagate throughout the
subsequent iterations, and drastically alter the rendering. Like a virus.
 
;^o
kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Jan 14 02:33AM -0800

hi,
I have defined a class and then i create a pointer type instance of it at every iteration.After that i push that instance in a vector for later accessing the instance at a particular index.I am now confused about how to delete this pointer type instance after it is totally disposed.I came using 'delete' during destruction of the object.When i use this approach it causes some sort of segmentation fault.Is there any fool proof approach about delete this pointer instance after it is totally used from the vector without any seg faults.
Thank you,
Kushal
JiiPee <no@notvalid.com>: Jan 14 11:30AM

On 14/01/2017 10:33, kushal bhattacharya wrote:
> I have defined a class and then i create a pointer type instance of it at every iteration.After that i push that instance in a vector for later accessing the instance at a particular index.I am now confused about how to delete this pointer type instance after it is totally disposed.I came using 'delete' during destruction of the object.When i use this approach it causes some sort of segmentation fault.Is there any fool proof approach about delete this pointer instance after it is totally used from the vector without any seg faults.
> Thank you,
> Kushal
 
 
A bit difficult to understand what you mean. Would help if you give a
very short example about the problem.
kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Jan 14 04:56AM -0800

On Saturday, January 14, 2017 at 4:03:29 PM UTC+5:30, kushal bhattacharya wrote:
> I have defined a class and then i create a pointer type instance of it at every iteration.After that i push that instance in a vector for later accessing the instance at a particular index.I am now confused about how to delete this pointer type instance after it is totally disposed.I came using 'delete' during destruction of the object.When i use this approach it causes some sort of segmentation fault.Is there any fool proof approach about delete this pointer instance after it is totally used from the vector without any seg faults.
> Thank you,
> Kushal
 
 
 
 
for example
i have a class called Join
//now i create an instance of Join
for(int i=0;i<some_size;i++){
Join *j=new Join(with some parameter of constructor);
//after that i push it to vector of this class type(pointer type);
vector.push_back(j);
}
now if this Join instance is accessed by this vector via a particular index i want full access at those pushed instances.After all of the instances are use up (from this vector) i want to delete the pointer instances in order avoid any memory leak.I tried the conventional approach but there occurs some segmentation fault at some point.So is there any full proof method of disposing these pointer instances from the vector
jt@toerring.de (Jens Thoms Toerring): Jan 14 02:32PM

> avoid any memory leak.I tried the conventional approach but there occurs
> some segmentation fault at some point.So is there any full proof method of
> disposing these pointer instances from the vector
 
Calling 'delete' on each pointer you received from 'new' is the
way to go. If this results in a segmentation fault then there's
a bug in the code you haven't shown. And diagnosing invisible
bugs is a bit hard to do;-) Your best approach would probably
be to par down your program to the smallest possible one that
still shows the problem and post it here. While doing so you
might already figure out what's going wrong yourself.
 
Regareds, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
"Asger Joergensen" <Junk@Asger-P.dk>: Jan 14 02:54AM

Hi Richard
%
Richard wrote:
 
 
> Clearly you don't use VS for anything more fancy than typing.
 
> There is only one IDE that comes even close to VS productivity and
> that is CLion.
 
Don't forget C++Bulder
 
Best regards
Asger
Lynn McGuire <lynnmcguire5@gmail.com>: Jan 13 09:11PM -0600

On 1/13/2017 8:54 PM, Asger Joergensen wrote:
 
> Don't forget C++Bulder
 
> Best regards
> Asger
 
Is that the descendant of Turbo C ? The Turbo Pascal and Turbo C IDEs were freaking awesome. I developed several products with
those back in the 80s.
 
Lynn
jonkalb <google@kalbweb.com>: Jan 14 12:15AM -0800

> >> ever since.
 
> >I've heard of C++98, C++03, C++11, C++14, and C++17, but I've never heard of C++ version 2.1.
 
> Before standardization, C++ usually had version numbers.
 
No.
 
> book was published in 1991). What's called 2.1 is, I think, what
> corresponds to the 3rd edition of that book (published 1997),
> reflecting the language of a year or two prior to that.
 
You are referring to CFront version numbers, not language version numbers.
 
But at least I understand now what you meant.
"Asger Joergensen" <Junk@Asger-P.dk>: Jan 14 10:22AM

Hi Lynn
 
 
> Is that the descendant of Turbo C ? The Turbo Pascal and Turbo C IDEs were
> freaking awesome. I developed several products with those back in the 80s.
 
Yes a direct line, but a lot have happened since then:
https://www.embarcadero.com/
 
Best regards
Asger
Real Troll <real.troll@trolls.com>: Jan 13 10:30PM -0400

<https://channel9.msdn.com/Series/ConnectOn-Demand/211#time=0s>
"Chris M. Thomasson" <invalid@invalid.invalid>: Jan 13 05:40PM -0800

On 1/13/2017 2:37 PM, Mr Flibble wrote:
> 2017: "Ravioli" replaced "Romeo" in the NATO phonetic alphabet.
> #TrumpAdministration
 
I was thinking Romanesco Broccoli, or is that too visually pretty?
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)