Thursday, January 30, 2014

comp.lang.c++ - 26 new messages in 6 topics - digest

comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en

comp.lang.c++@googlegroups.com

Today's topics:

* C++ is hard (Google game) - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/dac6864900693dc7?hl=en
* Boost - 5 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/81738d66827a11c8?hl=en
* goto label inside of if statement - 8 messages, 5 authors
http://groups.google.com/group/comp.lang.c++/t/7c222b0d5330287c?hl=en
* Moving from C++03 to C++11 - 6 messages, 6 authors
http://groups.google.com/group/comp.lang.c++/t/4bf001f37864dec0?hl=en
* iterator_traits and SFINAE - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/54b1537c08997e10?hl=en
* What is the disadvantage with C++ in Embedded systems? - 2 messages, 2
authors
http://groups.google.com/group/comp.lang.c++/t/d2c6dd66860beb15?hl=en

==============================================================================
TOPIC: C++ is hard (Google game)
http://groups.google.com/group/comp.lang.c++/t/dac6864900693dc7?hl=en
==============================================================================

== 1 of 4 ==
Date: Sun, Jan 26 2014 2:18 pm
From: Richard Damon


On 1/26/14, 3:51 PM, Öö Tiib wrote:

> Not sure how google guesses what i want to ask.
>

If you haven't asked Google a question like this (at least that Google
can match to you now), Google will look at what other people have
entered as search strings. It may also weight them by how similar it
thinks those people are to you.




== 2 of 4 ==
Date: Sun, Jan 26 2014 2:52 pm
From: woodbrian77@gmail.com


On Sunday, January 26, 2014 4:18:46 PM UTC-6, Richard Damon wrote:
> On 1/26/14, 3:51 PM, Öö Tiib wrote:
>
>
> If you haven't asked Google a question like this (at least that Google
> can match to you now), Google will look at what other people have
> entered as search strings. It may also weight them by how similar it
> thinks those people are to you.

I prefer privacy --

http://donttrack.us/

Brian
Ebenezer Enterprises
http://webEbenezer.net





== 3 of 4 ==
Date: Sun, Jan 26 2014 3:04 pm
From: Mr Flibble


On 26/01/2014 22:52, woodbrian77@gmail.com wrote:
> On Sunday, January 26, 2014 4:18:46 PM UTC-6, Richard Damon wrote:
>> On 1/26/14, 3:51 PM, Öö Tiib wrote:
>>
>>
>> If you haven't asked Google a question like this (at least that Google
>> can match to you now), Google will look at what other people have
>> entered as search strings. It may also weight them by how similar it
>> thinks those people are to you.
>
> I prefer privacy --
>
> http://donttrack.us/
>
> Brian
> Ebenezer Enterprises
> http://webEbenezer.net

What dirty little secrets are you hiding?

/Flibble





== 4 of 4 ==
Date: Sun, Jan 26 2014 5:38 pm
From: woodbrian77@gmail.com


On Sunday, January 26, 2014 5:04:50 PM UTC-6, Mr Flibble wrote:
>
> What dirty little secrets are you hiding?
>

I don't have herpes. A lot of people are nosy and
don't mind their own business.





==============================================================================
TOPIC: Boost
http://groups.google.com/group/comp.lang.c++/t/81738d66827a11c8?hl=en
==============================================================================

== 1 of 5 ==
Date: Sun, Jan 26 2014 2:46 pm
From: woodbrian77@gmail.com


On Sunday, January 26, 2014 3:34:18 PM UTC-6, Ian Collins wrote:
> woodbrian77@gmail.com wrote:
> >
> > Do you disagree with my claim that C++ is most important
> > language for services?
>
> While C++ is an important language for services, it has to inter-operate
> with servers and clients written in other languages.

If you had said --

it sometimes has to inter-operate

I'd agree. I know of a few companies that write C++
programs that communicate with each other. That's
not exactly unheard of.

And as I said I'm open to working on adding support
for another language, but I don't think that language
will be Java. Python or C# is more likely.


> This is why most
> serialisation formats in common use today (SOAP, XML-RPC, JSON) are
> textual or binary extensions of them (BSON).
>

I think scientific apps and games often use binary serialization.

I believe the quality of my software is good and believe
that thinking about the software/service through another
project's eyes will help me to improve the software service.


Brian
Ebenezer Enterprises
http://webEbenezer.net




== 2 of 5 ==
Date: Sun, Jan 26 2014 2:56 pm
From: Ian Collins


woodbrian77@gmail.com wrote:
> On Sunday, January 26, 2014 3:34:18 PM UTC-6, Ian Collins wrote:
>> woodbrian77@gmail.com wrote:
>>>
>>> Do you disagree with my claim that C++ is most important
>>> language for services?
>>
>> While C++ is an important language for services, it has to inter-operate
>> with servers and clients written in other languages.
>
> If you had said --
>
> it sometimes has to inter-operate
>
> I'd agree. I know of a few companies that write C++
> programs that communicate with each other. That's
> not exactly unheard of.

Probably the most common type of "service" these days is the web
service. Web services almost exclusively use SOAP. If you are going to
write the back ends for web pages in C++, you will probably have to use
JSON to communicate with the client JavaScript.

> And as I said I'm open to working on adding support
> for another language, but I don't think that language
> will be Java. Python or C# is more likely.
>
>> This is why most
>> serialisation formats in common use today (SOAP, XML-RPC, JSON) are
>> textual or binary extensions of them (BSON).
>
> I think scientific apps and games often use binary serialization.
>
> I believe the quality of my software is good and believe
> that thinking about the software/service through another
> project's eyes will help me to improve the software service.

By using a proprietary binary format, you are restricting yourself to a
narrow range of applications. The easiest way to support other
languages is to use a well known on wire format.

--
Ian Collins




== 3 of 5 ==
Date: Sun, Jan 26 2014 6:20 pm
From: woodbrian77@gmail.com


On Sunday, January 26, 2014 4:56:28 PM UTC-6, Ian Collins wrote:
> woodbrian77@gmail.com wrote:
>
>
> Probably the most common type of "service" these days is the web
> service. Web services almost exclusively use SOAP. If you are going to
> write the back ends for web pages in C++, you will probably have to use
> JSON to communicate with the client JavaScript.
>

>
> >
> By using a proprietary binary format, you are restricting yourself to a
> narrow range of applications. The easiest way to support other
> languages is to use a well known on wire format.
>

Maybe. Currently I'm doing byte-level marshalling, but am
thinking about switching to bit-level marshalling. In that
case a boolean would be marshalled as one bit rather than
taking a whole byte.

I'm aware of HDF, netCDF and ASN 1. Do any of them
support bit-level marshalling? Do any of the standards
have support for polymorphism?

I marshall string lengths as variable length integers. Do
any of the standards require fixed length integers for string
lengths? I don't think I want that so am asking to find out
what standards to avoid.

Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net




== 4 of 5 ==
Date: Sun, Jan 26 2014 7:19 pm
From: Ian Collins


woodbrian77@gmail.com wrote:
> On Sunday, January 26, 2014 4:56:28 PM UTC-6, Ian Collins wrote:
>> woodbrian77@gmail.com wrote:
>>
>>
>> Probably the most common type of "service" these days is the web
>> service. Web services almost exclusively use SOAP. If you are going to
>> write the back ends for web pages in C++, you will probably have to use
>> JSON to communicate with the client JavaScript.
>>
>> By using a proprietary binary format, you are restricting yourself to a
>> narrow range of applications. The easiest way to support other
>> languages is to use a well known on wire format.
>>
>
> Maybe. Currently I'm doing byte-level marshalling, but am
> thinking about switching to bit-level marshalling. In that
> case a boolean would be marshalled as one bit rather than
> taking a whole byte.

Um, why? Surely the extra overhead would outweigh transmission time
savings?

> I'm aware of HDF, netCDF and ASN 1. Do any of them
> support bit-level marshalling? Do any of the standards
> have support for polymorphism?

ASN.1 is awfully complex and out of favour these says. I'm not familiar
with the others.

It looks like you set out to serialise the object model rather than
simply serialising data. Isn't that tying things too tightly to C++?

> I marshall string lengths as variable length integers. Do
> any of the standards require fixed length integers for string
> lengths? I don't think I want that so am asking to find out
> what standards to avoid.

Most interchange standards currently in vogue value simplicity over
minimising the payload size.

--
Ian Collins




== 5 of 5 ==
Date: Mon, Jan 27 2014 3:55 am
From: Jorgen Grahn


On Mon, 2014-01-27, woodbrian77@gmail.com wrote:
> On Sunday, January 26, 2014 4:56:28 PM UTC-6, Ian Collins wrote:
...
>> By using a proprietary binary format, you are restricting yourself to a
>> narrow range of applications. The easiest way to support other
>> languages is to use a well known on wire format.
>>
>
> Maybe. Currently I'm doing byte-level marshalling, but am
> thinking about switching to bit-level marshalling. In that
> case a boolean would be marshalled as one bit rather than
> taking a whole byte.
>
> I'm aware of HDF, netCDF and ASN 1. Do any of them
> support bit-level marshalling?

ASN.1 with the PER (packed encoding rules) does. But PER is also the
one you need expert help to generate a parser for ... I used it
2000--2001 with some telecom protocol (RANAP?) and it wasn't much fun
...

Personally I suspect a (possibly gzipped) text stream is good enough
almost all the time.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .





==============================================================================
TOPIC: goto label inside of if statement
http://groups.google.com/group/comp.lang.c++/t/7c222b0d5330287c?hl=en
==============================================================================

== 1 of 8 ==
Date: Sun, Jan 26 2014 3:10 pm
From: Jorgen Grahn


On Sun, 2014-01-26, Öö Tiib wrote:
> On Sunday, 26 January 2014 21:13:22 UTC+2, Jax wrote:
>> Do you mean that GOTO shouldn't ever be used or is it okay in certain
>> circumstances?
...
> So if you ever feel that you need to write tricky code to
> avoid goto then better use goto.

Agreed, but keeping in mind that:
- there are always (more or less) cleaner solutions, if you have
the time and guts to refactor the code a bit (and sometimes you
don't)
- goto is less useful in C++ than in C, since RAII can replace those
"goto cleanup1", "goto cleanup2" ... constructs.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .




== 2 of 8 ==
Date: Mon, Jan 27 2014 6:50 am
From: Jax


Paavo Helde <myfirstname@osa.pri.ee> wrote in
news:XnsA2C1EDBF771FBmyfirstnameosapriee@216.196.109.131:

> Jax <remove.bear.bottoms1@gmail.com> wrote in
> news:XnsA2C1C38BC1524JAX@127.0.0.1:
>
>
>> Flibble I am very new to C++ and would like to get your
>> recommendation. Do you mean that GOTO shouldn't ever be used or is it
>> okay in certain circumstances?
>
> As with all features, one uses goto if it is better than the
> alternatives. And "better" here means primarily more readable and
> maintainable code. Breaking out of deep nested loops with goto to near
> the beginning or the end of a function is IMO okay, as the relevant
> state of the program after the jump is pretty clear in such cases.
>
> The same functionality can be always achieved with reorganizing the
> code, possibly splitting it into multiple functions. Whether this makes
> the code more readable and maintainable than 'goto' depends on the
> circumstances and also on the taste (of the future readers and
> maintainers in particular). So there is no clear-cut answer. One thing
> is clear, the need for 'goto' is rare, if you find yourself writing a
> goto every week then something is probably wrong.
>
> HTH
> Paavo

Paavo.... Gareth tells me that your advice is reliable. I have made a note of
it. Thank you!

--
Jax :)




== 3 of 8 ==
Date: Mon, Jan 27 2014 11:21 am
From: W Karas


On Saturday, January 25, 2014 5:38:57 AM UTC-5, Alf P. Steinbach wrote:
> On 23.01.2014 20:32, W Karas wrote:
>
> > I was surprised to find that this code:
>
> >
>
> > struct A { A(); ~A(); };
>
> >
>
> > void bar();
>
> >
>
> > void foo(bool f)
>
> > {
>
> > if (0)
>
> > {
>
> > LAB: ;
>
> > }
>
> > else
>
> > {
>
> > A a;
>
> >
>
> > if (f) goto LAB;
>
> >
>
> > bar();
>
> > }
>
> > }
>
> >
>
> > will compile without warnings using GCC 4.7.3, even with -Wall and -Wextra.
>
>
>
> It's okay to jump across block boundaries with "goto", either into or
>
> out of a block, and it's also okay to jump into block boundaries with a
>
> `switch` (the old "duff's device" relied on that), but you can't
>
>
>
> * jump across function boundaries or
>
>
>
> * skip the initialization of a variable
>
>
>
>
>
> > The point, in case you were wondering, would be a macro-based "named block"
>
> > pseudo-construct, where the block could be exited from any depth of block
>
> > nesting, for example:
>
> >
>
> > #define BLOCK(NAME) if (0) { NAME: ; } else
>
> > #define EXITBLOCK(NAME) goto NAME;
>
> >
>
> > struct A { A(); ~A(); };
>
> >
>
> > void bar();
>
> >
>
> > void foo(bool f)
>
> > {
>
> > BLOCK(XYZ)
>
> > {
>
> > A a;
>
> >
>
> > if (f) EXITBLOCK(XYZ)
>
> >
>
> > bar();
>
> > }
>
> > }
>
>
>
> That's ingenious.

I'm honored, but you are too kind.

>
>
>
> But, heads-up: there once was a version of a Unix shell written in C
>
> with macros and support functions defined to make it look like Pascal.
>
> Heavy emphasis on **was**.
>
>
>
> And for example, when I once defined a WITH macro (corresponding to C#
>
> "using"), and even enlisted help from the community with the quality
>
> assurance of that, I thought this was the next best thing since pizza
>
> slices. It used a similar trick internally, using an `if` to introduce a
>
> variable for the `else` part. I have not used that macro since.
>
>
>
> * * *
>
>
>
> So, how to reasonably exit from a nested scope, without such shenanigans?
>
>
>
> Let's consider the common example, a nested loop, with some nested
>
> conditionals thrown in for good measure, plus an "at the end" action:
>
>
>
>
>
> [code]
>
> #include <iostream>
>
> #include <math.h> // sqrt
>
> using namespace std;
>
>
>
> auto main()
>
> -> int
>
> {
>
> int const max_a = 12345;
>
> int const max_numbers = 42;
>
> int n = 0;
>
> int prev_c = 0;
>
> for( int a = 1; a <= max_a; ++a )
>
> {
>
> for( int b = 1; b < a; ++b )
>
> {
>
> int const c_sq = a*a + b*b;
>
> int const c = int( sqrt( c_sq ) + 0.5 );
>
> if( c*c == c_sq )
>
> {
>
> if( c < prev_c )
>
> {
>
> cout << (n > 0? " " : "") << c;
>
> ++n;
>
> if( n == max_numbers )
>
> {
>
> goto finished;
>
> }
>
> }
>
> prev_c = c;
>
> }
>
> }
>
> }
>
> finished:
>
> cout << endl;
>
>
>
> cout << "Found " << n << " interesting numbers." << endl;
>
> }
>
> [/code]
>
>
>
>
>
> The C++ construct that is a scope that can be exited from some nested
>
> scope, is a function, and in most all cases introducing (refactoring as)
>
> a function is a good solution.
>
>
>
> In C++03 that function must be a named function or a function template
>
> instantiation. As a named function it can be at namespace scope or a
>
> member of a local class. In C++11 it can also be an anonymous function,
>
> as a lambda.
>
>
>
> The code below shows a C++03-style named function refactoring:
>
>
>
>
>
> [code]
>
> #include <iostream>
>
> #include <math.h> // sqrt
>
> using namespace std;
>
>
>
> auto list_interesting_numbers(
>
> int const max_numbers,
>
> int const max_a = 12345
>
> )
>
> -> int
>
> {
>
> int n = 0;
>
> int prev_c = 0;
>
> for( int a = 1; a <= max_a; ++a )
>
> {
>
> for( int b = 1; b < a; ++b )
>
> {
>
> int const c_sq = a*a + b*b;
>
> int const c = int( sqrt( c_sq ) + 0.5 );
>
> if( c*c == c_sq )
>
> {
>
> if( c < prev_c )
>
> {
>
> cout << (n > 0? " " : "") << c;
>
> ++n;
>
> if( n == max_numbers )
>
> {
>
> return n;
>
> }
>
> }
>
> prev_c = c;
>
> }
>
> }
>
> }
>
> return n;
>
> }
>
>
>
> auto main()
>
> -> int
>
> {
>
> int const n = list_interesting_numbers( 42 );
>
> cout << endl;
>
>
>
> cout << "Found " << n << " interesting numbers." << endl;
>
> }
>
> [/code]
>
>
>
>
>
> Since the `goto` has been eliminated, the effect of any statement here
>
> is clear just from inspecting the statement itself.
>
>
>
> Also, the function is more reusable.
>
>
>
> For some special cases of nested loops there are some other clean
>
> alternatives. For example, looping over a rectangular set of positions
>
> can be done with a single logical position variable. But I do not think
>
> that the Pascal solution, of introducing extra boolean "are we finished
>
> yet" variables, checked at every loop iteration, is clean for C++. That
>
> solution was nice for Pascal, and also for C, where a single exit point
>
> (SESE) is important. However, in C++ a single exit point can almost
>
> never be relied on (so that code that does, is misguided), and one has
>
> tools to deal with multiple exit points, namely destructors and `catch`.
>
>
>
>
>
> Cheers & hth.,
>
>
>
> - Alf

This is a situation where Pascal's nested functions where could be very advantageous. The nested function has access to the containing function's scope, so it is equivalent to a named block where "return" is a break from any level of nesting. Perhaps nested function support should be added to C++ (and C) since the hidden overhead (hidden pointer to containing function's scope) is straight-forward.

I believe the Standard already has one precedent for recommending a standard practice, namely, reserve symbols starting with underscore ( _ ) for standard library header files. Maybe this is a case where another such recommendation is needed. Perhaps that labels should begin with EXIT_BLOCK_ if and only if they are used exclusively to do a break from with a nested block. That has advantages over my tricky macros.




== 4 of 8 ==
Date: Mon, Jan 27 2014 12:30 pm
From: "Alf P. Steinbach"


* W Karas:
> This is a situation where Pascal's nested functions where could be very
> advantageous. The nested function has access to the containing function's
> scope, so it is equivalent to a named block where "return" is a break from
> any level of nesting. Perhaps nested function support should be added to
> C++ (and C) since the hidden overhead (hidden pointer to containing
> function's scope) is straight-forward.

The following is valid C++, as of C++11:


[code]
#include <iostream>
#include <math.h> // sqrt
using namespace std;

auto main()
-> int
{
int const max_a = 12345;
int const max_numbers = 42;

int n = 0;
[&]() -> void
{
int prev_c = 0;
for( int a = 1; a <= max_a; ++a )
{
for( int b = 1; b < a; ++b )
{
int const c_sq = a*a + b*b;
int const c = int( sqrt( c_sq ) + 0.5 );
if( c*c == c_sq )
{
if( c < prev_c )
{
cout << (n > 0? " " : "") << c;
++n;
if( n == max_numbers )
{
return;
}
}
prev_c = c;
}
}
}
}();
cout << endl;

cout << "Found " << n << " interesting numbers." << endl;
}
[/code]

Exactly how it implements references to local variables is up to the
compiler, but a smart compiler would use a pointer to the stack frame.
Unlike Pascal's nested function a C++ lambda can alternatively capture
by value.

I would however use a named function instead of an inline lambda.


Cheers & hth.,

- Alf





== 5 of 8 ==
Date: Mon, Jan 27 2014 1:03 pm
From: W Karas


On Monday, January 27, 2014 3:30:11 PM UTC-5, Alf P. Steinbach wrote:
> * W Karas:
>
> > This is a situation where Pascal's nested functions where could be very
>
> > advantageous. The nested function has access to the containing function's
>
> > scope, so it is equivalent to a named block where "return" is a break from
>
> > any level of nesting. Perhaps nested function support should be added to
>
> > C++ (and C) since the hidden overhead (hidden pointer to containing
>
> > function's scope) is straight-forward.
>
>
>
> The following is valid C++, as of C++11:
>
>
>
>
>
> [code]
>
> #include <iostream>
>
> #include <math.h> // sqrt
>
> using namespace std;
>
>
>
> auto main()
>
> -> int
>
> {
>
> int const max_a = 12345;
>
> int const max_numbers = 42;
>
>
>
> int n = 0;
>
> [&]() -> void
>
> {
>
> int prev_c = 0;
>
> for( int a = 1; a <= max_a; ++a )
>
> {
>
> for( int b = 1; b < a; ++b )
>
> {
>
> int const c_sq = a*a + b*b;
>
> int const c = int( sqrt( c_sq ) + 0.5 );
>
> if( c*c == c_sq )
>
> {
>
> if( c < prev_c )
>
> {
>
> cout << (n > 0? " " : "") << c;
>
> ++n;
>
> if( n == max_numbers )
>
> {
>
> return;
>
> }
>
> }
>
> prev_c = c;
>
> }
>
> }
>
> }
>
> }();
>
> cout << endl;
>
>
>
> cout << "Found " << n << " interesting numbers." << endl;
>
> }
>
> [/code]
>
>
>
> Exactly how it implements references to local variables is up to the
>
> compiler, but a smart compiler would use a pointer to the stack frame.
>
> Unlike Pascal's nested function a C++ lambda can alternatively capture
>
> by value.

If a hypothetical nested function in C++ were (implicitly or explicitly) inline, then assuming good optimization, any overhead issues would be moot.

>
>
>
> I would however use a named function instead of an inline lambda.

If the (named) function substituted for the block were declared inline, then the "problem" would be the need to make explicit the block's dependence on local variables in the parameter list. Good optimization would hopefully make object level overhead issues moot in this case too.

>
>
>
>
>
> Cheers & hth.,
>
>
>
> - Alf





== 6 of 8 ==
Date: Mon, Jan 27 2014 1:32 pm
From: "Alf P. Steinbach"


On 27.01.2014 22:03, W Karas wrote:
> On Monday, January 27, 2014 3:30:11 PM UTC-5, Alf P. Steinbach wrote:
>> * W Karas:
>>
>>> This is a situation where Pascal's nested functions where could be very
>>
>>> advantageous. The nested function has access to the containing function's
>>

Please fix the quoting before posting.

- Alf






== 7 of 8 ==
Date: Mon, Jan 27 2014 3:50 pm
From: W Karas


> Please fix the quoting before posting.
>
>
>
> - Alf

I have not found an alternative to using the groups.google.com web portal for usenet. I don't have enough time to properly follow this group, much less correct the mess that Google makes when quoting the original post. Is it best to simply delete all or most of the original post one is responding to when using the Google portal?




== 8 of 8 ==
Date: Mon, Jan 27 2014 4:48 pm
From: red floyd


On 1/27/2014 3:50 PM, W Karas wrote:
>> Please fix the quoting before posting.
>>
>>
>>
>> - Alf
>
> I have not found an alternative to using the groups.google.com web portal for usenet. I don't have enough time to properly follow this group, much less correct the mess that Google makes when quoting the original post. Is it best to simply delete all or most of the original post one is responding to when using the Google portal?
>

Use eternal-september.org






==============================================================================
TOPIC: Moving from C++03 to C++11
http://groups.google.com/group/comp.lang.c++/t/4bf001f37864dec0?hl=en
==============================================================================

== 1 of 6 ==
Date: Sun, Jan 26 2014 4:06 pm
From: retro54321@gmail.com



Could someone please suggest a good book (or any kind of resource) for someone who's very familiar with C++03 and who wants to get up to speed with C++11.

(I was considering getting the 4th addition of Bjarne's book, but rather than read about the entire language from start to finish, I just want to focus on the new stuff brought in with C++11).

Rhino




== 2 of 6 ==
Date: Sun, Jan 26 2014 5:51 pm
From: Öö Tiib


On Monday, 27 January 2014 02:06:20 UTC+2, retro...@gmail.com wrote:
> Could someone please suggest a good book (or any kind of resource) for someone who's very familiar with C++03 and who wants to get up to speed with C++11.

That PDF for 30$ fits perhaps best with what you ask:
http://www.artima.com/shop/overview_of_the_new_cpp

> (I was considering getting the 4th addition of Bjarne's book, but rather than read about the entire language from start to finish, I just want to focus on the new stuff brought in with C++11).

The updated revisions of good old books are worth getting anyway "C++ Primer",
"The C++ Programming Language" and "The C++ Standard Library: A Tutorial and Reference".




== 3 of 6 ==
Date: Mon, Jan 27 2014 12:56 am
From: Juha Nieminen


retro54321@gmail.com wrote:
> Could someone please suggest a good book (or any kind of resource) for someone who's very familiar with C++03 and who wants to get up to speed with C++11.

If you are already very familiar with C++03, then I think this is quite
a decent place to start:

http://en.wikipedia.org/wiki/C%2B%2B11

And when you want more info on a particular feature, just google it.

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---




== 4 of 6 ==
Date: Mon, Jan 27 2014 12:48 pm
From: woodbrian77@gmail.com


On Monday, January 27, 2014 2:56:48 AM UTC-6, Juha Nieminen wrote:
> retro54321@gmail.com wrote:
>
> > Could someone please suggest a good book (or any kind of resource) for someone who's very familiar with C++03 and who wants to get up to speed with C++11.
>

There's an archive you can download here:

http://webEbenezer.net/build_integration.html

that uses a number of C++ 2011 features.

>
> If you are already very familiar with C++03, then I think this is quite
> a decent place to start:
>
> http://en.wikipedia.org/wiki/C%2B%2B11
>

I use that also.


>
> And when you want more info on a particular feature, just google it.
>

Duckduckgo doesn't track people's searches like some
of the other search engines.

https://duckduckgo.com


Brian
Ebenezer Enterprises
http://webEbenezer.net




== 5 of 6 ==
Date: Mon, Jan 27 2014 3:31 pm
From: Ike Naar


On 2014-01-27, woodbrian77@gmail.com <woodbrian77@gmail.com> wrote:
> Duckduckgo doesn't track people's searches like some
> of the other search engines.

That's what they say, but how can you be sure they don't?




== 6 of 6 ==
Date: Mon, Jan 27 2014 6:04 pm
From: "K. Frank"


Hello Rhino!

On Sunday, January 26, 2014 7:06:20 PM UTC-5, retro...@.com wrote:
> Could someone please suggest a good book (or any kind of resource) for someone who's very familiar with C++03 and who wants to get up to speed with C++11.

I have found Bjarne Stroustrup's C++11 FAQ:

http://www.stroustrup.com/C++11FAQ.html

to be a good starting point. It's not complete (yet?),
and it's not highly detailed, but I have found it to be
very useful.

> ...
>
> Rhino


Good luck.


K. Frank





==============================================================================
TOPIC: iterator_traits and SFINAE
http://groups.google.com/group/comp.lang.c++/t/54b1537c08997e10?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Jan 26 2014 6:32 pm
From: kaballo@gmail.com


On Sunday, September 5, 2010 11:43:36 AM UTC-5, Howard Hinnant wrote:
> On Sep 5, 9:28 am, Marc <marc.gli...@gmail.com> wrote:
> > Hello,
> >
> > the standard defines iterator_traits with:
> > namespace std {
> >   template<class Iterator> struct iterator_traits {
> >      typedef typename Iterator::difference_type difference_type;
> >      typedef typename Iterator::value_type value_type;
> >      typedef typename Iterator::pointer pointer;
> >      typedef typename Iterator::reference reference;
> >      typedef typename Iterator::iterator_category iterator_category;
> >   };}
> >
> > plus two partial specializations for pointers.
> >
> > Since the typedefs are always present, iterator_traits can't be
> > instantiated with a non-iterator template argument, and thus
> > iterator_traits can't reliably be used in the signature of a function
> > (it won't fall in the SFINAE category).
> >
> > On the other hand, if iterator_traits was specified as an empty class
> > (no typedef) when Iterator::* don't exist (and Iterator is not a
> > pointer), it seems to me that iterator_traits would become usable for
> > sfinae purposes (std::distance wouldn't break user-defined distance
> > functions any more) and no currently valid code would break.
> >
> > Several libraries already contain some kind of is_iterator helper; the
> > implementation would be almost the same and the helper would become
> > redundant.
> >
> > Any opinion?
>
> I've long thought that this is the quality way to implement
> iterator_traits. I did so for the Metrowerks/Motorola/Freescale
> CodeWarrior std::lib, and I've done so again here:
>
> http://libcxx.llvm.org/
> http://llvm.org/svn/llvm-project/libcxx/trunk/include/iterator
>
> I also failed to try to standardize this technique. It never got high
> enough on my priority queue, and my impression of the chances of
> successful standardization consistently remained low. But I like it
> exactly for all of the reasons you state.
>
> This implementation of your idea keys only on the nested
> iterator_category type. For X to qualify as an iterator (and thus for
> iterator_traits<X> to be a non-empty class):
>
> 1. X::iterator_category must exist, and
> 2. X::iterator_category must be implicitly convertible to either
> std::input_iterator_tag or std::output_iterator_tag.
>
> Using these rules, I've never come across a case in the wild where
> this design breaks code. Though breakage is certainly theoretically
> possible (just vanishingly rare in my experience).
>
> -Howard

The addition of `next`/`prev` in C++11 causes problems with unqualified uses of those names when a type from the std namespace is involved, which IMHO are not vanishingly rare cases.

I found this post while trying to figure out a regression in Boost.Fusion caused exactly by this issue. The test case compiles fine on Clang but it fails with a compilation error as it should on MSVC, which was a vanishingly rare experience for me.

Regards,
--
Agustín K-ballo Bergé.-
http://talesofcpp.fusionfenix.com





==============================================================================
TOPIC: What is the disadvantage with C++ in Embedded systems?
http://groups.google.com/group/comp.lang.c++/t/d2c6dd66860beb15?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Jan 26 2014 10:53 pm
From: Rainer Grimm


> > What is the disadvantage with C++ in Embedded systems?.
I'm new in the embedded world. So I was astonished and irritated
how dominant C is in the area. Because of that impression I gave
a presentation in order to show, what C++11 can offer you in embedded world.
Here is my presentation:
http://meetingcpp.com/tl_files/2013/talks/EmbeddedC++11%20-%20RainerGrimm.pdf
Additonal to that there is a excellent paper describing in very detail the
performance issues of C++.
http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf
I'm sure that the embedded world is one of the keys domains of C++.




== 2 of 2 ==
Date: Mon, Jan 27 2014 2:56 pm
From: W Karas


On Thursday, February 27, 2003 8:52:03 PM UTC-5, vasanta wrote:
> What is the disadvantage with C++ in Embedded systems?. Why C is
> preferred than C++ in embedded systems?. Thanks in advance for help,
> appreciated.

Suppose you had a car with a lever that could switch it into 4-wheel drive. Your question is analogous to asking if you should remove the lever, so it would always run in 2-wheel drive.

A C99 program can be compiled with a C++ compiler with, at most, minor modifications. If there is any significant performance difference, that means the C++ compiler needs improving. It's not a consequence of differences in the languages.

If you use C++-specific features (not in C), there are performance implications. Just as there are performance implications to using 4-wheel drive instead of 2-wheel drive. Here is something I wrote that delves into that issue somewhat:

http://wkaras.webs.com/Cpp_overhead.html

A "managerial" argument that one hears is that, few programmers are careful enough to make good decision about when and how to use C++ features. I think in some niches that may be applicable. Thing is, dynamic allocation of resources is pretty common in code bases. So now you're looking for programmers who are thoughtful enough to do dynamic allocation WITHOUT all the C++ features for error-proofing dynamic allocation, yet not able or willing to use C++ effectively.




==============================================================================

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

No comments: