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:

* goto label inside of if statement - 5 messages, 5 authors
http://groups.google.com/group/comp.lang.c++/t/7c222b0d5330287c?hl=en
* What is the disadvantage with C++ in Embedded systems? - 10 messages, 6
authors
http://groups.google.com/group/comp.lang.c++/t/d2c6dd66860beb15?hl=en
* Moving from C++03 to C++11 - 4 messages, 4 authors
http://groups.google.com/group/comp.lang.c++/t/4bf001f37864dec0?hl=en
* Boost - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/81738d66827a11c8?hl=en
* How does the name lookup work in this case? - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/f7e465d3b9e6c21f?hl=en
* When can you assign one struct to another? - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/e52a3b60c6d136c4?hl=en

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

== 1 of 5 ==
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






== 2 of 5 ==
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?




== 3 of 5 ==
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





== 4 of 5 ==
Date: Tues, Jan 28 2014 1:57 pm
From: Vir Campestris


On 26/01/2014 21:32, Gareth Owen wrote:
> 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.

I'll second that - but add a bit of data.

I've been writing C since before some of my co-workers were born (yes,
it scares me too!) and I've only written ONE goto ever.

And that didn't make it to checkin...

They do have a place, but it's vanishingly rare. I think the place is
not in a C++ program.

Andy




== 5 of 5 ==
Date: Tues, Jan 28 2014 2:11 pm
From: Jax


Vir Campestris <vir.campestris@invalid.invalid> wrote in
news:lqCdnaGIYKcwunXPnZ2dnUVZ8v6dnZ2d@brightview.co.uk:

> On 26/01/2014 21:32, Gareth Owen wrote:
>> 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.
>
> I'll second that - but add a bit of data.
>
> I've been writing C since before some of my co-workers were born (yes,
> it scares me too!) and I've only written ONE goto ever.
>
> And that didn't make it to checkin...
>
> They do have a place, but it's vanishingly rare. I think the place is
> not in a C++ program.
>
> Andy

Andy.... you make me pause for thought. If I understand the implication of
what you wrote, then it means I haven't learned my first *real* C++
command!

--
Jax





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

== 1 of 10 ==
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.




== 2 of 10 ==
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).




== 3 of 10 ==
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




== 4 of 10 ==
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




== 5 of 10 ==
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





== 6 of 10 ==
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.





== 7 of 10 ==
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




== 8 of 10 ==
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 .




== 9 of 10 ==
Date: Tues, Jan 28 2014 1:20 pm
From: Jorgen Grahn


On Tue, 2014-01-28, 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.
...
> I see a few big reasons that C++ is relatively uncommon in the embedded
> world.

[snip things I don't agree with]

> 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.

My pet theory is that a lot of the problems C++ has (embedded or not)
stems from failed and almost-failed projects in the 1990s. "Let's
rewrite this system in C++, it's the next big thing!", followed by
- Inadequate training
- Too much focus on orthodox Object-Oriented Design a la Smalltalk
- Pre-standard language, with no standard library, no templates ...

People (not just managers) remember such things. Sometimes, they are
still sitting there today maintaining them ...

/Jorgen

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




== 10 of 10 ==
Date: Tues, Jan 28 2014 7:24 pm
From: Richard Damon


On 1/28/14, 11:18 AM, Scott Lurndal wrote:
> Wouter van Ooijen <wouter@voti.nl> writes:
>> Richard Damon schreef op 28-Jan-14 3:00 PM:
>>
>>> 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.


Templates should be considered as zero overhead because you only get the
code you asked for. The "problem" with templates is it can be too easy
to ask for lots of code when you don't realize it.

I actually find more problems with template libraries in large machines,
as once you get to dynamic linked/shared libraries, you can start to run
into problems of getting the templates to be in the right piece of code.





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

== 1 of 4 ==
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?




== 2 of 4 ==
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




== 3 of 4 ==
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




== 4 of 4 ==
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 2 ==
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




== 2 of 2 ==
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: How does the name lookup work in this case?
http://groups.google.com/group/comp.lang.c++/t/f7e465d3b9e6c21f?hl=en
==============================================================================

== 1 of 2 ==
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?




== 2 of 2 ==
Date: Tues, Jan 28 2014 1:32 pm
From: "Alf P. Steinbach"


On 28.01.2014 21:47, Peter wrote:
> 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

I think that is correct.

And I think probably C++11 §7.3.4/6, in the "Using directive" section,
applies:

"If name lookup finds a declaration for a name in two different
namespaces, and the declarations do not declare the same entity and do
not declare functions, the use of the name is ill-formed."

As it happens Visual C++ 12.0 appears to also think so:

[error]
original.cpp(19) : error C2872: 'Foo' : ambiguous symbol
could be 'Foo'
or 'original.cpp(8) : Foo::Foo'
[/error]


> 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.

Except that I believe that's wrong, it's reasonable: maybe its how the
language should be.


> In order for the compiler to find it I have to qualify it fully as
> Foo::Foo::x despite the "using namespace Foo;" line.

That's not full qualification, and Visual C++ still emits the diagnostic
above.

Full qualification is

::Foo::Foo::x;

and this is accepted by Visual C++.


> Why?

I think the ambiguity is real and that the g++ failure to diagnose it is
a compiler bug. I could be wrong. But, since the two compilers disagree,
at least one of Visual C++ and g++ has a bug here. ;-)


> How does the lookup work here?

C++11 §7.3.4/2

"A using-directive specifies that the names in the nominated namespace
can be used in the scope in which the using-directive appears after the
using-directive. During unqualified name lookup (3.4.1), the names
appear as if they were declared in the nearest enclosing namespace which
contains both the using-directive and the nominated namespace"


Cheers & hth.,

- Alf






==============================================================================
TOPIC: When can you assign one struct to another?
http://groups.google.com/group/comp.lang.c++/t/e52a3b60c6d136c4?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Jan 28 2014 4:01 pm
From: Bint


Hello, I have a struct, which includes another struct, like this:

typedef float CGFloat;

struct CGPoint {
CGFloat x;
CGFloat y;
};

struct LinePoint {
CGPoint pos;
float width;
};


Now, if I have a pointer to a bunch of LinePoints, can I directly assign one
of them with another LinePoint?

LinePoint P;
LinePoint *array;

*(array+i) = P;

Will it copy all of the fields, or not? Sometimes it seems like it does, and
other times no. I can't figure out what is going on.

Thanks
B'





== 2 of 3 ==
Date: Tues, Jan 28 2014 4:30 pm
From: "Alf P. Steinbach"


On 29.01.2014 01:01, Bint wrote:
> Hello, I have a struct, which includes another struct, like this:
>
> typedef float CGFloat;
>
> struct CGPoint {
> CGFloat x;
> CGFloat y;
> };
>
> struct LinePoint {
> CGPoint pos;
> float width;
> };
>
>
> Now, if I have a pointer to a bunch of LinePoints, can I directly assign one
> of them with another LinePoint?

Yes.


> LinePoint P;
> LinePoint *array;
>
> *(array+i) = P;
>
> Will it copy all of the fields, or not?

Yes, it will copy all of the field.

In passing,

(1) the preferred array indexing notation is

array[i] = P;

(2) the floating point type of choice when there are no strong reasons
for anything else, is `double` (e.g. `3.14` is of type `double`), and

(3) it's a good idea to use std::vector instead of trying to implement
dynamic size arrays yourself, i.e.

LinePoint P;
std::vector<LinePoint> array;

// Add items to array, then
array[i] = P;


> Sometimes it seems like it does, and
> other times no. I can't figure out what is going on.

You may have double deallocation, uninitialized pointer, indexing beyond
the array end, messed up heap or stack, ...

However, it may help to narrow down the causes by using std::vector::at,

array.at( i ) = P;

because it throws an exception if `i` is not in range for the current
array size.


Cheers & hth.,

- Alf





== 3 of 3 ==
Date: Tues, Jan 28 2014 4:31 pm
From: Victor Bazarov


On 1/28/2014 7:01 PM, Bint wrote:
> Hello, I have a struct, which includes another struct, like this:
>
> typedef float CGFloat;
>
> struct CGPoint {
> CGFloat x;
> CGFloat y;
> };
>
> struct LinePoint {
> CGPoint pos;
> float width;
> };
>
>
> Now, if I have a pointer to a bunch of LinePoints, can I directly assign one
> of them with another LinePoint?
>
> LinePoint P;
> LinePoint *array;
>
> *(array+i) = P;

Is there anything between those lines or are those it? I'm asking
because declaring 'array' a pointer to LinePoint and not assigning any
value to it (and not initializing it with anything valid) does not
certainly mean that you *have a pointer to _a bunch_ of LinePoints.

In fact it does not at all point to any LinePoint whatever, generally
speaking. It has a random value.

> Will it copy all of the fields, or not?

Yes, *if* 'array' points to the first valid object of type LinePoint and
there are at least 'i' of those in a row. If 'i' is such that you run
beyond the boundary of the array you have, the copying will not work
very well.

Post the code that shows how you make 'array' point to "a bunch of"
objects, and how you calculate 'i' before using the expression.

> Sometimes it seems like it does, and
> other times no. I can't figure out what is going on.

Distill your code to the bare minimum that seems to misbehave (or does
misbehave), then post it here entirely. For more information please see
section 5 of the FAQ Lite.

V
--
I do not respond to top-posted replies, please don't ask




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

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

Fwd: Proof That Men Have Better Friends

Sent from my iPad

Begin forwarded message:

From: Hsiao-Hung Kao <k6hsi@aol.com>
Date: January 30, 2014 12:03:46 PM CST
Subject: Fwd: Proof That Men Have Better Friends

 

 

Proof That Men Have Better Friends 

Friendship among Women:

A woman didn't come home one night. 

The next morning she told her husband

that she had slept over at a friend's house. 

The man called his wife's 10 best friends. 

None of them knew anything about it.

 

Friendship among Men:

A man didn't come home one night. 

The next morning he told his wife that he

had slept over at a friend's house. 

The woman called her husband's 10 best friends. 

Eight confirmed that he had slept over,

    and two said he was still there.

 

 

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