eiffelroom

Formal Generics in ROUTINE, PROCEDURE, FUNCTION and PREDICATE

helmut.brandl — Tue, 02 Mar 2010 23:18:22 +0000

There are 4 deferred classes defined in ELKS to represent agents

  ROUTINE  [BASE_TYPE, OPEN_ARGS->TUPLE]
  PROCEDURE[BASE_TYPE, OPEN_ARGS->TUPLE]   
  FUNCTION [BASE_TYPE, OPEN_ARGS->TUPLE, RESULT_TYPE]
  PREDICATE[BASE_TYPE, OPEN_ARGS->TUPLE]

The OPEN_ARGS is tuple to represent the tuple of arguments which need to be provided at call time. In case of FUNCTION, RESULT_TYPE is the type of the result returned by the query.

The first formal generic BASE_TYPE seems to be completely unnecessary. Clearly, each agent represents a feature of a certain type. But that type is not needed in the abstraction.

All routines in the standard library, which expect an agent as argument use as BASE_TYE the universal type ANY.

It is difficult to imagine that it makes sense to restrict the base type of an agent to be a descendant of a certain other type. The feature expecting a procedure or function as argument should work with any procedure/function which has a compatible signature. The only thing it does is call it.

Wouldn't it be more consisten to remove the formal generic BASE_TYPE from the above abstractions?

Ephemeral classes

manus_eiffel — Fri, 26 Feb 2010 22:21:01 +0000

I've recently been toying with the idea of ephemeral classes. An ephemeral class is a class which does not have attributes. The immediate benefits of such classes is that their features can be used for objectless calls, the same way we can access constants or external features. For those not familiar to Eiffel, the features of ephemeral classes can be seen as static methods.

For example:

ephemeral class A
feature
	objectless_feature do ... end
end
 
class TEST
feature
	g
		do
			{A}.objectless_feature
		end
end

Another benefit of such classes is that their features can be directly used for callbacks by some external C/C++ code without having the need for creating a C wrapper for calling back the Eiffel code.

The concept is not yet implemented in EiffelStudio as it is not just a matter of checking the absence of attributes but also to adapt the code generation not to rely on a Current object.

This is something that will most likely be submitted for adoption for the ECMA Eiffel language specification. But before that, I'd like to hear what you think about this!

Happy Eiffeling,

Manu

Storable and versioning

manus_eiffel — Tue, 16 Feb 2010 01:52:32 +0000

Introduction

Originally Eiffel Software's object serialization was written in C and was proposing the following alternative:

basic: the same version of the executable on a particular platform can store and retrieve objects.
general: different versions of the executable on a particular platform can store and retrieve objects.
independent: different versions of the executable running on different platforms can store and retrieve objects.

Initially you could only retrieve an object if and only if the storing and retrieving system where exactly the same (i.e. same number of attributes and same types for all of them). A couple of years ago, we added to the independent version a mechanism to fix mismatches (i.e. object of the same type but the type had its number of attributes changed, or the type of attributes have changed). The mechanism is known as correct_mismatch and you can benefit from it by redefining the correct_mismatch routine from MISMATCH_CORRECTOR whenever you change the content of a class.

Unfortunately this code was written in C and was not much compatible with object layouts in .NET. This is what prompted us to write a pure Eiffel version of our C storable mechanism. This mechanism is known as SED (SErialization-Deserialization). Thanks to SED, one could serialize objects from and to .NET as long as they had the same content. Contrary to the C version, SED is proposing the following alternatives:

session: the same running version of the executable can store and retrieve objects
basic: same as the C version
independent: same as the C version

What is missing is the general alternative which was deemed useless over the years as independent made more sense, especially with the extended facility such as correct_mismatch.

However SED has some limitations:

it cannot handle properly user defined expanded types.
it does not implement correct_mismatch

For the 6.6 release, we hope to solve the first limitation.

Versioning

Is correct_mismatch the best way to solve mismatch? Not quite because even if you have the same number and same kind of attributes there could be a mismatch. An example is in the ELKS class HASH_TABLE where from one implementation to the next of HASH_TABLE we decided that the deleted_marks array should have one more entry. To solve that problem, we forced a mismatch by adding a fake attribute to HASH_TABLE which in turn would trigger a mismatch. But this solution was really a workaround and the penalty is that fake added attribute.

For 6.6, we are planning on adding a storable_version note clause to a class that will be used upon retrieval to find out if there is a mismatch or not. The content of storable_version would be user defined and will be used by the storable mechanism to perform a quick check upon retrieval. If they are different then we trigger a mismatch, otherwise we proceed like today.

Currently the storable_version value is not inherited, so if you had an attribute to an ancestor class, you would need to change all its descendants.

Feel free to comment for discussing this further

Happy Eiffeling,

Manu

Transient attributes

manus_eiffel — Sat, 13 Feb 2010 01:33:50 +0000

I'm not sure if this feature was noticed by many so I figured out I would write an entry on the matter. Starting with 6.5 we have added the notion of transient attribute to our runtime. Transient attributes are not stored to disk and thus their absence in the storable file means that they can safely be ignored upon retrieval.

It can be useful in many scenarios. The most common one is the case of once per object implemented using an attribute and used as a caching mechanism. Since the value can easily be recomputed, you do not want to store the computed value to disk.

How it works, simply declare an attribute with a special note clause:

transient_attribute: detachable STRING note option: transient end

In 6.5, the support for transient only works with the C storable mechanism. In our forthcoming 6.6 release, it will also work with the Eiffel storable mechanism (a.k.a. SED) on both classic and .NET. It even works on .NET when using the .NET serialization library (to this purpose we are using the Microsoft .NET NonSerializedAttribute custom attribute on Eiffel generated attributes.) In addition in 6.6, INTERNAL has been augmented with queries to find out how many persistent fields they are in a type as well as finding out if a field is transient or not.

When can you use a transient attribute? Not all the time as you can see below with the validity rule as implemented in EiffelStudio. An attribute a of type T which is marked transient is valid if and only if it satisfies the following conditions:

if T is a reference type, T must be detachable
T is not a formal generic parameter
T is not a user defined expanded type
a is not an attribute of a user defined expanded class

The second is a direct consequence of #1. The last two are a limitation of the current implementation of storing/retrieving expanded types in the Eiffel Software runtime.

Happy Eiffeling,

Manu

Stumbling across errors in language design

nenieorg — Mon, 08 Feb 2010 17:49:04 +0000

The recently floated proposal to add the `across' looping construct to Eiffel seems seriously mistaken. I will go through the reasons that make it undesirable for me, and as a bonus end with a general theory of why such proposals occur.

Contents

1 What happened to the minimalism principle?
2 Not an everyday construct
3 Core language constructs shouldn't depend on libraries
4 Eiffel is verbose on purpose
5 A bad take at a known construct
6 Going past the Good Idea Entropy Axiom

What happened to the minimalism principle?

Eiffel used to have one good way of doing each thing, for clarity and homogeneity and common understanding in the context of team work, and it’s well worth the modest cost of the odd slightly painful border cases. We now have not one but 3 constructs: legacy loops, which I’ll call neanderthal loops in the rest of this post; across loops, let’s call them neo-neanderthal loops; and agent-based iterators, the one you use in modern Eiffel.

Not an everyday construct

The new construct is being justified by saying that loops in their most general form are an everyday programming construct. In fact, loops in regular programming are all from a very small family of very regular loops, usually on containers or similar like INTEGER_INTERVAL, that are very well captured by iteration agents (do_all and friends). A full time Eiffel programmer would probably need to write an explicit loop once a year or less. The very rare cases I meet where I have to write a neanderthal loop is because of omissions in libraries who sometimes miss some obvious looping construct (almost always general enough, I’m not advocating adding convoluted iteration routines to containers that apply only to one case specifically). Lazy readers might think “but I write loops all the time”, but if they look at all the loops you’ve written, and think how it could be replaced with an iteration agent, they will find there are very few cases that require an explicit loop. Neanderthal-loop fans often tell me that some loops can’t be written with a generic agent iterator but when I ask them to show me an example all they can find is examples of where they were being lazy or used a sadly incomplete library (I don’t think anyone who promised me an example ever delivered a credible one, though I’m not saying a few cases don’t exist, they’re just very rare).

The great advantage of using agent-based iterators is that their behaviour (termination etc) is much easier to reason about, by hand or machine. If your system has a handful of generic loops (in the implementation of the container library) it’s much easier to reason about instances of such loops once you’ve proven and modelled the core library routines' behaviour.

Core language constructs shouldn't depend on libraries

The use of a keyword for library syntactic sugar is upside down. Core language constructs should have minimal dependencies if any at all on upper level libraries in general, and on individual routine/classes fairly down the abstraction chain at that. What next, syntactic sugar for log routines?

This gratuitous syntactic sugar also pollutes the keywords namespace, which ideally should be kept small and manageable, and certainly not used for superfluous constructs that are well dealt with by the core language.

Eiffel is verbose on purpose

The verbosity argument is so anti-Eiffel as well, Eiffel is about clarity not about line count. If we’re going that way we could as well go punctuation {*o:i|print(i)*}. With a bit of effort the gold standard of syntax mediocrity, perl, could be within our reach!

The verbosity comparison between fully expanded neanderthal loops and compact neo-neanderthal variants in the proposal are disingenuous at best, the fair comparison would be to present neanderthal loops like this:

  from c := list.new_cursor until c.after loop
    print (c.item)
    c.forth
   end

which is a style both used by leading practitioners and the one consistent with the style of the neo-neanderthal examples. This reduces the line count "advantage" to hardly anything.

A bad take at a known construct

If I was trying to add a loop construct of that genre, I’d hide the cursor totally and do something like:

  across container as item loop
    print (item) 
  end

which is what other languages with neo-neanderthal looping constructs do, for a good reason. We don’t need to be gratuitously worse than the common practice for the sake of originality.

The construct above could be generalised to the hash table case with something like ‘across table with item, key loop’ — were it not anyway totally superfluous given that do_all_with_key does it much better (the only reason it’s not in HASH_TABLE is that as far as I know the maintainer got arrested for earlier crimes against software quality — the class is a crime hotspot — so the class has been unmaintained since the lengthy court martial proceedings started). Low-crime hash table classes like the one in Gobo are well equipped.

Going past the Good Idea Entropy Axiom

To finish I’ll expose my theory why this proposal happened.

One of the fundamental laws of the universe is the Good Idea Entropy Axiom, which reads:

– The aggregate quality of ideas available in the universe must never increase.

and I think that Bertrand has taken this theorem individually and, to compensate for the recently introduced and excellent theory of aliasing, has had to introduce neo-neanderthal loops so that his net contribution to the world of ideas is not positive. But the universe is full of people who produce more than their fair shares of bad ideas, so to each to their ability: I urge Bertrand leave to others the jobs of creating junk language proposals and keeps to the supply of good ideas.

Eiffelroom migrated from drupal5 to drupal6

Jocelyn Fiat — Thu, 28 Jan 2010 14:47:37 +0000

Hi Eiffelroom users,

You might not have noticed, but eiffelroom.org (or .com) is now running on drupal6 (before it was drupal5). . We tried to do the best migration as possible, however if you notice any regression/bug, please let us know using the contact page. The content text format is now using the same engine as mediawiki, that is to say wikitext syntax.

There is tiny difference with previous version of eiffelroom.

So from now, please:

use [[path:blog/someone/a_post| the post title]] instead of using the absolute url [http://www.eiffelroom.com/blog/someone/a_post the post title]
to display image, either use the [[Image:My Image Title]] , or use its absolute url to display them such as http://eiffel.com/images/eiffel08/design-by-contract.gif which will be transform as the associated image.
Please visit A picture says more than thousand words for more information, and even the Mediawiki syntax for image.
to link to eiffelstudio's pages on origo , you can do for instance[[eiffelstudio-origo:download/1540|Download 6.5 release]]
note this is possible to add other interwiki mappings, so if you are missing an important one, please suggest it.
If you feel like eiffelroom is missing an essential feature, please feel free to suggest it.

And now you can really use your http://support.eiffel.com/ account login/password to log into eiffelroom (before it was working as long as you didn't change your password on the support site).

Enjoy Eiffelroom

Working on UTF-8 Eiffel parser

ted_eiffel — Thu, 28 Jan 2010 07:25:07 +0000

I am so excited that I can really push ISE Eiffel compiler to support full Unicode. 6.6 should be the first version to support it.

The first thing I do is parsing UTF-8 source code.

Creating a .NET delegate object from an Eiffel routine

manus_eiffel — Fri, 15 Jan 2010 22:15:42 +0000

Short Description:

This tutorial will show you how to create a .NET delegate from an Eiffel routine

Someone recently asked me how to create a .NET delegate from an Eiffel routine. Ideally it would be nice to simply do:

	my_delegate := (agent my_routine).to_delegate

where `to_delegate' is a query from the ROUTINE class. However this feature does not yet exist. Instead I've devised a simple way to create a delegate given a routine name of the Current class:

	my_delegate := new_delegate ("my_routine")

Where new_delegate is defined as:

	new_delegate (a_name: STRING): DELEGATE
			-- Using `a_name' routine from the current class creates its corresponding
			-- .NET delegate if found, Void otherwise.
		require
			a_name_not_void: a_name /= Void
		local
			l_obj: SYSTEM_OBJECT
			l_method_info: METHOD_INFO
			l_params: NATIVE_ARRAY [SYSTEM_TYPE]
			l_delegate_type: SYSTEM_TYPE
			i, nb: INTEGER
		do
			l_obj := Current
				-- Obtain the associated MethodInfo for routine `a_name' from Current.
				-- Use the Eiffel name first and if we cannot find it, then the PascalCase version
				-- of the name (This is an EiffelStudio project settings for .NET code generation).
			l_method_info := l_obj.get_type.get_method (a_name)
			if l_method_info = Void then
				l_method_info := l_obj.get_type.get_method (pascal_case (a_name))
			end
 
				-- If not MethodInfo was found, the name was incorrect and we simply return Void.
			if l_method_info /= Void then
				if attached l_method_info.get_parameters as l_infos then
					from
						i := 0
						nb := l_infos.count
						create l_params.make (nb + 1)
					until
						i = nb
					loop
						l_params.put (i + 1, l_infos.item (i).parameter_type)
						i := i + 1
					end
				end
					-- Always the type of Current as first argument
					-- (Eiffel always generates instance methods).
				l_params.put (0, l_obj.get_type)
				l_delegate_type := new_delegate_type (l_method_info.return_type, l_params)
				if l_delegate_type /= Void then
					Result := {DELEGATE}.create_delegate (l_delegate_type, l_method_info, True)
				end
			end
		end
 
	new_delegate_type (a_return_type: SYSTEM_TYPE; a_parameters: NATIVE_ARRAY [SYSTEM_TYPE]): SYSTEM_TYPE
		local
			l_name: ASSEMBLY_NAME
			l_assembly: ASSEMBLY_BUILDER
			l_module: MODULE_BUILDER
			l_type: TYPE_BUILDER
			l_constructor: CONSTRUCTOR_BUILDER
			l_invoke: METHOD_BUILDER
		do
				-- Creating the assembly holding the delegate type
			create l_name.make ("DelegateDynamicAssembly" + counter.item.out)
 
			l_assembly := {APP_DOMAIN}.current_domain.define_dynamic_assembly (l_name,
				{ASSEMBLY_BUILDER_ACCESS}.run_and_save)
 
			l_module := l_assembly.define_dynamic_module (l_name.name,
				{SYSTEM_STRING}.concat (l_name.name, dll_extension))
 
				-- Creating the delegate type
			l_type := l_module.define_type ("Delegate" + counter.item.out,
				{TYPE_ATTRIBUTES}.Public | {TYPE_ATTRIBUTES}.sealed | {TYPE_ATTRIBUTES}.ansi_class |
					{TYPE_ATTRIBUTES}.auto_class,
				{MULTICAST_DELEGATE})
 
				-- Creating the .ctor
			l_constructor := l_type.define_constructor (
				{METHOD_ATTRIBUTES}.public | {METHOD_ATTRIBUTES}.special_name |
					{METHOD_ATTRIBUTES}.rt_special_name | {METHOD_ATTRIBUTES}.hide_by_sig,
				{CALLING_CONVENTIONS}.standard, << ({SYSTEM_OBJECT}).to_cil, ({POINTER}).to_cil >> )
 
			l_constructor.set_implementation_flags ({METHOD_IMPL_ATTRIBUTES}.runtime |
				{METHOD_IMPL_ATTRIBUTES}.managed)
 
				-- Create `invoke'
			l_invoke := l_type.define_method ("Invoke",
				{METHOD_ATTRIBUTES}.public | {METHOD_ATTRIBUTES}.hide_by_sig | 
					{METHOD_ATTRIBUTES}.new_slot | {METHOD_ATTRIBUTES}.virtual,
				{CALLING_CONVENTIONS}.standard,
				a_return_type, a_parameters)
 
			l_invoke.set_implementation_flags ({METHOD_IMPL_ATTRIBUTES}.runtime | 
				{METHOD_IMPL_ATTRIBUTES}.managed)
 
			Result := l_type.create_type
			l_assembly.save ({SYSTEM_STRING}.concat (l_name.name, dll_extension))
 
				-- Increment our counter
			counter.put (counter.item + 1)
		end
 
	dll_extension: SYSTEM_STRING = ".dll"
			-- Extension for assembly/module
 
	pascal_case (name: STRING): STRING
			-- Convert `name' using PascalCasing convention.
		require
			name_not_void: name /= Void
			name_not_empty: not name.is_empty
		local
			i, nb: INTEGER
			l_c: CHARACTER
		do
			Result := name
			Result := Result.twin
			from
				i := 2
				nb := Result.count
				Result.put (Result.item (1).upper, 1)
			until
				i > nb
			loop
					-- When we encounter a '_' we delete it if it is not the last one
					-- in `Result' and the character following the `_' has its case
					-- changed  to upper.
				l_c := Result.item (i)
				if l_c = '_' and i < nb then
					l_c := Result.item (i + 1)
					if l_c.upper /= l_c then
						Result.remove (i)
						nb := nb - 1
						Result.put (l_c.upper, i)
					end
				end
				i := i + 1
			end
		ensure
			result_not_void: Result /= Void
		end
 
	counter: CELL [INTEGER]
		once
			create Result.put (1)
		end

How to run sample program in eiffel studio

testss4u — Mon, 28 Dec 2009 09:07:38 +0000

class APPLICATION

inherit ARGUMENTS

create make

feature

make

do io.put_string ("Hello, world!%N")

end

when i compiled this program i got this result "Eiffel Compilation Succeeded" ..

When i run the program i got this out put

Launching system :

 - directory = `/home/ss4u/Desktop/project/'
 - arguments = `test'

System is running Application launched Application is running Application exited

But this output "Hello, world!" is not showing...

Make EiffelStudio a Tool for Adding Target Platforms to EiffelStudio

DonTHB — Fri, 18 Dec 2009 03:04:17 +0000

While this is likely a huge undertaking and may require architectural changes to the product, the easy addition of unsupported target platforms should exhibit the advantages of Eiffel. And because EiffelStudio has support, at the beta level, for only one platform I need to target.

Why doesn't it work?

creative.bachkhoa — Mon, 23 Nov 2009 03:33:35 +0000

Short Description:

involve read file and write to file

I start using I/O in eiffel, and my first program doesn't work.

	make
	local
      input : PLAIN_TEXT_FILE
      output : PLAIN_TEXT_FILE
      internal : ARRAY[CHARACTER]
      i, j : INTEGER
    do
      io.putstring ("Welcome to file-io land! %N")
      create  input.make_open_read ("C:\eiffel\test1.txt")
      io.put_string ("STOP")
      create  output.make_open_write("C:\eiffel\test1_copy.txt")
      create  internal.make(1,1000)
      from input.start ; input.read_character ; i := 0
      until input.off
      loop
        io.putchar(input.last_character)
        i := i + 1
        internal.put(input.last_character,i)
        input.read_character
      end
 
      input.close
 
 
      io.putstring("%N%NCopy from array%N%N")
      from j := 0
      until j = i
      loop
        j := j + 1
        output.putchar(internal @ j)
      end
      output.close
 
      io.putstring("Done.")
      end

Could anybody explain this to me?

Passback variable performance comparison

clemahieu — Wed, 18 Nov 2009 18:35:27 +0000

Short Description:

A performance comparison between CELL, TUPLE, and SPECIAL when used as a 1-variable passback in void-safe code.

These tests test the allocation performance of 3 passback variable options and the subsequent access time when retrieving the value back from the calling function.

The difficulty in a general solution arises with void safety. CELL needs to have an initial value provided upon creation, for a complex type a dummy value may not be an option so a detachable type would be used with the default value initialized to void. TUPLE isn't currently void-safe though in the future the thinking is that TUPLE will need default initialization similar to CELL. The performance hit would then be on the retrieval needing to go through an object test. SPECIAL has the unique property of being able to have an attached type without an initializer. Note there are 10x more retrieval attempts than allocations in order to get a descent time sample; allocation is by far the slower process.

Test setup:

ES version 6.5.8.1550
Finalized
Complete void-safety
Types attached by default

Results: test_1 CELL allocation: 21.259, 21.159, 21.206

test_2 TUPLE allocation: 24.490, 24.483, 24.514

test_3 SPECIAL allocation: 22.502, 22.515, 22.553

test_4 CELL access: 10.613, 10.571, 10.572

test_5 TUPLE access: 12.901, 12.841, 12.837

test_6 SPECIAL access: 13.642, 13.572, 13.580

test_7 CELL access no object test: 10.614, 10.590, 10.584

Allocation (greater is faster) CELL > SPECIAL > TUPLE

Access (greater is faster) CELL > TUPLE > SPECIAL

Allocation time is a factor of 20 slower than access so over all CELL is the fastest when used as a single creation single passback context. All of these options are very close in performance to each other and realistically shouldn't make a difference.

It's unusual that SPECIAL would have a slower access time than an object check with CELL or TUPLE.

feature	
	make
		do
			test_1
		end
 
	test_1
		local
			i: INTEGER
		do
			from
				i := 0
			until
				i > 100_000_000
			loop
				test_cell
				i := i + 1
			end
		end
 
	test_2
		local
			i: INTEGER
		do
			from
				i := 0
			until
				i > 100_000_000
			loop
				test_tuple
				i := i + 1
			end
		end
 
	test_3
		local
			i: INTEGER
		do
			from
				i := 0
			until
				i > 100_000_000
			loop
				test_special
				i := i + 1
			end
		end
 
	test_4
		local
			r0: CELL [detachable CELL [NATURAL_32]]
			r1: CELL [detachable CELL [NATURAL_32]]
			i: INTEGER
			val: detachable CELL [NATURAL_32]
			val_2: NATURAL_32
		do
			create r0.put (Void)
			create r1.put (Void)
			sub_ddmmss_cell (r0, r1, 0x55bf739f, 0xc3945435, 0x0fff167f, 0xf3e8e754)
			from
				i := 0
			until
				i > 1_000_000_000
			loop
				val := r0.item
				if attached {CELL [NATURAL_32]} val as val_l then
					val_2 := val_l.item
				end
				val := r1.item
				if attached {CELL [NATURAL_32]} val as val_l then
					val_2 := val_l.item
				end
				i := i + 1
			end
		end
 
	test_5
		local
			r0: TUPLE [r0: detachable CELL [NATURAL_32]]
			r1: TUPLE [r1: detachable CELL [NATURAL_32]]
			i: INTEGER
			val: detachable CELL [NATURAL_32]
			val_2: NATURAL_32
		do
			create r0
			create r1
			sub_ddmmss_tuple (r0, r1, 0x55bf739f, 0xc3945435, 0x0fff167f, 0xf3e8e754)
			from
				i := 0
			until
				i > 1_000_000_000
			loop
				val := r0.r0
				if attached {CELL [NATURAL_32]} val as val_l then
					val_2 := val_l.item
				end
				val := r1.r1
				if attached {CELL [NATURAL_32]} val as val_l then
					val_2 := val_l.item
				end
				i := i + 1
			end
		end
 
	test_6
		local
			r0: SPECIAL [CELL [NATURAL_32]]
			r1: SPECIAL [CELL [NATURAL_32]]
			i: INTEGER
			val_2: NATURAL_32
		do
			create r0.make_empty (1)
			create r1.make_empty (1)
			sub_ddmmss_special (r0, r1, 0x55bf739f, 0xc3945435, 0x0fff167f, 0xf3e8e754)
			from
				i := 0
			until
				i > 1_000_000_000
			loop
				val_2 := r0 [0].item
				val_2 := r1 [0].item
				i := i + 1
			end
		end
 
	test_7
		local
			r0: CELL [detachable CELL [NATURAL_32]]
			r1: CELL [detachable CELL [NATURAL_32]]
			i: INTEGER
			val: NATURAL_32
		do
			create r0.put (Void)
			create r1.put (Void)
			sub_ddmmss_cell (r0, r1, 0x55bf739f, 0xc3945435, 0x0fff167f, 0xf3e8e754)
			from
				i := 0
			until
				i > 1_000_000_000
			loop
				val := r0.item.item
				val := r1.item.item
				i := i + 1
			end
		end
 
	test_cell
		local
			r0: CELL [detachable CELL [NATURAL_32]]
			r1: CELL [detachable CELL [NATURAL_32]]
		do
			create r0.put (Void)
			create r1.put (Void)
			sub_ddmmss_cell (r0, r1, 0x55bf739f, 0xc3945435, 0x0fff167f, 0xf3e8e754)
		end
 
	test_tuple
		local
			r0: TUPLE [r0: detachable CELL [NATURAL_32]]
			r1: TUPLE [r1: detachable CELL [NATURAL_32]]
		do
			create r0
			create r1
			sub_ddmmss_tuple (r0, r1, 0x55bf739f, 0xc3945435, 0x0fff167f, 0xf3e8e754)
		end
 
	test_special
		local
			r0: SPECIAL [CELL [NATURAL_32]]
			r1: SPECIAL [CELL [NATURAL_32]]
		do
			create r0.make_empty (1)
			create r1.make_empty (1)
			sub_ddmmss_special (r0, r1, 0x55bf739f, 0xc3945435, 0x0fff167f, 0xf3e8e754)
		end
 
	sub_ddmmss_cell (sh: CELL [detachable CELL [NATURAL_32]]; sl: CELL [detachable CELL [NATURAL_32]]; ah: NATURAL_32; al: NATURAL_32; bh: NATURAL_32; bl: NATURAL_32)
		local
			x: NATURAL_32
		do
			x := al - bl
			sh.put (create {CELL [NATURAL_32]}.put (ah - bh - (al < bl).to_integer.to_natural_32))
			sl.put (create {CELL [NATURAL_32]}.put (x))
		end
 
	sub_ddmmss_tuple (sh: TUPLE [sh: detachable CELL [NATURAL_32]]; sl: TUPLE [sl: detachable CELL [NATURAL_32]]; ah: NATURAL_32; al: NATURAL_32; bh: NATURAL_32; bl: NATURAL_32)
		local
			x: NATURAL_32
		do
			x := al - bl
			sh.sh := create {CELL [NATURAL_32]}.put (ah - bh - (al < bl).to_integer.to_natural_32)
			sl.sl := create {CELL [NATURAL_32]}.put (x)
		end
 
	sub_ddmmss_special (sh: SPECIAL [CELL [NATURAL_32]]; sl: SPECIAL [CELL [NATURAL_32]]; ah: NATURAL_32; al: NATURAL_32; bh: NATURAL_32; bl: NATURAL_32)
		local
			x: NATURAL_32
		do
			x := al - bl
			sh.force (create {CELL [NATURAL_32]}.put (ah - bh - (al < bl).to_integer.to_natural_32), 0)
			sl.force (create {CELL [NATURAL_32]}.put (x), 0)
		end

Update: Replaced `extend' in special test with more realistic `force'. This makes CELL with an object test the fastest option.

Update: Added test_7 which tests accessing cell without an object test. This compared to test_4 with an object test shows object tests are negligible performance hits when the test always is true.

Trouble with array of linked_list elements

creative.bachkhoa — Wed, 11 Nov 2009 17:23:19 +0000

Short Description:

I represent an adjacency list of graph G(V,E).

feature
	adj_list: ARRAY[LINKED_LIST[INTEGER]]
feature
	make(vertices: INTEGER)
		local
			i: INTEGER
		do
			create adj_list.make(1,vertices)
			from
				i:=1
			until
				i > adj_list.upper
			loop
				create adj_list[i].make
				io.put_string("Enter the vertices match to vertex ")
                                io.put_integer(i)
				io.put_string (":%T")
				read_list(adj_list[i])
				i:=i+1
			end
		end

The compile said "expression cannot be used as instruction"  at the stage "create adj_list[i].make " 
 Does it make sense? Can anybody help me fix it?

Can't construct for local variables.

phundinhvu — Wed, 04 Nov 2009 10:13:35 +0000

I use this code, but when run it has error like this:

 
Syntax error at line 22 in class EXCEPTIONHAN
 
            -- Client deposit money into his account.
            local     account_number : INTEGER is 10
-----------------------------------------------^
                    i : INTEGER

See my code:

feature Client_Deposit is
			-- Client deposit money into his account.
			local 	account_number : INTEGER is 10
				i : INTEGER
				amount : REAL
			do
 
			rescue
 
			end -- client Deposit.

It's meant we can't construct for local variable in eiffel. In java, it's very easy. <java> void Client_Deposit(){ int account_number = 10; ..... } </java>

Exception in eiffel.

phundinhvu — Tue, 03 Nov 2009 03:23:18 +0000

I'm studying about exception in eiffel and how to hand it. When have results, i'll post it here. Now, i hope there're some conferences about this title.