<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Ram usage with ec++</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/25749/ram-usage-with-ec</link><description> 
Hi, 

 
as I understand from this link: www.caravan.net/.../guide.html 
in point D1 it is not possible to put an object in ROM if that object
is from a class that has been derived from another class, even though
everything is const. 

 
Isn&amp;#39;t this a</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: Ram usage with ec++</title><link>https://community.arm.com/thread/103280?ContentTypeID=1</link><pubDate>Wed, 22 Jul 2009 07:21:27 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:c1f41113-d5f7-4c87-a336-2b4643a64bf9</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
How often do you need to override a C++ class, and need objects of
that class to be const?&lt;/p&gt;

&lt;p&gt;
An example would be an abstract &amp;quot;lookup&amp;quot; class overriden by a
class having specific data. The alternative then would be to avoid
the class override and implement the actual functionality directly.
Or call helper functions if you need many lookup classes.&lt;/p&gt;

&lt;p&gt;
In most situations, the needs looks different in an embedded
application than in a PC application. Your const objects are normally
quite simple, so you may not get snagged so often by this.&lt;/p&gt;

&lt;p&gt;
A ring-buffer implemented in C++ is an example of a non-const
object. A CSerial class would normally also be used to create
non-const objects. Same with CTimer objects. In my experience, most
classes that are overriden or having virtual methods, ... are having
member data that makes it impossible to use a const object in the
first place. But that may not be a general case, and more a result of
how I tend to structure my programs.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Ram usage with ec++</title><link>https://community.arm.com/thread/77606?ContentTypeID=1</link><pubDate>Wed, 22 Jul 2009 07:07:03 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:57e59241-68b0-4c7c-aff8-a7c410892c30</guid><dc:creator>Jef Patat</dc:creator><description>&lt;p&gt;&lt;p&gt;
It seems to be true for the current C166 compiler. And as far as I
understand from what I read that&amp;#39;s the official ec++ website.&lt;br /&gt;
Maybe that&amp;#39;s why ec++ is considered &amp;#39;dead&amp;#39; ;-)&lt;br /&gt;
&lt;a href="http://en.wikipedia.org/wiki/Embedded_C%2B%2B"&gt;en.wikipedia.org/.../Embedded_C++&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;
As far as I understand this everything has to go in RAM or you
have to give up every OO principle. That just removes every use for
ec++ in embedded.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Ram usage with ec++</title><link>https://community.arm.com/thread/89883?ContentTypeID=1</link><pubDate>Wed, 22 Jul 2009 06:39:43 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:558b73de-c290-4331-a1cc-632103561c53</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
As Andy notes, I&amp;#39;m not sure if it is true.&lt;/p&gt;

&lt;p&gt;
The important thing is how clever the compiler and linker is at
anaylyzing all potential writes to the object.&lt;/p&gt;

&lt;p&gt;
A user-defined constructor would normally make changes to the
object.&lt;br /&gt;
An inherrited class may call a base class where the constructor does
make changes.&lt;br /&gt;
An object with virtual methods may be overriden by an alternative
implementation that does change fields in the object.&lt;/p&gt;

&lt;p&gt;
The problem here is that the constructors and destructor for an
object are not const, and only if the compiler/linker can prove that
no non-const methods can be called on the object will it be safe to
place the object in ROM.&lt;/p&gt;

&lt;p&gt;
I don&amp;#39;t think there is a standard that forbids placing a const
object in ROM if the tools can prove that it is safe. The general
case is that the compiler can&amp;#39;t.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Ram usage with ec++</title><link>https://community.arm.com/thread/56469?ContentTypeID=1</link><pubDate>Wed, 22 Jul 2009 06:30:28 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:af578583-79a3-459a-b8d0-f4d0384596aa</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
It is dated very early in 1998 - is it still true?&lt;/p&gt;

&lt;p&gt;
Is it true of the actual compiler &amp;amp; version that you&amp;#39;re
using?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>