Sameer Patil wrote:
> hello,
>    This time for my project i decided to use C++....i  am using
> LPC2148....i am having terrible problems with ISRs...i am unable to
> access Class members inside the ISR,the controller simply hangs....also
> my main.cpp contains a while(1) loop inside which i hv to do routine
> work...Now can G++ handle ISR and complicated loopings? i mean a have

I think we put our ISR static to get it work.

Jonathan

G++ is a fully functioning and capable C++ compiler, and the code you
describe is hardly complex. I wonder why your first reaction is to
suspect the compiler which has had many thousands of programmer hours
applied to it over several years, and is used in hundreds of large and
complex mission critical applications everyday, rather than suspecting
your tiny piece of code that you have just written and never yet tested.
It is far more likely to be a flaw in your code or your system/runtime
initialisation. We'd have to see all your code to determine the problem.

There are of course certain things that you must avoid in ISR, bearing
in mind that you cannot use anything that will block on a lower priority
level interrupt, or usually anything with significant stack requirement,
since the IRQ processor mode is typically allocated a relatively small
stack. Functions such as printf() for example will not normally work in
interrupt contexts, and most of the C++ standard library should be
avoided in any case.

C++ has slightly more comples runtime startup requirements than C, in
your startup, there must be code that invokes static constructors so
that the constructors of any global or statically allocated objects are
called.

Clifford

Clifford Slocombe wrote:
> G++ is a fully functioning and capable C++ compiler, and the code you
> describe is hardly complex. I wonder why your first reaction is to
> suspect the compiler which has had many thousands of programmer hours
> applied to it over several years, and is used in hundreds of large and
> complex mission critical applications everyday, rather than suspecting
> your tiny piece of code that you have just written and never yet tested.
> It is far more likely to be a flaw in your code or your system/runtime
> initialisation. We'd have to see all your code to determine the problem.
>
> There are of course certain things that you must avoid in ISR, bearing
> in mind that you cannot use anything that will block on a lower priority
> level interrupt, or usually anything with significant stack requirement,
> since the IRQ processor mode is typically allocated a relatively small
> stack. Functions such as printf() for example will not normally work in
> interrupt contexts, and most of the C++ standard library should be
> avoided in any case.
>
> C++ has slightly more comples runtime startup requirements than C, in
> your startup, there must be code that invokes static constructors so
> that the constructors of any global or statically allocated objects are
> called.
>
> Clifford

hello everybody....
  Firstly i appologise for my words that i said about G++. I know that
it is certainly a very capable compiler but i only had doubt as to how
would it perform on typical embedded systems with such limited
resources.....and as far as my code goes....there may be lot many other
factors as this is the first time ever I am using C++ for
embedded.....you just mentioned about startup....i will certainly make
those changes and will write back shortly about the results.......Thank
you all for the help......

Sameer

Sameer Patil wrote:
> i only had doubt as to how
> would it perform on typical embedded systems with such limited
> resources...

In C++ you only pay for what you use over and above C. That is to say
that if you write essentially C code but compile it as C++ there should
be little or no overhead compared with C++ (with the exception of static
initialisation).

Much of C++ such as the bool data type, function overloading, and basic
classes come at little or no overhead. The compiler's stronger type
checking also comes entirely free of any code overhead.

Virtual functions and multiple inheritance carry some overhead. Be
cautious using dynamic memory allocation - this is generally true in any
language in embedded systems, but in C++ the new operator not only
allocates memory, but also invokes the constructor for every object
instantiated, and conversely calls the destructor on deletion. Using the
standard memory manager, such operations are non-deterministic. Standard
library classes such as std::string and all of the STL use dynamic
memory allocation extensively and should be used with caution or not at
all. <iostream> is also large and probably requires as much if not more
memory that the C stdio library.



Clifford

Clifford Slocombe wrote:
> Sameer Patil wrote:
>> i only had doubt as to how
>> would it perform on typical embedded systems with such limited
>> resources...
>
> In C++ you only pay for what you use over and above C. That is to say
> that if you write essentially C code but compile it as C++ there should
> be little or no overhead compared with C++ (with the exception of static
> initialisation).
>
> Much of C++ such as the bool data type, function overloading, and basic
> classes come at little or no overhead. The compiler's stronger type
> checking also comes entirely free of any code overhead.
>
> Virtual functions and multiple inheritance carry some overhead. Be
> cautious using dynamic memory allocation - this is generally true in any
> language in embedded systems, but in C++ the new operator not only
> allocates memory, but also invokes the constructor for every object
> instantiated, and conversely calls the destructor on deletion. Using the
> standard memory manager, such operations are non-deterministic. Standard
> library classes such as std::string and all of the STL use dynamic
> memory allocation extensively and should be used with caution or not at
> all. <iostream> is also large and probably requires as much if not more
> memory that the C stdio library.
>
>
>
> Clifford


ohh.....again thanks a lot! its been a really good learning "session"
for me as i am totally new to using C++ for embedded....a lot of things
just got clear for me.......again thanks a lot!

Sameer.

Sameer Patil wrote:
> its been a really good learning "session"
> for me as i am totally new to using C++ for embedded

You shoild take a look at www.embedded.com, there are many articles on
C++ in embedded systems, for starters this two part article:

http://www.embedded.com/columns/technicalinsights/207200004
http://www.embedded.com/columns/technicalinsights/207200275

And here is a far more complete treatment than mine of the costs and
overheads of various C++ features:
http://www.embedded.com/98/9802fe3.htm

Clifford

Clifford Slocombe wrote:
> Sameer Patil wrote:
>> its been a really good learning "session"
>> for me as i am totally new to using C++ for embedded
>
> You shoild take a look at www.embedded.com, there are many articles on
> C++ in embedded systems, for starters this two part article:
>
> http://www.embedded.com/columns/technicalinsights/207200004
> http://www.embedded.com/columns/technicalinsights/207200275
>
> And here is a far more complete treatment than mine of the costs and
> overheads of various C++ features:
> http://www.embedded.com/98/9802fe3.htm
>
> Clifford

Well, again thanks A LOT!