Expanded or reference - Revision history

Hzwakenberg at 21:06, 1 March 2022

2022-03-01T21:06:33Z

← Older revision		Revision as of 23:06, 1 March 2022
Line 274:		Line 274:
	bar.foo.set_attribute(zoo)		bar.foo.set_attribute(zoo)

−	is in fact ~~equivakent~~ to the following sequence of instructions:	+	is in fact equivalent to the following sequence of instructions:

	temporary_foo := bar.foo -- (1) copy expanded object foo		temporary_foo := bar.foo -- (1) copy expanded object foo

Hzwakenberg: /* Principal characteristics of expanded type expressions */

2016-05-28T18:30:26Z

Principal characteristics of expanded type expressions

← Older revision		Revision as of 20:30, 28 May 2016
Line 118:		Line 118:
	</div>		</div>
	An expanded type [[Glossary#Expression\|expression]] has		An expanded type [[Glossary#Expression\|expression]] has
−	properties which one needs to know.	+	properties which one needs to know about.
	As explained above, the object that corresponds to an		As explained above, the object that corresponds to an
	<tt>expanded</tt> type [[Glossary#Expression\|expression]] cannot be referenced.		<tt>expanded</tt> type [[Glossary#Expression\|expression]] cannot be referenced.

Hzwakenberg: /* Initialisation of expanded type variables */

2016-05-28T18:27:53Z

Initialisation of expanded type variables

← Older revision		Revision as of 20:27, 28 May 2016
Line 161:		Line 161:

	===Initialisation of <tt>expanded</tt> type variables===		===Initialisation of <tt>expanded</tt> type variables===
−	Variables whose type is <tt>expanded</tt> are ~~also~~ initialised automatically.	+	Variables whose type is <tt>expanded</tt> are initialised automatically.
	For certain truly basic <tt>expanded</tt> types, the initialisation is done directly by the compiler.		For certain truly basic <tt>expanded</tt> types, the initialisation is done directly by the compiler.
	After presenting all these special cases, we will deal with the general case of an <tt>expanded</tt> class.		After presenting all these special cases, we will deal with the general case of an <tt>expanded</tt> class.

Hzwakenberg: /* Some advice before you write an expanded class */

2016-05-28T18:25:32Z

Some advice before you write an expanded class

← Older revision		Revision as of 20:25, 28 May 2016
Line 208:		Line 208:
	and this applies to the great majority of applications.		and this applies to the great majority of applications.
	As we have explained above, the principal use of <tt>expanded</tt> classes is to make it possible to integrate the most basic objects into the object model.		As we have explained above, the principal use of <tt>expanded</tt> classes is to make it possible to integrate the most basic objects into the object model.
−	Having said that, it can perhaps be useful to resort to an <tt>expanded</tt> class, ~~whether~~ to ~~make available a~~ [[#RoutineTank\|group of utility routines]], or to economise on memory in the special case when a [[#ManySmallObjects\|large number of small objects]] is used.	+	Having said that, it can perhaps be useful to resort to an <tt>expanded</tt> class, either to [[#RoutineTank\|group utility routines]], or to economise on memory in the special case when a [[#ManySmallObjects\|large number of small objects]] is used.
	Finally, we will present the [[#ExpandedPitfalls\|traps to avoid]] when designing an <tt>expanded</tt> class.		Finally, we will present the [[#ExpandedPitfalls\|traps to avoid]] when designing an <tt>expanded</tt> class.

Hzwakenberg: /* Traps to avoid with expanded classes */

2016-05-28T18:19:31Z

Traps to avoid with expanded classes

← Older revision		Revision as of 20:19, 28 May 2016
Line 262:		Line 262:
	===Traps to avoid with <tt>expanded</tt> classes===		===Traps to avoid with <tt>expanded</tt> classes===
	</div>		</div>
−	The first trap to avoid ~~is to do with~~ classes with many attributes.	+	The first trap to avoid concerns classes with many attributes.
	When an <tt>expanded</tt> object is very big, passing this object as a parameter to a [[Glossary#Routine\|routine]] can turn out to be much more expensive than with an ordinary object.		When an <tt>expanded</tt> object is very big, passing this object as a parameter to a [[Glossary#Routine\|routine]] can turn out to be much more expensive than with an ordinary object.
	Indeed, for an ordinary object, only its memory address is copied onto the stack.		Indeed, for an ordinary object, only its memory address is copied onto the stack.
Line 270:		Line 270:

	The second trap to avoid is much more dangerous, because it does not only risk slowing down the application's execution.		The second trap to avoid is much more dangerous, because it does not only risk slowing down the application's execution.
−	This trap is to do with the mistaken interpretation that one can give to a modifying procedure call applied to an <tt>expanded</tt> object obtained by means of an indirect reading of an attribute:	+	This trap has to do with the mistaken interpretation that one can give to a modifying procedure call applied to an <tt>expanded</tt> object obtained by means of an indirect reading of an attribute:

	bar.foo.set_attribute(zoo)		bar.foo.set_attribute(zoo)
Line 305:		Line 305:
	[[library_class:REAL_EXTENDED\|<tt>REAL_EXTENDED</tt>]] and		[[library_class:REAL_EXTENDED\|<tt>REAL_EXTENDED</tt>]] and
	[[library_class:POINTER\|<tt>POINTER</tt>]].		[[library_class:POINTER\|<tt>POINTER</tt>]].
−	~~So long as~~ the compiler ~~is unable to~~ warn you of this possible problem, be careful when you use <tt>expanded</tt> classes.	+	Until the compiler can warn you of this possible problem, be careful when you use <tt>expanded</tt> classes.

Ramack at 21:14, 20 March 2013

2013-03-20T21:14:22Z

← Older revision		Revision as of 23:14, 20 March 2013
Line 32:		Line 32:
	[[Syntax diagrams#ClassDeclaration\|<tt>expanded</tt>]].		[[Syntax diagrams#ClassDeclaration\|<tt>expanded</tt>]].
	In Eiffel jargon, when we speak of an <tt>expanded</tt> class,		In Eiffel jargon, when we speak of an <tt>expanded</tt> class,
−	we are talking about a class whose objects are handled without an intermediate pointer, objects that are directly written, or ''expanded'', onto the memory area that they use.	+	we are talking about a class whose objects are handled without an intermediate pointer, objects that are directly written, or ''expanded'', onto the memory area that they use I. e. they are passed by value.
	In contrast, if we talk of a ''reference class'' or of a ''reference type'', it is to emphasise that the objects in question are not <tt>expanded</tt>.		In contrast, if we talk of a ''reference class'' or of a ''reference type'', it is to emphasise that the objects in question are not <tt>expanded</tt>.

Ramack at 21:13, 20 March 2013

2013-03-20T21:13:26Z

← Older revision		Revision as of 23:13, 20 March 2013
Line 1:		Line 1:
−	[[Category:Smarteiffel]]
	In our opinion, it is essential to have a good understanding of how objects are represented in memory while an application is running.		In our opinion, it is essential to have a good understanding of how objects are represented in memory while an application is running.
	The aim is not to make every one of us an expert in the subject, but		The aim is not to make every one of us an expert in the subject, but
Line 33:		Line 32:
	[[Syntax diagrams#ClassDeclaration\|<tt>expanded</tt>]].		[[Syntax diagrams#ClassDeclaration\|<tt>expanded</tt>]].
	In Eiffel jargon, when we speak of an <tt>expanded</tt> class,		In Eiffel jargon, when we speak of an <tt>expanded</tt> class,
−	we are talking about a class whose objects are handled without an intermediate pointer, objects that are directly written, or ''expanded'', onto the memory area that they use ~~I. e. they are passed by value~~.	+	we are talking about a class whose objects are handled without an intermediate pointer, objects that are directly written, or ''expanded'', onto the memory area that they use.
	In contrast, if we talk of a ''reference class'' or of a ''reference type'', it is to emphasise that the objects in question are not <tt>expanded</tt>.		In contrast, if we talk of a ''reference class'' or of a ''reference type'', it is to emphasise that the objects in question are not <tt>expanded</tt>.

Ramack: /* Expanded or reference objects, the choice */

2013-03-20T21:13:16Z

Expanded or reference objects, the choice

← Older revision		Revision as of 23:13, 20 March 2013
Line 33:		Line 33:
	[[Syntax diagrams#ClassDeclaration\|<tt>expanded</tt>]].		[[Syntax diagrams#ClassDeclaration\|<tt>expanded</tt>]].
	In Eiffel jargon, when we speak of an <tt>expanded</tt> class,		In Eiffel jargon, when we speak of an <tt>expanded</tt> class,
−	we are talking about a class whose objects are handled without an intermediate pointer, objects that are directly written, or ''expanded'', onto the memory area that they use.	+	we are talking about a class whose objects are handled without an intermediate pointer, objects that are directly written, or ''expanded'', onto the memory area that they use I. e. they are passed by value.
	In contrast, if we talk of a ''reference class'' or of a ''reference type'', it is to emphasise that the objects in question are not <tt>expanded</tt>.		In contrast, if we talk of a ''reference class'' or of a ''reference type'', it is to emphasise that the objects in question are not <tt>expanded</tt>.

Ramack: /* Initialisation of expanded type variables */ added NATRUAL

2013-03-20T20:57:13Z

Initialisation of expanded type variables: added NATRUAL

← Older revision		Revision as of 22:57, 20 March 2013
Line 172:		Line 172:
	[[library_class:INTEGER\|<tt>INTEGER</tt>]],		[[library_class:INTEGER\|<tt>INTEGER</tt>]],
	[[library_class:INTEGER_64\|<tt>INTEGER_64</tt>]]<tt>}</tt>,		[[library_class:INTEGER_64\|<tt>INTEGER_64</tt>]]<tt>}</tt>,
		+	or <tt>NATURAL</tt>s <tt>{</tt>[[library_class:NATURAL_8\|<tt>NATURAL_8</tt>]],
		+	[[library_class:NATURAL_16\|<tt>NATURAL_16</tt>]],
		+	[[library_class:NATURAL_32\|<tt>NATURAL_32</tt>]],
		+	[[library_class:NATURAL\|<tt>NATURAL</tt>]],
		+	[[library_class:NATURAL_64\|<tt>NATURAL_64</tt>]]<tt>}</tt>
	the object used to initialise them corresponds to the value <tt>0</tt>.		the object used to initialise them corresponds to the value <tt>0</tt>.

Ramack at 21:14, 4 March 2013

2013-03-04T21:14:20Z

← Older revision		Revision as of 23:14, 4 March 2013
Line 1:		Line 1:
−	[[Category:~~Book~~]]	+	[[Category:Smarteiffel]]
	In our opinion, it is essential to have a good understanding of how objects are represented in memory while an application is running.		In our opinion, it is essential to have a good understanding of how objects are represented in memory while an application is running.
	The aim is not to make every one of us an expert in the subject, but		The aim is not to make every one of us an expert in the subject, but

← Older revision		Revision as of 22:57, 20 March 2013
Line 172:		Line 172:
	[[library_class:INTEGER\|<tt>INTEGER</tt>]],		[[library_class:INTEGER\|<tt>INTEGER</tt>]],
	[[library_class:INTEGER_64\|<tt>INTEGER_64</tt>]]<tt>}</tt>,		[[library_class:INTEGER_64\|<tt>INTEGER_64</tt>]]<tt>}</tt>,
		+	or <tt>NATURAL</tt>s <tt>{</tt>[[library_class:NATURAL_8\|<tt>NATURAL_8</tt>]],
		+	[[library_class:NATURAL_16\|<tt>NATURAL_16</tt>]],
		+	[[library_class:NATURAL_32\|<tt>NATURAL_32</tt>]],
		+	[[library_class:NATURAL\|<tt>NATURAL</tt>]],
		+	[[library_class:NATURAL_64\|<tt>NATURAL_64</tt>]]<tt>}</tt>
	the object used to initialise them corresponds to the value <tt>0</tt>.		the object used to initialise them corresponds to the value <tt>0</tt>.