comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* Getting Started with a Visual Studio C++ 2013 IDE - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/6af661da9c3466bf?hl=en
* Boost - 6 messages, 4 authors
http://groups.google.com/group/comp.lang.c++/t/81738d66827a11c8?hl=en
* Address one past the end of array - is this syntax a valid C++? - 6 messages,
3 authors
http://groups.google.com/group/comp.lang.c++/t/3660f2b84a4f1cb3?hl=en
* Meaning of ~0 - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/49b86d4e311b7a5f?hl=en
* Overloaded function template with different return types - 2 messages, 2
authors
http://groups.google.com/group/comp.lang.c++/t/a4fb484d72da3e8b?hl=en
* Choosing the right epsilon for comparing doubles - 5 messages, 4 authors
http://groups.google.com/group/comp.lang.c++/t/5f5b1d64b66b5096?hl=en
==============================================================================
TOPIC: Getting Started with a Visual Studio C++ 2013 IDE
http://groups.google.com/group/comp.lang.c++/t/6af661da9c3466bf?hl=en
==============================================================================
== 1 of 4 ==
Date: Sat, Feb 1 2014 2:42 pm
From: Victor Bazarov
On 2/1/2014 3:19 PM, Tobias Müller wrote:
> "W. eWatson" <wolftracks@invalid.com> wrote:
>> Been at that link, but it didn't help. I think there are just too many
>> variety of editions for Visual Studio.
>>
>> I just installed 2010, and see there's a video in it for Beginner
>> Developers. Cleverly the title is for the 2008 Express Edition. A little
>> examination here shows me this isn't going to help me. Sigh!
>
> From VS 2005 to VS 2010 there are only minor differences regarding the user
> interface. Especially when it comes to the basic concepts. Most notable
> improvements in VS 2010 are IMO the much better intellisense (on-the-fly
> analysis for code completion, refactoring and navigation) and the profiler
> that is available not only in team edition.
> But for the first steps that probably not so relevant.
To answer a question in another post, no, there is no NG for it (not an
active one anyway).
I recommend getting a book. Something in line with "Visual Studio for
Dummies". They are usually well written (not that I've read any, but I
heard many people's praises) without condescension and full of easy
explanations on how to accomplish some simple tasks, which should give
the OP at least some handle on the product.
As with any other complex tool, ease comes with practice. So, start by
doing what the book says, and then try repeating those (usually simple)
steps with some variations.
V
--
I do not respond to top-posted replies, please don't ask
== 2 of 4 ==
Date: Sat, Feb 1 2014 2:56 pm
From: "Rick C. Hodgin"
On Friday, January 31, 2014 11:28:55 PM UTC-5, W. eWatson wrote:
> I understand C++. What I'm looking for is how one operates the IDE
> provided in VS C++ Desktop. What programming I've done usually does not
> include a sophisticated IDE. I see FILE, EDIT,VIEW, DEBUG, etc. along
> the top of the IDE. I'd like more details on these items. I would
> suspect somewhere there's an explanation of them. Most manuals describe
> them in the first 10 pages. Does a tutorial or manual that explains them
> exist? It would be nice to see some examples of building a program and
> compiling libraries for it.
>
> BTW, I've spent a lot of time today Googling VS introductions to IDEs,
> but they never sync with the VS C++ 2013 product I have.
There is an add-on utility I would recommend. It's called "Visual Assist X"
and it's made by Whole Tomato (www.wholetomato.com). It will augment your
editing experience to provide many features that are natively lacking in the
Visual Studio IDE environment.
Best regards,
Rick C. Hodgin
== 3 of 4 ==
Date: Sat, Feb 1 2014 5:31 pm
From: "W. eWatson"
On 2/1/2014 2:42 PM, Victor Bazarov wrote:
> On 2/1/2014 3:19 PM, Tobias Müller wrote:
>> "W. eWatson" <wolftracks@invalid.com> wrote:
>>> Been at that link, but it didn't help. I think there are just too many
>>> variety of editions for Visual Studio.
>>>
>>> I just installed 2010, and see there's a video in it for Beginner
>>> Developers. Cleverly the title is for the 2008 Express Edition. A little
>>> examination here shows me this isn't going to help me. Sigh!
>>
>> From VS 2005 to VS 2010 there are only minor differences regarding
>> the user
>> interface. Especially when it comes to the basic concepts. Most notable
>> improvements in VS 2010 are IMO the much better intellisense (on-the-fly
>> analysis for code completion, refactoring and navigation) and the
>> profiler
>> that is available not only in team edition.
>> But for the first steps that probably not so relevant.
>
> To answer a question in another post, no, there is no NG for it (not an
> active one anyway).
>
> I recommend getting a book. Something in line with "Visual Studio for
> Dummies". They are usually well written (not that I've read any, but I
> heard many people's praises) without condescension and full of easy
> explanations on how to accomplish some simple tasks, which should give
> the OP at least some handle on the product.
>
> As with any other complex tool, ease comes with practice. So, start by
> doing what the book says, and then try repeating those (usually simple)
> steps with some variations.
>
> V
I drove down to my local Barnes and Noble bookstore this afternoon.
It's45 miles from here. I found about six C++ books, They pretty much
off handed remarked about the IDE. One was probably the Dummies (2010)
book you mentioned. It briefly mentioned IDE. There are about 10
versions of the Dummy books. Only two allow "Look Inside". Pretty
limited in what they allow to be read.
Well, I guess I just bounce around the IDE, and see if I can make any
sense of it. That plus some googling.
== 4 of 4 ==
Date: Sat, Feb 1 2014 6:11 pm
From: "Rick C. Hodgin"
On Saturday, February 1, 2014 8:31:59 PM UTC-5, W. eWatson wrote:
> I drove down to my local Barnes and Noble bookstore this afternoon.
> It's45 miles from here. I found about six C++ books, They pretty much
> off handed remarked about the IDE. One was probably the Dummies (2010)
> book you mentioned. It briefly mentioned IDE. There are about 10
> versions of the Dummy books. Only two allow "Look Inside". Pretty
> limited in what they allow to be read.
>
> Well, I guess I just bounce around the IDE, and see if I can make any
> sense of it. That plus some googling.
YouTube is a great resources. And it's (reasonably) free.
Best regards,
Rick C. Hodgin
==============================================================================
TOPIC: Boost
http://groups.google.com/group/comp.lang.c++/t/81738d66827a11c8?hl=en
==============================================================================
== 1 of 6 ==
Date: Sat, Feb 1 2014 2:44 pm
From: Ian Collins
woodbrian77@gmail.com wrote:
> On Saturday, February 1, 2014 4:20:15 PM UTC-6, Ian Collins wrote:
>
>> That still wouldn't help in the situations I'm familiar with. A
>> technique one of my clients uses is to build their release software in a
>> VM and then snapshot and archive the machine. They need to know that
>> they can recreate any release in a reliable, reproducible, manner. You
>> would have to tie yourself up in all sorts of legal knots to meet their
>> requirements...
>>
>
>
> They could store code generated by the C++ Middleware
> Writer if they wanted to.
That wouldn't help when a customer with a 10 year old system asks for a fix!
Anyway, the market segments I'm familiar with are probably at the more
paranoid end of the spectrum when it comes to tools. I'm sure the
majority of potential customers are more open minded when it comes to
web based tools. Just be aware of another issue I'm seeing more often:
customers wanting to know if their data will go anywhere near the US!
--
Ian Collins
== 2 of 6 ==
Date: Sat, Feb 1 2014 3:46 pm
From: woodbrian77@gmail.com
On Saturday, February 1, 2014 4:44:57 PM UTC-6, Ian Collins wrote:
> woodbrian77@gmail.com wrote:
>
> >>
> > They could store code generated by the C++ Middleware
> > Writer if they wanted to.
>
> That wouldn't help when a customer with a 10 year old system asks for a fix!
>
A company could ask us to store a particular version.
If we know about it, I don't see a problem with that.
There would be some administrative work around it, but
it doesn't seem like too big a deal. We'll automate
it if there's enough interest.
> Anyway, the market segments I'm familiar with are probably at the more
> paranoid end of the spectrum when it comes to tools. I'm sure the
> majority of potential customers are more open minded when it comes to
> web based tools. Just be aware of another issue I'm seeing more often:
> customers wanting to know if their data will go anywhere near the US!
>
Other countries spy.
I would like to see the NSA's budget cut by half.
The IRS should be chopped back too.
Brian
Ebenezer Enterprises
http://webEbenezer.net
== 3 of 6 ==
Date: Sat, Feb 1 2014 4:25 pm
From: Ian Collins
woodbrian77@gmail.com wrote:
>
> There are more specifics here
>
> http://webEbenezer.net/comparison.html
Your examples return 1 from main on success, which isn't a good idea...
Use EXIT_SUCCESS and EXIT_FAILURE.
--
Ian Collins
== 4 of 6 ==
Date: Sun, Feb 2 2014 4:46 am
From: Öö Tiib
On Sunday, 2 February 2014 01:46:29 UTC+2, woodb...@gmail.com wrote:
> On Saturday, February 1, 2014 4:44:57 PM UTC-6, Ian Collins wrote:
> > woodbrian77@gmail.com wrote:
> >
> > >>
> > > They could store code generated by the C++ Middleware
> > > Writer if they wanted to.
> >
> > That wouldn't help when a customer with a 10 year old system asks for a fix!
> >
>
> A company could ask us to store a particular version.
> If we know about it, I don't see a problem with that.
> There would be some administrative work around it, but
> it doesn't seem like too big a deal. We'll automate
> it if there's enough interest.
They need to build tests and then patched version of
the 10 year old product. How does their build system
integrate with your online code generator? How does it
integrate now? How will it integrate 10 years later?
Will their current build system run without changes 10
years later? Are you alive 10 years later?
Most opponents of usage of Boost speak some sort of NIH
and FUD rhetoric, despite all source code is available
(including 10+ years old versions) from several sources
and heavily peer-reviewed. How you overcome that with
your service?
== 5 of 6 ==
Date: Sun, Feb 2 2014 5:21 am
From: Dombo
Op 01-Feb-14 22:11, woodbrian77@gmail.com schreef:
> Saturday, February 1, 2014 12:57:21 PM UTC-6, Dombo wrote:
>> Op 01-Feb-14 19:34, woodbrian77@gmail.com schreef:
>>>> Ask yourself what is the benefit of online code generation for the
>>>> client.
>>>
>>> Longevity is an important factor. Users need
>>> tools that will outlast their projects. Unlike
>>> most of our competitors, we have a business model
>>> that's based on on line code generation.
>>
>> Longevity of the tools is exactly the reason is why relying on some
>> online tool is generally not a good idea for the reasons I stated in my
>> previous post. Again: what is the benefit of online code generation for
>> the client?
>>
> Are you using an open source search engine?
I fail to see the relevance of that question. A search engine does not
generate code to be integrated into my software. If the search engine
would change its algorithms or the company behind it pull the plug it
wouldn't affect my business much if at all, unlike a online code
generation tool which my software would depend on.
It is still not clear to me what is the benefit for the client is of
online code generation.
>>> I get the feeling some are surprised by how a
>>> small company like Ebenezer Enterprises is
>>> able to outsmart bigger comptetitors.
>>> Recall the story of David against Goliath.
>>> David, using a new technology, took down
>>> the more established Goliath. Is on line
>>> code generation the new slingshot?
>>
>> I've seen very little to suggest that you are outsmarting anyone.
>
> I'm not sure where you've looked.
I've seen your posts here, and I've looked at your website, and found
nothing to support your assertion that you are outsmarting your 'bigger
competitors'. In fact I get the impression you don't even are aware of
many of the well known alternatives for your offering out there.
The impression I get is that CMW is little more than a personal hobby
project with very little or no use from anyone else.
> Some "successful" companies like Southwest Airlines
> and Facebook have had to learn the hard way that
> the languages they were using didn't scale well.
> I've been using C++ from the beginning. Work done
> on the foundation may not be easy to notice, but it
> provides for the long term future of the company.
Whether C++ is the appropriate choice for Facebook or Southwest Airlines
is not the subject being discussed here. Nor does it explain why a
online tool would be better from a longevity perspective.
>>> Sorry if you don't like it, but this is the
>>> way things are headed. Ebenezer Enterprises
>>> is in better shape today than ever. This is
>>> from our website:
>>
>>> I'm willing to donate 15 hours/week for six months
>>> to a project that uses the C++ Middleware Writer.
>>>
>>> Also I'll pay $500 and give a $1,000 investment in
>>> Ebenezer Enterprises to someone who helps me find
>>> someone interested in this. I'll pay the $500
>>> after working for four months on the project.
>>> Ebenezer Enteprises works to reward investments to
>>> 3 times their original amount. So the investment
>>> would result in between $0 and $3,000, depending
>>> on how things go for the company.
>>
>> That sounds more like a desperate company to me than a company in good
>> shape. Add to that an amateurish website. Not the kind of company you
>> would want to rely on to provide some online service.
>
> I acknowledge the website could be better and the
> documentation also. I've been asking for ideas on
> how to improve that. If you have some specific
> ideas on that, please let me know.
Ask yourself what incentive people have to spend time and energy to
provide consultancy to improve your offering.
> Beggars can't be choosers as far as who they are going
> to rely on.
You are assuming that your potential customers are beggars. And even if
that is true (I hope for your sake it isn't) there are plenty of free-
and paid alternatives to choose from.
> If you are drowning and someone offers
> to help you, are you going to turn them down if they
> don't have a lifeguard certification?
In your analogy I would be already surrounded by certified lifeguards.
So why would I send the certified lifeguards away in favor of someone
who is struggling to stay afloat himself?
There are already many well known and proven alternatives for what you
are offering. The question remains in what way your solution improves on
what there is already out there.
> I'm willing to help a company get their mojo back.
I don't mean to be harsh, but frankly I doubt you have what it takes to
do that.
== 6 of 6 ==
Date: Sun, Feb 2 2014 5:56 am
From: Dombo
Op 01-Feb-14 22:52, woodbrian77@gmail.com schreef:
> On Saturday, February 1, 2014 1:27:51 PM UTC-6, Dombo wrote:
>>> Op 01-Feb-14 19:54, woodbrian77@gmail.com schreef:
>>>> On Saturday, February 1, 2014 12:34:29 PM UTC-6, woodb...@gmail.com wrote:
>>>>> On Saturday, February 1, 2014 10:52:21 AM UTC-6, Dombo wrote:
>>>>
>>>>> Ask yourself what is the benefit of online code generation for the
>>>>> client.
>>>>
>>>> Longevity is an important factor.
>>>
>>> Another factor is simplifying the development
>>> process. Some competitors expect you to
>>> download huge libraries and maintain them.
>>> "Oops. Sorry, there's a bug in such and such.
>>> Please patch your install ..."
>>
>> At least the client has the option to decided whether or not to install
>> the patch or not. There is always a risk with updates, updates not only
>> fix bugs but quite often also introduce new bugs. If you are not
>> affected by the bugs that are supposedly fixed and your project is in a
>> critical phase, one might want to postpone the update.
>
> I'm afraid the lack of choice here is due to "leaders"
> like Bill Gates and Obama.
I don't see how you can possibly blame Bill Gates and Obama for the lack
of choice when to apply a patch in your online code generation scheme.
Sounds like crazy talk to me.
==============================================================================
TOPIC: Address one past the end of array - is this syntax a valid C++?
http://groups.google.com/group/comp.lang.c++/t/3660f2b84a4f1cb3?hl=en
==============================================================================
== 1 of 6 ==
Date: Sat, Feb 1 2014 3:33 pm
From: Mr Flibble
On 01/02/2014 22:36, Victor Bazarov wrote:
> On 2/1/2014 12:23 PM, Peter wrote:
>> Assume we have an array:
>>
>> int arr[5];
>>
>> It's legal to refer to address arr + 5, but, of course, illegal to
>> refer to element arr[5] as it's not part of the array. However, arr +
>> n is equivalent to &arr[n]. My question is: does this equivalence
>> also hold for an edge case of n = 5 (or, generally, n equal to number
>> of elements of array)?
>>
>> While there's nothing wrong with arr + 5, &arr[5] looks highly
>> suspicious: it looks like in the first step arr[5] is evaluated
>> (which introduces an undefined behaviour) which would mean the
>> expression as a whole is undefined. Does the equivalence still hold
>> in this special case?
>
> I would not be surprised at the validity of this after I've learned that
> initializing a reference by dereferencing a null pointer is now legal.
> *nullptr creates a special kind of reference, and the only useful
> operation you can do with it is to take its address, which in turn
> should give you null, as I understand it. So, using the same logic, the
> expression a[n] is the same as *(a+n), which is to give you a reference
> to a non-existing element (one beyond the last in the array) and with
> that reference the only valid operation is to take its address.
> According to the precedence rules, &arr[5] is evaluated as &(*(arr+5)),
> which is OK (if you subscribe to the invalid reference idea and the
> validity of applying the 'address of' operator to it).
Bullshit mate; dereferencing null pointers is UB.
/Flibble
== 2 of 6 ==
Date: Sun, Feb 2 2014 3:39 am
From: bblaz
On 02/02/14 00:33, Mr Flibble wrote:
> On 01/02/2014 22:36, Victor Bazarov wrote:
>> On 2/1/2014 12:23 PM, Peter wrote:
>>> Assume we have an array:
>>>
>>> int arr[5];
>>>
>>> It's legal to refer to address arr + 5, but, of course, illegal to
>>> refer to element arr[5] as it's not part of the array. However, arr +
>>> n is equivalent to &arr[n]. My question is: does this equivalence
>>> also hold for an edge case of n = 5 (or, generally, n equal to number
>>> of elements of array)?
>>>
>>> While there's nothing wrong with arr + 5, &arr[5] looks highly
>>> suspicious: it looks like in the first step arr[5] is evaluated
>>> (which introduces an undefined behaviour) which would mean the
>>> expression as a whole is undefined. Does the equivalence still hold
>>> in this special case?
>>
>> I would not be surprised at the validity of this after I've learned that
>> initializing a reference by dereferencing a null pointer is now legal.
>> *nullptr creates a special kind of reference, and the only useful
>> operation you can do with it is to take its address, which in turn
>> should give you null, as I understand it. So, using the same logic, the
>> expression a[n] is the same as *(a+n), which is to give you a reference
>> to a non-existing element (one beyond the last in the array) and with
>> that reference the only valid operation is to take its address.
>> According to the precedence rules, &arr[5] is evaluated as &(*(arr+5)),
>> which is OK (if you subscribe to the invalid reference idea and the
>> validity of applying the 'address of' operator to it).
>
> Bullshit mate; dereferencing null pointers is UB.
>
> /Flibble
Not always true.
Dereferencing pointers which do not point to valid objects is undefined
behavior if the program necessitates the lvalue-to-rvalue conversion of
the *arr expression.
see 4.1 #1.
5.3.1 #3
The result of the unary & operator is a pointer to its operand. The
operand shall be either an lvalue of type
other than "array of runtime bound" or a qualified-id.
Evaluation of &*arr expression does not necessitate the lvalue-to-rvalue
conversion, hence its legal.
Also 5.3.1 #1
The unary * operator performs indirection: the expression to which it is
applied shall be a pointer to an
object type, or a pointer to a function type and the result is an lvalue
referring to the object or function
to which the expression points. If the type of the expression is
"pointer to T," the type of the result is
"T." [ Note: indirection through a pointer to an incomplete type (other
than cv void) is valid. The lvalue
thus obtained can be used in limited ways (to initialize a reference,
for example); this lvalue must not be
converted to a prvalue, see 4.1. -- end note ]
blaz
== 3 of 6 ==
Date: Sun, Feb 2 2014 6:36 am
From: Dombo
Op 01-Feb-14 23:36, Victor Bazarov schreef:
> On 2/1/2014 12:23 PM, Peter wrote:
>> Assume we have an array:
>>
>> int arr[5];
>>
>> It's legal to refer to address arr + 5, but, of course, illegal to
>> refer to element arr[5] as it's not part of the array. However, arr +
>> n is equivalent to &arr[n]. My question is: does this equivalence
>> also hold for an edge case of n = 5 (or, generally, n equal to number
>> of elements of array)?
>>
>> While there's nothing wrong with arr + 5, &arr[5] looks highly
>> suspicious: it looks like in the first step arr[5] is evaluated
>> (which introduces an undefined behaviour) which would mean the
>> expression as a whole is undefined. Does the equivalence still hold
>> in this special case?
>
> I would not be surprised at the validity of this after I've learned that
> initializing a reference by dereferencing a null pointer is now legal.
> *nullptr creates a special kind of reference, and the only useful
> operation you can do with it is to take its address, which in turn
> should give you null, as I understand it. So, using the same logic, the
> expression a[n] is the same as *(a+n), which is to give you a reference
> to a non-existing element (one beyond the last in the array) and with
> that reference the only valid operation is to take its address.
> According to the precedence rules, &arr[5] is evaluated as &(*(arr+5)),
> which is OK (if you subscribe to the invalid reference idea and the
> validity of applying the 'address of' operator to it).
I'm not sure this is the case; according to the C++ 11 draft standard
(N3337): "Note: std::nullptr_t is a distinct type that is neither a
pointer type nor a pointer to member type; rather, a prvalue of this
type is a null pointer constant and can be converted to a null pointer
value or null member pointer value.". I.e. since nullptr is not a
pointer type the fact that you can legally dereference it (which
surprised me a bit, but I suppose there is a good reason for it),
doesn't necessarily mean that it is also legal to dereference a pointer
referencing a non-existing element.
== 4 of 6 ==
Date: Sun, Feb 2 2014 8:47 am
From: Mr Flibble
On 02/02/2014 12:39, bblaz wrote:
> On 02/02/14 00:33, Mr Flibble wrote:
>> On 01/02/2014 22:36, Victor Bazarov wrote:
>>> On 2/1/2014 12:23 PM, Peter wrote:
>>>> Assume we have an array:
>>>>
>>>> int arr[5];
>>>>
>>>> It's legal to refer to address arr + 5, but, of course, illegal to
>>>> refer to element arr[5] as it's not part of the array. However, arr +
>>>> n is equivalent to &arr[n]. My question is: does this equivalence
>>>> also hold for an edge case of n = 5 (or, generally, n equal to number
>>>> of elements of array)?
>>>>
>>>> While there's nothing wrong with arr + 5, &arr[5] looks highly
>>>> suspicious: it looks like in the first step arr[5] is evaluated
>>>> (which introduces an undefined behaviour) which would mean the
>>>> expression as a whole is undefined. Does the equivalence still hold
>>>> in this special case?
>>>
>>> I would not be surprised at the validity of this after I've learned that
>>> initializing a reference by dereferencing a null pointer is now legal.
>>> *nullptr creates a special kind of reference, and the only useful
>>> operation you can do with it is to take its address, which in turn
>>> should give you null, as I understand it. So, using the same logic, the
>>> expression a[n] is the same as *(a+n), which is to give you a reference
>>> to a non-existing element (one beyond the last in the array) and with
>>> that reference the only valid operation is to take its address.
>>> According to the precedence rules, &arr[5] is evaluated as &(*(arr+5)),
>>> which is OK (if you subscribe to the invalid reference idea and the
>>> validity of applying the 'address of' operator to it).
>>
>> Bullshit mate; dereferencing null pointers is UB.
>>
>> /Flibble
>
> Not always true.
More bullshit. It is always true mate; dereferencing null pointers is UB.
8.3.2/5
"A reference shall be initialized to refer to a valid object
or function. [ Note: in particular, a null reference cannot exist in a
well-defined program, because the only
way to create such a reference would be to bind it to the "object"
obtained by dereferencing a null pointer,
which causes undefined behavior. As described in 9.6, a reference cannot
be bound directly to a bit-field.
--end note ]"
[snipped unrelated Standard quotes]
/Flibble
== 5 of 6 ==
Date: Sun, Feb 2 2014 9:43 am
From: bblaz
On 02/02/14 17:47, Mr Flibble wrote:
> On 02/02/2014 12:39, bblaz wrote:
>> On 02/02/14 00:33, Mr Flibble wrote:
>>> On 01/02/2014 22:36, Victor Bazarov wrote:
>>>> On 2/1/2014 12:23 PM, Peter wrote:
>>>>> Assume we have an array:
>>>>>
>>>>> int arr[5];
>>>>>
>>>>> It's legal to refer to address arr + 5, but, of course, illegal to
>>>>> refer to element arr[5] as it's not part of the array. However, arr +
>>>>> n is equivalent to &arr[n]. My question is: does this equivalence
>>>>> also hold for an edge case of n = 5 (or, generally, n equal to number
>>>>> of elements of array)?
>>>>>
>>>>> While there's nothing wrong with arr + 5, &arr[5] looks highly
>>>>> suspicious: it looks like in the first step arr[5] is evaluated
>>>>> (which introduces an undefined behaviour) which would mean the
>>>>> expression as a whole is undefined. Does the equivalence still hold
>>>>> in this special case?
>>>>
>>>> I would not be surprised at the validity of this after I've learned
>>>> that
>>>> initializing a reference by dereferencing a null pointer is now legal.
>>>> *nullptr creates a special kind of reference, and the only useful
>>>> operation you can do with it is to take its address, which in turn
>>>> should give you null, as I understand it. So, using the same logic,
>>>> the
>>>> expression a[n] is the same as *(a+n), which is to give you a reference
>>>> to a non-existing element (one beyond the last in the array) and with
>>>> that reference the only valid operation is to take its address.
>>>> According to the precedence rules, &arr[5] is evaluated as &(*(arr+5)),
>>>> which is OK (if you subscribe to the invalid reference idea and the
>>>> validity of applying the 'address of' operator to it).
>>>
>>> Bullshit mate; dereferencing null pointers is UB.
>>>
>>> /Flibble
>>
>> Not always true.
>
> More bullshit. It is always true mate; dereferencing null pointers is UB.
>
> 8.3.2/5
>
> "A reference shall be initialized to refer to a valid object
> or function. [ Note: in particular, a null reference cannot exist in a
> well-defined program, because the only
> way to create such a reference would be to bind it to the "object"
> obtained by dereferencing a null pointer,
> which causes undefined behavior. As described in 9.6, a reference cannot
> be bound directly to a bit-field.
> --end note ]"
>
> [snipped unrelated Standard quotes]
>
> /Flibble
& is an unary operator & not a reference type. I think your quote is
irrelevant in this case.
blaz
== 6 of 6 ==
Date: Sun, Feb 2 2014 9:45 am
From: bblaz
On 02/02/14 19:43, bblaz wrote:
> On 02/02/14 17:47, Mr Flibble wrote:
>> On 02/02/2014 12:39, bblaz wrote:
>>> On 02/02/14 00:33, Mr Flibble wrote:
>>>> On 01/02/2014 22:36, Victor Bazarov wrote:
>>>>> On 2/1/2014 12:23 PM, Peter wrote:
>>>>>> Assume we have an array:
>>>>>>
>>>>>> int arr[5];
>>>>>>
>>>>>> It's legal to refer to address arr + 5, but, of course, illegal to
>>>>>> refer to element arr[5] as it's not part of the array. However, arr +
>>>>>> n is equivalent to &arr[n]. My question is: does this equivalence
>>>>>> also hold for an edge case of n = 5 (or, generally, n equal to number
>>>>>> of elements of array)?
>>>>>>
>>>>>> While there's nothing wrong with arr + 5, &arr[5] looks highly
>>>>>> suspicious: it looks like in the first step arr[5] is evaluated
>>>>>> (which introduces an undefined behaviour) which would mean the
>>>>>> expression as a whole is undefined. Does the equivalence still hold
>>>>>> in this special case?
>>>>>
>>>>> I would not be surprised at the validity of this after I've learned
>>>>> that
>>>>> initializing a reference by dereferencing a null pointer is now legal.
>>>>> *nullptr creates a special kind of reference, and the only useful
>>>>> operation you can do with it is to take its address, which in turn
>>>>> should give you null, as I understand it. So, using the same logic,
>>>>> the
>>>>> expression a[n] is the same as *(a+n), which is to give you a
>>>>> reference
>>>>> to a non-existing element (one beyond the last in the array) and with
>>>>> that reference the only valid operation is to take its address.
>>>>> According to the precedence rules, &arr[5] is evaluated as
>>>>> &(*(arr+5)),
>>>>> which is OK (if you subscribe to the invalid reference idea and the
>>>>> validity of applying the 'address of' operator to it).
>>>>
>>>> Bullshit mate; dereferencing null pointers is UB.
>>>>
>>>> /Flibble
>>>
>>> Not always true.
>>
>> More bullshit. It is always true mate; dereferencing null pointers is UB.
>>
>> 8.3.2/5
>>
>> "A reference shall be initialized to refer to a valid object
>> or function. [ Note: in particular, a null reference cannot exist in a
>> well-defined program, because the only
>> way to create such a reference would be to bind it to the "object"
>> obtained by dereferencing a null pointer,
>> which causes undefined behavior. As described in 9.6, a reference cannot
>> be bound directly to a bit-field.
>> --end note ]"
>>
>> [snipped unrelated Standard quotes]
>>
>> /Flibble
>
> & is an unary operator & not a reference type. I think your quote is
> irrelevant in this case.
>
> blaz
To be clear, i was refering to the op.
==============================================================================
TOPIC: Meaning of ~0
http://groups.google.com/group/comp.lang.c++/t/49b86d4e311b7a5f?hl=en
==============================================================================
== 1 of 3 ==
Date: Sat, Feb 1 2014 4:06 pm
From: Old Wolf
I'm sure this would have been asked before, but Google can't
cope with searching for tilde, so...
What does ~0 evaluate to?
N2521 just says "The operand of ~ shall have integral or
enumeration type; the result is the one's complement of
its operand." without any further explanation.
Does it mean the value whose representation is all-bits-1 ?
What if this is a trap representation?
== 2 of 3 ==
Date: Sat, Feb 1 2014 5:19 pm
From: Richard Damon
On 2/1/14, 7:06 PM, Old Wolf wrote:
> I'm sure this would have been asked before, but Google can't
> cope with searching for tilde, so...
>
> What does ~0 evaluate to?
>
> N2521 just says "The operand of ~ shall have integral or
> enumeration type; the result is the one's complement of
> its operand." without any further explanation.
>
> Does it mean the value whose representation is all-bits-1 ?
> What if this is a trap representation?
>
The operation ~ is only defined for integral or unscoped enums (which
will also ultimately reduce to a integral type). For unsigned types, the
concept of a one's complement is well defined, being identical to the
value of MAX_INT - x (or what ever the max value of the type is), the C
standard actually gives this definition. For signed types, the bit by
bit definition still applies, but the "value" of the result will be
implementation defined (based mostly on the type of negative numbers the
machine uses) and may produce "trap" values.
In the case of all-bits-1 this is well defined for all 3 standard systems.
For two's complement it is -1
For one's complement it is -0
For Sign / Magnitude it is the most negative number of that type.
== 3 of 3 ==
Date: Sun, Feb 2 2014 12:02 pm
From: Paavo Helde
Old Wolf <oldwolf@inspire.net.nz> wrote in news:1022b30a-f150-48bf-99b8-
19319709d023@googlegroups.com:
> I'm sure this would have been asked before, but Google can't
> cope with searching for tilde, so...
>
> What does ~0 evaluate to?
>
> N2521 just says "The operand of ~ shall have integral or
> enumeration type; the result is the one's complement of
> its operand." without any further explanation.
>
> Does it mean the value whose representation is all-bits-1 ?
> What if this is a trap representation?
0 is a signed int value. Bitwise operations depend on the representation
of signed types, which are implementation-specific, so not very reliable.
Also, if you assign the result to a value of potentially larger type
(e.g. unsigned long), it may fail to initialize higher bits. Using ~0U, ~
0UL, ~0ULL would be better.
Actually there is a standard idiom to obtain an unsigned value of any
type with all bits set, namely by converting -1 to this type, e.g.
unsigned long x = -1;
This is guaranteed to work as the C++ standard specifies such conversions
as modulo 2^n, meaning you get an unsigned value of 2^n-1, which means
all bits set. However, this it not very intuitive so may confuse novices.
hth
==============================================================================
TOPIC: Overloaded function template with different return types
http://groups.google.com/group/comp.lang.c++/t/a4fb484d72da3e8b?hl=en
==============================================================================
== 1 of 2 ==
Date: Sat, Feb 1 2014 5:57 pm
From: hbdevelop1@gmail.com
Hello all,
In functional\hash\hash.hpp in Boost ver. 1.54.0, there are many overloads of the template function hash_value where only the return type changes (see a snapshot of code at the end of this post).
1-
How does the compiler determine which version of the hash_value it should use in a call?
For example, for struct hash<unsigned int>::operator() it uses the version that returns boost::hash_detail::basic_numbers<T>::type.
Why ? What is the rule it applies ?
2-
How can I force the compiler to use a certain version of hash_value ?
Thank you very much in advance
----- code from boost\functional\hash\hash.hpp ------
namespace boost
{
namespace hash_detail
{
struct enable_hash_value { typedef std::size_t type; };
template <typename T> struct basic_numbers {};
template <typename T> struct long_numbers;
template <typename T> struct ulong_numbers;
...
template <> struct basic_numbers<unsigned int> :
boost::hash_detail::enable_hash_value {};
...
template <typename T> struct long_numbers2 {};
template <typename T> struct ulong_numbers2 {};
template <typename T> struct long_numbers : long_numbers2<T> {};
template <typename T> struct ulong_numbers : ulong_numbers2<T> {};
...
}
//version 1 of hash_value
template <typename T>
typename boost::hash_detail::basic_numbers<T>::type hash_value(T v)
{
return static_cast<std::size_t>(v);
}
//version 2 of hash_value
template <typename T>
typename boost::hash_detail::long_numbers<T>::type hash_value(T v)
{
return hash_detail::hash_value_signed(v);
}
//version 3 of hash_value
template <typename T>
typename boost::hash_detail::ulong_numbers<T>::type hash_value(T v)
{
return hash_detail::hash_value_unsigned(v);
}
...
template <> struct hash<unsigned int> :
public std::unary_function<unsigned int, std::size_t>
{
std::size_t operator()(unsigned int v) const
{
return boost::hash_value(v); //uses version 1 of hash_value
}
};
== 2 of 2 ==
Date: Sun, Feb 2 2014 5:22 am
From: Ken-Yi Lee
On Sunday, February 2, 2014 9:57:50 AM UTC+8, hbdev...@gmail.com wrote:
> Hello all,
> In functional\hash\hash.hpp in Boost ver. 1.54.0, there are many overloads of the template function hash_value where only the return type changes (see a snapshot of code at the end of this post).
> 1-
> How does the compiler determine which version of the hash_value it should use in a call?
>
> For example, for struct hash<unsigned int>::operator() it uses the version that returns boost::hash_detail::basic_numbers<T>::type.
>
> Why ? What is the rule it applies ?
You can take a look at the namespace: boost::hash_detail. A struct, enable_hash_value, is used to determine the bindings. For example, bool, char and unsigned char types are listed in basic_numbers.
> 2-
> How can I force the compiler to use a certain version of hash_value ?
You can use casting.
Feis
==============================================================================
TOPIC: Choosing the right epsilon for comparing doubles
http://groups.google.com/group/comp.lang.c++/t/5f5b1d64b66b5096?hl=en
==============================================================================
== 1 of 5 ==
Date: Sun, Feb 2 2014 8:35 am
From: walkietalkie74
Hi all,
Sorry if this question has been already asked in the past (I bet so). I would appreciate if you could point me in the right direction.
I do not generally compare doubles because I am well aware of the round-off errors that make such a comparison meaningless.
However, I am trying to write my program in a test-driven way, so I'd like to write a tester that checks that the result of a specific calculation is actually zero.
My code is the one below. It's calculating a straight line equation based on a point and a vector (in space, a straight line is the intersection of two planes, hence the getPlane1() and getPlane2()), and is checking whether the obtained equation is correct by calculating arbitrary points that are supposed to be on the same straight line, and checking whether their coordinates solve the plane equations:
bool GeometryTester::runTests() {
Point p(2, -2, 1);
Vector v(2, 4, 2);
StraightLine straightLine = Geometry::getStraightLine(p, v);
bool result = true;
for (double scalar = -10.0; scalar <= 10.0; scalar += 0.11131719) {
Point calcPoint = Geometry::getPoint(p, v, scalar);
double s1 = straightLine.getPlane1().solve(calcPoint.getX(),
calcPoint.getY(),
calcPoint.getZ());
double s2 = straightLine.getPlane2().solve(calcPoint.getX(),
calcPoint.getY(),
calcPoint.getZ());
result = result &&
MathComparer::equalsZero(s1);
result = result &&
MathComparer::equalsZero(s2);
}
return result;
}
For now, in MathComparer::equalsZero(), I am using a (wrong - I know) direct == comparison between the argument passed in and 0.0, but I'd like to replace it with the appropriate comparison using an epsilon.
Am I correct in thinking that the epsilon should actually be chosen depending on the current calculation and the accuracy I am expecting from it?
I can see, for example, that the solve() method most of the times returns 0.0 but at times something like 6e-12 (which is absolutely sensible, given the imprecise nature of floating-pint types).
Would it be sensible to pass in an arbitrary epsilon to the equalsZero() function?
I have seen examples of usage of std::numerics<double>::epsilon but I am not sure how it should be used in my case...
Can you help me understand this stuff better?
Thanks!
== 2 of 5 ==
Date: Sun, Feb 2 2014 1:15 pm
From: Richard Damon
On 2/2/14, 11:35 AM, walkietalkie74 wrote:
> Hi all,
>
> Sorry if this question has been already asked in the past (I bet so).
> I would appreciate if you could point me in the right direction.
>
> I do not generally compare doubles because I am well aware of the
> round-off errors that make such a comparison meaningless.
>
> However, I am trying to write my program in a test-driven way, so I'd
> like to write a tester that checks that the result of a specific
> calculation is actually zero.
...
>
> Am I correct in thinking that the epsilon should actually be chosen
> depending on the current calculation and the accuracy I am expecting
> from it?
>
> I can see, for example, that the solve() method most of the times
> returns 0.0 but at times something like 6e-12 (which is absolutely
> sensible, given the imprecise nature of floating-pint types).
>
> Would it be sensible to pass in an arbitrary epsilon to the
> equalsZero() function?
>
> I have seen examples of usage of std::numerics<double>::epsilon but I
> am not sure how it should be used in my case...
>
> Can you help me understand this stuff better?
>
> Thanks!
>
Yes, you are correct that "How close to zero is ok" is a question that
is VERY much dependent on the problem at hand. There are ways to analyze
the computation to see how much error would be "expected", to help you
set the bounds.
The other alternative would be to replace the floating point either with
an "exact math" number class (assuming the answers are expressible with
that or a number type that keeps track of possible error (either as an
interval of possible values, or as a estimated value and error bound).
== 3 of 5 ==
Date: Sun, Feb 2 2014 1:42 pm
From: Jax
walkietalkie74 <a.laforgia@gmail.com> wrote in
news:60d97607-ea5c-4001-96fc-6e48f0211d65@googlegroups.com:
> Hi all,
>
> Sorry if this question has been already asked in the past (I bet so). I
> would appreciate if you could point me in the right direction.
>
> I do not generally compare doubles because I am well aware of the
> round-off errors that make such a comparison meaningless.
>
> However, I am trying to write my program in a test-driven way, so I'd
> like to write a tester that checks that the result of a specific
> calculation is actually zero.
>
> My code is the one below. It's calculating a straight line equation
> based on a point and a vector (in space, a straight line is the
> intersection of two planes, hence the getPlane1() and getPlane2()), and
> is checking whether the obtained equation is correct by calculating
> arbitrary points that are supposed to be on the same straight line, and
> checking whether their coordinates solve the plane equations:
>
> bool GeometryTester::runTests() {
>
> Point p(2, -2, 1);
> Vector v(2, 4, 2);
> StraightLine straightLine = Geometry::getStraightLine(p, v);
>
> bool result = true;
>
> for (double scalar = -10.0; scalar <= 10.0; scalar += 0.11131719) {
> Point calcPoint = Geometry::getPoint(p, v, scalar);
>
> double s1 = straightLine.getPlane1().solve(calcPoint.getX(),
> calcPoint.getY(),
> calcPoint.getZ());
>
> double s2 = straightLine.getPlane2().solve(calcPoint.getX(),
> calcPoint.getY(),
> calcPoint.getZ());
>
> result = result &&
> MathComparer::equalsZero(s1);
>
> result = result &&
> MathComparer::equalsZero(s2);
> }
>
> return result;
> }
>
> For now, in MathComparer::equalsZero(), I am using a (wrong - I know)
> direct == comparison between the argument passed in and 0.0, but I'd
> like to replace it with the appropriate comparison using an epsilon.
>
> Am I correct in thinking that the epsilon should actually be chosen
> depending on the current calculation and the accuracy I am expecting
> from it?
>
> I can see, for example, that the solve() method most of the times
> returns 0.0 but at times something like 6e-12 (which is absolutely
> sensible, given the imprecise nature of floating-pint types).
>
> Would it be sensible to pass in an arbitrary epsilon to the equalsZero()
> function?
>
> I have seen examples of usage of std::numerics<double>::epsilon but I am
> not sure how it should be used in my case...
>
> Can you help me understand this stuff better?
>
> Thanks!
Walkietalkie as I'm sure you know there's more than one pair of planes
which can describe a given line..... so are there some special constraints
on the 2 planes you obtain which define the straight line? Just wondering.
Anyways you may want to consider always choosing the error (epsilon) to be
a few orders of magnitude greater than the specified inaccuracy of your
floating-point hardware. Alternatively, and I prefer this, epsilon could
be based on the magnitude of the numbers you are comparing rather than an
absolute constant.
--
Jax :)
== 4 of 5 ==
Date: Sun, Feb 2 2014 1:42 pm
From: Paavo Helde
walkietalkie74 <a.laforgia@gmail.com> wrote in
news:60d97607-ea5c-4001-96fc-6e48f0211d65@googlegroups.com:
> Hi all,
>
> Sorry if this question has been already asked in the past (I bet so).
> I would appreciate if you could point me in the right direction.
>
> I do not generally compare doubles because I am well aware of the
> round-off errors that make such a comparison meaningless.
>
> However, I am trying to write my program in a test-driven way, so I'd
> like to write a tester that checks that the result of a specific
> calculation is actually zero.
[...]
> For now, in MathComparer::equalsZero(), I am using a (wrong - I know)
> direct == comparison between the argument passed in and 0.0, but I'd
> like to replace it with the appropriate comparison using an epsilon.
>
> Am I correct in thinking that the epsilon should actually be chosen
> depending on the current calculation and the accuracy I am expecting
> from it?
Yes. As a trivial example, adding-subtracting an unbounded amount of
floating-point numbers can result in arbitrily large shifts from the
correct value.
However, most probably your algorithm has a limited number of floating-
point operations, so it ought to be possible to calculate the maximum
possible error. Alas, finding this can be well more complicated than the
original algorithm so it seems an overkill for a test function (you might
need to write a test for the test, etc). Probably the best approach is to
use some kind of epsilon estimated by gut feeling, but not totally
arbitrary.
>
> I can see, for example, that the solve() method most of the times
> returns 0.0 but at times something like 6e-12 (which is absolutely
> sensible, given the imprecise nature of floating-pint types).
6e-12 seems actually pretty big error unless the numbers in your tests
themselves are pretty large. The zero which is output from your test
function is most probably the result of subtracting two large numbers.
You should actually compare the relative difference of those numbers,
e.g. divide them by each other and if the result differs from 1.0 more
than a few epsilons (std::numeric_limits<double>::epsilon()) then your
algorithm might be either wrong or numerically unstable (the latter is
worse). The exact value of "few" above would be based on gut feeling ;-)
hth
Paavo
== 5 of 5 ==
Date: Sun, Feb 2 2014 2:40 pm
From: walkietalkie74
On Sunday, 2 February 2014 21:42:39 UTC, Jax wrote:
> Walkietalkie as I'm sure you know there's more than one pair of planes
> which can describe a given line..... so are there some special constraints
> on the 2 planes you obtain which define the straight line? Just wondering.
Hi Jax, thanks for your answer.
Yes, I know that there can be infinite pairs of planes which can describe a given line. This is the actual algorithm used in the method that builds the equations of the planes, given a point and a vector:
StraightLine Geometry::getStraightLine(const Point& p, const Vector& v) {
StraightLine straightLine;
double vx = v.getvx();
double vy = v.getvy();
double vz = v.getvz();
double xp = p.getX();
double yp = p.getY();
double zp = p.getZ();
straightLine.setPlane1(Plane(vy, -vx, 0, vx*yp - vy*xp));
straightLine.setPlane2(Plane(0, vz, -vy, vy*zp - vz*yp));
return straightLine;
}
Do you see any errors?
I used the GeometryTester class in my previous post to test that the equations are correct. Almost all the points that I calculate are solutions for the equations, with the exceptions of a few for which the solve() functions returns something like 0.000000000006....(which should be an approximation of zero - though I agree that it's quite a big error).
> Anyways you may want to consider always choosing the error (epsilon) to be
> a few orders of magnitude greater than the specified inaccuracy of your
> floating-point hardware. Alternatively, and I prefer this, epsilon could
> be based on the magnitude of the numbers you are comparing rather than an
> absolute constant.
Thanks. I have already discarded the idea of an absolute constant. I am aware of the existence of std::numerics<double>::epsilon and I've found a few examples around showing how to relate it to the magnitude of the numbers involved in the calculations.
Someone suggested to use it the following way:
a and b are "equal" if:
std::abs(a - b) <= std::abs(a) * std::numeric_limits<double>::epsilon
It seems using the same algorithm shown in section 4.2.2 of The Art of Computer Programming (D. Knuth), but it doesn't seem to work.
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.lang.c++"
group.
To post to this group, visit http://groups.google.com/group/comp.lang.c++?hl=en
To unsubscribe from this group, send email to comp.lang.c+++unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c++/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment