mirrors/eiffel-org
1
0
Fork 0
mirror of https://github.com/EiffelSoftware/eiffel-org.git synced 2026-04-04 09:09:22 +02:00
Code Issues Packages Projects Releases Wiki Activity

Author:admin

Browse Source 
Date:2008-09-17T13:53:28.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@3 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
jfiat
2008-09-17 13:53:28 +00:00
parent 4fee9356ea
commit 2ee31ab9c7
763 changed files with 36576 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

46
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/batch-compilation.wiki Normal file
View File

@@ -0,0 +1,46 @@
[[Property:title|Batch compilation]]
[[Property:weight|2]]
In order to launch a compilation without user intervention you need to specify the `-batch' switch in the '''ec''' command line, otherwise the Eiffel compilation will be blocked. We will present below a typical example of batch processing on both Unix and Windows platforms where we want to compile a project in both frozen and finalized mode, then to launch the C compilations. At the same time we want to save the output of '''ec''' and the C compilations.
===Unix===
In a file called `launch_ec' you can have the following:
<code>
#!/bin/sh
output_file="/output_path/OUTPUT"
cd /your_project_path
#Launch Eiffel compilation
ec -batch -config config.ecf -finalize -c_compile 2> $output_file
#Since only C compilation for finalized code is done
#Launch C compilation for frozen code
cd EIFGENs/target_name/W_code
finish_freezing > $output_file</code>
It will go the directory where your project is located and compile your Eiffel code using the `config.ecf' file located in your project directory and compile automatically the C code. All outputs will be stored in the file `/output_path/OUTPUT'.
'''Note:''' All output from '''ec''' are going to the error output, so do not forget to redirect the error output when you want to see the result.
===Windows===
In a file called `launched_ec.bat' you can have the following:
<code>
rem Launch Eiffel compilation
ec -batch -config config.ecf -finalize -c_compile > c:\output_path\OUTPUT
rem Since only C compilation for finalized code is done
rem Launch C compilation for frozen code
cd EIFGENs\target_name\W_code
finish_freezing > c:\output_path\OUTPUT</code>
It will go the directory where your project is located and compile your Eiffel code using the `config.ecf' file located in your project directory and compile automatically the C code. All outputs will be stored in the file `c:\output_path/OUTPUT'.
{{seealso| '''See Also''' <br/>
[[EiffelStudio: Command line options|Command line compiler options]] }}

70
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/class-menu.wiki Normal file
View File

@@ -0,0 +1,70 @@
[[Property:title|Class menu]]
[[Property:weight|2]]
The Class command (c or C) in the main menu will only work if the system has been successfully compiled, and will give you information based on the result of the last successful compilation. It produces the following menu:
<code>
(A) Ancestors : show the ancestors of a class.
(B) Attributes : show the attributes of a class.
(C) Clients : show the clients of a class.
(E) Deferred : show the deferred features of a class.
(D) Descendants : show the descendants of a class.
(V) Edit : edit the text of a class.
(P) Exported : show the exported features of a class.
(X) Externals : show the external features of a class.
(F) Flat : show the flat form of a class.
(I) Flatshort : show the flat-short form of a class.
(O) Once : show the once & constant features of a class.
(R) Routines : show the routines of a class.
(S) Short : show the short form of a class.
(U) Suppliers : show the suppliers of a class.
(T) Text : show the text of a class.
(H) Help : show list of commands.
(M) Main : go back to main menu.
(Q) Quit : terminate session.
(Y) Yank : yank (save) output of last command to a file.
</code>
Each command will prompt you for the name of a class and a filter to use; you can also include the class name and the filter name after the command, separated by a space, as in:
<code>Command => a linked_list ascii</code>
to obtain the ancestors of the <eiffel>LINKED_LIST</eiffel> class:
<code>
-- Automatic generation produced by ISE Eiffel --
LINKED_LIST [G]
DYNAMIC_LIST [G]
LIST [G]
CHAIN [G]
CURSOR_STRUCTURE [G]
ACTIVE [G]
BAG [G]
COLLECTION [G]
CONTAINER [G]
ANY
INDEXABLE [G, H -> INTEGER]
TABLE [G, H]
BAG [G]...
SEQUENCE [G]
ACTIVE [G]...
BILINEAR [G]
LINEAR [G]
TRAVERSABLE [G]
CONTAINER [G]...
LINEAR [G]...
FINITE [G]
BOX [G]
CONTAINER [G]...
SEQUENCE [G]...
DYNAMIC_CHAIN [G]
CHAIN [G]...
UNBOUNDED [G]
FINITE [G]...
DYNAMIC_CHAIN [G]...
-- Generated by ISE Eiffel --
-- For more details: http://www.eiffel.com --
Command =></code>

28
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/compile-and-run-menu.wiki Normal file
View File

@@ -0,0 +1,28 @@
[[Property:title|Compile (and run) menu]]
[[Property:weight|1]]
The Compile command (i or I) in the main menu yields the following item menu:
<code>
(A) Arguments : set the arguments.
(C) F-compile : (re)compile the C code generated by finalize.
(Z) Finalize : finalize the system (discard assertions by default).
(F) Freeze : freeze the system.
(L) Melt : melt the system.
(K) Quick melt : quick melt the system.
(R) Run : execute the system.
(W) W-compile : (re)compile the C code generated by freeze.
(H) Help : show list of commands.
(M) Main : go back to main menu.
(Q) Quit : terminate session.
(Y) Yank : yank (save) output of last command to a file.
</code>
The most common compiling option is L (Melt): recompile the system, melting recent changes. The other compilation possibilities are F (Freeze) and Z (Finalize). After a Freeze you will need to C-compile the result using the W (W-compile) command; similarly, you can C-compile the result of a Finalize using C (F-compile).
{{warning| '''Caution''': You cannot select a different project from within ec loop; also, you cannot select a different configuration file from within the command, although you may of course change the contents of the configuration file (for example by using an editor in an other window). }}
The R option (Run) runs the application. You will be prompted for the arguments if the application needs any.

20
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/documentation-menu.wiki Normal file
View File

@@ -0,0 +1,20 @@
[[Property:title|Documentation menu]]
[[Property:weight|7]]
The Documentation Menu enables you to generate documentation about the classes of your system:
<code>
(I) Documentation (Flat/Short): Generate flat/short form of all classes in system.
(S) Documentation (Short): Generate short form of all classes in system.
(F) Documentation (Flat): Generate flat form of all classes in system.
(T) Documentation (Text): Generate text form of all classes in system.
(H) Help : show list of commands.
(M) Main : go back to main menu.
(Q) Quit : terminate session.
(Y) Yank : yank (save) output of last command to a file.
</code>
The four documentation commands will trigger the creation of documentation files corresponding to requested information using the specified filter. These files will then be located in the Documentation subdirectory of your project directory.

44
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/feature-menu.wiki Normal file
View File

@@ -0,0 +1,44 @@
[[Property:title|Feature menu]]
[[Property:weight|3]]
The Feature Menu enables you to find properties of a feature:
<code>
(A) Ancestors : show the ancestor versions of a feature.
(C) Callers : show the callers of a feature.
(D) Descendants : show the descendant versions of a feature.
(F) Flat : show the flat form of a feature.
(O) Homonyms : shown the homonyms of a feature.
(I) Implementers : show the classes implementing a feature.
(T) Text : show the text of a feature.
(H) Help : show list of commands.
(M) Main : go back to main menu.
(Q) Quit : terminate session.
(Y) Yank : yank (save) output of last command to a file.
</code>
Each command will prompt you for the name of a class, the name of a feature in that class and a filter name; you can specify these names (or just the class name) after the command.
{|
|-
| <center>'''Command'''</center>
| <center>'''Description'''</center>
|-
| <code>Ancestors</code>
| All the versions of a feature that appeared in ancestors.
|-
| <!Unavailable:vertical_alignment!><code>Callers</code>
| The list of classes which contains calls to the feature. Modifiers:
* <code>All senders</code> - include all callers rather than only those in the specified class
* <code>Only assigners</code> - restrict callers to those that use given feature only as a target of an assignment instruction
* <code>Only creators</code> - restrict callers to those that use given feature only as a target of a creation instruction
|-
| <code>Descendants</code>
| All the versionsof a feature that appeared in descendants.
|-
| <code>Implementers</code>
| The list of classes where the feature is redeclared.
|}

13
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/index.wiki Normal file
View File

@@ -0,0 +1,13 @@
[[Property:title|Command line interactive mode]]
[[Property:weight|3]]
* [[Interactive command line: Introduction|Introduction]]
* [[Compile (and run) menu|The Compile (and Run) menu]]
* [[Class menu|The Class menu]]
* [[Feature menu|The Feature menu]]
* [[System menu|The System menu]]
* [[Profile menu|The Profile menu]]
* [[Documentation menu|The Documentation menu]]

155
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/profile-menu.wiki Normal file
View File

@@ -0,0 +1,155 @@
[[Property:title|Profile menu]]
[[Property:weight|6]]
An execution of an instrumented system will generate a file that contains profiling information. This file (named profinfo) is located in the same directory as your compiled system. You must process it through a profile converter to produce the Execution Profile.
The profile menu will enable you to produce the Execution profile and to extract information from it.
The menu (obtained by selecting (P) Profile in the main menu) looks like this:
<code>
(S) Switches : show the output switches
#Call-E Name-E Total-D
Self-D Desc-D %Time-D.
(U) Query : manipulate subqueries.
(I) Input : specify input file (filename or last_output)
[*.pfi].
(L) Language : specify language (eiffel, c, cycles)
[eiffel].
(R) Run : run the query.
(G) Generate : generate profile information for latest run.
(E) Defaults : reset all values to their defaults.
(H) Help : show list of commands.
(M) Main : go back to main menu.
(Q) Quit : terminate session.
(Y) Yank : yank (save) output of last command to a file.</code>
==Switches submenu==
The (S) Switches submenu enables you to set global options. It leads you to the following set of choices:
<code>
(N) Calls : disable output of number of calls to a feature [enabled].
(F) Feature name : disable output of feature names [enabled].
(T) Total : enable output of time spent in both the function and its descendants [disabled].
(S) Self : enable output of time spent in a function itself [disabled].
(D) Descendants : enable output of time spent in descendants of a function [disabled].
(P) Percentage : enable output of percentage of time spent in a feature [disabled].
(H) Help : show list of commands.
(M) Main : go back to main menu.
(U) Parent menu : go back to parent menu.
(Q) Quit : terminate session.
(Y) Yank : yank (save) output of last command to a file.</code>
Each one of these commands switches on or off the corresponding column output. The default is set on for the first two, off for the others. To enable or disable a column, type the name with a toggle effect.
==Query submenu==
The (U) Query submenu enables you to define a set of queries. The result will be a Total Query; by default it is the boolean and all the queries you have entered individually, but you may deactivate some of these and choose other boolean operators.
<code>
(A) Add : add a sub query.
(I) Inactivate : inactivate sub query.
(R) Reactivate : reactivate sub query.
(C) Operator : change the boolean operator.
(S) Show : show the list of queries.
(H) Help : show list of commands.
(M) Main : go back to main menu.
(U) Parent menu : go back to parent menu.
(Q) Quit : terminate session.
(Y) Yank : yank (save) output of last command to a file.</code>
To get useful information, you should add the appropriate queries through (A) Add. Each individual query has the following form: attribute operator value, where attribute is one of:
* feature name
* calls
* total
* self
* descendants
* percentage
operator is one of: <, >, <=, >=, =, /=, in
and value is one of:
* An integer (for calls)
* A string (for feature name). The string may contain wild card characters: ?, standing for arbitrary characters, and *,standing for arbitrary substrings.
* A real value (for other attributes)
* An interval, of the form a-b for two values a and b.
* max
* min
* avg
The (S) Show command will display the current queries, each with an associated number. The output includes the total query, explained next.
To inactivate a query, use (I) Inactivate. You will be prompted for a query index, which you may retrieve from (S) Show. This is useful if you make a change about a query, or want to set it aside for future use.
To reactivate a query, use (R) Reactivate. Again you will have to provide a query index.
The Total Query resulting from a succession of (A) Add commands, possibly with some (I) Inactivate and (R) Reactivate commands, is a boolean query resulting by default from adding all the currently active queries. For example after the following set of commands(note that commands output help lines, which have been skipped here):
<code>
Command => a
--> Subquery: featurename = put*
Command => a
--> Subquery: calls = 3
-- Here we change our mind and deactivate the second query
-- to replace it by calls = 3:
Command => s
[1] featurename = put* is active
[2] calls = 3 is active
The total active query:
featurename = put* and
calls >
Command => i
--> Subquery index: 2
Command =&gt; a
--> Subquery: calls > 5</code>
<br/>
The (S) Show command will show the following result:
<code>
Command => s
All subqueries:
[1] featurename = put* is active
[2] calls = 3 is inactive
[3] calls > 5 is active
The total active query:
featurename = put* and
calls > 5</code>
To change the boolean operator to 'or' rather than 'and', use the (C) Operator command. It will prompt you for the index of the operator and the new value:
<code>
Command => c
--> Operator index followed by operator ('and' or 'or'): 1 or
Command => s
All subqueries:
[1] featurename = put* is active
[2] calls = 3 is inactive
[3] calls > 5 is active
The total active query:
featurename = put* or
calls > 5</code>
==Input command==
The (I) Input command serves to load Execution Profiles. It is initially set to *.pfi meaning that it will load all files with extension pfi. By calling the command repeatedly with new arguments, you are able to load more Execution Profiles. If you use the command without any argument, and the set of input files contained just one file, then the queries will use the last generated output. This avoids explicitly loading a file.
==Language command==
The (L) Language command enables you to specify the languages to which profiling should be applied. You can specify Eiffel only, C only, or both. If you specify only one language, the query results will not contain any information about routines written in the other language.
The default is Eiffel only. To switch to both Eiffel and C, use Command => L eiffel and c
To return to just Eiffel, simply type L.
==Run Command==
To run the current total query, use (R) Run.
==Generate command==
To run the profile converter under the command-line interface, use the (G) Generate command. This will generate an Execution Profile, stored in a file with the extension .pfi.
When running the Generate command with no arguments, you will be prompted for the following information:
* Name of file to be converted (default: profinfo).
* Compilation mode: workbench or finalized (default: workbench).
* Name of profiler tool (default: eiffel).
You can also type in the arguments directly without waiting to be prompted, as in command => g profinfo finalize eiffel <br/>
{{seealso| '''See Also''' <br/>
[[Profiler Wizard|Profiler wizard]] }}

23
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/system-menu.wiki Normal file
View File

@@ -0,0 +1,23 @@
[[Property:title|System menu]]
[[Property:weight|4]]
The System Menu gives general information about the system:
<code>
(A) Config : show the config file.
(L) Classes : show the classes in alphabetic order.
(S) Cluster hierarchy: display the cluster hierarchy of the system.
(C) Clusters : show the system's classes, cluster by cluster.
(V) Edit : edit the config file.
(I) Indexing : show indexing clauses of classes.
(O) Modifications: show classes modified since last compilation.
(T) Statistics : show system statistics.
(H) Help : show list of commands.
(M) Main : go back to main menu.
(Q) Quit : terminate session.
(Y) Yank : yank (save) output of last command to a file.</code>
The A (Config) command shows the configuration file; the E (Edit) command enables you to edit the configuration file; the C (Clusters) command is useful to display the entire list of classes, cluster by cluster.

186
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/eiffelstudio-using-command-line-options.wiki Normal file
View File

@@ -0,0 +1,186 @@
[[Property:title|EiffelStudio: Command line options]]
[[Property:link_title|Using command line options]]
[[Property:weight|1]]
You may start ec through a command of the following form:
<code>'''ec''' ''option'' ... [''class_name''][''feature_name'']</code>
''class_name'', if present, must be the name of a class of the system to which '''ec''' is applied. This system is identified by its configuration file; by default this is the file called Ace.ecf in the working directory, but you can select any other one through the -config ''file_name'' option. Similarly, the default project directory is the working directory, but you can select another through the -project_path ''directory_name'' option.
''feature_name'', if present, must be the final name of a feature of the class called ''class_name''. <br/>
The table below lists the available options, the arguments they require, and their effect:
{|
|-
| '''OPTION'''
| '''ARGUMENTS'''
| '''EFFECT'''
|-
| ''Operation options''
|-
| -melt
|
| Normal compilation, except on an incremental recompilation where added/removed classes (of classes not in system) will be detected.
|-
| -freeze
|
| Freeze system.
|-
| -finalize
|
| Produce a finalized system. See below.
|-
| -precompile
|
| Precompile a system, treating it as a library.
|-
| ''Browsing operations''
|-
| -ancestors
| class_name
| Print the ancestors of the class.
|-
| -aversions
| class_name, feature_name
| Print the ancestor versions of the feature.
|-
| -callers
| class_name, feature_name
| Print all the routines that call the feature.
|-
| -clients
| class_name
| Print the clients of the class
|-
| -descendants
| class_name
| Print the descendants of the class.
|-
| -dversions
| class_name, feature_name
| Print all the versions of the feature in the descendant versions of the class.
|-
| -flat
| class_name
| Print the flat view of the class.
|-
| -flatshort
| class_name
| Print the Flat Contract view (previously called flat-short form) of the class.
|-
| -implementers
| class_name, feature_name
| Print all the classes that declare or redeclare the feature.
|-
| -short
| class_name
| Print the Contract view (previously called short form) of the class.
|-
| -suppliers
| class_name, feature_name
| Print all the suppliers of the class.
|-
| ''Other options''
|-
| -batch
|
| Launch the compilation without user request.
|-
| -clean
|
| Delete project if already compiled and compile project as if it was the first time.
|-
| -config
| file_name
| Use the file as configuration.
|-
| -c_compile
|
| Launch C compilation, if needed, after Eiffel compilation.
|-
| -file
| file_name
| Save the output to the file.
|-
| -filter
| filter_file_name
| Print text as processed by the filter.
|-
| -help
|
| Print the help.
|-
| -keep
|
| Keep assertions in final mode. Useful with -finalize only.
|-
| -loop
|
| Enter interactive mode. See below.
|-
| -metadata_cache_path
| directory_name
| Specify location of Metadata Cache used for .NET compilation. This overrides any settings from your configuration file.
|-
| -no_library
|
| When converting an old configuration file format, do not convert clusters into libraries.
|-
| -project_path
| directory_name
| Use this directory as compilation directory. (Default: current directory.)
|-
| -stop
|
| Stop on errors. (Default: no.)
|-
| -use_settings
|
| Use the project global settings to retrieve the project location for the last compilation of this project.
|-
| -version
|
| Print compiler version number.
|}
'''Note''': In the third column, to print means to produce the requested information on the default output of the '''ec''' command. <br/>
Some options can have modifiers that can affect their results. The modifiers are listed in the table below:
{|
|-
| <center>'''Option'''</center>
| <center>'''Modifier'''</center>
| <center>'''Effect'''</center>
|-
| -callers
|-
|
| -show_all
| Include all callers rather than only those in the specified class.
|-
|
| -assigners
| Restrict callers to those that use given feature only as a target of an assignment instruction.
|-
|
| -creators
| Restrict callers to those that use given feature only as a target of a creation instruction.
|}
==Finalization==
To produce a finalized system, you may use the command '''ec''' -finalize. The effect is the same as when you press the Finalize button in the graphical environment, except for two differences:
# All assertion checking will by default be turned off in the resulting finalized system. In the graphical environment, an interactive panel asks you whether you want to keep or discard assertions. Command '''ec''', however, was designed to be callable automatically from shell scripts or programs, and for that reason never asks for interactive user input (except under the loop option). To retain the assertion checking options specified in the configuration file, use the option -keep in connection with -finalize (the order of the two options is arbitrary).
# At the end of the Eiffel part of the compilation you are presented with the message:
<code>System recompiled.
You must now run "finish_freezing" in:
''your_project_path''|EIFGENs|''target_name''|F_code</code>
with | replaced by \ if your platform is Windows, / if it is Unix. To execute the C compilation and linking part of the finalization, change directory to ''your_project_path''|EIFGENs|''target_name''|F_code as indicated and execute '''finish_freezing'''.
{{seealso| '''See Also''' <br/>
[[Batch compilation|Batch compilation]] }}

10
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/index.wiki Normal file
View File

@@ -0,0 +1,10 @@
[[Property:title|Command line]]
[[Property:weight|-13]]
* [[Command line: Introduction|Introduction]]
* [[EiffelStudio: Command line options|Command line options]]
* [[Batch compilation|Batch compilation]]
* [[Command line interactive mode|Command line interactive mode]]

23
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-45-and-ise-eiffel-50/assertions-checking-configuration-changes.wiki Normal file
View File

@@ -0,0 +1,23 @@
[[Property:title|Assertions checking configuration changes]]
[[Property:weight|0]]
One of the major differences between 4.5 and 5.0 is how to specify the assertion checking in the ace file or in the project settings window. In 4.5, assertions of a certain type where checked if their level was below the requested level. Here is what the level hierarchy looked like:
# require
# ensure
# loop
# check
# invariant
# all
Meaning that you could not just check one type of assertions. With 5.0 this is now possible and we changed the presentation to follow the cost to evaluate a given type of assertions, the first one being the less expensive:
# check
# require
# ensure
# loop
# invariant
# all
The default assertion level has changed too. Not specifying any assertion level used to be equivalent to selecting the 'require' level. This is not the case any more in 5.0 it will be not checking assertions.

31
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-45-and-ise-eiffel-50/compiler-differences-45-50.wiki Normal file
View File

@@ -0,0 +1,31 @@
[[Property:title|Compiler differences from 4.5 to 5.0]]
[[Property:weight|1]]
==What's new==
* Implementation of new external syntax.
* Implementation of verbatim strings.
* Implementation of agents.
* Implementation of agent creations on `Result' and `Current' object.
* Improved incrementality of the C compilation: fewer directories will have their C files changed after a freeze.
* New MSIL generation.
* Introduction of 4 new basic classes: INTEGER_8, INTEGER_16, INTEGER_64, WIDE_CHARACTER.
* Changed the storable mechanism so that we do not store POINTER objects with their value, instead we store a NULL value. As a consequence it is safe to store on disk objects that have references to C objects. Upon retrieval those references will be equal to `default_pointer'. This is now the default behavior, if someone wants to have the previous behavior, simply call `set_keep_pointer_value' from STORABLE.
==Improvements==
* New run-time speed improvement (between 30 to 100% faster than the 4.5 release).
* Compiler that is much faster (between 200 and 300% faster than 4.5).
* Compiler now detects unused local variables (at freeze/finalize time only)
==Bug fixes==
* Compiler now fixes incrementality issues with frozen/melted code.
* Degree 4/Degree 3 crash on *_SERVER when doing an incremental recompilation has been fixed.
* Fixed crash when using creation expression that includes a feature call.
* Fixed creation of an ARRAY of BIT type.
* CHARACTER has been extended to support the extended ASCII which means that the following expressions are now True instead of being False as it was in our previous version:
** '%/127/' < '%/128/'
** '%/127/' < '%/128/'
** When using `independent_store', in case of retrieval error due to a name change in one of the class attributes we will display the original attribute name that was used to make the storable file. This will help when managing many storable files.

10
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-45-and-ise-eiffel-50/index.wiki Normal file
View File

@@ -0,0 +1,10 @@
[[Property:title|Major changes between ISE Eiffel 4.5 and ISE Eiffel 5.0]]
[[Property:link_title|5.0]]
[[Property:weight|-7]]
* [[Assertions checking configuration changes|Assertions checking]]
* [[Changes between 4.5 and 5.0|EiffelThread]]
* [[Compiler differences from 4.5 to 5.0|Miscellaneous]]

61
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-50-and-ise-eiffel-51.wiki Normal file
View File

@@ -0,0 +1,61 @@
[[Property:title|Major changes between ISE Eiffel 5.0 and ISE Eiffel 5.1]]
[[Property:link_title|5.1]]
[[Property:weight|-8]]
==What's new==
* .NET generation now includes:
** Support for multiple inheritance.
** Support for generics.
** Partial implementation of generic conformance (same as what was supported up to and including ISE Eiffel 4.2).
** Support for tuples and agents.
** Support for any existing Eiffel code that does not use C externals.
** Partial support for compiling Eiffel libraries using C externals (e.g. WEL)
And the following limitations:
** Eiffel classes cannot inherit from non-Eiffel .NET classes (but they can be clients).
** The compiler performances are rather poor now (both in terms of memory usage and speed)
Those limitations should disappear with 5.2 which will be the official release that fully supports .NET
** Support for INTEGER_64 constants. Now a manifest integer value that is written in decimal or hexadecimal format that can't fit into an INTEGER_32 will be automatically promoted to an INTEGER_64 constant value.
** New feature access syntax for accessing constants, C/C++ externals and IL static externals. [[Differences between ETL 2nd printing and Eiffel Software implementation|Check out more here]] .
==Improvements==
* Compiler that is about 20% faster than 5.0.
==Bug fixes==
* Fixed <code>VAPE</code> errors that were not previously reported. Now <code>VAPE</code> errors are checked against arguments of a feature used in a precondition and are also checked for a qualified call.
* Fixed a conformance bug that made a manifest array not conform to ANY.
* Fixed a generic conformance bug where an assignment attempt would change the behavior of the execution.
* Fixed a wrongly reported error by the compiler in the following case:
In a system that has a generic class CLIENT with constraint `G -> SUPPLIER create make end', where the creation procedure of SUPPLIER is exported to {CLIENT}. If another class has an attribute `x: CLIENT [SUPPLIER]' the compiler reports a <code>VTCG</code> error, though it should accept the classes.
* Fixed a crash when one of the following command lines was used in a directory with no existing project that contains no default configuration file:
<code>ec -flat -all
ec -short -all
ec -flatshort -all
ec -flat -all_and_parents
ec -short -all_and_parents
ec -flatshort -all_and_parents</code>
* Fixed a bug in output display between standard output and error output. Doing the following:
<code>io.put_string ("foo%N")
io.error.put_string ("bar%N")</code>
you get the following output when simply launched from the command line:
<code>foo
bar</code>
however if you do:
<code>my_program >& RESULT</code>
to redirect both standard and error outputs to RESULT you get in the RESULT file this incorrect content:
<code>bar
foo</code>
* Fixed a non reported <code>VTEC</code> or <code>VTCG</code> error when an invalid type used as actual generic parameters in an explicit type in a creation instruction.

36
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-51-and-ise-eiffel-52.wiki Normal file
View File

@@ -0,0 +1,36 @@
[[Property:title|Major changes between ISE Eiffel 5.1 and ISE Eiffel 5.2]]
[[Property:link_title|5.2]]
[[Property:weight|-9]]
==What's new==
* .NET generation now includes support for the following language features:
** Support for multiple inheritance.
** Support for generics.
** Partial implementation of generic conformance
** Support for tuples and agents.
** Support for any existing Eiffel code that does not use C externals.
** Support for compiling Eiffel libraries using C externals that are not related to the Eiffel Software C runtime.
And the following limitations:
** Eiffel classes cannot inherit from non-Eiffel .NET classes (but they can be clients).
** No support for `expanded' keyword.
* .NET generation now supports assembly signing in enterprise edition.
* .NET generation now supports precompiled libraries.
* Supports for manifest integer constants of different sizes, i.e. you can now assign for example the value `8' to a location of type <eiffel>INTEGER_8</eiffel>, <eiffel>INTEGER_16</eiffel>, <eiffel>INTEGER</eiffel> or <eiffel>INTEGER_64</eiffel>, however you can only assign the value `254' to a location of type <eiffel>INTEGER_16</eiffel>, <eiffel>INTEGER</eiffel> or <eiffel>INTEGER_64</eiffel>.
==Improvements==
* Compiler that is about 20% faster than 5.1.
* Runtime is about 10-20% faster than 5.1
==Changes==
* One cannot create an instance of a basic expanded class ( <eiffel>BOOLEAN</eiffel>, <eiffel>CHARACTER</eiffel>, <eiffel>INTEGER_8</eiffel>, <eiffel>INTEGER_16</eiffel>, <eiffel>INTEGER</eiffel>, <eiffel>INTEGER_64</eiffel>, <eiffel>POINTER</eiffel>, <eiffel>REAL</eiffel>, <eiffel>DOUBLE</eiffel>), you will now get a <code>VGCC(6)</code> error. Instead directly assign to it, or create an instance of its corresponding _REF class.
==Bug fixes==
* Fixed memory corruption issue when trying to access an <eiffel>INTEGER_64</eiffel> value.
* Fixed a problem with manifest <eiffel>INTEGER_64</eiffel> constants whose values were incorrectly interpreted.
* Fixed <code>VAPE</code> errors that were not previously reported in 5.1. Now <code>VAPE</code> errors are checked against call to infix and prefix features.

164
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-52-and-ise-eiffel-53.wiki Normal file
View File

@@ -0,0 +1,164 @@
[[Property:title|Major changes between ISE Eiffel 5.2 and ISE Eiffel 5.3]]
[[Property:link_title|5.3]]
[[Property:weight|-10]]
==What's new==
* Finalized executable with option `exception trace' enabled will now display the instruction number (usually equivalent to the line number in the routine) being executed when a failure occurred. It was already displaying this information in workbench/melted mode, we have just extended this feature to finalize mode.
* Incremental compilation is now available for .NET code generation. Meaning that if you modify one class, only this class is being recompiled. It dramatically improves development time when targeting .NET.
* In .NET code generation, assertions can be turned on or off on a class per class basis without having to recompile those classes.
* Implemented [[EiffelBase, The Kernel|recoverable storable]] to enable the retrieval of slightly different version of an object. It only applies for classic Eiffel.
==Improvements==
* Enabled support for Borland C compiler in .NET.
* Removed too many warnings during C compilation on Tru64.
* Improved formatting of exception traces so that class names, feature names, exception tags are not truncated. Display limit has been pushed at about 256 characters.
==Changes==
* Made `\\' follow the balancing rules for various integer types.
* Precompiled libraries now precompiles all classes reachable from clusters defined in project settings only if root class is ANY, otherwise it will only precompile classes reachable from the root class. In 5.1 and prior version it was precompiling all classes reachable from clusters.
==Bug fixes==
===Language issues===
* Fixed semantic of object creations to strictly follow definition given in "Eiffel: The Language". Namely, if you have x of type <eiffel>X</eiffel>:
<code>create x.make is equivalent to x := create {X}.make</code>
It implies some bug fixes which might break existing code. For example:
<code>
x: X is
once
-- If make calls back to x then it used to return
-- a non-Void value for x, where it should have been Void.
create Result.make
end
x: X
-- If make accesses back the x attribute then it used to return
-- new value of x rather than the old value.
create x.make</code>
Or in melted code only the following code now works properly, i.e. <eiffel>make</eiffel> gets the old value of x, not the new one <br/>
<code>create x.make (x)</code>
* Fixed undetected <code>VDRD(3)</code> errors: compiler was not strict enough and accepted <code> ensure </code> where only <code> ensure then </code> was valid.
===Store/Retrieve issues===
* Fixed issue in storable mechanism when retrieving expanded objects.
* Fixed issue with independent_store where storing arrays of objects whose count was greater than 65536 will cause a memory corruption.
* Added <eiffel>correct_mismatch</eiffel> on <eiffel>HASH_TABLE</eiffel> to enable retrieval of the 5.1 and older version of <eiffel>HASH_TABLE</eiffel>.
===Runtime/code generation issues===
* Fixed incorrect C code generation in final mode when creating an <eiffel>ARRAY</eiffel> of expanded type.
* Fixed incorrect C code generation in final mode when creating a complex object which contains expanded objects that have expanded objects.
* Fixed random crash issue in finalized applications due to incorrect memory management when you have code similar to:
<code> f (g: STRING): ANY is
do
Result := create {STRING}.make_from_string (g)
end</code>
* Fixed issue with <eiffel>deep_equal</eiffel> on <eiffel>ARRAY</eiffel> of expanded types which was returning <code> False </code> where it should have returned <code> True </code>.
* Fixed code generation issue with double constants where code below was not producing the expected result of 1e+030:
<code> value: DOUBLE is 1.0e15
print (value * value) </code>
* Fixed issue in melted code where computation such as <eiffel>INTEGER_X</eiffel> // <eiffel>INTEGER_Y</eiffel> will either crash or give an incorrect computation where X and Y represents integers that are either 8, 16, 32 or 64 bits long and X < Y.
* Fixed incorrect C code generation of finalized code when your project configuration includes a precompiled library and that you cancel finalization process at degree -2, and then restart a finalization.
* Fixed issue with incorrect C code generation of inspect instruction based on character values above 128.
* Fixed compilation crash at degree 3 with following code:
<code> local
i: INTEGER
do
i := << 1 >> @ 2
end</code>
* Fixed a crash in finalized mode with invariant checking enabled with following code and when checking the invariant triggers a garbage collection cycle: <br/>
<code> value: INTEGER
is_value_required: BOOLEAN is
do
Result := value = 1
end
</code>
* Fixed crash of compiler at degree 4 while trying to compile this incorrect class:
<code>class CRASH
inherit
CHAIN -- Missing generic parameter
create
make
feature -- Initialization
make is
do
end
index: INTEGER is
do
end
duplicate (n: INTEGER): like Current is
do
end
end</code>
* Fixed issue with pathological memory allocation scheme that could trigger an `out of memory' exception where enough memory is still available.
* Fixed incorrect allocation of expanded arrays where creation routine of expanded class was not called on all items of the newly created array.
* Fixed incorrect creation type of attribute where attribute's type has some generic parameter. In some cases, instead of creating an <eiffel>ARRAY [B2 [C]]</eiffel> it would create an <eiffel>ARRAY [B2 [STRING]]</eiffel>.
===.NET issues===
* Fixed issue in IL code generation where having a class that inherits from a non-Eiffel .NET class. And the class has the following features:
<code> a: ARRAY [like f]
f: STRING is
do
end</code>
Then you could neither load nor execute the generated code.
* Fixed incorrect C file naming when generating a .NET system that uses a C++ external (it should be .cpp, not just .c).
* Fixed incorrect .NET code generation with following assignment attempts whose source is expanded:
<code> local
a: ANY
o: SYSTEM_OBJECT
do
a ?= 12
o ?= 12
end</code>
* Fixed incorrect code generation in .NET for assertions checking with following code where precondition of <eiffel>test</eiffel> will not be checked although it should:
<code> make is
do
test_which_fail_and_rescued
test
end
test is
require
should_be_checked: False
do
end
test_which_fail_and_rescued is
local
retried: BOOLEAN
do
if not retried then
failure
end
rescue
retried := true;
retry
end
failure is
require
should_be_checked: False
do
end</code>
* Fixed .NET verification issue where sometimes you could get the following message when checking an Eiffel assembly against peverify: [IL]: Error: Unverifiable PE Header/native stub.
* Fixed incorrect code generation when creating and accessing a <eiffel>NATIVE_ARRAY</eiffel> of expanded type.
* Fixed incorrect metadata heap generation to use standard CLI tables.
* Fixed bug where content of <eiffel>NATIVE_ARRAY</eiffel> could not be looked up in .NET debuggers (cordbg, DbgClr or Visual Studio)

79
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-53-and-ise-eiffel-54.wiki Normal file
View File

@@ -0,0 +1,79 @@
[[Property:title|Major changes between ISE Eiffel 5.3 and ISE Eiffel 5.4]]
[[Property:link_title|5..4]]
[[Property:weight|-11]]
==What's new==
* Support for assertion checking on external routines.
* Removed limitation about implementing or redefining a non-external routine by an external one and vice versa.
* Support for new C/C++ inline specification.
* For .NET, allow calling of overloaded features for a .NET classes to be called without using disambiguated names. Disambiguated names are still needed when redefining inherited features from .NET classes.
* Support for inclusion of .NET resources within Eiffel assemblies.
* Launch C compilation when needed if "-c_compile" option is specified on the "ec" command line.
* Added ability to define custom attributes on assembly. One as to define custom attributes under the new `assembly_metadata' index clause of the root class.
* Limited support for new <code> convert </code> keyword (only on argument passing and assignments. Not supported when used with infix routines).
==Improvements==
* Improved speed of compilation by about 20-30%
* Improved run-time memory allocation speed and footprint so that it has a 15%-20% faster allocation scheme and takes less memory than before.
* Reduced waiting time at the end of the degree 6 when performing a compilation from scratch (reduced to about 50% or more of the time it used to take)
* Improved speed of <eiffel>TUPLE</eiffel> creation and <eiffel>TUPLE</eiffel> access which generates more compact C code.
* Improved speed of agent calls by a factor of 2 to 3.
* Improved speed of Eiffel calls from C (CECIL and use of $ operator on routines). It also makes generated executables smaller (about 1-5% smaller depending on number of routines used in this context)
==Changes==
* Changed the way we generate calls to C/C++ external routines. It is possible that because of this change, code that used to C compile, will not compile anymore. This happens mostly when mixing C and C++ code and the C call being made is incorrect but was not previously checked against the C header files if provided.
* In multithreaded mode, all C externals that could potentially block the execution of the system should be marked `blocking' as in: <br/>
<code> sleep (m: INTEGER) is
external
"C blocking"
end</code>
Not doing it could generate dead-lock during the execution of a multithreaded system.
* Static access on externals is now only authorized when external is a frozen external without assertions.
* Compiler will now report a warning for assignments like those: <br/>
<code>td: TUPLE [DOUBLE]
ti: TUPLE [INTEGER]
td := ti</code>
The warning will help you correct code using this pattern, because in the next release this will be rejected in order to conform to the Eiffel language specification.
* Now we do not generate by default the .NET attribute <eiffel>ComVisibleAttribute</eiffel> with a False value. If needed it has to be done through the new compiler functionality to add custom attributes on assembly.
* Changed indexing clause tag for specifying custom attributes for .NET systems. Now `attribute' is replaced by `metadata'. Now you can have:
** metadata: generated for both interface and implementation classes
** assembly_metadata: generated for assembly only when specified in root class of system
** class_metadata: generated only for implementation class
** interface_metadata: generated only for interface class
==Bug fixes==
===Language issues===
* Now checks for valid export status in agent creation. Meaning that in class <eiffel>MY_CLASS</eiffel>, the following agent creation <code> agent </code> <eiffel>target</eiffel>. <eiffel>call</eiffel> is valid if and only if <eiffel>call</eiffel> is exported to <eiffel>MY_CLASS</eiffel>.
* Allowed type specification for open operands in agent creation, i.e. one can now write: <code> agent </code> <eiffel>f</eiffel> ({ <eiffel>A</eiffel>}).
* Fixed bug which allowed compiler to accept the following incorrect code: <eiffel>char</eiffel>: <eiffel>CHARACTER</eiffel> <code> is </code> <code> "rdsf" </code>
* Fixed bug in error reporting for incompatible <eiffel>BIT</eiffel> types involving bit manifest constants. It would always report <eiffel>BIT 0</eiffel>, instead of the actual number of bits in the bit manifest constant.
===Compiler issues===
* Fixed non-detection of changes when changing code from <code> agent </code> <eiffel>call </eiffel>to <code> agent </code> <code> Current </code>. <eiffel>call</eiffel>. Which should check for the validity of export of <eiffel>call </eiffel> to current class.
* Fixed creation and assignment attempts on generic types that have anchored types in their generic parameter, and the anchor is itself generic.
===Runtime/code generation issues===
* Fixed issue when shared library definition file did not exist or was invalid. Now it will not produce any C compilation errors.
* Fixed bug in recoverable storable when there is a mismatch. The first assignment attempt in <eiffel>internal_correct_mismatch</eiffel> from <eiffel>ANY</eiffel> would crash.
* Fixed issue when retrieving storable files that contain TUPLE instances.
* Fixed issues when using agents in a multithreaded application, they will sometimes disable the garbage collector and the application might quickly run out of memory.
* Fixed random crashes when EIF_MEMORY_CHUNK, EIF_MEMORY_SCAVENGE and EIF_STACK_CHUNK environment variables had an incorrect value. Instead the runtime will now fix the value to an appropriate one.
===.NET issues===
* Fixed bug in code generation with following statement: <br/>
<code>l_time: TIME_SPAN
print (l_time.total_milliseconds.out)</code>
* Fixed incorrect code generation with code accessing attributes of .NET expanded types.
* Fixed incorrect computation of equal when used with basic types, e.g. equal (1, 1) would return False instead of True.
===Store/Retrieve issues===
* Fixed memory corruption bug with recoverable storable when a mismatch was detected
* Fixed issue where mismatch was not detected if attributes were dropped
* Fixed issue with independent store when storing <eiffel>TUPLE</eiffel> objects where it would crash if storable did not include a reference to <eiffel>ANY</eiffel>.

148
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-54-and-ise-eiffel-55.wiki Normal file
View File

@@ -0,0 +1,148 @@
[[Property:title|Major changes between ISE Eiffel 5.4 and ISE Eiffel 5.5]]
[[Property:link_title|5.5]]
[[Property:weight|-12]]
==What's new==
* Full support for new <code>convert</code> keyword.
* Made <code>Void,</code> previously a feature of <eiffel>ANY</eiffel>, a keyword. This prevents the renaming of <eiffel>Void</eiffel> into <eiffel>not_void</eiffel> previously possible when it was a routine of <eiffel>ANY</eiffel>.
* Addition of the <code>reference</code> keyword used in generic constraints (See next point).
* Added support for reference and expanded constraints on a formal generic parameter. In other word, one can now write:
<code>class A [reference G] ... end
class B [expanded G] ... end</code>
to say that the valid actual generic parameters for <eiffel>A</eiffel> are always reference types, and for <eiffel>B</eiffel> are always expanded types.
* Added support for Microsoft .NET 2.0 runtime.
* Allowed agent creation on infix or prefix routines.
==Improvements==
* Reduced, in classic mode, size of finalized executables by 10 to 50%.
* Improved speed of evaluation of global onces, in a multithreaded system, by having a lock-free mechanism after a once has been evaluated.
* Reduced memory usage of special of expanded which do not have any reference attributes. Before there was a 8 bytes (or 16 bytes depending on the platform) overhead per item in the special.
==Changes==
* Compiler is now checking that you cannot redeclare a formal generic parameter into a reference type unless the formal generic parameter is being constraint to be always a reference type (See the '''What's new''' section above).
* Removed obsolete <eiffel>eifcid</eiffel>, <eiffel>eif_expand</eiffel> and <eiffel>eifexp</eiffel>from the CECIL interface, one has to use <eiffel>eif_type_id</eiffel>instead.
* In .NET, changed the naming conventions of resources included in an assembly. The extension `.resources' is appended for resources that are originally provided as `.resx' or `.txt' files. Other files are embedded as is in the assembly and the name of the resource is the name of the file.
* In .NET, now all classes inherit from <eiffel>ANY</eiffel>. Before all classes inherited from <eiffel>SYSTEM_OBJECT</eiffel>. The consequences are:
** You can write an Eiffel generic classes where the actual generic parameter is a .NET class.
** If you used to inherit from .NET classes and Eiffel classes you can replace the inheritance clause below:
<code>class A
inherit
APPLICATION_EXCEPTION
undefine
finalize,
equals,
to_string,
get_hash_code
end
ANY</code>
by the much simpler inheritance clause:
<code>class A
inherit
APPLICATION_EXCEPTION
</code>
** If you were using a feature of <eiffel>SYSTEM_OBJECT</eiffel> directly on Eiffel classes, now you need to assign the value to a variable entity of type <eiffel>SYSTEM_OBJECT</eiffel>. In other word:
<code>e: EIFFEL_CLASS
o: SYSTEM_OBJECT
...
o := e
o.feature_of_system_object</code>
** The following assignment attempt will succeed whereas it failed before because <eiffel>SYSTEM_OBJECT</eiffel> did not inherit from <eiffel>ANY</eiffel>:
<code>a: ANY
o: SYSTEM_OBJECT
...
check o /= Void and a = Void end
a ?= o
check o /= Void and a /= Void end</code>
* New format of the independent storable files which takes into account internal changes made for a better generic conformance in classic mode.
* New validity rule for expanded types: It is valid to use an expanded type of base class <eiffel>C</eiffel> in the text of a class <eiffel>B</eiffel> if and only if it satisfies the following conditions:
** <eiffel>C</eiffel> is not a deferred class
** <eiffel>C</eiffel>'s version of the procedure <eiffel>default_create</eiffel> (inherited from <eiffel>ANY</eiffel>) is one of the creation procedures of <eiffel>C</eiffel> available to <eiffel>B</eiffel> for creation.
* New validity rule for expanded class: An expanded class <eiffel>C</eiffel> needs to have the version of the procedure <eiffel>default_create</eiffel> (inherited from <eiffel>ANY</eiffel>) as one of its creation procedure.
==Bug fixes==
===Language issues===
* Fixed issue about conformance checking of type containing a formal generic parameter. We would always evaluate the formal to its constraint, thus allowing the code below to be accepted where it should not have been:
<code>
class A [G]
feature
bug is
local
l_any: LIST [ANY]
l_g: LIST [G]
do
l_any := l_g
l_g := l_any
end
</code>
The workaround is to use the <code>reference</code> keyword to guarantee that the formal generic parameter will always be instantiated with a reference type. For example the code below is correct:
<code>
class A [reference G]
feature
bug is
local
l_any: LIST [ANY]
l_g: LIST [G]
do
l_any := l_g
l_g ?= l_any
end
</code>
===Compiler issues===
* Enabled creation of <eiffel>SPECIAL</eiffel> instances, no need to create an instance of <eiffel>TO_SPECIAL</eiffel>or <eiffel>ARRAY</eiffel> to get a <eiffel>SPECIAL</eiffel>instance. Now you can simply do:
<code>my_special: SPECIAL [INTEGER]
create my_special.make (10)</code>
* Fixed incrementality issues with <code>strip</code> and static calls on external routines which could fail after a class has been added to or removed from the system.
===Runtime/code generation issues===
* Fixed incorrect code generation which would result in a C compiler error in classic mode when assigning a Void entity to a formal generic parameter that will be instantiated as a basic type.
* In multithreaded mode, fixed dead lock on Unix platforms when evaluating global onces.
* In multithreaded mode, prevented dead lock when a thread is exiting.
* In multithreaded mode, prevented memory corruption which could occur if the first thing that a thread performs when launched is to trigger a GC collection.
* Fixed incorrect generic conformance data when manipulating expanded generic types. For example, the following code:
<code>class A [G, H]
feature
item: H
end
class C [G]
end
class ROOT_CLASS
create
make
feature
make is
local
l_a: A [STRING, expanded C [ANY]]
do
create l_a
io.put_string (l_a.item.generating_type)
end
end
</code>
would print
<code>expanded C [STRING]</code>
instead of
<code>expanded C [ANY]</code>
* Fixed issue where you could get a bogus reference when trying to get a reference to the object associated to an ID (obtained through the <eiffel>IDENTIFIED</eiffel> class).
===.NET issues===
* Fixed incorrect code generation of native arrays which would cause the code to be rejected in newer version of the .NET Framework.
* Fixed incorrect computation of `max_stack' for a routine body which could make the generated code not verifiable.
===Store/Retrieve issues===
* Fix some issues related to the use of recoverable storable when manipulating generic types.

152
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-55-and-ise-eiffel-56.wiki Normal file
View File

@@ -0,0 +1,152 @@
[[Property:title|Major changes between ISE Eiffel 5.5 and ISE Eiffel 5.6]]
[[Property:link_title|5.6]]
[[Property:weight|-13]]
==What's new==
{{seealso|See also: [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
* Implemented once manifest strings. They can be used at the same places where normal manifest strings can be used, e.g.:
<code>s := once "abc"
io.put_string (once "Hello World!")</code>
Once manifest strings are not created every time they are accessed. Instead one instance is created at the first access and then it is reused for subsequent accesses. In multithreaded application one instance is created for one thread.
* Supported aligned and non-aligned verbatim strings. Aligned verbatim strings use characters <code>[</code> and <code>]</code> in opening and closing sequence respectively, non-aligned verbatim strings use <code>{</code> and <code>}</code>.
* Added support for manifest type expression "{<eiffel>MY_TYPE</eiffel>}" which gives an instance of <eiffel>TYPE</eiffel> [<eiffel>MY_TYPE</eiffel>].
* New syntax for manifest constants. Now they can be preceeded by a manifest type expression. For example <code>1</code> is of type <eiffel>INTEGER</eiffel>, whereas {<eiffel>INTEGER_8</eiffel>} 1 is of type <eiffel>INTEGER_8</eiffel>.
* Support for <eiffel>NATURAL_XX</eiffel> types which are unsigned integers.
* Supported new feature alias syntax to specify operator and bracket names:
<code>negate alias "-": like Current ...
multiply alias "*" (other: like Current): like Current ...
item alias "[]" (index: INTEGER): G ...</code>
The first two declarations can be used similar to features <code>prefix "-"</code> and <code>infix "*"</code>. The last one can be used to make feature calls with bracket expressions like
<code>letter := letters [i]</code>
Operator and bracket aliases can also be used in <code>rename</code> subclause to change an alias name associated with a feature.
* Supported new feature assigner syntax to associate feature with an assigner command:
<code>item alias "[]" (index: INTEGER): G assign put ...
put (value: G; index: INTEGER) ...</code>
Given the declaration above the following instructions become equivalent:
<code>x.put (x.item (i + 1), i)
x.item (i) := x.item (i + 1)
x [i] := x [i + 1]</code>
==Improvements==
* Optimized .NET code generated for <code>inspect</code> instruction.
* Optimized access to process-relative once routines to avoid heavy-weight synchronization primitives when possible.
* Speed-up access to once routines in finalized multi-threaded applications.
* Improved some error messages to be more precise.
* Removed the requirement to freeze code that declares process-relative once routine.
* Improved multi-threaded application performance in classic mode by using built-in support for thread-local storage provided by some ''C'' compilers.
* Allowed underscores in hexadecimal literals.
* Provided syntax highlighting for hexadecimal literals in editor.
* Slightly improved reporting of syntax errors.
* Made keyword operator names clickable in flat view.
==Changes==
* Void does not conform to expanded types. As a consequence, assignments of Void to expanded entities will be rejected rather than throwing an exception at run-time. And comparison of expanded entities to Void will cause a <code>VWEQ</code> validity error.
* Changed default behavior of once routines in .NET mode from once-per-process to once-per-thread to match behavior in classic mode.
* Provided project options (<code>old_verbatim_strings</code> and <code>old_verbatim_strings_warning</code>) to support semantics of verbatim strings as in previous versions when they were not left-aligned.
* Changed processing of hexadecimal integer literals to be consistent for different integer types. For example, <code>0xFF</code> gives <code>255</code> when assigned to a variable of type <eiffel>INTEGER</eiffel> rather than <code>-1</code> as before.
* Due to the new {} syntax, a few older syntax constructs have been removed:
** "{<eiffel>X</eiffel>} <code>Precursor</code> (..)" is rejected and should be replaced by "<code>Precursor</code> {<eiffel>X</eiffel>} (...)".
** "<code>agent</code> <eiffel>f</eiffel> (?, {<eiffel>A</eiffel>})" is now rejected, as it would conflict with a manifest type expression, instead you should write "<code>agent</code> <eiffel>f </eiffel>(?, {<eiffel>A</eiffel>} ?)".
* In .NET, all usage of <eiffel>INTEGER_8</eiffel> from .NET libraries have been changed to <eiffel>NATURAL_8</eiffel>.
* In .NET, renamed <eiffel>TYPE</eiffel>, <eiffel>ATTRIBUTE_</eiffel> and <eiffel>VOID_</eiffel> from the mscorlib assembly into <eiffel>SYSTEM_TYPE</eiffel>, <eiffel>SYSTEM_ATTRIBUTE</eiffel> and <eiffel>SYSTEM_VOID</eiffel>.
* Changed exception handling for once routines so that exception raised during the first call is raised during any subsequent call to this routine.
* Introduced upper limit for value of integer constant used in <code>BIT</code> type declaration and extended <code>VTBT</code> rule to cover this change.
* To evaluate the type of a manifest array we now use the first item of the manifest array instead of the last one as a first guessed type.
* Allowed for integer literals with intermediate underscores at arbitrary positions.
* To ensure same behavior on various platforms, the standard output is now unbuffered (it previously was unbuffered on Windows and line buffered on Unix platforms).
==Bug fixes==
===Language issues===
* Used <code>'%N'</code> as an end of line in verbatim strings regardless of the end of line sequence in source code.
* Fixed incorrect handling of negative hexadecimal integer literals when sign before the literal was not taken into account. For example, <code>-0x1</code> could be interpreted as <code>1</code>.
* Implemented checks for input ranges of integer constants and fixed issue with inability to assign minimum integer values to variables of the corresponding integer types.
{|
|+ Allowed integer values
|-
| Type
| Integer interval
| Unsigned hexadecimal representation
|-
| <eiffel>INTEGER_8</eiffel>
| <code>-128 .. 127</code>
| <code>0x0 .. 0xFF</code>
|-
| <eiffel>INTEGER_16</eiffel>
| <code>-32768 .. 32767</code>
| <code>0x0 .. 0xFFFF</code>
|-
| <eiffel>INTEGER_32</eiffel>
| <code>-2147483648 .. 2147483647</code>
| <code>0x0 .. 0xFFFFFFFF</code>
|-
| <eiffel>INTEGER_64</eiffel>
| <code>-9223372036854775808 .. 9223372036854775807</code>
| <code>0x0 .. 0xFFFFFFFFFFFFFFFF</code>
|}
* Excluded nonsignificant leading zeroes from determination of allowed integer constant type, so that <code>00000000000000123</code> is now a valid <eiffel>INTEGER_8</eiffel> value.
* Shared the same data accross once routines and string constant attributes from different generic derivations of the same class. Added a warning for once routines that appear in a generic class to notify about this change in semantics.
* Correctly supported replication of once features when compiling for .NET.
* Changed order of evaluation of once routines to check precondition with class invariant even when once routine has already been called.
* Added a check that length of identifier, manifest string and free operator does not exceed a maximum value of 32767 bytes.
===Compiler issues===
* Fixed crash of the compiler at the very end of a finalization of a system which has an assignment of a manifest type into a variable of type <eiffel>ARRAY</eiffel> [<code>like</code> <eiffel>anchor</eiffel>] where <eiffel>anchor</eiffel> is a feature being redefined with a different type in a descendant class.
* Fixed an issue where compiler would report more than once the same error in an incremental recompilation.
* Fixed issue where changing a normal routine to an external and having a compile error, and then reverting back to a normal routine while fixing the error would cause the compiler to crash.
* Fixed some cases where project could be corrupted after a recompilation.
* Now compiler reports <code>VTCT</code> errors at the end of degree 5, rather than during degree 5, so that you can collect all the <code>VTCT</code> errors at once.
* Thanks to the improvement in <code>VTCT</code> errors reporting, now compiler will not generate an incorrect <code>VTCT</code> errors during an incremental recompilation for a class which has actually been removed from the system.
* Supported recompilation of once routines when their status is changed from "process-relative" to "thread-relative" or back.
* Supported output of multi-line obsolete messages.
* Fixed a recompilation bug that resulted in incorrect (or even, in case of .NET, in invalid) generated code when incrementally finalizing a system without explicitly specified root creation procedure.
* Fixed a bug with resolving some generic-like types (i.e., types that are processed in a special way: tuple, native array, typed pointer) that depend on anchored types: before they were converted to "normal" generic types thus loosing their special properties.
* Fixed a bug that caused compiler to crash when finalizing a code that looks like
<code>if true then [else(if) ...] end</code>
i.e. has empty compound for a primary condition which is a constant <code>true</code>.
* Fixed a bug in processing configuration option <code>precompiled</code> that caused a compiler to crash when no option value was provided.
* Fixed a bug in incremental recompilation when multi-branch validity rules are violated in one class because constant attribute used in the multi-branch instruction is changed in another class, that declares them, into a non-constant feature.
* Fixed multiple bugs in feature basic text view that caused truncated or extraneous output.
* Fixed bug where if an actual generic parameter was an anchor, then if the type containing this actual was used for assignment attempt or for creation we would use an incorrect type for the actual generic. We were using the type of the anchor in the class were the code was written, instead of actually re-evaluating the type of the anchor for each descendant class.
===Runtime/code generation issues===
* Fixed bug in <eiffel>deep_twin</eiffel> from <eiffel>ANY</eiffel> in .NET which would cause a call on Void target when applied on object of type <eiffel>STRING</eiffel> and possibly other types.
* Corrected C code on Windows for constants of type <eiffel>INTEGER_64</eiffel>. Before constants of this type between <code>-2147483648</code> and <code>-1</code> could be processed as positive 64-bit values.
* Fixed incorrect C and IL code generation for <eiffel>INTEGER_8</eiffel> and <eiffel>INTEGER_16</eiffel> arithmetic and shift operations that might produce incorrect result when combined in two or more operations in a row. For example,
<code>i := (i + i) |>> 1</code>
assigned <code>-128</code> to <code>i</code> of type <eiffel>INTEGER_8</eiffel> if the initial value of <code>i</code> was <code>-128</code>. Now this instruction assigns <code>0</code>.
* Synchronized access to data of process-relative once routines to avoid race conditions when two or more threads simultaneously access the same once routine.
* Avoided permanent blocking of a thread accessing process-relative once routine when this routine is concurrently evaluated in some other thread and raises an exception.
* Fixed bugs in memory allocation in C code for result of a once function that returns basic type:
** it might cause memory corruption when memory size required to store the result is greater than size of a pointer;
** there was a memory leak.
* Fixed a bug in classic mode that caused last exception to be cleared after returning from a routine that has a rescue clause but returns normally.
* Fixed several bugs related to handling of nested exceptions in classic mode.
* Changed a limit of maximum class name length in melted byte code from 256 bytes to 32767 bytes.
* Changed C code generation for long strings (that result from long manifest strings, identifiers, etc.) to avoid restrictions imposed by some C compilers on long string literals (in particular, by the Microsoft C compiler <code>cl</code> that issued error C2026).
* Fixed a bug in finalized C code generation when calling <code>Precursor</code> in a routine which is recursively calling itself before the call to <code>Precursor</code>. Instead of generating the call to <code>Precursor</code> we would generate a recursive call to the routine.
* Fixed a bug where calls to <eiffel>standard_is_equal</eiffel> from <eiffel>ANY</eiffel> on objects whose type is generic would yield <code>False</code> where it should have been <code>True</code>.
===.NET issues===
* Corrected processing of literal floating point fields from external assemblies (such as <eiffel>System</eiffel><code>.</code><eiffel>Math</eiffel><code>.</code><eiffel>PI</eiffel>) to obtain proper values.
* Fixed a bug where the value -1 was actually 255 on .NET.
* Fixed issue where declaring a <eiffel>NATIVE_ARRAY</eiffel> of a .NET expanded type would be rejected by the compiler.
* Fixed issue where assigning a .NET expanded type to an entity of type <eiffel>ANY</eiffel> would be rejected by the compiler.
* Fixed a crash in the compiler when generating the code for a class which inherits from a .NET class and from an Eiffel class which has some anchored types.
* Fixed a bug in assertion monitoring that could lead to wrong monitoring of assertions that are evaluated concurrently in different threads.
* Fixed a bug in code generation for entry point of executable when root procedure is a redeclaration of a deferred feature that caused an exception <code>MissingMethodException</code> to be raised on startup of such an application.
* Fixed a bug in code generation when solely inheriting from a .NET interface.
* Fixed a bug in code generation when inheriting from a .NET class which has a routine whose name is identical to one of the routine of <eiffel>ANY</eiffel>.
* Fixed a bug in code generation of custom attributes encoding in the case of a named argument whose base type is a .NET enum type.
* Improved <eiffel>conforms_to</eiffel> from <eiffel>ANY</eiffel> so that even though full generic conformance is still not yet supported, it checks it properly when the base class are the same.
===Store/Retrieve issues===
* Fixed an issue where the GC would be disabled after a failure in a retrieval operation.

67
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-56-and-ise-eiffel-57.wiki Normal file
View File

@@ -0,0 +1,67 @@
[[Property:title|Major changes between ISE Eiffel 5.6 and ISE Eiffel 5.7]]
[[Property:link_title|5.7]]
[[Property:weight|-14]]
==What's new==
{{seealso|See also: [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
* Support for new expanded semantics defined in ECMA-367. The current limitations are: no copy semantics in the .NET code generation, and still no generic conformance.
* Inline agents as defined in ECMA-367 with the limitation to only accept the do form.
* Added possibility to define agents on attributes or externals.
* Named tuples as defined in ECMA-367.
* Added <eiffel>PREDICATE</eiffel> class for agent based on boolean queries.
* Added <eiffel>CHARACTER_32</eiffel> for Unicode support.
==Improvements==
* Improved memory management:
** Ensure that if a block of allocated memory is not used it will eventually be freed. Before it will only be freed if it was the last allocated block.
** Compaction is actually working. Before it was working if you had a lot of dead objects, now it will compact even if all you have is alive objects and that the memory is fragmented.
** For large memory heap (i.e. larger than 1GB) improved speed of collections where there is a lot of dead objects.
* Changed the way we search melted file, it is done in the following order:
** Directory specified by environment parameter MELT_PATH
** Current working directory
** Directory where application is launched
** Original directory where .melted file was generated the first time.
* Improved speed of initial compilation of .NET projects as well as the speed for incremental compilation at degree 6 which went from a few seconds to no time if no new assemblies have been added to the system.
* No freeze is required when adding an agent, saving you time since C compilation can be long for very large project.
* Reduced the required disk space for a workbench compilation in classic mode (went from 1.8 GB to 1GB for a very large project).
* Improved speed of agent calls in classic mode.
* Support use of IL enumerations with underlying integer types different from System.Int32. In particular, the built-in features `to_integer' and `from_integer' now use the underlying type rather than System.Int32.
* Support generation of IL properties as well as custom attributes for them.
* Support the new syntax without the <code>is</code> keyword in the feature declaration.
* Allowed bracket expressions to be used as a target of a qualified feature call (this is an extension to ECMA standard that does not permit this syntax at the moment).
* Added checks for <code>VYCP(2,3)</code> and <code>VYCQ(2,3)</code> (validity rules for conversion features to prohibit conversion to conforming types).
==Changes==
* <code>VWEQ</code> is not an error, but a warning that can be triggered or not depending on your configuration.
* Inherited assertions are rechecked each time that a feature is redefined, meaning that some errors that were not previously detected by the compiler can now be found.
==Bug fixes==
* Fixed an issue with x2c if you had inlined C code which contains comments with single or double quote. Then it will not properly convert .x into .c file.
* Fixed bugs in code generation for once manifest strings that caused "index out of bounds" exception, void results.
* Fixed a bug in processing synonyms of a routine with an indexing clause that might cause a compiler crash, in particular this could happen for synonyms of a global once routine.
* Fixed a bug in recompilation of a once routine that changes its process-relative status into thread-relative one or back in multithreaded finalized mode that can cause C compilation to fail due to unresolved externals.
* Corrected inlining of routines redeclared into attributes or into routines with a different internal/external status.
* Fixed a bug in incremental recompilation of queries with assigner commands.
* Added detection of a <code>VUEX</code> error for static feature calls used in intervals of a multibranch instruction.
===Compiler issues===
* Added a new validity error <code>VTEC(3)</code> to report unsupported inheritance hierarchy under .NET when an expanded type is based on a class with an external ancestor.
* Not supported reverse attachment of boxed built-in .NET value types to Eiffel reference types such as <eiffel>NUMERIC</eiffel>, <eiffel>HASHABLE</eiffel>, etc.
===Runtime/code generation issues===
* Ensured that our runtime is async-safe for signals for all the runtime routines using some locking mechanisms.
* Fixed a memory corruption issue in <eiffel>arycpy</eiffel> if a GC cycle was triggered as part of the processus of reallocating the SPECIAL object.
* Fixed a bug with allocating memory for once routines that caused "no memory" exception at program startup when Borland run-time is used.
===.NET issues===
* Removed limitation to inherit an Eiffel class which inherited from a .NET class.
===Store/Retrieve issues===
* Fixed a memory leak in the recoverable retrieval when an exception is raised from a <eiffel>correct_mismatch</eiffel> routine call.
* Fixed test#store008 regarding a crash when retrieving a type that does not exist in retrieved system.

71
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-57-and-ise-eiffel-60.wiki Normal file
View File

@@ -0,0 +1,71 @@
[[Property:title|Major changes between ISE Eiffel 5.7 and ISE Eiffel 6.0]]
[[Property:link_title|6.0]]
[[Property:weight|-7]]
==What's new==
{{seealso|See also: [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
* Added support for multiple constraints in formal generic parameters.
* The root class can now be a generic class, and thus one can now specify a root type.
* The notion of creation readiness according to ECMA Eiffel standard (2nd edition, chapter 8.12.12) is implemented.
* Added experimental option for full class checking. It can be enabled at the system, cluster or class level. However not all our code has been compiled with this option so don't be surprised if you get errors in our libraries. The next release should fix all the remaining issues.
* Integers can now also be specified with binary and octal representation.
* Manifest characters can now also be specified with binary, octal and hexadecimal representation. Manifest characters can be specified up to 32 Bit.
* Supported reattachment of generic derivations with expanded parameters to generic derivations with reference parameters.
==Improvements==
* The command line compiler doesn't need a configuration file to compile a system, one can simply provide a root class and the compiler will automatically use the current directory and EiffelBase. You can also add more libraries if needed.
* Improved backup mechanism so that overridden classes are copied in the library where they are defined (they were previously copied in the library where the override cluster was defined).
* Possibility for hidden/implementation clusters in libraries, i.e. clusters that are not accessible if the library is used (like libraries in libraries are not accessible).
* Class names which don't match the source filename emit a warning.
* The unique keyword will yield a syntax warning if enabled.
* Static access on external routines is allowed even if not marked frozen (this simply applies a relaxed rule that was adopted by ECMA).
* When an environment variable is being used to compile a system and if this environment variable value changes next time you use a project, you will get a prompt asking whether or not you want to update the value or keep the initial one.
* Externals (includes, objects, resources, ...) can now be relative to the ecf file by using the new replacement $ECF_CONFIG_PATH.
* UUID is not needed for non library systems. If no UUID is specified a random one will be generated.
==Changes==
* Added supplier_precondition assertion level that enables to only check preconditions of trusted libraries. By default when importing an old project they are not enabled, thus assertions on the library you are using are most likely going to be disabled.
* Added the platform value as part of the version info of the compiler. This will prevent trying to load a project compiled for a different platform instead of failing with a retrieval error.
* The compiler can be compiled against the original EiffelBase version or with the FreeELKS version which is now the default one for EiffelBase.
==Bug fixes==
* Fixed eweasel test#tuple006 showing a failure when calling <eiffel>deep_copy</eiffel> on a <eiffel>TUPLE</eiffel> instance.
* Fixed bug#12782 where compiler would crash at degree 1 when removing a formal generic parameter of class (eweasel test#incr249 and test#incr284).
* Fixed bug#12823 where specifying in the command line a target in a different case than the lower case version of the actual target name would fail to find the target in your configuration file.
* Fixed bug#12698 where compiler was not processing the target extension properly if not specified in lower case.
* Fixed bug#12591: compiler would not find classes from library referenced deeply using relative path. This also removes the extra `.' or `..' in the displayed path for a class.
* Fixed issue with incorrect labeled tuples which were not detected in signature of features (see eweasel test#tuple008).
* Fixed crash when checking an incorrect labeled tuple (e.g. <eiffel>TUPLE</eiffel> [a, a: <eiffel>INTEGER</eiffel>]) (see eweasel test#tuple009).
* Fixed issue with inline agents where if you have one and during a compilation from scratch you have a compiler error, then fixing this error and recompiling, it would crash when melting or freezing (test#incr277).
* Fixed issue with C compilation linking error when a generic class which have an invariant clause has its formal generics changed (test#incr278).
* Fixed C compilation error on Windows for trying to compile empties Cxxx directories (test#ccomp061).
* Fixed incorrect code generation of agents on attribute when target is open (test#exec264).
* Fixed incremental bug when an agent creation based on a feature whose signature changes for less arguments (test#incr276).
* Fixed a backup creation bug when two classes from the same cluster/library have the same original file name, the backup would only contain one or the other because we use the original file name. Now we use the original class name.
* Fixed various issues with the processing of the Eiffel Configuration File.
===Compiler issues===
* Adapted the compiler so that ISE_EIFFEL does not need to be defined with a short path name on Windows, since some file systems can disable support for short path.
* Fixed incrementality bug with agents where finalizing and then freezing would cause some unresolved externals.
===Runtime/code generation issues===
* Fixed a memory corruption which would occur once an invariant has been violated.
* Fixed a memory corruption which could occur when performing a deep_twin on an object whose graph contains a TUPLE object. See test#tuple006.
===.NET issues===
* Speed up consumer cache synchronization so working with large .NET caches or large assembly sets is much faster.
* Fixed bug#12565 where a wrong EIFFEL_NAME_ATTRIBUTE custom attribute would be generated on .NET for Eiffel generic class where the actual generic parameter is a .NET value type..
* Fixed bug in .NET resx to resource generation when using resx files with relative paths.
* .NET Enums can be automatically converted to INTEGERs.
* Indexing tags ''interface_metadata'' and ''class_metadata'' are supported on feature level like this is done on class level and allow to specify custom attributes for associated methods only in interface type or only in implementation type.
* All versioned COM import interfaces now have versioned interface member names based on the trailing version number of the interface name, as this meta information is not available in any other way. This greatly improves the versioned names and makes implementing interfaces much easier.
* Fixed various issues in the .NET consumer that would prevent the usage of certain .NET assemblies.
* Added configurable (project to class-level) optimization for .NET project that will mark all classes frozen if they are not descended by another.
===Store/Retrieve issues===
* Now the retrieval of objects is done with the GC (garbage collector) disabled.
* Fixed issue when retrieving 64-bit storables on 32-bit machines. It requires a regeneration of the 64-bit storables if one wants to retrieve them on 32-bit machines. Fixed bug#11744.

50
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-60-and-ise-eiffel-61.wiki Normal file
View File

@@ -0,0 +1,50 @@
[[Property:title|Major changes between ISE Eiffel 6.0 and ISE Eiffel 6.1]]
[[Property:link_title|6.1]]
[[Property:weight|-8]]
==What's new==
{{seealso|See also: [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
* Multiple errors are reported for each compilation degree.
* Experimental support for Non-conforming Inheritance has been added (Classic only). Classes may now be inherited (using inherit {NONE} but no conformance of that class is implied.
* Attachment marks are supported. Now it's possible to specify whether an entity is attached or detachable:
<code>a: !A -- a cannot be used before it is attached
b: ?A -- b can be used before it is attached</code>
Default attachment status (for types without an attachment mark) is controlled by the option ''is_attached_by_default''.
* Object test expression is a replacement for the reverse assignment construct with a new notion of scope:
<code>if {o: !A} e then do_something_with (o) end</code>
* Attached variables are subject to the new check that they are properly set before use, in particular, attached attributes must be set by a creation procedure and all attached local variables must be set before they are used. The checks are performed when the option ''is_void_safe'' is turned on.
* A feature call can be performed only on an attached target if the option ''is_void_safe'' is turned on.
* Certified attachment patterns (CAP) are used to identify additional cases when an entity is attached (controlled by the option ''is_void_safe''). In particular, the following code is considered void-safe:
<code>f (a: ?ANY)
do
if a /= void then
x := a.out
end
end</code>
==Improvements==
* Improved speed of degree 3. Improvements are even more visible when the checking of inherited features in their descendants is enabled.
==Changes==
* No major known changes.
==Bug fixes==
* Fixed an issue where the version of <eiffel>default_create</eiffel> from <eiffel>ANY</eiffel> would not yield a dynamic binding if statically it had an empty body (See test#exec280).
===Compiler issues===
* The options ''is_void_safe'' and ''is_attached_by_default'' are not tracked during recompilation, so in order to take any changes in their settings, the project has to be recompiled from scratch.
* Object test is not permitted inside a precondition or a check instruction.
* Object tests inside a feature should use different names for the corresponding locals.
===Runtime/code generation issues===
* Non-conforming inheritance dynamic conformance only works with Classic compilations, for .Net non-conforming inheritance has no effect on code generation
* Implemented time accounting on Windows.
===Store/Retrieve issues===
* Fixed a potential dead lock when an exception occurs while retrieving an object in a multithreaded environment (See test#store012).

52
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-61-and-ise-eiffel-62.wiki Normal file
View File

@@ -0,0 +1,52 @@
[[Property:title|Major changes between ISE Eiffel 6.1 and ISE Eiffel 6.2]]
[[Property:link_title|6.2]]
[[Property:weight|-9]]
==What's new==
{{seealso|See also: [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
* Exceptions as objects are now implemented.
* Added support for new ~ operator which can compare 2 objects safely regardless of their type.
* Added detection of harmful catcall at runtime (harmless ones are currently ignored).
* Added support for `note' keyword with a migration path in case `note' is being used as an identifier in your code.
* Added `-gc_stats' option to get some information on how much CPU time is spent in GC during an Eiffel compilation.
* Introduced several new much more powerful CAPs that now can be applied not only to read-only entities, but also to local variables (including <code>Result</code>), and can take into account execution paths as well as some obvious void-safe patterns.
==Improvements==
* Improved speed of compiler by a significant factor for large system.
* Generated code is about 3-4% faster with a size reduction of about 2-3%.
* Improved number of dynamic to static bindings in finalized code. Improved quality of inlined code for reducing even more of the dynamic calls.
* Reduced the size of the AST stored in memory during a compilation by 20/25% which results in a memory usage reduction for EiffelStudio of about 15%. For example when compiling EiffelStudio on Windows 64-bit, it was taking 920MB with the previous version, and now it would be 800MB.
* Fixed performance issue with {<eiffel>SPECIAL</eiffel>}.<eiffel>clear_all</eiffel> when handling a special of reference.
* Removed <code>VUOT(2)</code> that required that the type of an object test local is attached.
==Changes==
* Protected several calls to `eif_wean' on the same EIF_OBJECT. This will prevent a memory corruption for people using it incorrectly with a minor slow down since in a typical application there should not be too many protected objects.
* Removed <code>VFAV(4)</code> validity error that is no longer specified in the standard.
* Due to new meaning of ~, the old syntax for agents is not being supported anymore. If you still have some code using the old agent syntax, compile it with 6.1 with syntax warning enabled to fix your code before upgrading to 6.2.
==Bug fixes==
===Language issues===
* Fixed various limitations with support of attached types in 6.1, including support for
** attachment marks for tuple types and formal generics
** object tests in class invariants
===Compiler issues===
* Fixed eweasel test#final046 by avoiding useless creation of temporary objects during dynamic dispatch. It can also dramatically speed up certain kinds of code; on the compiler itself, the speed up is about 8-10%. In the worst case scenario it is 400% or more. Note this bug was introduced in version 6.0. Compared to 5.7, in 6.2 the worst case scenario is still about 10% slower.
* Fixed an incorrect code generation for `is_equal' in ANY when exception trace is off which could cause a memory corruption.
* Fixed various issues with compiler when inlining is enabled.
* Fixed compiler crash when compiling a class where a type used in a signature of a feature has the wrong number of generic parameters. Fixed eweasel test#incr285.
* Fixed an incorrect code generation for the dynamic binding of routines defined in generic classes and attribute access in general. Fixed eweasel test#exec272 and test#final039.
* Fixed eweasel test#melt081 where having a redefined routine involving an anchor to a non-existing feature would crash the compiler instead of reporting a VEEN error.
* Various bug fixes with respect of handling of expanded generic classes used in generic classes.
===Runtime/code generation issues===
* Changed the usage of `eif_adopt', `eif_protect', `eif_wean', `eif_freeze' and `eif_unfreeze' so that they can be used in concurrent thread, meaning that it is safe to use them as long as the argument is different in various threads.
===Store/Retrieve issues===
* Fixed some issues with the storing or retrieving of generic expanded types.

16
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/index.wiki Normal file
View File

@@ -0,0 +1,16 @@
[[Property:title|Compiler History]]
[[Property:weight|-8]]
* [[Major changes between ISE Eiffel 6.0 and ISE Eiffel 6.1|Major changes between ISE Eiffel 6.0 and ISE Eiffel 6.1]]
* [[Major changes between ISE Eiffel 5.7 and ISE Eiffel 6.0|Major changes between ISE Eiffel 5.7 and ISE Eiffel 6.0]]
* [[Major changes between ISE Eiffel 5.6 and ISE Eiffel 5.7|Major changes between ISE Eiffel 5.6 and ISE Eiffel 5.7]]
* [[Major changes between ISE Eiffel 5.5 and ISE Eiffel 5.6|Major changes between ISE Eiffel 5.5 and ISE Eiffel 5.6]]
* [[Major changes between ISE Eiffel 5.4 and ISE Eiffel 5.5|Major changes between ISE Eiffel 5.4 and ISE Eiffel 5.5]]
* [[Major changes between ISE Eiffel 5.3 and ISE Eiffel 5.4|Major changes between ISE Eiffel 5.3 and ISE Eiffel 5.4]]
* [[Major changes between ISE Eiffel 5.2 and ISE Eiffel 5.3|Major changes between ISE Eiffel 5.2 and ISE Eiffel 5.3]]
* [[Major changes between ISE Eiffel 5.1 and ISE Eiffel 5.2|Major changes between ISE Eiffel 5.1 and ISE Eiffel 5.2]]
* [[Major changes between ISE Eiffel 5.0 and ISE Eiffel 5.1|Major changes between ISE Eiffel 5.0 and ISE Eiffel 5.1]]
* [[Major changes between ISE Eiffel 4.5 and ISE Eiffel 5.0|Major changes between ISE Eiffel 4.5 and ISE Eiffel 5.0]]

85
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/differences-between-etl-2nd-printing-and-eiffel-software-implementation.wiki Normal file
View File

@@ -0,0 +1,85 @@
[[Property:title|Differences between ETL 2nd printing and Eiffel Software implementation]]
[[Property:link_title|]]
[[Property:weight|-9]]
{{seealso|See also: [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
==Added classes==
* New basic classes have been added: <eiffel>INTEGER_8</eiffel>, <eiffel>INTEGER_16</eiffel>, <eiffel>INTEGER_64</eiffel> and <eiffel>WIDE_CHARACTER</eiffel>. <eiffel>INTEGER</eiffel> is now specified as having a 32 bits representation
* New <eiffel>TUPLE</eiffel>, <eiffel>ROUTINE</eiffel>, <eiffel>PROCEDURE</eiffel> and <eiffel>FUNCTION</eiffel> classes required by the agent mechanism.
==Added keywords==
* <code>Precursor</code>
* <code>reference</code>: new keyword to specify that a type is used as a reference type.
* <code> agent</code>: new keyword used by the agent mechanism.
* <code>create</code>: Instead of using the famous exclamation mark to create an instance of a class, you can use the keyword <code>create</code>. Below you will find a correspondence table between the old and the new syntaxes. The old syntax is still valid, but at some points Eiffel Software will remove it from its implementation:
{|
|-
| Old syntax
| New syntax
|-
| !! a
| <code>create</code> a
|-
| !! a.make
| <code>create</code> a.make
|-
| !<eiffel>B</eiffel>! a
| <code>create</code> {<eiffel>B</eiffel>} a
|-
| !<eiffel>B</eiffel>! a.make
| <code>create</code> {<eiffel>B</eiffel>} a.make
|}
==Added semantics==
* [[7 Genericity and Arrays|Generic creation]]
* Expression creation: you can now create an object within an expression. For example, you want to create an object and pass it as an argument to a function. Whereas you had to create a local variable, create the object and pass it to the function, you now simply need to pass to the function the creation expression. Here is a small example:
{|
|-
| Old method
| New method
|-
|
<code>
local
a: STRING
do
!! a.make (10)
f (a)
end
</code>
|
<code>
do
f (create {STRING}.make (10))
end
</code>
|}
This is also very useful since it can improve the power of assertions.
* Mutually recursive constraints: one can now write class A [H, G->H] or class B [H -> C, G -> ARRAY [H]]. As a result, the declaration A [D, E] is valid only if E is a descendant of D. Similarly, the declaration B [E, ARRAY [D]] is not valid, if E is a descendant of D.
* [[10 Other Mechanisms|Tuples]]
* [[11 Agents|Agents]]
* Feature access: <br/>
<code>
local
value: INTEGER
do
value := {MY_CLASS}.value
end
</code>
<br/>
The previous call is valid, if and only if:
** <eiffel>value</eiffel> is a feature representing a constant of a basic type (<eiffel>INTEGER</eiffel>, <eiffel>DOUBLE</eiffel> or <eiffel>CHARACTER</eiffel>)
** <eiffel>value</eiffel> is a C/C++/DLL external feature
** <eiffel>value</eiffel> is an IL static external feature
==Added external support==
Look at the page for [[C externals|C]] and [[C++ Externals|C++]] with the introduction of `struct' and C++ external features encapsulation.

337
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/differences-between-standard-ecma-367-and-eiffel-software-implementation.wiki Normal file
View File

@@ -0,0 +1,337 @@
[[Property:title|Differences between standard ECMA-367 and Eiffel Software implementation]]
[[Property:weight|-10]]
==Kernel classes==
{|
|-
| <center>'''Feature'''</center>
| <center>'''Example'''</center>
| <center>'''ETL2'''</center>
| <center>'''ECMA-367'''</center>
| <center>'''EiffelStudio'''</center>
|-
| Fictitious class for tuples
| <eiffel>TUPLE</eiffel>
| No
| Yes
| Yes
|}
==Features==
{|
|-
| <center>'''Feature'''</center>
| <center>'''Example'''</center>
| <center>'''ETL2'''</center>
| <center>'''ECMA-367'''</center>
| <center>'''EiffelStudio'''</center>
|-
| Prefix and infix feature names
| <code>infix "+"</code>
| Yes
| No
| Yes
|-
| Operator and bracket aliases
| <code>add alias "+"</code>
| No
| Yes
| Yes, except for new rules for free operator names
|-
| Assigner command
| <code>item alias "[]" (index: INTEGER): G assign put</code>
| No
| Yes
| Yes
|}
==Genericity==
{|
|-
| <center>'''Feature'''</center>
| <center>'''Example'''</center>
| <center>'''ETL2'''</center>
| <center>'''ECMA-367'''</center>
| <center>'''EiffelStudio'''</center>
|-
| Mutually recursive constraints
| <code>A [H, G -> H]</code><br/>
<code>B [H -> C, G -> ARRAY [H]]</code>
| No
| Yes
| Yes
|-
| Full mutually recursive constraints
| <code>A [H -> G, G -> H]</code><br/>
| No
| Yes
| Yes
|-
| Expandedness restriction on formal generic
| <code>A [reference G]</code><br/>
<code>B [expanded H]</code>
| No
| No
| Yes
|}
==Creating objects==
{|
|-
| <center>'''Feature'''</center>
| <center>'''Example'''</center>
| <center>'''ETL2'''</center>
| <center>'''ECMA-367'''</center>
| <center>'''EiffelStudio'''</center>
|-
| Implicit creation procedure (version of <code>ANY.default_create</code>)
| <code>class A feature ... end</code><br/>
<code>-- The following instructions are equivalent:</code><br/>
<code>create {A} a</code><br/>
<code>create {A} a.default_create</code>
| No
| Yes
| Yes
|-
| Bang-bang syntax
| <code>!! a</code><br/>
<code>!! a.make</code><br/>
<code>!B! a</code><br/>
<code>!B! a.make</code>
| Yes
| No
| Yes, marked as obsolete
|-
| Keyword syntax
| <code>create a</code><br/>
<code>create a.make</code><br/>
<code>create {B} a</code><br/>
<code>create {B} a.make</code>
| No
| Yes
| Yes
|-
| Creation expression
| <code>print (create {TIME}.make_now)</code>
| No
| Yes
| Yes
|-
| [[7 Genericity and Arrays|Generic creation]]
| <code>create {G} x.make</code>
| No
| Yes
| Yes
|}
==Attachment==
{|
|-
| <center>'''Feature'''</center>
| <center>'''Example'''</center>
| <center>'''ETL2'''</center>
| <center>'''ECMA-367'''</center>
| <center>'''EiffelStudio'''</center>
|-
| Preserving expandedness status when attaching expanded object to reference entity
| <code>x</code> <code>:=</code> <code>y</code>
| No, object is copied to new object of the corresponding reference type
| Yes
| Yes, except for TYPED_POINTER that is converted to POINTER before reattachment
|-
| Reverse assignment
| <code>x</code> <code>?=</code> <code>y</code>
| Yes
| No
| Yes
|}
==Feature calls==
{|
|-
| <center>'''Feature'''</center>
| <center>'''Example'''</center>
| <center>'''ETL2'''</center>
| <center>'''ECMA-367'''</center>
| <center>'''EiffelStudio'''</center>
|-
| Precursor call
| <code>Precursor</code>
| No
| Yes
| Yes
|-
| Non-object call
| <code>c := {COLOR}.green</code>
| No
| Yes
| Yes
|-
| Assigner call
| <code>x</code> <code>[</code><code>i</code><code>]</code> <code>:=</code> <code>x</code> <code>[</code><code>i</code><code>]</code> <code>+</code> <code>1</code>
| No
| Yes
| Yes
|-
| Bracket expression as call target
| <code>x</code> <code>[</code><code>i</code><code>]</code><code>.</code><eiffel>update</eiffel>
| No
| No
| Yes
|}
==Void safety==
{|
|-
| <center>'''Feature'''</center>
| <center>'''Example'''</center>
| <center>'''ETL2'''</center>
| <center>'''ECMA-367'''</center>
| <center>'''EiffelStudio'''</center>
|-
| Attachment marks
| <code>a: !ANY</code> <br/>
<code>b: ?ANY</code>
| No
| Yes, attached by default
| Yes, default attachment status is controlled by option ''is_attached_by_default''
|-
| Object test
| <code>{o: !STRING} e</code>
| No
| Yes
| Yes, all object tests should use different names for locals inside a feature, object tests are not permitted in preconditions and check instructions
|-
| Attached target of a call
| <code>x.f</code>
| No
| Yes
| Yes, by option ''is_void_safe''
|-
| Properly set variable
| <code>x := value</code> <br/>
<code>use (x)</code>
| No
| Yes
| Yes, by option ''is_void_safe''
|}
==Expressions==
{|
|-
| <center>'''Feature'''</center>
| <center>'''Example'''</center>
| <center>'''ETL2'''</center>
| <center>'''ECMA-367'''</center>
| <center>'''EiffelStudio'''</center>
|-
| Bracket expression
| <code>y := x [i]</code>
| No
| Yes
| Yes
|-
| Creation expression
| <code>set_buffer (create {STRING}.make (100))</code>
| No
| Yes
| Yes
|-
| Manifest type
| <code>{MY_TYPE}</code>
| No
| Yes
| Yes
|-
| Manifest [[10 Other Mechanisms|tuple]]
| <code>[a, b, c]</code>
| No
| Yes
| Yes
|-
| [[11 Agents|Agent]]
| <code>list.do_all (agent print (?))</code>
| No
| Yes
| Yes
|-
| Once manifest string
| <code>once "abc"</code>
| No
| Yes
| Yes
|}
==Constants==
{|
|-
| <center>'''Feature'''</center>
| <center>'''Example'''</center>
| <center>'''ETL2'''</center>
| <center>'''ECMA-367'''</center>
| <center>'''EiffelStudio'''</center>
|-
| Verbatim string
|
<code>x := "[
This string is left-adjusted.
]"
y := "{
This string is used "as is".
}"</code>
| No
| Yes
| Yes
|-
| Manifest type qualifier
| <code>{INTEGER_8} 123</code>
| No
| Yes
| Yes
|-
| Non-decimal integer
| <code>0xFF</code>
| No
| Yes
| Hexadecimal integers
|-
| Integer with intermediate underscores
| <code>1_000 0xFFFF_0000</code>
| In groups by 3 digits
| Yes
| Yes
|}
==Interfacing with external software==
{|
|-
| <center>'''Feature'''</center>
| <center>'''ETL2'''</center>
| <center>'''ECMA-367'''</center>
| <center>'''EiffelStudio'''</center>
|-
| Access to software written in C
| Basic syntax for any external software
| Registered sub-language
| See details for [[C externals|C externals]]
|-
| Access to software written in C++
| Basic syntax for any external software
| Registered sub-language
| See details for [[C++ Externals|C++ externals]]
|-
| Access to dynamically loaded libraries (DLLs)
| Basic syntax for any external software
| Registered sub-language
| No
|-
| Other external software
| Basic syntax for any external software
| Unregistered sub-language
| No
|}

68
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/dynamic-library-generation/definition-file.wiki Normal file
View File

@@ -0,0 +1,68 @@
[[Property:title|Definition file]]
[[Property:weight|2]]
The syntax is pretty simple when you understand what you need to export a feature: you need the name of the '''feature''', the name of the concerned '''class''', and the name of a '''creation procedure'''. What is optional is to specify an '''alias''', an '''index''' and a '''calling convention'''. The index and calling convention are mainly used to create a DLL for windows, and the alias to export the feature under a different name.
===Syntax===
{|
|-
| '''Export_feature'''
| Class_name [Creation_part] ":" Feature [Optional_part]
|-
| '''Creation_part'''
| "(" feature_name ")"
|-
| '''Optional_part'''
| [Index_part] [Alias_part]
|-
| '''Index_part'''
| "@" integer
|-
| '''Alias_part'''
| "Alias" alias_name
|-
| '''Call_type_part'''
| "call_type" call_type_name
|}
===Example===
<code>ROOT_CLASS (make): foo @ 4 Alias my_foo call_type __stdcall</code>
===Constraint===
<div>
* on the class: <div>The class cannot be deferred or generic.</div>
* on the feature: <div>It could be any feature except an attribute, an external feature or a deferred feature.</div>
* on the creation procedure: <div>It must have zero argument, and no return type.</div>
* on the alias name: <div>It must be a valid name for a C function.</div>
* on the index: <div>It must be strictly positive.</div>
* on the call type: <div>It must be a valid call type for the targeted platform (useful for Windows only). For Visual C++, the valid calling conventions are __stdcall, __cdecl and __fastcall.</div>
For each feature the required fields are the '''class''', the '''creation procedure''', and of course the '''feature''' itself.
* If the feature is a creation procedure then do not specify any creation, it will use the feature as creation. For example '''ROOT_CLASS: make'''.
* If the class has no creation procedure, do not specify any creation. default_create will be automatically used.
===A definition file===
<code>
-- EXPORTED FEATURE(s) OF THE SHARED LIBRARY
-- SYSTEM : demo
-- CLASS [BAR]
-- Here get_string uses make_b as creation
BAR (make_b) : get_string
-- Here print_bar uses make_a as creation
BAR (make_a) : print_bar
-- CLASS [ROOT_CLASS]
-- Here the feature is also a creation
ROOT_CLASS : make
ROOT_CLASS (make) : foo
ROOT_CLASS (make) : test_bar</code>
</div>

29
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/dynamic-library-generation/dynamic-library-builder.wiki Normal file
View File

@@ -0,0 +1,29 @@
[[Property:title|Dynamic library builder]]
[[Property:weight|1]]
In order to facilitate the creation of C dynamic libraries using EiffelStudio, a wizard helps generate the definition files used to define the contents of the shared library. If for some reason you need to override the wizard, the [[Definition file|syntactic rules]] of the definition files are available, but their knowledge is not necessary to use the generation of dynamic libraries in EiffelStudio.
The wizard is accessible in the '''Tools'''/ '''Dynamic library builder''' menu.
The dynamic library window that appears when selecting this menu is mainly composed of a list which contains all features that should be exported. This list is course empty at first.
[[Image:shared-library-window]]
{{note| '''Note''': The layout of this wizard is slightly different on Windows and on Unix systems, because the index and calling convention fields never appear on Unix systems. }}
To add a new feature to the definition file, you can either:
* Pick the feature from any place in EiffelStudio and drop it into the list. If several creation procedures exists in the container class, a dialog is popped up to give the choice between all possible creation procedures.
* Or, use the Add command [[Image:16x16--general-add-icon]] in the '''Edit'''/ '''Add''' menu. This pops up a dialog where it is possible to enter manually all parameters for the exported feature.
[[Image:new-exported-feature]]
Other commands of the '''Edit''' menu allow you to remove [[Image:16x16--general-delete-icon]] exported features or to modify their export parameters [[Image:16x16--general-edit-icon]] .
It is also possible to check the validity of the definition file. This command [[Image:view-unmodified-icon]] performs both a global check, to ensure that for example two features do not have the same name or same index in the library, and also local checks, that check for each feature that the parameters are valid.
Other commands, located in the '''File''' menu, give standard file operations, such as opening [[Image:general-open-icon]] a definition file, creating a new definition file [[Image:new-document-icon]] ,or saving the current definition file [[Image:16x16--general-save-icon]] .
{{tip| '''Tip''': Although the wizard can handle several files during the same EiffelStudio session, remember that only one file can be used in the project settings to effectively generate a shared library. }}

46
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/dynamic-library-generation/dynamic-library-generated-files.wiki Normal file
View File

@@ -0,0 +1,46 @@
[[Property:title|Dynamic library: Generated files]]
[[Property:weight|3]]
Basically, once the Eiffel definition file is created, the compiler will generate a set of files and will compile them to generate the Dynamic library into the ''EIFGENs/target_name/W_code'' or ''EIFGENs/target_name/F_code'' directory.
{{note| '''Note''': To generate and compile these files, you have to indicate the definition file that should be used in the [[Advanced Options|advanced node of the project settings]] of your system. This way EiffelStudio will know which one to use. If you do not specify any definition file, nothing will be generated. }}
The set of files is composed of:
<div>
* EIFGENs/target_name/W_code/'''system.def''' (or F_code)
* EIFGENs/target_name/W_code/'''edynlib.c''' (or F_code)
* $(ISE_EIFFEL)/studio/spec/$(ISE_PLATFORM)/templates/'''egc_dynlib.template''' <br/>
this file will be copied during the compilation into the EIFGENs/target_name/W_code/E1 directory as '''egc_dynlib.c'''
* $(ISE_EIFFEL)/studio/spec/$(ISE_PLATFORM)/include/'''egc_dynlib.h'''
* and the Makefile
</div>
The ''system.def'' is only used on windows, it is the definition file used to generate a DLL when linking.<br/>
Information about the DLL
<code>LIBRARY demo.dll
DESCRIPTION DEMO.DLL</code>
The following are EXPORTed functions.
<code>EXPORTS</code>
This part concerns the run-time. It initializes the run-time and reclaim Eiffel objects.
<code>
;System
init_rt
reclaim_rt
</code>
The exported for the BAR class:
<code>; CLASS [BAR]
get_string
print_bar
</code>
The exported for the ROOT_CLASS class:
<code>; CLASS [ROOT_CLASS]
make
foo
test_bar</code>
The ''edynlib.c'' file is the interface between the Eiffel system and the C code. It contains the declaration and the implementation of the function used to directly call the eiffel feature with its real name.
The <span> ''egc_dynlib.c'' </span> and <span> ''egc_dynlib.h'' </span> files are used for operations performed by the run-time.

10
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/dynamic-library-generation/index.wiki Normal file
View File

@@ -0,0 +1,10 @@
[[Property:title|Dynamic library generation]]
[[Property:weight|-12]]
* [[Dynamic library generation: Introduction|Introduction]]
* [[Dynamic library builder|Dynamic library builder]]
* [[Definition file|Definition file]]
* [[Dynamic library: Generated files|Generated files]]

14
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/index.wiki Normal file
View File

@@ -0,0 +1,14 @@
[[Property:title|Compiler]]
[[Property:weight|-9]]
* [[Compiler: introduction|Introduction]]
* [[Differences between ETL 2nd printing and Eiffel Software implementation|Differences between ETL 2nd printing and Eiffel Software implementation]]
* [[Command line|Command line compiler]]
* [[External features|External features]]
* [[Dynamic library generation|Dynamic library generation]]
* [[Melting Ice Technology|Melting Ice Technology]]
* [[Supported C compilers|Supported C compilers]]
* [[Compiler History|Version History]]

16
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/melting-ice-technology.wiki Normal file
View File

@@ -0,0 +1,16 @@
[[Property:title|Melting Ice Technology]]
[[Property:weight|-15]]
EiffelStudio relies on Melting Ice Technology, the proprietary compilation mechanism of Eiffel Software, which offers three forms of compilation:
* ''melting'' for making a few changes. The fastest of the mechanisms, typically taking a few seconds after small changes. Melting time is proportional to the size of the changed parts and affected classes, while the time needed to freeze or finalize is partly proportional to the size of the whole system. As long as you do not include new external C/C++ code, a C/C++ compiler is not required. However, execution speed is not optimal. The generated executable is debuggable.
* ''freezing'' generates C code from the active system, and then compiles it into machine code; you must have a C/C++ compiler installed. You need to use this option if you add new agents or external C/C++ calls. Unless you add external code, you can re-freeze every couple of days. The rest of the time, you can melt your software to receive immediate feedback. The speed is still slower than when finalizing, but the generated executable is still debuggable.
* ''finalizing'' delivers a production version (intermediate or final) of your software. It can be used to measure its performance in operational conditions. Finalization performs extensive time and space optimizations that enable Eiffel to match the efficiency of C/C++; it also creates a stand-alone C package that you can use for cross-platform development. Because of all the optimizations involved, finalizing takes the most time, and the generated executable is not debuggable.
Melting and freezing generate an executable in the EIFGENs|target_name|W_code subdirectory of the project directory. The executable is composed of a standard executable file named after the system, and of a < ''system name''>.melted file, which is called the Eiffel update file. Although it is recommended to finalize the system when running it from outside EiffelStudio (since the performance is better), it is possible to launch a melted/frozen executable. However, the Eiffel update file is necessary, the executable alone will not run.
Basically, the Eiffel update file incorporates the changes that have been made to the system since it was last frozen. Therefore, it is very small when the system has just been frozen, and progressively becomes bigger each time the system is melted. On the contrary, the executable is only modified when the system is frozen, never when it is melted.
The contents of the Eiffel update file are in a byte code representation which is dynamically interpreted at run-time.

26
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/supported-c-compilers.wiki Normal file
View File

@@ -0,0 +1,26 @@
[[Property:title|Supported C compilers]]
[[Property:weight|-14]]
==Unix/Linux Users:==
EiffelStudio supports `gcc' on most platforms and the native`cc' compiler if it is an ANSI C compiler.
==Microsoft Visual C++ Users==
EiffelStudio supports only version 6.0 and higher of the Microsoft Visual C++ environment. You can still use older versions of the Microsoft C++ environment (version 4.1, 4.2 or 5.0) as long as you have the latest Platform SDK from Microsoft, but this won't be supported by Eiffel Software.
Normally it will automatically detect the location of the C compiler. In case it wouldn't, make sure that the Microsoft tools are correctly setup to run from the MS-DOS prompt. To do that you need to set the environment variable PATH, LIB and INCLUDE to the value specified in the file`vcvars32.bat' from the `bin' directory of the VC installation.
==Borland C++ Users:==
EiffelStudio only supports version 5.5.1 of Borland C++ which is included in the installation of EiffelStudio. We do not support any other versions.
By default the installation program will set in the registry keys the ISE_C_COMPILER key to `bcb'.
==Changing your C compiler on Windows==
You can do it in two different ways. The first one is using the registry keys of the Windows