Tuesday, March 15, 2016

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

ram@zedat.fu-berlin.de (Stefan Ram): Mar 15 11:14PM

> bArray = { false };
>}
>What does the last line of code do?
 
It is ending the compound statement (6.3) that begun with »{«.
 
A compound statement is a statement defined by this production:
 
compound-statement ::= "{" {statement} "}".
 
, it is executed by executing the enclosed statements in the
given order.
Bob Langelaan <bobl0456@gmail.com>: Mar 15 02:05PM -0700

This code compiles on MS VS 2015:
 
#include <array>
int main()
{
std::array<bool, 100> bArray;
bArray = { false };
}
 
What does the last line of code do?
 
Thanks,
Bob
Vir Campestris <vir.campestris@invalid.invalid>: Mar 15 09:15PM

On 15/03/2016 21:05, Bob Langelaan wrote:
> bArray = { false };
> }
 
> What does the last line of code do?
 
Initialises the first element of the array with false.
 
http://en.cppreference.com/w/cpp/container/array
 
and follow the links to
 
http://en.cppreference.com/w/cpp/language/aggregate_initialization
 
HTH
Andy
Marcel Mueller <news.5.maazl@spamgourmet.org>: Mar 15 10:17PM +0100

On 15.03.16 22.05, Bob Langelaan wrote:
> bArray = { false };
> }
 
> What does the last line of code do?
 
Assign a list of one boolean to the array. Due to the fixed nature of
std::array this will in fact clear all elements.
 
 
Marcel
Bob Langelaan <bobl0456@gmail.com>: Mar 15 02:22PM -0700

On Tuesday, March 15, 2016 at 2:17:14 PM UTC-7, Marcel Mueller wrote:
 
> Assign a list of one boolean to the array. Due to the fixed nature of
> std::array this will in fact clear all elements.
 
> Marcel
 
Marcel,
 
Are you saying that the last statement assigns all 100 bool values in bArray to false? I would have thought a loop of some type would have been necessary to accomplish this? Can you expand on the last statement you made? Thanks,
Bob
Bob Langelaan <bobl0456@gmail.com>: Mar 15 02:36PM -0700

On Tuesday, March 15, 2016 at 2:06:11 PM UTC-7, Bob Langelaan wrote:
 
> What does the last line of code do?
 
> Thanks,
> Bob
 
Ok, I modified code to:
 
#include <array>
#include <iostream>
 
int main()
{
std::array<bool, 100> bArray;
bArray = { true };
for (auto x : bArray)
{
std::cout << x << " ";
}
}
 
And I have figured out what is happening by varying whether true or false is assigned or statement is commented out.
 
If assigned false, all 100 bools become false; if assigned true, only the first element becomes true, the remainder become false; if commented out the 100 bools have seemingly random values (memory in bArray is not initialized in other words).
Marcel Mueller <news.5.maazl@spamgourmet.org>: Mar 15 10:49PM +0100

On 15.03.16 22.22, Bob Langelaan wrote:
>> Assign a list of one boolean to the array. Due to the fixed nature of
>> std::array this will in fact clear all elements.
 
> Are you saying that the last statement assigns all 100 bool values in bArray to false?
 
Exactly.
 
> I would have thought a loop of some type would have been necessary to accomplish this? Can you expand on the last statement you made? Thanks,
 
It is a ->"list initializer".
 
And similar to C array assignments trailing elements are initialized to
zero i.e. false.
 
 
Marcel
Gareth Owen <gwowen@googlemail.com>: Mar 15 08:44AM -0600


> std::string object is created for the exception message which can
> cause std::bad_alloc (a std::runtime_error exception) to be thrown
> replacing the originally intended exception.
 
std::bad_alloc is not a runtime_error (needing a string constructor
would be particularly idiotic for bad_alloc), but the point still holds.
 
 
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Gareth Owen <gwowen@googlemail.com>: Mar 15 08:45AM -0600


> Oh, so you mean that the programmer may do something in handling the
> exception to convert logic_error to runtime_error. Sure.
 
No, the problem is
 
throw std::logic_error("I've made a terrible mistake");
 
calls the constructor
 
std::logic_error(const std::string&);
 
which has to construct a string, which might throw std::bad_alloc
 
 
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Bo Persson <bop@gmb.dk>: Mar 15 12:22PM -0600

On 2016-03-15 15:45, Gareth Owen wrote:
 
> calls the constructor
 
> std::logic_error(const std::string&);
 
> which has to construct a string, which might throw std::bad_alloc
 
There is also a constructor
 
explicit logic_error(const char*);
 
which doesn't have to call a string constructor.
 
 
 
Bo Persson
 
 
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
woodbrian77@gmail.com: Mar 15 11:28AM -0700

On Tuesday, March 15, 2016 at 12:30:17 PM UTC-5, Bo Persson wrote:
 
> which doesn't have to call a string constructor.
 
> Bo Persson
 
What's the point of std::logic_error? Asserting has
already been defended and I agree with those who say to
use asserts. Recent threads, including this one, have
pointed out dangers and snares associated with
std::logic_error. IMO C++ would be better off without it.
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
Juha Nieminen <nospam@thanks.invalid>: Mar 15 09:03AM

> I think the using approach is clearer than the typedef
> approach. And from a code generator perspective the
> using approach is easier to support.
 
It's still good to understand how typedef works.
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 15 01:25AM

> On Monday, March 14, 2016 at 3:39:41 AM UTC-5, Alf P. Steinbach wrote:
 
> Alf, please don't swear here.
 
'This video may contain sexual swearwords, I'm afraid. There are 28
'fucks'. Including that one 29. Ah, fuck it, make it 30.' -- Paul Calf
 
https://www.youtube.com/watch?v=42UCpOzTbNU
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Mar 15 12:37AM

On Mon, 14 Mar 2016 15:46:11 -0700 (PDT)
 
> I'm sorry, but I don't think the other libraries mentioned
> for C++ serialization options will endure like the the C++
> Middleware Writer.
 
I think this is verging on blasphemy.
 
You would do much better if you refrained from further posting to this
newsgroup until you sort out your personal issues.
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.

No comments: