DOCSLIB.ORG

Interfaces and Sub-Typing Interfaces Java Interface Notes

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Interfaces and Sub-Typing Interfaces Java Interface Notes Interfaces Interfaces • So far, we have talked about interfaces informally in the ordinary English sense of and the word. Sub-typing – “interface to a class tells the client how to obtain the functionality implemented in that class” • Java has a construct called interface which can be used formally for this purpose – and for doing some other really cool things… Java interface Notes Class IntPuzzle implements IPuzzle{ • Interface itself cannot be instantiated. interface IPuzzle{ …… void scramble(); public void scramble(){ – incomplete specification int tile(int r, int c); …..} • It is not enough for a class to just have implementations public int tile(int r, int c){ boolean move(char d); of interface methods; class header must also assert } …..} public boolean move(char d){ “implements I” for Java to recognize that the class …..} implements interface I. } • A class may implement several interfaces. • Name of interface: IPuzzle – (eg) class X implements IPuzzle, IRaq { • A class can implement this interface by implementing public instance methods with the names and type ……} signatures specified in the interface. • The class may implement other methods. 1 Example of code duplication Why interface construct? • Suppose we have two implementations of puzzles: • One use of interfaces: software engineering – Class IntPuzzle uses an int to hold state – specifying and enforcing boundaries between – Class ArrayPuzzle uses an array to hold state different parts of a team project, as in Puzzle • Assume client wants to use both implementations in code example. – perhaps for benchmarking both implementations to pick • But interfaces can do much more. the best one? – Interfaces let you write more “generic” code – client code has a display method as always to print out puzzles that reduces code duplication. • What would the display method look like? Class Client{ IntPuzzle p1 = new IntPuzzle(); Observation ArrayPuzzle p2 = new ArrayPuzzle(); ….display(p1)…display(p2)… • Two display methods are needed because types public static void display(IntPuzzle p){ IntPuzzle and ArrayPuzzle are different, and for (int r = 0; r < 3; r++) parameter p must have one type or the other. for (int c = 0;c<3;c++) { System.out.print(p.tile(r,c)); • Ironically, the code inside the two methods is Code duplicated System.out.print(‘ ‘); identical. because types }} – Code relies only on assumption that parameter p is passed IntPuzzle and public static void display(ArrayPuzzle p){ an object that has an instance method tile(int,int). ArrayPuzzle for (int r = 0; r < 3; r++) are different. • Is there a way to avoid this code duplication? for (int c = 0;c<3;c++) { System.out.print(p.tile(r,c)); – Use interfaces and sub-typing System.out.print(‘ ‘); }} } 2 Interfaces as types Note IPuzzle Interfaces: IPuzzle IRan IRaq IntPuzzle ArrayPuzzle Classes: AClass BClass • Name of an interface can be used as a variable type. – (eg) IPuzzle p1, p2; • Class that implements the interface is said to be a sub-type of • Since a class can implement several interfaces, it the interface type. may have many super-types. – IntPuzzle and ArrayPuzzle are sub-types of IPuzzle. • Interface is said to be a super-type of those classes. • An interface can be implemented by several – IPuzzle is a super-type of type IntPuzzle and ArrayPuzzle. classes, so it may have many sub-types. Names, Objects and Types Paradox with interfaces as types • In programming languages, like in real life, • We cannot instantiate an interface I. we attribute type both to names (variables) – Interface is a partial specification. and to objects. • If we cannot create objects of type I, why bother • Example from real life: gender permitting interface names to be types? – Two types: Male and Female – (eg) IPuzzle p1,p2; – These types are assigned to people (objects): – Fine, but what would we ever assign to p1 and p2?!! • The President of Cornell is a Male. • To understand this, let us look at a real-life • The Provost of Cornell is a Female. analogy. – These types are also assigned to names: • Male George, Sam, Helmut, Bubba; • Female Rie, Naomi, Indira, Melanie; 3 Sub-typing in real life Unisex names Human Male Female • Some names can refer to people of either gender: • Let us add a new type called Human. • Humans have certain functionalities: (eg): Sandy, Pat, Jackie – They walk upright. • How do we fit unisex names into our – They have juxtaposed thumbs. – They are intelligent…. classification? • Male and female are sub-types of type Human because they implement this functionality although in different • Here is an idea…. ways. • Like an interface, type Human cannot be instantiated directly: every human must be either a male or a female. Sub-types and subsets Human Back to names Male Female Male Female Human • Using these types, we can now give types to Sub-types Subsets unisex names as well: • Male George, Sam, Helmut, Bubba; • Sub-types and subsets are distinct concepts. • Female Rie, Naomi, Indira, Melanie; • Sub-types are characterized by some common • Human Jo, Sandy, Pat; functionality. – Sub-type female in our example is characterized by ability to give birth. • In this example, a mixture of males and females is a subset of type human, but it is not a sub-type. 4 Naming people Up-casting • Simple picture without sub-typing: • Situation is a little more complex with unisex names (sub-typing). – Male objects get male names. – Female objects get female names. • Example: Sandy = new Female(); – Type of reference returned by RHS is Female. •Examples: – Type of LHS name is Human. //we created a new male object and named it George – Nevertheless, no type error because Female is sub-type George = new Male(); //type checks of Human. //give object named Sam the alias Bubba • Up-casting: type of RHS reference is sub-type of Bubba = Sam; //type checks type of LHS name. //give object named Bubba the alias Melanie • Up-casting is always type-correct. Melanie = Bubba;//type mismatch • Example: Sandy = Laura; • In last example, we do not need to know anything about – You do not need to know the object named Laura to who Bubba is to see that there is a type mismatch. determine that the assignment is type-correct. Down-casting Resolution of paradox with • Is this type-correct? Bubba = Sandy; interfaces as types • Answer: depends. • Java allows up-casting: – Type of RHS name (reference) Sandy is Human which is super-type of LHS name – IPuzzle p1 = new ArrayPuzzle(); – Type of object named Sandy: either Male or Female – IPuzzle p2 = new IntPuzzle(); – Whether or not the assignment is legal depends not on the •Note: type of the RHS reference but on the type of the actual object. – Type of reference returned by right-hand side • Down-casting: Type of LHS name is sub-type of RHS expression of first statement is ArrayPuzzle. reference. – Type of variable on left-hand side is IPuzzle. • Down-casting may or may not be legal – Two types are different, but type of rhs reference is a – need to look at object to determine legality sub-type of type of the variable. 5 Your code Why up-casting? Class IntPuzzle implements IPuzzle{ • Sub-typing and up-casting allow you to avoid …scramble()…tile()…move()…twist() code duplication in many situations. } • Puzzle example: you and client agree on interface Class ArrayPuzzle implements IPuzzle{ IPuzzle. ……scramble()...tile()…move()… } interface IPuzzle{ void scramble(); Class IntPuzzle implements a method called twist int tile(int r, int c); which is not a method of interface IPuzzle. boolean move(char d); } Client Code Method execution public static void display(IPuzzle p){ Class Client{ for (int r = 0; r < 3; r++) IntPuzzle p1 = new IntPuzzle(); for (int c = 0;c<3;c++) { ArrayPuzzle p2 = new ArrayPuzzle(); System.out.print(p.tile(r,c)); ….display(p1)…display(p2)… Up-casting: System.out.print(‘ ‘); Objects of type IntPuzzle }} public static void display(IPuzzle p){ and ArrayPuzzle are for (int r = 0; r < 3; r++) passed to parameter of • Subtle point: which tile method is invoked in code shown for (int c = 0;c<3;c++) { type IPuzzle. above? System.out.print(p.tile(r,c)); – tile method in IntPuzzle class?? System.out.print(‘ ‘); • What if object passed in is of type ArrayPuzzle? }} – tile method in ArrayPuzzle class?? } • What if object passed in is of type IntPuzzle? – tile method in IPuzzle interface?? • Huh?? • To understand this, let us look again at execution model. 6 Program area IntPuzzle: ..scramble..tile…move… ArrayPuzzle:..scramble..tile..move.. Resolving the name “p.tile” Heap • Stack frame for invocation of display has storage for variables p,r,c. Stack IntPuzzle • Suppose method is passed an IntPuzzle object in parameter p as shown. c i: ArrayPuzzle r i: • Invocation “p.tile(r,c)” in body of display is p IPuzzle: scramble executed as discussed earlier: tile scramble – Look up method tile in object O referenced by p. move tile – Invoke that method passing it this (object O),r,c. move – In our example, therefore, we would invoke the tile method implemented in the IntPuzzle class. Note on type-checking Think public static void display(IPuzzle p){ • Type of paramater p: IPuzzle for (int r = 0; r < 3; r++) – IPuzzle itself does not have a tile method! for (int c = 0;c<3;c++) { • Actual method that gets invoked is implemented System.out.print(p.tile(r,c)); sometimes in the ArrayPuzzle class and System.out.print(‘ ‘); sometimes in the IntPuzzle class! }} • Dynamic method binding: • Compile-time check: does type of reference p (IPuzzle) – Name “p.tile” is not resolved to a single method. have a method called tile with the right type signature? If – In different invocations, name may be resolved to not, error. different methods. • Runtime: go into object referred to by p and look up its tile • Method display is sometimes said to be a method.
Load more

Recommended publications
  • Metaclasses: Generative C++
    Metaclasses: Generative C++ Document Number: P0707 R3 Date: 2018-02-11 Reply-to: Herb Sutter ([email protected]) Audience: SG7, EWG Contents 1 Overview .............................................................................................................................................................2 2 Language: Metaclasses .......................................................................................................................................7 3 Library: Example metaclasses .......................................................................................................................... 18 4 Applying metaclasses: Qt moc and C++/WinRT .............................................................................................. 35 5 Alternatives for sourcedefinition transform syntax .................................................................................... 41 6 Alternatives for applying the transform .......................................................................................................... 43 7 FAQs ................................................................................................................................................................. 46 8 Revision history ............................................................................................................................................... 51 Major changes in R3: Switched to function-style declaration syntax per SG7 direction in Albuquerque (old: $class M new: constexpr void M(meta::type target,
    [Show full text]
  • Generic Programming
    Generic Programming July 21, 1998 A Dagstuhl Seminar on the topic of Generic Programming was held April 27– May 1, 1998, with forty seven participants from ten countries. During the meeting there were thirty seven lectures, a panel session, and several problem sessions. The outcomes of the meeting include • A collection of abstracts of the lectures, made publicly available via this booklet and a web site at http://www-ca.informatik.uni-tuebingen.de/dagstuhl/gpdag.html. • Plans for a proceedings volume of papers submitted after the seminar that present (possibly extended) discussions of the topics covered in the lectures, problem sessions, and the panel session. • A list of generic programming projects and open problems, which will be maintained publicly on the World Wide Web at http://www-ca.informatik.uni-tuebingen.de/people/musser/gp/pop/index.html http://www.cs.rpi.edu/˜musser/gp/pop/index.html. 1 Contents 1 Motivation 3 2 Standards Panel 4 3 Lectures 4 3.1 Foundations and Methodology Comparisons ........ 4 Fundamentals of Generic Programming.................. 4 Jim Dehnert and Alex Stepanov Automatic Program Specialization by Partial Evaluation........ 4 Robert Gl¨uck Evaluating Generic Programming in Practice............... 6 Mehdi Jazayeri Polytypic Programming........................... 6 Johan Jeuring Recasting Algorithms As Objects: AnAlternativetoIterators . 7 Murali Sitaraman Using Genericity to Improve OO Designs................. 8 Karsten Weihe Inheritance, Genericity, and Class Hierarchies.............. 8 Wolf Zimmermann 3.2 Programming Methodology ................... 9 Hierarchical Iterators and Algorithms................... 9 Matt Austern Generic Programming in C++: Matrix Case Study........... 9 Krzysztof Czarnecki Generative Programming: Beyond Generic Programming........ 10 Ulrich Eisenecker Generic Programming Using Adaptive and Aspect-Oriented Programming .
    [Show full text]
  • Java Application Programming Interface (API) Java Application Programming Interface (API) Is a List of All Classes That Are Part of the Java Development Kit (JDK)
    Java Application Programming Interface (API) Java application programming interface (API) is a list of all classes that are part of the Java development kit (JDK). It includes all Java packages, classes, and interfaces, along with their methods, fields, and constructors. These prewritten classes provide a tremendous amount of functionality to a programmer. A programmer should be aware of these classes and should know how to use them. A complete listing of all classes in Java API can be found at Oracle’s website: http://docs.oracle.com/javase/7/docs/api/. Please visit the above site and bookmark it for future reference. Please consult this site often, especially when you are using a new class and would like to know more about its methods and fields. If you browse through the list of packages in the API, you will observe that there are packages written for GUI programming, networking programming, managing input and output, database programming, and many more. Please browse the complete list of packages and their descriptions to see how they can be used. In order to use a class from Java API, one needs to include an import statement at the start of the program. For example, in order to use the Scanner class, which allows a program to accept input from the keyboard, one must include the following import statement: import java.util.Scanner; The above import statement allows the programmer to use any method listed in the Scanner class. Another choice for including the import statement is the wildcard option shown below: import java.util.*; This version of the import statement imports all the classes in the API’s java.util package and makes them available to the programmer.
    [Show full text]
  • A Metaobject Protocol for Fault-Tolerant CORBA Applications
    A Metaobject Protocol for Fault-Tolerant CORBA Applications Marc-Olivier Killijian*, Jean-Charles Fabre*, Juan-Carlos Ruiz-Garcia*, Shigeru Chiba** *LAAS-CNRS, 7 Avenue du Colonel Roche **Institute of Information Science and 31077 Toulouse cedex, France Electronics, University of Tsukuba, Tennodai, Tsukuba, Ibaraki 305-8573, Japan Abstract The corner stone of a fault-tolerant reflective The use of metalevel architectures for the architecture is the MOP. We thus propose a special implementation of fault-tolerant systems is today very purpose MOP to address the problems of general-purpose appealing. Nevertheless, all such fault-tolerant systems ones. We show that compile-time reflection is a good have used a general-purpose metaobject protocol (MOP) approach for developing a specialized runtime MOP. or are based on restricted reflective features of some The definition and the implementation of an object-oriented language. According to our past appropriate runtime metaobject protocol for implementing experience, we define in this paper a suitable metaobject fault tolerance into CORBA applications is the main protocol, called FT-MOP for building fault-tolerant contribution of the work reported in this paper. This systems. We explain how to realize a specialized runtime MOP, called FT-MOP (Fault Tolerance - MetaObject MOP using compile-time reflection. This MOP is CORBA Protocol), is sufficiently general to be used for other aims compliant: it enables the execution and the state evolution (mobility, adaptability, migration, security). FT-MOP of CORBA objects to be controlled and enables the fault provides a mean to attach dynamically fault tolerance tolerance metalevel to be developed as CORBA software. strategies to CORBA objects as CORBA metaobjects, enabling thus these strategies to be implemented as 1 .
    [Show full text]
  • Variable-Arity Generic Interfaces
    Variable-Arity Generic Interfaces T. Stephen Strickland, Richard Cobbe, and Matthias Felleisen College of Computer and Information Science Northeastern University Boston, MA 02115 [email protected] Abstract. Many programming languages provide variable-arity func- tions. Such functions consume a fixed number of required arguments plus an unspecified number of \rest arguments." The C++ standardiza- tion committee has recently lifted this flexibility from terms to types with the adoption of a proposal for variable-arity templates. In this paper we propose an extension of Java with variable-arity interfaces. We present some programming examples that can benefit from variable-arity generic interfaces in Java; a type-safe model of such a language; and a reduction to the core language. 1 Introduction In April of 2007 the C++ standardization committee adopted Gregor and J¨arvi's proposal [1] for variable-length type arguments in class templates, which pre- sented the idea and its implementation but did not include a formal model or soundness proof. As a result, the relevant constructs will appear in the upcom- ing C++09 draft. Demand for this feature is not limited to C++, however. David Hall submitted a request for variable-arity type parameters for classes to Sun in 2005 [2]. For an illustration of the idea, consider the remarks on first-class functions in Scala [3] from the language's homepage. There it says that \every function is a value. Scala provides a lightweight syntax for defining anonymous functions, it supports higher-order functions, it allows functions to be nested, and supports currying." To achieve this integration of objects and closures, Scala's standard library pre-defines ten interfaces (traits) for function types, which we show here in Java-like syntax: interface Function0<Result> { Result apply(); } interface Function1<Arg1,Result> { Result apply(Arg1 a1); } interface Function2<Arg1,Arg2,Result> { Result apply(Arg1 a1, Arg2 a2); } ..
    [Show full text]
  • On the Interaction of Object-Oriented Design Patterns and Programming
    On the Interaction of Object-Oriented Design Patterns and Programming Languages Gerald Baumgartner∗ Konstantin L¨aufer∗∗ Vincent F. Russo∗∗∗ ∗ Department of Computer and Information Science The Ohio State University 395 Dreese Lab., 2015 Neil Ave. Columbus, OH 43210–1277, USA [email protected] ∗∗ Department of Mathematical and Computer Sciences Loyola University Chicago 6525 N. Sheridan Rd. Chicago, IL 60626, USA [email protected] ∗∗∗ Lycos, Inc. 400–2 Totten Pond Rd. Waltham, MA 02154, USA [email protected] February 29, 1996 Abstract Design patterns are distilled from many real systems to catalog common programming practice. However, some object-oriented design patterns are distorted or overly complicated because of the lack of supporting programming language constructs or mechanisms. For this paper, we have analyzed several published design patterns looking for idiomatic ways of working around constraints of the implemen- tation language. From this analysis, we lay a groundwork of general-purpose language constructs and mechanisms that, if provided by a statically typed, object-oriented language, would better support the arXiv:1905.13674v1 [cs.PL] 31 May 2019 implementation of design patterns and, transitively, benefit the construction of many real systems. In particular, our catalog of language constructs includes subtyping separate from inheritance, lexically scoped closure objects independent of classes, and multimethod dispatch. The proposed constructs and mechanisms are not radically new, but rather are adopted from a variety of languages and programming language research and combined in a new, orthogonal manner. We argue that by describing design pat- terns in terms of the proposed constructs and mechanisms, pattern descriptions become simpler and, therefore, accessible to a larger number of language communities.
    [Show full text]
  • Generic Programming
    Generic Programming Read Ch5 1 Outline • Why do we need generic programming? • Generic class • Generic method • Java interface, generic interface • Java object type and conversion 2 Why do we need generic class? • IntNode/DoubleNode/ByteNode/LocaonNode/… • IntArrayBag/DoubleArrayBag/ByteArrayBag/LocaonBag/… • A generic class (e.g., bag, node) can be used for all the above possible bags. 3 Outline • Why do we need generic programming? • Generic class • Generic method • Java interface, generic interface • Java object type and conversion 4 Generic Class public class ArrayBag<E> implements Cloneable{ private E[ ] data; private int manyItems; public void add(E element){ //similar implementaon as in IntArrayBag} … } Use a generic class: ArrayBag<Integer> intbag = new ArrayBag<Integer>(); ArrayBag<String> strbag = new ArrayBag<String>(); intbag.add(4); strbag.add(“Hello”); 5 Something to pay aenJon -- constructor public ArrayBag(int iniJalCapacity) { if (iniJalCapacity < 0) throw new IllegalArgumentExcepJon ("The iniJalCapacity is negave: " + iniJalCapacity); data = (E[]) new Object[iniJalCapacity]; manyItems = 0; } data = new E[iniJalCapacity]; WRONG 6 Something to pay aenJon -- elements • IntArrayBag – Data contains the real value of each element • ArrayBag<E> – E[] data contains the reference to the real objects • Example • Implementaons of Equals, countOfOccurences, search, etc. for(int i=0; i<data.length;i++) if(data[i]==paramObj.data[i] … for(int i=0; i<data.length;i++) if(data[i].equals(paramObj.data[i]); … 7 Something to pay aenJon –
    [Show full text]
  • Interface Definition Language (IDL)
    An OMG® Interface Definition Language™ Publication Interface Definition Language™ Version 4.2 OMG Document Number: formal/18-01-05 Release Date: March 2018 Standard Document URL: http://www.omg.org/spec/IDL/4.2/ IPR mode: Non-Assert Copyright © 1997-2001, Electronic Data Systems Corporation Copyright © 1997-2001, Hewlett-Packard Company Copyright © 1997-2001, IBM Corporation Copyright © 1997-2001, ICON Computing Copyright © 1997-2001, i-Logix Copyright © 1997-2001, IntelliCorp Copyright © 1997-2001, Microsoft Corporation Copyright © 1997-2001, ObjectTime Limited Copyright © 1997-2001, Oracle Corporation Copyright © 1997-2001, Platinum Technology, Inc. Copyright © 1997-2001, Ptech Inc. Copyright © 1997-2001, Rational Software Corporation Copyright © 1997-2001, Reich Technologies Copyright © 1997-2001, Softeam Copyright © 1997-2001, Sterling Software Copyright © 1997-2001, Taskon A/S Copyright © 1997-2001, Unisys Corporation Copyright © 2002, Laboratoire d’Informatique Fondamentale de Lille Copyright © 2013-2017, Thales Copyright © 2013-2017, Real-Time Innovations, Inc. Copyright © 2018, Object Management Group, Inc. USE OF SPECIFICATION – TERMS, CONDITIONS & NOTICES The material in this document details an Object Management Group specification in accordance with the terms, conditions and notices set forth below. This document does not represent a commitment to implement any portion of this specification in any company's products. The information contained in this document is subject to change without notice. LICENSES The companies listed above have granted to the Object Management Group, Inc. (OMG) a nonexclusive, royalty-free, paid up, worldwide license to copy and distribute this document and to modify this document and distribute copies of the modified version. Each of the copyright holders listed above has agreed that no person shall be deemed to have infringed the copyright in the included material of any such copyright holder by reason of having used the specification set forth herein or having conformed any computer software to the specification.
    [Show full text]
  • The Bus Interface for 32-Bit Microprocessors That
    Freescale Semiconductor, Inc. MPC60XBUSRM 1/2004 Rev. 0.1 . c n I , r o t c u d n o c i PowerPC™ Microprocessor m e S Family: e l a c The Bus Interface for 32-Bit s e Microprocessors e r F For More Information On This Product, Go to: www.freescale.com Freescale Semiconductor, Inc... Freescale Semiconductor,Inc. F o r M o r G e o I n t f o o : r w m w a t w i o . f n r e O e n s c T a h l i e s . c P o r o m d u c t , Freescale Semiconductor, Inc. Overview 1 Signal Descriptions 2 Memory Access Protocol 3 Memory Coherency 4 . System Status Signals 5 . c n I Additional Bus Configurations 6 , r o t Direct-Store Interface 7 c u d n System Considerations 8 o c i m Processor Summary A e S e Processor Clocking Overview B l a c s Processor Upgrade Suggestions C e e r F L2 Considerations for the PowerPC 604 Processor D Coherency Action Tables E Glossary of Terms and Abbreviations GLO Index IND For More Information On This Product, Go to: www.freescale.com Freescale Semiconductor, Inc. 1 Overview 2 Signal Descriptions 3 Memory Access Protocol 4 Memory Coherency . 5 System Status Signals . c n I 6 Additional Bus Configurations , r o t 7 Direct-Store Interface c u d n 8 System Considerations o c i m A Processor Summary e S e B Processor Clocking Overview l a c s C Processor Upgrade Suggestions e e r F D L2 Considerations for the PowerPC 604 Processor E Coherency Action Tables GLO Glossary of Terms and Abbreviations IND Index For More Information On This Product, Go to: www.freescale.com Freescale Semiconductor, Inc.
    [Show full text]
  • The RPC Abstraction
    The RPC abstraction • Procedure calls well-understood mechanism - Transfer control and data on single computer • Goal: Make distributed programming look same - Code libraries provide APIs to access functionality - Have servers export interfaces accessible through local APIs • Implement RPC through request-response protocol - Procedure call generates network request to server - Server return generates response Interface Definition Languages • Idea: Specify RPC call and return types in IDL • Compile interface description with IDL compiler. Output: - Native language types (e.g., C/Java/C++ structs/classes) - Code to marshal (serialize) native types into byte streams - Stub routines on client to forward requests to server • Stub routines handle communication details - Helps maintain RPC transparency, but - Still had to bind client to a particular server - Still need to worry about failures Intro to SUN RPC • Simple, no-frills, widely-used RPC standard - Does not emulate pointer passing or distributed objects - Programs and procedures simply referenced by numbers - Client must know server—no automatic location - Portmap service maps program #s to TCP/UDP port #s • IDL: XDR – eXternal Data Representation - Compilers for multiple languages (C, java, C++) Sun XDR • “External Data Representation” - Describes argument and result types: struct message { int opcode; opaque cookie[8]; string name<255>; }; - Types can be passed across the network • Libasync rpcc compiles to C++ - Converts messages to native data structures - Generates marshaling routines (struct $ byte stream) - Generates info for stub routines Basic data types • int var – 32-bit signed integer - wire rep: big endian (0x11223344 ! 0x11, 0x22, 0x33, 0x44) - rpcc rep: int32 t var • hyper var – 64-bit signed integer - wire rep: big endian - rpcc rep: int64 t var • unsigned int var, unsigned hyper var - wire rep: same as signed - rpcc rep: u int32 t var, u int64 t var More basic types • void – No data - wire rep: 0 bytes of data • enum {name = constant,.
    [Show full text]
  • Avalon® Interface Specifications
    Avalon® Interface Specifications Updated for Intel® Quartus® Prime Design Suite: 20.1 Subscribe MNL-AVABUSREF | 2021.05.27 Send Feedback Latest document on the web: PDF | HTML Contents Contents 1. Introduction to the Avalon® Interface Specifications......................................................4 1.1. Avalon Properties and Parameters............................................................................5 1.2. Signal Roles..........................................................................................................5 1.3. Interface Timing....................................................................................................5 1.4. Example: Avalon Interfaces in System Designs.......................................................... 5 2. Avalon Clock and Reset Interfaces..................................................................................8 2.1. Avalon Clock Sink Signal Roles................................................................................ 8 2.2. Clock Sink Properties............................................................................................. 9 2.3. Associated Clock Interfaces ....................................................................................9 2.4. Avalon Clock Source Signal Roles.............................................................................9 2.5. Clock Source Properties..........................................................................................9 2.6. Reset Sink.........................................................................................................
    [Show full text]
  • Oriented Design with UML and Java Part VI: Exception Handling in Java
    Object – Oriented Design with UML and Java Part VI: Exception Handling in Java Copyright © David Leberknight and Ron LeMaster. Version 2011 Exception Handling A false sense of security? Care must be taken if you intend for the program to continue running. Both C++ and Java support exceptions. Normal control flow (looping, etc.) and recursion are relatively easy to get right; Multi-threaded control flow is very difficult; Exception Handling looks easy, but it takes planning and effort to get right. Design you Exception Handling as part of a larger error logging, monitoring, diagnostics, and recovery infrastructure. Try to avoid throwing exceptions yourself, in most cases. Consider every plausible failure scenario. Is your system required to return meaningful error messages? ( VI ) Exception Handling - 2 The Basic E.H. Model Java and C++ have subtle differences in their exception handling, but here, in the abstract, is what the two approaches have in common… try { throw new Exception( “Error!” ); // Skip over this code } catch( Exception e ) { // Do something about the Exception... } The throw statement is like a goto; it jumps to the nearest matching catch without executing any intervening code, with the following exceptions: In Java, any code within an intervening finally block will get executed. C++ objects in stack memory will get destructed when they go out of scope. Note: do not throw an exception from a C++ destructor! ( VI ) Exception Handling - 3 C++ Example Suppose a class DatabaseException is a subclass of Exception... try { throw new DatabaseException( “Deadlock detected!” ); cout << “The impossible has happened!” << endl; } catch( Exception* e ) // Nearest matching catch.
    [Show full text]