🚀 go-pugleaf

In article <RMARTIN.96Apr16161415@rcm.oma.com> rmartin@oma.com (Robert C.  
Martin) writes:
> In article <4kjfrh$28g@Starbase.NeoSoft.COM> timd@Starbase.NeoSoft.COM (Tim  
Dugan) writes:
> 
>    Although I have no figures or measurements, I would have to say
>    that I suspect that the one area where C++ is slower is that
>    there is something about C++ that encourages programmers to
>    perform a great deal more allocation and de-allocation of 
>    memory, causing memory fragmentation and slowing the allocation/
>    deallocation process.  
> 
> There is nothing about C++ that encourages programmers to perform
> a great deal more allocation and de-allocation of memory.  Some
> popular styles advocate this, but they advocate it in C++ as well as
> other languages.  
> 

Agreed. C++ is not the only language that advocates dynamic allocation
and deallocation.

Polymorphism is one of the major characteristics of object-oriented
programming. By declaring a variable

	in name "x" of class "C"

we can expect that "x" take of value of a subclass of "C". To get
this polymorphism, you have to use dynamic memory allocation for
"x". In C++, you use pointers. In Java or Eiffel, you use smart
references.

Transframe is language originally designed for, but not limited to,
embedded/real-time systems. The language does not advocate using
dynamic references when they are not necessary. Even with static
allocation, you can still get polymorphism, as long as the maximum
size of the subclass value is known. For example, you can statcally
allocate the storage for a polymorphic character variable which can
take an ANSI character, an Unicode character, or a variable-length
character.

Sometimes you might be required to dynamically allocate an object
in large grain, but within the large piece of strage, you may not
wnat to fragment the memoery into many small pieces.

Back to Roman Fietze's example:

> In my special case I built a menu system based on an own curses
> implementation on pSOS. With the old C version I passed pointers to some
> structures to the menu library functions. In the C++ version I build a
> menu by adding menu items to a menu object, which causes many memory
> copy, allocation and deallocation calls (not to give the CPU any chance
> I even used a String class instead of char *'s). The other drawback is
> that with the old system I could hold the text for the menu text in ROM
> only (by declaring it const), but with C++ I have to copy it using e.g.
> the operator+= or some constructor, and even the type specifier const
> isn't a guarantee for beeing allocated in a readonly memory (ROM on
> embedded systems, readonly sections e.g. on UNIX), it just says, the
> variable cann only be initialized, but not changed by an assignement
> operator.

If your system want to created new windows dynamically, you might need
to allocate window structures dynamically. But within the window, if
you do not want the window have function of dynamic configuration, e.g.
adding/deleting menu items and other child windows, then, you can allocate
everything statically by writing the following code:

object myWindow is FramedToplevelWindow
{
     object myMemu is Menu
     {
	object fileItem is PullDownMenu
	{
	    string = "File";
	    object openItem is MenuItemString
	    {
		string = "Open...\tCtrl+O";
	    };
	    object saveItem is MenuItemString
	    {
		style = (Disabled);
		string = "Save...\tCtrl+s";
	    };
	};
	object editItem is PullDownMenu
	{
	    object copyItem is MenuItemIcon
	    {
		style = (Disabled);
		icon = icon_Copy;
	    };
	    object pasteItem is MenuItemIcon
	    {
		style = (Disabled);
		icon = icon_Paste;
	    };
	    object sp1 is MenuItemSeparator
	};
	...
      };
};

However, if you do wish to configue the menu items dynamically,
for example, you may want a "recall" pull-down menu under the
"file" menu-item to list all the files opened previously in
history, then, you need to design your windows in a dyamaic
structure in which children are allocated dynamically.

For many small handout devices, I belive that the user interface
is fixed, and dynamic configuration in the final released product
is not necessary. Though in the development environment (for virtual
products), Transframe enables dynamic configruation for rapid
prototyping.

For large and complex desktop applications, the window structure
should be dynamic.

It is the decision of application, not the decision of a language,
that whether dyamaic structure should be used. Therefore, a language
should provide options that an application can choose.

David Shang