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) - 11 messages, 6 authors
http://groups.google.com/group/comp.lang.c++/t/dac6864900693dc7?hl=en
* goto label inside of if statement - 4 messages, 4 authors
http://groups.google.com/group/comp.lang.c++/t/7c222b0d5330287c?hl=en
* Boost - 7 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/81738d66827a11c8?hl=en
* Moving from C++03 to C++11 - 2 messages, 2 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? - 1 messages, 1
author
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 11 ==
Date: Sun, Jan 26 2014 12:12 pm
From: Mr Flibble
Google: "Why is [language] so..."
Javascript: popular
Java: popular
Python: popular
Perl: ugly
R: slow
Ruby: slow
Fortran: fast
C++: hard
/Flibble
== 2 of 11 ==
Date: Sun, Jan 26 2014 12:26 pm
From: woodbrian77@gmail.com
On Sunday, January 26, 2014 2:12:43 PM UTC-6, Mr Flibble wrote:
> Google: "Why is [language] so..."
>
> Javascript: popular
> Java: popular
> Python: popular
> Perl: ugly
> R: slow
> Ruby: slow
> Fortran: fast
> C++: hard
>
Duckduckgo says C++ is fast and complicated:
https://duckduckgo.com/?q=%22why+is+C%2B%2B+so%22
Brian
Ebenezer Enterprises
http://webEbenezer.net
== 3 of 11 ==
Date: Sun, Jan 26 2014 12:51 pm
From: Öö Tiib
On Sunday, 26 January 2014 22:12:43 UTC+2, Mr Flibble wrote:
> Google: "Why is [language] so..."
> Javascript: popular
> Java: popular
> Python: popular
> Perl: ugly
> R: slow
> Ruby: slow
> Fortran: fast
> C++: hard
I typed the text and google suggested first in drop down:
Javascript: why is javascript v8 so fast
Java: why is javascript so popular
Python: why is python documentation so bad
Perl: why is perl 6 taking so long
R: why is runescape so laggy
Ruby: why is ruby on rails so popular
Fortran: why is fortran so fast
C++: why is c++ called so
Not sure how google guesses what i want to ask.
== 4 of 11 ==
Date: Sun, Jan 26 2014 1:10 pm
From: Mr Flibble
On 26/01/2014 20:51, Öö Tiib wrote:
> On Sunday, 26 January 2014 22:12:43 UTC+2, Mr Flibble wrote:
>> Google: "Why is [language] so..."
>> Javascript: popular
>> Java: popular
>> Python: popular
>> Perl: ugly
>> R: slow
>> Ruby: slow
>> Fortran: fast
>> C++: hard
>
> I typed the text and google suggested first in drop down:
>
> Javascript: why is javascript v8 so fast
> Java: why is javascript so popular
> Python: why is python documentation so bad
> Perl: why is perl 6 taking so long
> R: why is runescape so laggy
> Ruby: why is ruby on rails so popular
> Fortran: why is fortran so fast
> C++: why is c++ called so
>
> Not sure how google guesses what i want to ask.
You are not playing the game properly.
Google: "Why is [thing] so"
Don't put anything in-between [thing] and "so".
/Flibble
== 5 of 11 ==
Date: Sun, Jan 26 2014 1:26 pm
From: Paavo Helde
Mr Flibble <flibbleREMOVE_THIS_AND_THIS@i42.co.uk> wrote in
news:Xo6dnZ9Z14ai8XjPnZ2dnUVZ8tOdnZ2d@giganews.com:
> Google: "Why is [language] so..."
> C++: hard
To keep us entertained, of course!
== 6 of 11 ==
Date: Sun, Jan 26 2014 1:26 pm
From: Vir Campestris
On 26/01/2014 20:26, woodbrian77@gmail.com wrote:
> Duckduckgo says C++ is fast and complicated:
>
> https://duckduckgo.com/?q=%22why+is+C%2B%2B+so%22
Google tells _me_ it's also hard and popular.
Your answers may vary.
Andy
== 7 of 11 ==
Date: Sun, Jan 26 2014 2:08 pm
From: woodbrian77@gmail.com
On Sunday, January 26, 2014 3:26:15 PM UTC-6, Vir Campestris wrote:
> On 26/01/2014 20:26, woodbrian77@gmail.com wrote:
>
> > Duckduckgo says C++ is fast and complicated:
> >
> > https://duckduckgo.com/?q=%22why+is+C%2B%2B+so%22
>
> Google tells _me_ it's also hard and popular.
>
I think you mean C++ when you say "it's." Duckduckgo
also said those things. I was just giving a summary
of the top two things it came back with.
== 8 of 11 ==
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.
== 9 of 11 ==
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
== 10 of 11 ==
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
== 11 of 11 ==
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: goto label inside of if statement
http://groups.google.com/group/comp.lang.c++/t/7c222b0d5330287c?hl=en
==============================================================================
== 1 of 4 ==
Date: Sun, Jan 26 2014 12:27 pm
From: Öö Tiib
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?
One is certain that C++ programs can be written without using 'goto'
because there are large C++ code-bases (millions of lines) without a
single 'goto' in them.
Goto may cause that program logic is hard to understand. However
the silly tricks with loops, switches, continues or break's that I have
seen sometimes written for emulating goto are even worse. So if you
ever feel that you need to write tricky code to avoid goto then better
use goto.
== 2 of 4 ==
Date: Sun, Jan 26 2014 1:22 pm
From: Paavo Helde
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
== 3 of 4 ==
Date: Sun, Jan 26 2014 1:32 pm
From: Gareth Owen
Paavo Helde <myfirstname@osa.pri.ee> writes:
> 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.
Jax,
Take Paavo's advice and memorise it.
You'll not find it a better argument more cogently stated.
If you remember nothing else, remember the first sentence.
== 4 of 4 ==
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 .
==============================================================================
TOPIC: Boost
http://groups.google.com/group/comp.lang.c++/t/81738d66827a11c8?hl=en
==============================================================================
== 1 of 7 ==
Date: Sun, Jan 26 2014 1:27 pm
From: woodbrian77@gmail.com
On Sunday, January 26, 2014 1:00:37 PM UTC-6, Öö Tiib wrote:
> On Sunday, 26 January 2014 19:51:49 UTC+2, woodb...@gmail.com wrote:
>
> > Other serialization libraries are also focused on C++.
> > Corba takes language neutral approach. Is it thriving?
> > I tend to think it is stagnant and dying.
>
> If someone asks for C++ solution for serialization then he
> gets lot of answers like protocol buffers, jsoncpp,
> codesynthesis xsd, tinyxml, boost serialize, and so
The C++ Middleware Writer has support for serializing
some of Boost. G-d willing we'll add support for other
types in the future including more of Boost. It will
depend on the needs of users.
> on. Like you see all are capable to serialize into language
> neutral formats. Other languages have same or
> different tools for serialization since what matters is
> the format.
>
I'm talking about binary serialization here.
> > My approach is to focus first on C++. After dust
> > settles, I hope to provide support for one or two other
> > languages. C++ is most important language for services,
> > so good place to start.
>
> Lot of network services are not written in C++.
>
Do you disagree with my claim that C++ is most important
language for services?
>
> > Don't hold your breath if you have requests for some
> > libraries. The maintenance can be very thin.
>
> I speak of experience. Boost tends to have lower amount of
> defects than other C++ libraries. If there is a defect then it is
> usually fixed soon and also workaround is found.
Some of Boost is as you describe. Other parts don't
get much love.
Brian
Ebenezer Enterprises
http://webEbenezer.net
== 2 of 7 ==
Date: Sun, Jan 26 2014 1:34 pm
From: Ian Collins
woodbrian77@gmail.com wrote:
> On Sunday, January 26, 2014 1:00:37 PM UTC-6, Öö Tiib wrote:
>
>>> My approach is to focus first on C++. After dust
>>> settles, I hope to provide support for one or two other
>>> languages. C++ is most important language for services,
>>> so good place to start.
>>
>> Lot of network services are not written in C++.
>>
>
> 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. This is why most
serialisation formats in common use today (SOAP, XML-RPC, JSON) are
textual or binary extensions of them (BSON).
--
Ian Collins
== 3 of 7 ==
Date: Sun, Jan 26 2014 2:18 pm
From: Öö Tiib
On Sunday, 26 January 2014 23:27:36 UTC+2, woodb...@gmail.com wrote:
> On Sunday, January 26, 2014 1:00:37 PM UTC-6, Öö Tiib wrote:
> > On Sunday, 26 January 2014 19:51:49 UTC+2, woodb...@gmail.com wrote:
> >
> > > Other serialization libraries are also focused on C++.
> > > Corba takes language neutral approach. Is it thriving?
> > > I tend to think it is stagnant and dying.
> >
> > If someone asks for C++ solution for serialization then he
> > gets lot of answers like protocol buffers, jsoncpp,
> > codesynthesis xsd, tinyxml, boost serialize, and so
> > on. Like you see all are capable to serialize into language
> > neutral formats. Other languages have same or
> > different tools for serialization since what matters is
> > the format.
>
> I'm talking about binary serialization here.
The binary formats are less used than text formats when traffic
is small enough. There are plenty of binary formats and most
have C++ or C serialization/deserialization available. Protocol
Buffers have language neutral binary format from above.
Boost Serialization binary format may have differences between
versions of library and it is C++ only. However it may be useful
for usage within single application.
> > > My approach is to focus first on C++. After dust
> > > settles, I hope to provide support for one or two other
> > > languages. C++ is most important language for services,
> > > so good place to start.
> >
> > Lot of network services are not written in C++.
> >
>
> Do you disagree with my claim that C++ is most important
> language for services?
No. Claiming what is more or less important programming language
misses the point about importance of formats. I was saying that
there are lot of services that are not written in C++. These are
important too and the programs need to interoperate so need to
use common format.
> > I speak of experience. Boost tends to have lower amount of
> > defects than other C++ libraries. If there is a defect then it is
> > usually fixed soon and also workaround is found.
>
> Some of Boost is as you describe. Other parts don't
> get much love.
Most of the libraries in Boost seem to be made with love.
== 4 of 7 ==
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
== 5 of 7 ==
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
== 6 of 7 ==
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
== 7 of 7 ==
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
==============================================================================
TOPIC: Moving from C++03 to C++11
http://groups.google.com/group/comp.lang.c++/t/4bf001f37864dec0?hl=en
==============================================================================
== 1 of 2 ==
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 2 ==
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".
==============================================================================
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 1 ==
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++.
==============================================================================
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