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? - 12 messages, 8
authors
http://groups.google.com/group/comp.lang.c++/t/d2c6dd66860beb15?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
* goto label inside of if statement - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/7c222b0d5330287c?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
* Moving from C++03 to C++11 - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/4bf001f37864dec0?hl=en
* illegal void argument - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/c039b912fa7c33f7?hl=en
* Functor with recursive call - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/7c8534b6a9ab8b48?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 12 ==
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 .
== 2 of 12 ==
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 .
== 3 of 12 ==
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.
== 4 of 12 ==
Date: Wed, Jan 29 2014 1:19 am
From: see.my.homepage@gmail.com
> 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.
There is one important feature that templates have and that is missing in "pure C" - the ability to pass constants down the instantiated component. Constants are pretty cool - they can be used, for example, to define buffer sizes.
Now imagine I have a component that internally uses some buffer. This buffer needs a size and in order to avoid dynamic memory management (we are talking embedded, right?) this buffer needs to be sized statically. In C the only reasonable and widely practiced way is via preprocessor macros:
#define FOOBAR_BUFFER_SIZE 1024
But then it is not possible (or it's impractical) to instantiate two foobars with different buffer sizes in a single program.
Templates provide a clean way to do that:
FooBar<1024> smallFB;
FooBar<2048> bigFB;
without introducing any unreasonable overhead.
I would *love* to have this possibility in embedded projects and this is one important reason I would consider C++ there.
--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com
== 5 of 12 ==
Date: Wed, Jan 29 2014 2:07 am
From: Wouter van Ooijen
see.my.homepage@gmail.com schreef op 29-Jan-14 10:19 AM:
> #define FOOBAR_BUFFER_SIZE 1024
>
> But then it is not possible (or it's impractical) to instantiate two foobars with different buffer sizes in a single program.
>
> Templates provide a clean way to do that:
>
> FooBar<1024> smallFB;
> FooBar<2048> bigFB;
>
> without introducing any unreasonable overhead.
>
> I would *love* to have this possibility in embedded projects and this is one important reason I would consider C++ there.
>
There are ways to do that in C, one would be putting the all of the
ringbuffer declaration in a macro. (That has of course other reprecussions.)
As simple use of this feature is a fixed-maximum-size string:
class string;
template<>
class string<> {
public:
char * body;
unsigned int _maximum, _size;
string( char *body, unsigned int maximum ):
body( body ), _maximum( maximum ), _size( 0 ){}
public:
::: all string operators :::
};
template< unsigned int n >
class string : public string<> {
char body[ n ];
public:
string() : string<>( body, n ){}
::: a few operators that must be string<n> specific
};
The strings of different size are all compatible with the base class
string<> and can be used in combination, yet they all have their
individual maximum size.
Wouter
== 6 of 12 ==
Date: Wed, Jan 29 2014 2:22 am
From: Juha Nieminen
Scott Lurndal <scott@slp53.sl.home> wrote:
> 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 templates can increase the size of the executable beyond what's
absolutely necessary, but they can also actually *decrease* it,
compared to the alternatives. This is because templates allow the
compiler to optimize the code on a type-by-type basis. (Heck, in some
cases the compiler can even optimize portions of the code away, by
evaluating it at compile time and putting just the result in the executable
binary.)
One common problem with templates is that many people get the wrong
impression when they observe how they apparently affect executable
sizes. The problem is that they often, inadvertently, compile with
debug and symbol information, and with templates the symbol names
tend to be larger than with non-templated code (sometimes significantly
larger). Thus such an executable file can be larger when using templates,
until you strip it. But many people don't know this.
If we look at the *actual* executable code that's generated by the
compiler, whether using templates increases, decreases or retains
the size, depends on what you would consider the *alternative* to
templates. If you would need to reuse the same routines with different
types, how would you do it without templates? Depending on your
solution you might actually find that, ironically, your solution
results in a larger (and often slower) binary than with templates.
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
== 7 of 12 ==
Date: Wed, Jan 29 2014 4:55 am
From: David Brown
On 29/01/14 10:19, see.my.homepage@gmail.com wrote:
>> 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.
>
> There is one important feature that templates have and that is
> missing in "pure C" - the ability to pass constants down the
> instantiated component. Constants are pretty cool - they can be used,
> for example, to define buffer sizes.
>
> Now imagine I have a component that internally uses some buffer. This
> buffer needs a size and in order to avoid dynamic memory management
> (we are talking embedded, right?) this buffer needs to be sized
> statically. In C the only reasonable and widely practiced way is via
> preprocessor macros:
>
> #define FOOBAR_BUFFER_SIZE 1024
>
> But then it is not possible (or it's impractical) to instantiate two
> foobars with different buffer sizes in a single program.
>
> Templates provide a clean way to do that:
>
> FooBar<1024> smallFB; FooBar<2048> bigFB;
>
> without introducing any unreasonable overhead.
>
> I would *love* to have this possibility in embedded projects and this
> is one important reason I would consider C++ there.
>
There are many cases where C requires macros (often complicated ones) to
get efficient code code. Often with low-level embedded code you are
dealing with memory-mapped peripherals, and if you have several
identical peripherals it can be difficult to get efficient code (i.e.,
without extra layers of indirection caused by pointer-to-peripheral
function arguments) - you end up with duplicate source code, ugly
macros, etc. Templates on integers can let you write a neat template
class that gives you the most direct possible access to such peripherals
while still retaining a nice function or class interface.
== 8 of 12 ==
Date: Wed, Jan 29 2014 4:58 am
From: David Brown
On 28/01/14 22:01, Jorgen Grahn wrote:
> 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
>
That is certainly true. I often talk about "small" embedded systems, as
distinct from "embedded linux" and "pc without a keyboard" embedded
systems. "Resource constrained" is another useful term, but there is no
clear way to give exact classifications here.
== 9 of 12 ==
Date: Wed, Jan 29 2014 6:01 am
From: "Alf P. Steinbach"
On 25.01.2014 17:48, deepadivakaruni@gmail.com wrote:
> i think so c++ is more complicated when compared to c.
Yes, but that is not a disadvantage of the language for embedded systems.
> And also the many keywords are used to perform only one application.
Well, ditto.
* * *
Thread subject line:
"What is the disadvantage with C++ in Embedded systems?"
Please state your question in the article, not only in the subject line.
From the statements in the article one would think you were asking
something unspecified about the language complexity.
* * *
A main disadvantage of C++ for embedded systems, and for OS drivers
etc., compared to C, is that full C++ requires much RUNTIME SUPPORT that
C doesn't require, in particular for dynamic initialization of statics,
exception handling and RTTI like dynamic_cast.
There was once an initiative to use a subset of C++ called "EC++", see
<url: http://en.wikipedia.org/wiki/Embedded_C%2B%2B>, but it went too
far, was too impractical, and has been effectively dead since 2002.
Cheers & hth.,
- Alf
== 10 of 12 ==
Date: Wed, Jan 29 2014 8:31 am
From: Robert Wessel
On Wed, 29 Jan 2014 15:01:04 +0100, "Alf P. Steinbach"
<alf.p.steinbach+usenet@gmail.com> wrote:
>On 25.01.2014 17:48, deepadivakaruni@gmail.com wrote:
>> i think so c++ is more complicated when compared to c.
>
>Yes, but that is not a disadvantage of the language for embedded systems.
>
>
>> And also the many keywords are used to perform only one application.
>
>Well, ditto.
>
> * * *
>
>Thread subject line:
>"What is the disadvantage with C++ in Embedded systems?"
>
>Please state your question in the article, not only in the subject line.
>
> From the statements in the article one would think you were asking
>something unspecified about the language complexity.
>
> * * *
>
>A main disadvantage of C++ for embedded systems, and for OS drivers
>etc., compared to C, is that full C++ requires much RUNTIME SUPPORT that
>C doesn't require, in particular for dynamic initialization of statics,
>exception handling and RTTI like dynamic_cast.
Well, it requires *some* runtime support for those things. "Much" is
arguable.
For example, RTTI usually requires only a pointer in each vtable (per
vtable, so per class, not per instance) to a (short) block of type
information (typical overhead is under 50 bytes per class). The
routines needed to deal with that are pretty short too (depending on
the use, typeid can be very short - a lookup in the vtable, and
dynamic_cast requires a bit of a walk of the class hierarchy graph).
Other than the per-class memory overhead, RTTI doesn't impose any
execution time costs, unless you actually do a typeid or dynamic_cast.
Exceptions usually require a few extra instructions at routine/block
entry and exit, a few bytes of stack space for each of those, and a
small amount of code at the throw and catch (some (small) common
chunks of which sometimes end up the library).
Dynamic initialization of statics (and ctors on statics), require the
compilation of a list of pointers to each such static, and then
runtime support to step through that list, calling each ctor in turn
(IOW, several lines of code), and, of course the actual code for the
initialization of each object.
Of course, bad implementations can make any of that worse.
So those have some overhead, but it's not like they're going to drag
in hundreds of KB of runtime library or triple the size of the object
code, and what embedded compiler doesn't have at least something in
the CRT anyway?
A more useful argument against exception in some environments is that
they don't have a good context in which to work. Consider an
interrupt handler in a device driver called by the OS - you're not
going to be able to propagate an exception back past the call from the
OS.
== 11 of 12 ==
Date: Wed, Jan 29 2014 8:52 am
From: "Alf P. Steinbach"
On 29.01.2014 17:31, Robert Wessel wrote:
> On Wed, 29 Jan 2014 15:01:04 +0100, "Alf P. Steinbach"
> <alf.p.steinbach+usenet@gmail.com> wrote:
>
>> On 25.01.2014 17:48, deepadivakaruni@gmail.com wrote:
>>> i think so c++ is more complicated when compared to c.
>>
>> Yes, but that is not a disadvantage of the language for embedded systems.
>>
>>
>>> And also the many keywords are used to perform only one application.
>>
>> Well, ditto.
>>
>> * * *
>>
>> Thread subject line:
>> "What is the disadvantage with C++ in Embedded systems?"
>>
>> Please state your question in the article, not only in the subject line.
>>
>> From the statements in the article one would think you were asking
>> something unspecified about the language complexity.
>>
>> * * *
>>
>> A main disadvantage of C++ for embedded systems, and for OS drivers
>> etc., compared to C, is that full C++ requires much RUNTIME SUPPORT that
>> C doesn't require, in particular for dynamic initialization of statics,
>> exception handling and RTTI like dynamic_cast.
>
>
> Well, it requires *some* runtime support for those things. "Much" is
> arguable.
>
> For example, RTTI usually requires only a pointer in each vtable (per
> vtable, so per class, not per instance) to a (short) block of type
> information (typical overhead is under 50 bytes per class). The
> routines needed to deal with that are pretty short too (depending on
> the use, typeid can be very short - a lookup in the vtable, and
> dynamic_cast requires a bit of a walk of the class hierarchy graph).
> Other than the per-class memory overhead, RTTI doesn't impose any
> execution time costs, unless you actually do a typeid or dynamic_cast.
I wasn't talking about size or time costs, but rather, the need for that
information to exist and be initialized.
> Exceptions usually require a few extra instructions at routine/block
> entry and exit, a few bytes of stack space for each of those, and a
> small amount of code at the throw and catch (some (small) common
> chunks of which sometimes end up the library).
Exceptions require far more than you list (e.g. to support
std::exception_ptr), but ditto: it's not the space or time overhead
that's at issue.
> Dynamic initialization of statics (and ctors on statics), require the
> compilation of a list of pointers to each such static, and then
> runtime support to step through that list, calling each ctor in turn
> (IOW, several lines of code), and, of course the actual code for the
> initialization of each object.
Ditto: while space and time may be relevant on some devices, they're not
showstoppers, but the assumption of control that's inherent in C++'s
requirements of runtime support, can be.
At one time the issues that I pointed at meant that these features were
simply not available for some environments, As I recall, in particular
one mobile phone OS didn't support dynamic initialization of statics,
exceptions or RTTI. One had to make do with a slightly lobotomized
ARM-style C++.
Things have changed and are changing, especially for CUDA programming
(which I need to delve into!), but the issues are there still.
Cheers & hth.,
- Alf
== 12 of 12 ==
Date: Wed, Jan 29 2014 10:11 am
From: Wouter van Ooijen
Robert Wessel schreef op 29-Jan-14 5:31 PM:
> Exceptions usually require a few extra instructions at routine/block
> entry and exit, a few bytes of stack space for each of those, and a
> small amount of code at the throw and catch (some (small) common
> chunks of which sometimes end up the library).
>
> So those have some overhead, but it's not like they're going to drag
> in hundreds of KB of runtime library or triple the size of the object
> code, and what embedded compiler doesn't have at least something in
> the CRT anyway?
More a library implementation issue than a language issue, but when I
build my Cortex M0 application with exception handling some exception
handler (the one around main?) is linked along and the minimum
application size is ~ 500 Kb. And my poor chip has only 8Kb.
Wouter
==============================================================================
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 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: goto label inside of if statement
http://groups.google.com/group/comp.lang.c++/t/7c222b0d5330287c?hl=en
==============================================================================
== 1 of 2 ==
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
== 2 of 2 ==
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: 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
==============================================================================
TOPIC: Moving from C++03 to C++11
http://groups.google.com/group/comp.lang.c++/t/4bf001f37864dec0?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Jan 29 2014 12:11 am
From: Saeed Amrollahi
On Sunday, January 26, 2014 4:06:20 PM UTC-8, 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.
>
>
>
> (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
Hi Rhino
I guess the best approach to move from C++03 to C++11 is a mixture
of reading books, watching C++ Videos and writing programs using new compilers
like Visual Studio 2012, GCC 4.9.0 and Clang.
I believe the first and best resource for you is the C++11 FAQ by Bjarne Stroustrup:
http://www.stroustrup.com/C++11FAQ.html
It's freely available. I can't count how much I referred to this link during last 5 years ago!
The 4th edition of The C++ Programming Language by him is thick book
(1200+ pages), but you can read another book by this great man: A Tour of C++:
http://www.stroustrup.com/Tour.html
The following paper is related to issue:
Bjarne Stroustrup: What is C++0x?. CVu. Vol 21, Issues 4 and 5. 2009.
Also, you can read the following 3-parts interview:
Interview with Debasish Jana for The Computer Society of India:
Part 1: Paradigm & Philosophy, June 2011.
Part 2: Evolution of C++ towards C++0x, July 2011.
Part 3: C++0x Technicalities and Intricacies, August 2011.
If you prefer watching video, I strongly recommend the seminars GoingNative 2012, and GoingNative 2013. You can download videos and seminars from There are several seminars by Bjarne Stroustrup, Herb Sutter, Stephen T. Lavavej, Hans Boehm and Sean Parent which address your issue.
Andrew Koenig and Barbara Moo have the following 3-parts papers:
- 4 Useful New Features in C++0x
- 3 Most Useful Library Features of C++0x
- C++0x's Tools for Library Authors
At last, may be the following seminar by me can help you:
http://www.saeedamrollahi.com/edu/C++11-SRTTU.pdf
HTH,
-- Saeed Amrollahi Boyouki
P.S The title of your post is motivating, and I'll try to prepare a seminar
under that.
==============================================================================
TOPIC: illegal void argument
http://groups.google.com/group/comp.lang.c++/t/c039b912fa7c33f7?hl=en
==============================================================================
== 1 of 3 ==
Date: Wed, Jan 29 2014 7:04 am
From: Öö Tiib
In C++ we can have void return type and we can "return" it:
void foo();
void bar()
{
return (void)42; // ok #1
return foo(); // ok #2
}
Fun way to confuse novices indeed. However, it appears that we can not (for
whatever unknown reason) pass void arguments:
void bad()
{
foo((void)42); // illegal
}
Even if I think I will be extra clever and add overload of 'foo' that supposedly
accepts anything ...
void foo(...);
... then I get different failures or successes on different mac/ubuntu clang/gcc
versions. Seems that compilers are confused.
Is there reason why we have such inconsistency?
== 2 of 3 ==
Date: Wed, Jan 29 2014 7:29 am
From: Victor Bazarov
On 1/29/2014 10:04 AM, Öö Tiib wrote:
> In C++ we can have void return type and we can "return" it:
>
> void foo();
>
> void bar()
> {
> return (void)42; // ok #1
> return foo(); // ok #2
> }
>
> Fun way to confuse novices indeed. However, it appears that we can not (for
> whatever unknown reason) pass void arguments:
>
> void bad()
> {
> foo((void)42); // illegal
> }
>
> Even if I think I will be extra clever and add overload of 'foo' that supposedly
> accepts anything ...
>
> void foo(...);
>
> ... then I get different failures or successes on different mac/ubuntu clang/gcc
> versions. Seems that compilers are confused.
>
> Is there reason why we have such inconsistency?
Inconsistency? Returning from a 'void' function by calling another void
function is syntactic sugar. How would you reconcile passing a void
argument with overloading? What about conversions? I am too lazy to
check (with a compiler or the Standard), maybe you know, what would
happen if you do
int someth();
void foo() {
return someth();
}
? Would it be OK? IOW, is it the same as
void foo() {
someth();
return;
}
? If it's OK, then any expression value *can* be converted to 'void'
when used in a 'return' from a 'void' function. Would you allow the
same for any expression converted as a single argument? Or does it have
to be explicit?
And the clincher for me is the question "what problem does it solve?"
The ability to return an expression from a void function was added to
help resolve some template generation problems. And in this case it
seems that the sole purpose is obfuscation...
V
--
I do not respond to top-posted replies, please don't ask
== 3 of 3 ==
Date: Wed, Jan 29 2014 7:31 am
From: "Alf P. Steinbach"
On 29.01.2014 16:04, Öö Tiib wrote:
> In C++ we can have void return type and we can "return" it:
>
> void foo();
>
> void bar()
> {
> return (void)42; // ok #1
> return foo(); // ok #2
> }
>
> Fun way to confuse novices indeed. However, it appears that we can not (for
> whatever unknown reason) pass void arguments:
>
> void bad()
> {
> foo((void)42); // illegal
> }
>
> Even if I think I will be extra clever and add overload of 'foo' that supposedly
> accepts anything ...
>
> void foo(...);
>
> ... then I get different failures or successes on different mac/ubuntu clang/gcc
> versions. Seems that compilers are confused.
>
> Is there reason why we have such inconsistency?
>
`(void)` as a formal argument list doesn't indicate a formal argument of
type `void`. It's just a special syntax from C, where it specifies that
the function really doesn't take *any* arguments, at all.
In C++ the special syntax is unnecessary, since in C++ `()` also says
that, but the special syntax is supported for C compatibility.
Also baffling: why you can create a "void value" via `void()`. I guess
for uniform treatment in template code. But still it's kind of
inconsistent with the basic idea of `void` as an incomplete type.
Cheers & hth.,
- Alf
==============================================================================
TOPIC: Functor with recursive call
http://groups.google.com/group/comp.lang.c++/t/7c8534b6a9ab8b48?hl=en
==============================================================================
== 1 of 4 ==
Date: Wed, Jan 29 2014 8:12 am
From: "A"
I have a functor which looks like this:
struct TLocalRecursiveF
{
void operator()(int *P1, std::vector<TStruct*> &S1)
{
P1++;
S1.push_back(TStruct());
this->operator()(P1, S1);
}
} RecursiveF;
RecursiveF(P0, S0);
Now, ignore for a sec the meaninglessness of this functor. In reality it is
a tree node builder.
It works fine but I am wondering, is this prefered to doing something like
this:
struct TLocal
{
static void RecursFunc(int *P1, std::vector<TStruct*> &S1)
{
P1++;
S1.push_back(TStruct());
RecursFunc(P1, S1);
}
};
TLocal::RecursFunc(P0, S0);
Is one version preferred over another or faster over another?
== 2 of 4 ==
Date: Wed, Jan 29 2014 8:16 am
From: "A"
As I've seen that some use struct variables to simulate parameters, I am
actually asking, is that preferred to the way I passed parameters e.g.
this->operator()(...parameterlist...)
in a recursive part of the call.
== 3 of 4 ==
Date: Wed, Jan 29 2014 8:28 am
From: Victor Bazarov
On 1/29/2014 11:12 AM, A wrote:
> I have a functor which looks like this:
>
> struct TLocalRecursiveF
> {
> void operator()(int *P1, std::vector<TStruct*> &S1)
> {
> P1++;
> S1.push_back(TStruct());
> this->operator()(P1, S1);
> }
> } RecursiveF;
>
> RecursiveF(P0, S0);
>
> Now, ignore for a sec the meaninglessness of this functor. In reality it is
> a tree node builder.
> It works fine but I am wondering, is this prefered to doing something like
> this:
>
> struct TLocal
> {
> static void RecursFunc(int *P1, std::vector<TStruct*> &S1)
> {
> P1++;
> S1.push_back(TStruct());
> RecursFunc(P1, S1);
> }
> };
>
> TLocal::RecursFunc(P0, S0);
>
> Is one version preferred over another or faster over another?
A member function has a hidden argument - the object for which it's
called. If your function has no particular need for the object, making
it 'static' will mean tiny savings in both stack size use during
recursion and performance. Most likely you won't notice it, really. As
always the advice is to measure it before making a decision.
Functors have a very specific trait - they satisfy a requirement to be
"callable", which makes them useful with standard algorithms like
'for_each'. In that sense the alternative to a functor is not a struct
with a static member function, but a stand-alone function. The functor
is really only needed when it has a *state*. A stand-alone function
usually doesn't.
V
--
I do not respond to top-posted replies, please don't ask
== 4 of 4 ==
Date: Wed, Jan 29 2014 8:44 am
From: "Alf P. Steinbach"
On 29.01.2014 17:12, A wrote:
>
> Is one version preferred over another or faster over another?
I would prefer the one that most closely matches the requirements at
hand and is most clear and simple to understand.
The requirements are however not obvious.
If you need local state then a non-static member function might be it,
but I would prefer a named one rather than operator(), unless this
object has to be passed to other code as a functor.
Otherwise the static member function is good.
You might alternatively consider a named namespace level function placed
in e.g. a `detail` namespace.
Or if this is in a (outer) class, just an ordinary but non-public member
function of that class, instead of doing everything locally, even if in
a sense that is like polluting the class scope with the implementation
details of one of its member functions.
A local lambda would run into the problem of expressing the recursion,
which would necessitate either a local struct or accessing an outside
reference to the lambda (e.g. a `std::function` instance), so that would
just be more complication, not less. I think.
Summing up, one of the four first. ;-)
Cheers & hth.,
- Alf
==============================================================================
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