comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* What is the disadvantage with C++ in Embedded systems? - 9 messages, 7
authors
http://groups.google.com/group/comp.lang.c++/t/d2c6dd66860beb15?hl=en
* Moving from C++03 to C++11 - 6 messages, 5 authors
http://groups.google.com/group/comp.lang.c++/t/4bf001f37864dec0?hl=en
* Boost - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/81738d66827a11c8?hl=en
* goto label inside of if statement - 7 messages, 4 authors
http://groups.google.com/group/comp.lang.c++/t/7c222b0d5330287c?hl=en
* How does the name lookup work in this case? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/f7e465d3b9e6c21f?hl=en
==============================================================================
TOPIC: What is the disadvantage with C++ in Embedded systems?
http://groups.google.com/group/comp.lang.c++/t/d2c6dd66860beb15?hl=en
==============================================================================
== 1 of 9 ==
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 9 ==
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.
== 3 of 9 ==
Date: Tues, Jan 28 2014 6:00 am
From: Richard Damon
On 1/27/14, 1:53 AM, Rainer Grimm wrote:
>>> 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++.
>
I see a few big reasons that C++ is relatively uncommon in the embedded
world.
1) Many of the processors used in the embedded world tend to be "small
market" in terms of demand for tools, and it would seem to be
significantly simpler to make a C compiler for a system then a C++ one.
2) Embedded systems are much more sensitive to efficiency concerns.
While C++ has done a good job of keeping to the "don't pay for what you
don't use", there are a few areas where this doesn't hold (or at least
the perception is that it doesn't). One big area for this is exceptions.
When using C++, you really can't just ignore exceptions (though there is
a variant "Embedded C++" which removes them). Early versions of
exception had execution costs in all cases which was bad for embedded,
more recently techniques have been developed where this has changed to a
space cost (for tables to define unwinding), and time on the exception
path. The non-obvious costs on these paths can be a barrier for C++, as
sometimes in the embedded world there are performance requirements even
on the error paths.
3) C++ has the most to offer for BIG systems, where the encapsulation
can help manage complexity. Most embedded systems, almost by definition,
don't get that complex (because there isn't enough machine to put that
much complexity into). This reduces the demand for it, so coupled with
point 1, resources don't get allocated to it.
4) Perception-wise, it is easier for a mediocre C++ program to make a
big mess than a C programmer. Misusing features like templates and
inheritance can seriously bloat a program. While this isn't really the
language's fault, some managers can feel that they have been burnt by
this too many times, so want to avoid it. (of coarse here the real
answer is to learn not to make that sort of mistake, bad programmers can
make a mess in any language).
None of these says that you CAN'T use C++ for an embedded project, but
the provide dis-incentives for it. As a common example, for many of the
chips I have used, the chip vendor provides a version of a C development
platform for free with some small limitations, and a full C system for
not much money (less than a day pay). For the reasons above, the haven't
made the effort to provide a C++ solution (there hasn't been enough call
for it to make it worth it). There is perhaps a 3rd party vendor with a
C++ system available, but its cost is more like a month's pay. IT can be
hard to make the economic justification that the C++ system is worth it
at the beginning of the development cycle, especially if the estimate
for the program time is only a very few months, C++ is NOT going to buy
that much of a gain in the initial system. (There may be some longer
term justifications, but that is often harder to make, those savings can
be from a totally different budget).
== 4 of 9 ==
Date: Tues, Jan 28 2014 7:08 am
From: Wouter van Ooijen
Richard Damon schreef op 28-Jan-14 3:00 PM:
> I see a few big reasons that C++ is relatively uncommon in the embedded
> world.
>
> 1) Many of the processors used in the embedded world tend to be "small
> market" in terms of demand for tools, and it would seem to be
> significantly simpler to make a C compiler for a system then a C++ one.
Can't argue with that (if there is no C++ compiler for a chip you
obviously can't use C++ on it), but there are GCC (including G++)
compilers for AVR and ARM/Cortex, which together are a significant part
of the small-chips market.
> 2) Embedded systems are much more sensitive to efficiency concerns.
> While C++ has done a good job of keeping to the "don't pay for what you
> don't use", there are a few areas where this doesn't hold (or at least
> the perception is that it doesn't). One big area for this is exceptions.
> When using C++, you really can't just ignore exceptions
At least for GCC you can: put -fno-exceptions on the command line and
forget about them.
> 3) C++ has the most to offer for BIG systems, where the encapsulation
> can help manage complexity. Most embedded systems, almost by definition,
> don't get that complex (because there isn't enough machine to put that
> much complexity into). This reduces the demand for it, so coupled with
> point 1, resources don't get allocated to it.
Which is a pity, because small projects can benefit a lot from code
reuse, and C++ offers mechanisms (templates, static class attributes)
that have zero overhead.
> 4) Perception-wise, it is easier for a mediocre C++ program to make a
> big mess than a C programmer. Misusing features like templates and
> inheritance can seriously bloat a program. While this isn't really the
> language's fault, some managers can feel that they have been burnt by
> this too many times, so want to avoid it. (of coarse here the real
> answer is to learn not to make that sort of mistake, bad programmers can
> make a mess in any language).
(amen to the last sentence)
> C++ is NOT going to buy
> that much of a gain in the initial system. (There may be some longer
> term justifications, but that is often harder to make, those savings can
> be from a totally different budget).
One day I hope to prove that C++ (when used appropriately) has A LOT to
offer for programming small systems (micro-controllers).
Wouter
== 5 of 9 ==
Date: Tues, Jan 28 2014 8:18 am
From: scott@slp53.sl.home (Scott Lurndal)
Wouter van Ooijen <wouter@voti.nl> writes:
>Richard Damon schreef op 28-Jan-14 3:00 PM:
>> I see a few big reasons that C++ is relatively uncommon in the embedded
>> world.
>>
>> 1) Many of the processors used in the embedded world tend to be "small
>> market" in terms of demand for tools, and it would seem to be
>> significantly simpler to make a C compiler for a system then a C++ one.
>
>Can't argue with that (if there is no C++ compiler for a chip you
>obviously can't use C++ on it), but there are GCC (including G++)
>compilers for AVR and ARM/Cortex, which together are a significant part
>of the small-chips market.
>
>> 2) Embedded systems are much more sensitive to efficiency concerns.
>> While C++ has done a good job of keeping to the "don't pay for what you
>> don't use", there are a few areas where this doesn't hold (or at least
>> the perception is that it doesn't). One big area for this is exceptions.
>> When using C++, you really can't just ignore exceptions
>
>At least for GCC you can: put -fno-exceptions on the command line and
>forget about them.
In fact, I've written several "embedded" applications (two operating systems
and two hypervisors, for very large-scale systems) in C++. Avoiding exceptions
was mandatory (given the lack of a runtime), and templates were discouraged
(to reduce cache footprint for the OS/Hypervisor).
-fno-exceptions was used in all cases.
Here are the compiler flags we used for the hypervisor:
#
# The compiler can be instructed to use the %RBP register as a
# frame pointer. This reduces the available register pool by one and
# does increase the size of the dvmm by about 1%, but it produces complete
# and reliable stack tracebacks.
#GCCFLAGS+= -fomit-frame-pointer # Don't reserve RBP for frame info
GCCFLAGS += -fno-omit-frame-pointer # Reserve RBP for frame info
DEFINES = -DUSE_FRAMEPOINTER
#
# We're PIC because the monitor doesn't live in either the first
# 2GB (mcmodel=small) or the last 2GB (mcmodel=kernel). We could use
# mcmodel=large, but gcc 3.4 doesn't implement that yet.
#
GCCFLAGS += -fPIC # Position Independent Code
GCCFLAGS += -mno-red-zone # Don't use stack redzone
GCCFLAGS += -fno-strict-aliasing # Compiler can't assume no aliases
GCCFLAGS += -nostdlib # Don't use /lib
GCCFLAGS += -nostartfiles # Don't use crt0.o
GCCFLAGS += -Wall # Turn on all warning conditions
GCCFLAGS += -Werror # Make warnings fatal
GCCFLAGS += -g
OPTIMFLAGS = -mtune=opteron # Tune for the opteron processor
OPTIMFLAGS += -O2
GCCONLYFLAGS+=-ffreestanding # Freestanding compile
>
>> 3) C++ has the most to offer for BIG systems, where the encapsulation
>> can help manage complexity. Most embedded systems, almost by definition,
>> don't get that complex (because there isn't enough machine to put that
>> much complexity into). This reduces the demand for it, so coupled with
>> point 1, resources don't get allocated to it.
>
>Which is a pity, because small projects can benefit a lot from code
>reuse, and C++ offers mechanisms (templates, static class attributes)
>that have zero overhead.
Almost zero. Templates can lead to additional code (.text) footprint
when overused, which can impact performance due to cache loading. The
inline keyword must be used judiciously.
Using C++ as "C with Classes" for embedded and bare-metal code is
good - you get the data encapsulation and inheritance provided by
the class keyword which helps with design and maintainence.
There is no rule that states one must use _all_ features of C++ in every
single C++ program, notwithstanding some dogmatic contributors to this
newsgroup.
scott
== 6 of 9 ==
Date: Tues, Jan 28 2014 10:17 am
From: Wouter van Ooijen
Scott Lurndal schreef op 28-Jan-14 5:18 PM:
> In fact, I've written several "embedded" applications (two operating systems
> and two hypervisors, for very large-scale systems) in C++. Avoiding exceptions
> was mandatory (given the lack of a runtime), and templates were discouraged
> (to reduce cache footprint for the OS/Hypervisor).
My (so far small-scale) experience with templates is that you can use
them to give the compiler the chance to do inlining followed by other
optimzations, thus reducing the code size.
Of course, this must be used with care: code that does not depend on the
template arguments and does not benefit from said optimizations
should be outside the template.
> GCCFLAGS += -nostdlib # Don't use /lib
I use the same. IMO it nicely sumarizes the situation of small-system
programmers with respect to the overall C++ community: the compiler is
usesfull, but the libraries are almost useless.
> There is no rule that states one must use _all_ features of C++ in every
> single C++ program, notwithstanding some dogmatic contributors to this
> newsgroup.
Total agreement here. And bafflement why anyone should think otherwise.
Every language feature has its place (for some it is down there with the
suplhur and fire). Use what is beneficial, ignore the rest. And if you
can, enforce this in your toolchain! Personally I hate global objects
with run-time initialization (if anyone doesn't understand why start
googling NOW), so in the linkerscript I allocate a 0-size region called
'stupid_fool_you_used_a_global_object_with_runtime_initialization" for
the .init and .preinit_array sections.
Wouter
== 7 of 9 ==
Date: Tues, Jan 28 2014 11:12 am
From: David Brown
On 28/01/14 15:00, Richard Damon wrote:
> On 1/27/14, 1:53 AM, Rainer Grimm wrote:
>>>> 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++.
>>
>
> I see a few big reasons that C++ is relatively uncommon in the embedded
> world.
>
> 1) Many of the processors used in the embedded world tend to be "small
> market" in terms of demand for tools, and it would seem to be
> significantly simpler to make a C compiler for a system then a C++ one.
>
The small ones for which a C++ compiler would be much harder, such as
the 8051, are very much on the decline. All the major C compiler
vendors support C++ (GHS, CodeWarrior, Mentor, etc.) for all but the
most brain-dead microcontrollers - and of course, gcc is available for
dozens of architectures and is, I believe, by far the most common
embedded compiler. (For some architectures, gcc C++ is limited from
lack of library support, but that mostly affects exceptions and RTTI.)
However, many commercial vendors still view C++ as a "premium" choice,
and price accordingly - making it a major investment for small users.
For example, Code Warrior is free for a limited (but perfectly usable)
code size as long as you program in C - if you want C++, you need the
full version at $5000. This is despite the fact the compiler you use
for some targets is actually gcc - the debugger, libraries, wizards,
etc., are all C only for the free and low-cost versions.
Prices like that are okay for big projects, but the added investment is
often hard to justify.
> 2) Embedded systems are much more sensitive to efficiency concerns.
> While C++ has done a good job of keeping to the "don't pay for what you
> don't use", there are a few areas where this doesn't hold (or at least
> the perception is that it doesn't). One big area for this is exceptions.
> When using C++, you really can't just ignore exceptions
Yes you can - all embedded toolchains will have an equivalent of the
"-fno-exceptions" switch, along with a "-fno-rtti". Of course, that
means you can't use exception-heavy PC code directly on your embedded
system, but that is usually the case anyway. In particular, in embedded
code you normally want to minimise dynamic memory, while in PC code you
typically consider it to be "free".
> (though there is
> a variant "Embedded C++" which removes them).
"Embedded C++" was a piece of crap from the day it was conceived - some
of the compromises chosen are daft. Dropping exceptions, RTTI, and
multiple inheritance was reasonable enough - dropping templates was
silly, and dropping namespaces gains absolutely nothing.
> Early versions of
> exception had execution costs in all cases which was bad for embedded,
> more recently techniques have been developed where this has changed to a
> space cost (for tables to define unwinding), and time on the exception
> path. The non-obvious costs on these paths can be a barrier for C++, as
> sometimes in the embedded world there are performance requirements even
> on the error paths.
>
Yes - exceptions can make it hard to see all possible execution paths.
For embedded systems, you can't just crash with a helpful error message
if you fail to catch an exception.
Also, exceptions can cause limitations with optimisers - and embedded
systems often have to make greater use of less processing resources than
in the PC world.
> 3) C++ has the most to offer for BIG systems, where the encapsulation
> can help manage complexity. Most embedded systems, almost by definition,
> don't get that complex (because there isn't enough machine to put that
> much complexity into). This reduces the demand for it, so coupled with
> point 1, resources don't get allocated to it.
>
> 4) Perception-wise, it is easier for a mediocre C++ program to make a
> big mess than a C programmer. Misusing features like templates and
> inheritance can seriously bloat a program. While this isn't really the
> language's fault, some managers can feel that they have been burnt by
> this too many times, so want to avoid it. (of coarse here the real
> answer is to learn not to make that sort of mistake, bad programmers can
> make a mess in any language).
>
> None of these says that you CAN'T use C++ for an embedded project, but
> the provide dis-incentives for it. As a common example, for many of the
> chips I have used, the chip vendor provides a version of a C development
> platform for free with some small limitations, and a full C system for
> not much money (less than a day pay). For the reasons above, the haven't
> made the effort to provide a C++ solution (there hasn't been enough call
> for it to make it worth it). There is perhaps a 3rd party vendor with a
> C++ system available, but its cost is more like a month's pay. IT can be
> hard to make the economic justification that the C++ system is worth it
> at the beginning of the development cycle, especially if the estimate
> for the program time is only a very few months, C++ is NOT going to buy
> that much of a gain in the initial system. (There may be some longer
> term justifications, but that is often harder to make, those savings can
> be from a totally different budget).
>
Agreed.
== 8 of 9 ==
Date: Tues, Jan 28 2014 12:49 pm
From: scott@slp53.sl.home (Scott Lurndal)
Wouter van Ooijen <wouter@voti.nl> writes:
>Scott Lurndal schreef op 28-Jan-14 5:18 PM:
>> There is no rule that states one must use _all_ features of C++ in every
>> single C++ program, notwithstanding some dogmatic contributors to this
>> newsgroup.
>
>Total agreement here. And bafflement why anyone should think otherwise.
>Every language feature has its place (for some it is down there with the
>suplhur and fire). Use what is beneficial, ignore the rest. And if you
>can, enforce this in your toolchain! Personally I hate global objects
>with run-time initialization (if anyone doesn't understand why start
>googling NOW), so in the linkerscript I allocate a 0-size region called
>'stupid_fool_you_used_a_global_object_with_runtime_initialization" for
>the .init and .preinit_array sections.
>
>Wouter
>
Or, you can do this to handle static constructors without libc, if you like:
Linker script:
. = ALIGN(32);
_srodata = .;
.rodata : {
*(.rodata)
*(.rodata.*)
*(.gnu.linkonce.r*)
*(.got)
*(.got.*)
__CTOR_LIST__ = .;
LONG((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
*(.ctors)
LONG(0)
__CTOR_END__ = .;
__DTOR_LIST__ = .;
LONG((__DTOR_END__ - __DTOR_LIST__) / 8 - 2)
*(.dtors)
LONG(0)
__DTOR_END__ = .;
}
_erodata = .;
util/cppsupport.cpp:
extern void (*__CTOR_LIST__[])();
/*
* This is called by setup64.S to call the constructors of global objects,
* before it calls dvmm_bsp_start().
*
* GNU LD lays out the __CTOR_LIST__ as an array of function pointers. The
* first element of the array (index == 0) contains an integer which
* represents the value derived from subtracting two from the actual number
* of entries in the table. Thus the content of the first element is
* one less than the index of the last entry in the table.
*
* Call in reverse order XXX - why? Check crt0.o for canonical behavior
*/
extern "C" void
__call_constructors()
{
size_t count = *(size_t *)__CTOR_LIST__;
for(count++; count; --count) {
__CTOR_LIST__[count]();
}
}
setup64.S:
...
#
# Clear BSS
#
testl $1, %ebx # BSP or AP?
jnz 1f # AP, skip clear BSS & constructors
xorq %rax, %rax
leaq _sbss(%rip), %rdi
movq $0, %rcx
leaq _ebss(%rip), %rcx
subq %rdi, %rcx
rep stosb
pushq %rsi # Save RSI, since we'll need it later.
#
# Invoke the debugger early initialization function
#
movabsq $debugger, %rdi # Set this
movabsq $_ZN10c_debugger10early_initEv, %rcx # Call ::early_init
call *%rcx
#
# Invoke global C++ constructors.
#
movabsq $__call_constructors, %rcx
call *%rcx
popq %rsi # Restore RSI.
#
# Invoke C++ code. Pass begin and end address of memory map.
#
1:
movq $512, %rax # Starting with 512 bytes
subq %rsi, %rax # Subtract remaining
addq $0x90000, %rax # e820 data map address
# Use x86_64 calling conventions
movq $0x90000, %rdi # Pass arg1 to main
addq %r12, %rdi # Rebase arg1
movq %rax, %rsi # Pass arg2 to main
addq %r12, %rsi # Rebase arg2
movq %r15, %rdx # Arg3 is real-mode segment base
xorq %rbp, %rbp # Indicate end of stack for -fframe-pointer
movabsq $dvmm_bsp_start, %rcx # We use an indirect jump to invoke main
testl $1, %ebx # BSP or AP?
jz 4f # BSP, use 'dvmm_bsp_start'
movabsq $dvmm_ap_start, %rcx # AP, use 'dvmm_ap_start'
4: call *%rcx # because it is more than 2GB away from here
== 9 of 9 ==
Date: Tues, Jan 28 2014 1:01 pm
From: Jorgen Grahn
On Tue, 2014-01-28, David Brown wrote:
...
> The small ones for which a C++ compiler would be much harder, such as
> the 8051, are very much on the decline. All the major C compiler
> vendors support C++ (GHS, CodeWarrior, Mentor, etc.) for all but the
> most brain-dead microcontrollers - and of course, gcc is available for
...
> ... In particular, in embedded
> code you normally want to minimise dynamic memory, while in PC code you
> typically consider it to be "free".
I think it has been said here recently, but anyway: lots of embedded
systems are no longer small. The ones I've worked on for the last
decade or so have run some Unix, frequently have lots of fast CPUs,
and more memory than we'll ever find a use for.
(Of course, I acknowledge the existence of the other kinds too, and
that they ship more units.)
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
==============================================================================
TOPIC: Moving from C++03 to C++11
http://groups.google.com/group/comp.lang.c++/t/4bf001f37864dec0?hl=en
==============================================================================
== 1 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 ---
== 2 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
== 3 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?
== 4 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
== 5 of 6 ==
Date: Mon, Jan 27 2014 10:20 pm
From: woodbrian77@gmail.com
On Monday, January 27, 2014 5:31:52 PM UTC-6, Ike Naar wrote:
> 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?
I'm not 100% sure, but there are a few clues.
They are a small company and I think they are
probably all on the same page. They advertise
that they don't track, so if they were secretly
tracking they would be risking a self-inflicted
wound. Their jobs and investment in the company
would be hurt by that.
I've read a little about them and have heard the
CEO on TV.
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
== 6 of 6 ==
Date: Tues, Jan 28 2014 3:57 am
From: Richard Damon
On 1/28/14, 1:20 AM, woodbrian77@gmail.com wrote:
> On Monday, January 27, 2014 5:31:52 PM UTC-6, Ike Naar wrote:
>> 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?
>
> I'm not 100% sure, but there are a few clues.
>
> They are a small company and I think they are
> probably all on the same page. They advertise
> that they don't track, so if they were secretly
> tracking they would be risking a self-inflicted
> wound. Their jobs and investment in the company
> would be hurt by that.
>
> I've read a little about them and have heard the
> CEO on TV.
>
> Brian
> Ebenezer Enterprises - In G-d we trust.
> http://webEbenezer.net
>
They may not track individual accesses (Like I am fairly sure Google
does), but would be surprised if they didn't collect the aggregate,
non-identified usage data. If they provide the suggestions, they must.
==============================================================================
TOPIC: Boost
http://groups.google.com/group/comp.lang.c++/t/81738d66827a11c8?hl=en
==============================================================================
== 1 of 3 ==
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 .
== 2 of 3 ==
Date: Tues, Jan 28 2014 7:08 am
From: woodbrian77@gmail.com
On Monday, January 27, 2014 5:55:11 AM UTC-6, Jorgen Grahn wrote:
> On Mon, 2014-01-27, woodbrian77@gmail.com wrote:
>
> > 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 fu
> ...
Thanks and thanks to Ian for his comment on ASN.1. I think I'll
steer clear of that.
>
> Personally I suspect a (possibly gzipped) text stream is good enough
> almost all the time.
>
I think those working on scientific apps would disagree.
The serialization of their data is faster with binary and
there's probably no need for an additional compression step.
Brian
Ebenezer Enterprises
http://webEbenezer.net
== 3 of 3 ==
Date: Tues, Jan 28 2014 12:45 pm
From: Jorgen Grahn
On Tue, 2014-01-28, woodbrian77@gmail.com wrote:
...
>> Personally I suspect a (possibly gzipped) text stream is good enough
>> almost all the time.
>>
>
> I think those working on scientific apps would disagree.
> The serialization of their data is faster with binary and
> there's probably no need for an additional compression step.
Quite possible for some kinds of scientific apps -- I think my "almost
all the time" gets me off that particular hook!
/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 7 ==
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 :)
== 2 of 7 ==
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.
== 3 of 7 ==
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
== 4 of 7 ==
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
== 5 of 7 ==
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
== 6 of 7 ==
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?
== 7 of 7 ==
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: How does the name lookup work in this case?
http://groups.google.com/group/comp.lang.c++/t/f7e465d3b9e6c21f?hl=en
==============================================================================
== 1 of 1 ==
Date: Tues, Jan 28 2014 12:47 pm
From: Peter
Consider this definition (namespace and class share the same name):
namespace Foo
{
int x;
class Foo
{
public:
static int x;
};
int Foo::x;
}
I wondered what Foo::x would refer to with "using" directive used for namespace Foo: a global variable x in namespace Foo or static member of class Foo? Basically, I assumed the following code would not compile:
int main()
{
using namespace Foo;
Foo::x;
return 0;
}
My reasoning went like this:
- Foo::x is a global variable x from namespace Foo
- Foo::Foo::x is a static member of class Foo from namespace Foo, but since
"using" directive is applied, the namespace name can be omitted, thus Foo::x is also a static member of class Foo
- conclusion: call to Foo::x in main() is ambiguous - it refers to two different entities
However, the compiler I tested it with (one of g++ recent versions) had no trouble disambiguating this: experiments showed Foo::x in main() is interpreted as global variable x in namespace Foo. Moreover, if I remove the definition of global x from namespace Foo, then the compiler emits the following error:
main.cpp: In function 'int main()':
main.cpp:16:4: error: 'x' is not a member of 'Foo'
Foo::x;
so it doesn't find the static member of class Foo. In order for the compiler to find it I have to qualify it fully as Foo::Foo::x despite the "using namespace Foo;" line. Why? How does the lookup work here?
==============================================================================
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