DOCSLIB.ORG

Common Language Infrastructure for Research (Clir): Editing and Optimizing .Net Assemblies

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Common Language Infrastructure for Research (Clir): Editing and Optimizing .Net Assemblies COMMON LANGUAGE INFRASTRUCTURE FOR RESEARCH (CLIR): EDITING AND OPTIMIZING .NET ASSEMBLIES A Thesis by Shawn H. Windle Submitted to the Graduate School Appalachian State University in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE December 2012 Major Department: Computer Science COMMON LANGUAGE INFRASTRUCTURE FOR RESEARCH (CLIR): EDITING AND OPTIMIZING .NET ASSEMBLIES A Thesis by Shawn H. Windle December 2012 APPROVED BY: Dr. James B. Fenwick Jr. Chairperson, Thesis Committee Dr. Cindy Norris Member, Thesis Committee Dr. James T. Wilkes Member, Thesis Committee Dr. James T. Wilkes Chairperson, Computer Science Edelma D. Huntley Dean, Research and Graduate Studies Copyright°c Shawn H. Windle 2012 All Rights Reserved ABSTRACT COMMON LANGUAGE INFRASTRUCTURE FOR RESEARCH (CLIR): EDITING AND OPTIMIZING .NET ASSEMBLIES. (December 2012) Shawn H. Windle, Appalachian State University Thesis Chairperson: Dr. James B. Fenwick Jr. In 2002, Microsoft released the .NET Framework as it’s implementation of the Common Language Infrastructure (CLI). The subsequent release of Mono, an open-source implemen- tation of the CLI, allowed the .NET Framework audience to also include Max OS X, Linux and Unix users. These tools enabled high-level .NET development, but low-level researchers such as code optimizers have few tools available to manipulate .NET assembly files. This thesis presents the Common Language Infrastructure for Research (CLIR) comprised of three components: the Common Language Engineering Library (CLEL), the Common Language Optimizing Framework (CLOT), and a suite of utility applications. CLIR enables researchers to experiment with and develop tools for the .NET Framework languages. CLEL provides the means to read, edit and write low-level .NET assemblies. CLOT uses CLEL to provide a framework for code optimization including algorithms and data structures for three traditional optimizations. Evaluations of program performance demonstrate meaningful decrease in program execution time due to the application of these optimizations, thus validating CLIR and enabling further .NET optimization research. iv ACKNOWLEDGEMENTS I would like to express my profound appreciation to my thesis chairperson, Dr. James B. Fenwick Jr., for all of the hard work and time he put into helping me, not just with this thesis, but also for all of the classes I took at Appalachian State University with him. I would also like to thank Dr. Cindy Norris, Professor Kenneth Jacker and Dr. James Wilkes for all of their advice and help. I would also like to acknowledge that without the support from my family this thesis would not have been possible. v Contents Abstract iv Acknowledgement v List of Figures viii List of Tables ix 1 Introduction 1 2 Background 3 2.1 The Common Language Infrastructure . 3 2.2 Overview of the Assembly .text section . 7 2.3 Common Intermediate Language Instruction Format . 19 2.4 Related Work . 24 3 CLIR: Common Language Infrastructure for Research 26 3.1 CLEL: Common Language Engineering Library . 27 3.2 CLOT: Common Language Optimization Toolset . 32 3.3 User Applications . 35 4 Optimizations Background and Implementation 38 4.1 Optimization Overview and Goals . 38 4.2 Branch Instruction Replacement . 39 4.2.1 Peephole Optimization Background . 39 4.2.2 Branch Instruction Replacement Implementation . 40 4.3 Constant Propagation . 47 4.3.1 Constant Propagation Background . 47 4.3.2 Constant Propagation Implementation . 50 4.4 Method Inlining . 53 4.4.1 Method Inlining Background . 53 4.4.2 Method Inlining Implementation . 55 5 Optimization Tests 58 5.1 Introduction and Testing Environment . 59 5.2 One Pass Branch Instruction Replacement . 60 5.3 Constant Propagation . 63 5.4 Method Inlining . 66 vi 6 Conclusion and Future Work 69 6.1 Conclusion . 69 6.2 Future Work . 71 Bibliography 72 A Bubble Sort in C# 76 B BubbleSort.exe hexadecimal dump 78 C Assembly File Format 84 Vita 120 vii List of Figures 3.1 CLIR overview . 27 3.2 CLEL class . 27 3.3 CLEL overview . 28 3.4 ICLELReader interface . 28 3.5 ICLELWriter interface . 28 3.6 CLELAssembly class . 29 3.7 Token class . 30 3.8 ClassDescriptor class . 30 3.9 BuiltInType class . 30 3.10 MethodDescriptor class . 30 3.11 CLELInstruction class . 31 3.12 CLOT namespaces overview . 32 3.13 IOptimization interface . 33 3.14 OptimizationConfiguration class . 33 3.15 OptimizationController class . 36 3.16 Optimization Scheduling Tool . 37 3.17 OptimizationKey class . 37 4.1 Peephole examples . 39 4.2 BIR example . 41 4.3 BIR algorithm (version 1) . 41 4.4 Branch body . 42 4.5 Peephole BIR algorithm (version 1.1) . 42 4.6 Branch body, with missed replacement . 43 4.7 Converge BIR algorithm (version 2) . 43 4.8 One Pass BIR algorithm (version 3) . 45 4.9 Branch lists example . 45 4.10 Constant propagation example . 47 4.11 Constant propagation can uncover other optimization opportunities . 48 4.12 Reaching definitions algorithm . 48 4.13 A gen and kill set example . 50 4.14 Example assignment statement decomposed . 51 4.15 Constant propagation example . 52 4.16 Rules for method inlining . 55 C.1 PE and assembly file format . 84 C.2 Assembly .text section . 84 C.3 Overview of .rsrc section . 112 viii List of Tables 2.1 Method header - public BubbleSort() . 8 2.2 Stream header - #GUID . 9 2.3 #˜ stream . 10 2.4 TypeRef table . 11 2.5 TypeDef table . 12 2.6 Field table . 13 2.7 MethodDef table . 14 2.8 Param table . 15 2.9 MemberRef table . 16 2.10 StandAloneSig table . 16 2.11 #Strings stream . 17 2.12 #US stream . 18 2.13 #Blob stream . 18 2.14 Unconditional branch examples . 20 2.15 Conditional branch examples . 20 2.16 Load examples . 21 2.17 Method call examples . 22 5.1 Relative program sizes . 59 5.2 Branches replaced for Game of Life . 61 5.3 Branches replaced for Huffman . 61 5.4 Branches replaced for ZipFolder . 62 5.5 Code size changes (in bytes) . 62 5.6 Average execution time (in seconds) for BIR . 62 5.7 ZipFile C# code fragment . 63 5.8 ZipFile CIL . 63 5.9 ZipFile Assembly . 63 5.10 Number of Constants Propagated . 64 5.11 Average execution time (in seconds) . 64 5.12 Huffman Coding VB.NET code fragment . 65 5.13 FindProbabilitiesForSymbols CIL . 65 5.14 Average execution time (in seconds) for Method Inlining at 10% and 20% . 67 5.15 Average execution time (in seconds) for Method Inlining at 30%, 40% and 50% 67 C.1 DOS header . 85 C.2 DOS stub instructions . 87 C.3 PE header . 88 C.4 Standard fields . 88 ix C.5 NT specific . 90 C.6 Data directories . ..
Load more

Recommended publications
  • IJIRT | Volume 2 Issue 6 | ISSN: 2349-6002
    © November 2015 | IJIRT | Volume 2 Issue 6 | ISSN: 2349-6002 .Net Surbhi Bhardwaj Dronacharya College of Engineering Khentawas, Haryana INTRODUCTION as smartphones. Additionally, .NET Micro .NET Framework (pronounced dot net) is Framework is targeted at severely resource- a software framework developed by Microsoft that constrained devices. runs primarily on Microsoft Windows. It includes a large class library known as Framework Class Library (FCL) and provides language WHAT IS THE .NET FRAMEWORK? interoperability(each language can use code written The .NET Framework is a new and revolutionary in other languages) across several programming platform created by Microsoft for languages. Programs written for .NET Framework developingapplications. execute in a software environment (as contrasted to hardware environment), known as Common It is a platform for application developers. Language Runtime (CLR), an application virtual It is a Framework that supports Multiple machine that provides services such as Language and Cross language integration. security, memory management, and exception handling. FCL and CLR together constitute .NET IT has IDE (Integrated Development Framework. Environment). FCL provides user interface, data access, database Framework is a set of utilities or can say connectivity, cryptography, web building blocks of your application system. application development, numeric algorithms, .NET Framework provides GUI in a GUI and network communications. Programmers manner. produce software by combining their own source code with .NET Framework and other libraries. .NET is a platform independent but with .NET Framework is intended to be used by most new help of Mono Compilation System (MCS). applications created for the Windows platform. MCS is a middle level interface. Microsoft also produces an integrated development .NET Framework provides interoperability environment largely for .NET software called Visual between languages i.e.
    [Show full text]
  • NET Framework
    Advanced Windows Programming .NET Framework based on: A. Troelsen, Pro C# 2005 and .NET 2.0 Platform, 3rd Ed., 2005, Apress J. Richter, Applied .NET Frameworks Programming, 2002, MS Press D. Watkins et al., Programming in the .NET Environment, 2002, Addison Wesley T. Thai, H. Lam, .NET Framework Essentials, 2001, O’Reilly D. Beyer, C# COM+ Programming, M&T Books, 2001, chapter 1 Krzysztof Mossakowski Faculty of Mathematics and Information Science http://www.mini.pw.edu.pl/~mossakow Advanced Windows Programming .NET Framework - 2 Contents The most important features of .NET Assemblies Metadata Common Type System Common Intermediate Language Common Language Runtime Deploying .NET Runtime Garbage Collection Serialization Krzysztof Mossakowski Faculty of Mathematics and Information Science http://www.mini.pw.edu.pl/~mossakow Advanced Windows Programming .NET Framework - 3 .NET Benefits In comparison with previous Microsoft’s technologies: Consistent programming model – common OO programming model Simplified programming model – no error codes, GUIDs, IUnknown, etc. Run once, run always – no "DLL hell" Simplified deployment – easy to use installation projects Wide platform reach Programming language integration Simplified code reuse Automatic memory management (garbage collection) Type-safe verification Rich debugging support – CLR debugging, language independent Consistent method failure paradigm – exceptions Security – code access security Interoperability – using existing COM components, calling Win32 functions Krzysztof
    [Show full text]
  • Investigating the Feasibility of an MPI-Like Library Implemented in .Net Using Only Fully Managed Code
    Investigating the Feasibility of an MPI-like Library Implemented in .Net Using Only Fully Managed Code Daniel Holmes MSc in High Performance Computing The University of Edinburgh Year of Presentation: 2007 Abstract The .Net development platform and the C# language, in particular, offer many benefits to programmers including increased productivity, security, reliability and robustness, as well as standards-based application portability and cross-language inter-operation. The Message Passing Interface (MPI) is a standardised high performance computing paradigm with efficient, frequently-used implementations in many popular languages. A partial implementation of McMPI, the first MPI-like library to be targeted at .Net and written in pure C#, is presented. It is sufficiently complete to demonstrate typical application code and to evaluate relative performance. Although the effective bandwidth for large messages (over 100 Kbytes) using 100Mbit/s Ethernet is good, the overheads introduced by .Net remoting and object serialisation are shown to result in high latency and to limit bandwidth to 166Mbit/s when using a 1Gbit/s Ethernet interconnection. A possible resolution that still uses pure C#, i.e. using .Net sockets, is proposed but not implemented. Contents Chapter 1. Introduction ..................................................................................... 1 Chapter 2. Background ..................................................................................... 2 2.1 Object-Oriented HPC .................................................................................
    [Show full text]
  • Adding Self-Healing Capabilities to the Common Language Runtime
    Adding Self-healing capabilities to the Common Language Runtime Rean Griffith Gail Kaiser Columbia University Columbia University [email protected] [email protected] Abstract systems can leverage to maintain high system availability is to perform repairs in a degraded mode of operation[23, 10]. Self-healing systems require that repair mechanisms are Conceptually, a self-managing system is composed of available to resolve problems that arise while the system ex- four (4) key capabilities [12]; Monitoring to collect data ecutes. Managed execution environments such as the Com- about its execution and operating environment, performing mon Language Runtime (CLR) and Java Virtual Machine Analysis over the data collected from monitoring, Planning (JVM) provide a number of application services (applica- an appropriate course of action and Executing the plan. tion isolation, security sandboxing, garbage collection and Each of the four functions participating in the Monitor- structured exception handling) which are geared primar- Analyze-Plan-Execute (MAPE) loop consumes and pro- ily at making managed applications more robust. How- duces knowledgewhich is integral to the correct functioning ever, none of these services directly enables applications of the system. Over its execution lifetime the system builds to perform repairs or consistency checks of their compo- and refines a knowledge-base of its behavior and environ- nents. From a design and implementation standpoint, the ment. Information in the knowledge-base could include preferred way to enable repair in a self-healing system is patterns of resource utilization and a “scorecard” tracking to use an externalized repair/adaptation architecture rather the success of applying specific repair actions to detected or than hardwiring adaptation logic inside the system where it predicted problems.
    [Show full text]
  • Python Guide Documentation 0.0.1
    Python Guide Documentation 0.0.1 Kenneth Reitz 2015 11 07 Contents 1 3 1.1......................................................3 1.2 Python..................................................5 1.3 Mac OS XPython.............................................5 1.4 WindowsPython.............................................6 1.5 LinuxPython...............................................8 2 9 2.1......................................................9 2.2...................................................... 15 2.3...................................................... 24 2.4...................................................... 25 2.5...................................................... 27 2.6 Logging.................................................. 31 2.7...................................................... 34 2.8...................................................... 37 3 / 39 3.1...................................................... 39 3.2 Web................................................... 40 3.3 HTML.................................................. 47 3.4...................................................... 48 3.5 GUI.................................................... 49 3.6...................................................... 51 3.7...................................................... 52 3.8...................................................... 53 3.9...................................................... 58 3.10...................................................... 59 3.11...................................................... 62
    [Show full text]
  • Programming with Windows Forms
    A P P E N D I X A ■ ■ ■ Programming with Windows Forms Since the release of the .NET platform (circa 2001), the base class libraries have included a particular API named Windows Forms, represented primarily by the System.Windows.Forms.dll assembly. The Windows Forms toolkit provides the types necessary to build desktop graphical user interfaces (GUIs), create custom controls, manage resources (e.g., string tables and icons), and perform other desktop- centric programming tasks. In addition, a separate API named GDI+ (represented by the System.Drawing.dll assembly) provides additional types that allow programmers to generate 2D graphics, interact with networked printers, and manipulate image data. The Windows Forms (and GDI+) APIs remain alive and well within the .NET 4.0 platform, and they will exist within the base class library for quite some time (arguably forever). However, Microsoft has shipped a brand new GUI toolkit called Windows Presentation Foundation (WPF) since the release of .NET 3.0. As you saw in Chapters 27-31, WPF provides a massive amount of horsepower that you can use to build bleeding-edge user interfaces, and it has become the preferred desktop API for today’s .NET graphical user interfaces. The point of this appendix, however, is to provide a tour of the traditional Windows Forms API. One reason it is helpful to understand the original programming model: you can find many existing Windows Forms applications out there that will need to be maintained for some time to come. Also, many desktop GUIs simply might not require the horsepower offered by WPF.
    [Show full text]
  • Diploma Thesis
    Faculty of Computer Science Chair for Real Time Systems Diploma Thesis Porting DotGNU to Embedded Linux Author: Alexander Stein Supervisor: Jun.-Prof. Dr.-Ing. Robert Baumgartl Dipl.-Ing. Ronald Sieber Date of Submission: May 15, 2008 Alexander Stein Porting DotGNU to Embedded Linux Diploma Thesis, Chemnitz University of Technology, 2008 Abstract Programming PLC systems is limited by the provided libraries. In contrary, hardware-near programming needs bigger eorts in e. g. initializing the hardware. This work oers a foundation to combine advantages of both development sides. Therefore, Portable.NET from the DotGNU project has been used, which is an im- plementation of CLI, better known as .NET. The target system is the PLCcore- 5484 microcontroller board, developed by SYS TEC electronic GmbH. Built upon the porting, two variants to use interrupt routines withing the Portabe.NET runtime environment have been analyzed. Finally, the reaction times to occuring interrupt events have been examined and compared. Die Programmierung für SPS-Systeme ist durch die gegebenen Bibliotheken beschränkt, während hardwarenahe Programmierung einen gröÿeren Aufwand durch z.B. Initialisierungen hat. Diese Arbeit bietet eine Grundlage, um die Vorteile bei- der Entwicklungsseiten zu kombinieren. Dafür wurde Portable.NET des DotGNU- Projekts, eine Implementierung des CLI, bekannter unter dem Namen .NET, be- nutzt. Das Zielsystem ist das PLCcore-5484 Mikrocontrollerboard der SYS TEC electronic GmbH. Aufbauend auf der Portierung wurden zwei Varianten zur Ein- bindung von Interrupt-Routinen in die Portable.NET Laufzeitumgebung untersucht. Abschlieÿend wurden die Reaktionszeiten zu eintretenden Interrupts analysiert und verglichen. Acknowledgements I would like to thank some persons who had inuence and supported me in my work.
    [Show full text]
  • Outils De Développement Pour .NET Framework
    Outils de développement pour .NET Framework 8QGHU&RQVWUXFWLRQ (Q&RQVWUXFWLRQ Didier Donsez 8QLYHUVLWp-RVHSK)RXULHU *UHQREOH ,0$,0$*/65$'(/( 'LGLHU'RQVH]#LPDJIU 'LGLHU'RQVH]#LHHHRUJ Didier Donsez, 2003, Outils de développement pour 1 .NET 2 Petit rappel sur .NET et C# I .NET • Développement Multi langage • C#, C++, Java Script, Eiffel, Component Pascal, APL, Cobol, Oberon, Perl, Python, Scheme, Smalltalk, Standard ML, Haskell, Mercury, Oberon et Java/J++ • CIL (Common Intermediate Language) • CTS (Common Type System) 7 • CLI (Common Language Infrastructure) ( 1 U X R • CLR (CLI Runtime implémenté par MicroSoft) S W Q H • JIT, pré-JIT (à l’installation, ou développement) P H S S R O I H C# : le langage « Post-Java » Y p G H G • « Syncrétisation » de Java et de C++ V O L W X 2 I Standardisation ECMA (European Computer Manufacturers Association) · http://www.ecma.ch ] H V Q • ECMA-334 CLI (Format COFF, CTS, Metadata, …) R ' U H L G • ECMA-335 C# L ' 3 1RQ0LFUR6RIW .NET I Motivations • .NET sur des OS non Windows (Unix, Linux, MacOS X, …) • Implémentations libres • Outils libres I Project 7 ( 1 U • ROTOR (MicroSoft) sauf Linux (Shared Sources) X R S W Q H • Mono project (Ximian) P H S S R O H Y • DotGNU (Free Software Foundation) p G H G V O L W X 2 ] H V Q R ' U H L G L ' 4 Implémentations I MicroSoft · Commerciales · .NET CLR · Compact .NET CLR • Code partagé • « Rotor » : Shared Source CLI 7 ( 1 U 3.6 Mloc ( 10,721 fichiers) X R S W Q H KWWSPVGQPLFURVRIWFRPQHWVVFOL P H S S R • GC moins performant, JIT différent
    [Show full text]
  • Comparative Studies of Six Programming Languages
    Comparative Studies of Six Programming Languages Zakaria Alomari Oualid El Halimi Kaushik Sivaprasad Chitrang Pandit Concordia University Concordia University Concordia University Concordia University Montreal, Canada Montreal, Canada Montreal, Canada Montreal, Canada [email protected] [email protected] [email protected] [email protected] Abstract Comparison of programming languages is a common topic of discussion among software engineers. Multiple programming languages are designed, specified, and implemented every year in order to keep up with the changing programming paradigms, hardware evolution, etc. In this paper we present a comparative study between six programming languages: C++, PHP, C#, Java, Python, VB ; These languages are compared under the characteristics of reusability, reliability, portability, availability of compilers and tools, readability, efficiency, familiarity and expressiveness. 1. Introduction: Programming languages are fascinating and interesting field of study. Computer scientists tend to create new programming language. Thousand different languages have been created in the last few years. Some languages enjoy wide popularity and others introduce new features. Each language has its advantages and drawbacks. The present work provides a comparison of various properties, paradigms, and features used by a couple of popular programming languages: C++, PHP, C#, Java, Python, VB. With these variety of languages and their widespread use, software designer and programmers should to be aware
    [Show full text]
  • J2EE and .Net Security
    J2EE and .Net security 1. Introduction 1.1. Document Revision History Author Document Last Modified Note Version Date Ger Mulcahy 1.2 12/02/2002 Third draft Ger Mulcahy 1.1 01/02/2002 Added information on JAAS, JSSE, Project Liberty, DotGNU, etc. Ger Mulcahy 1.0 21/01/2002 Second Draft – added contributors Ger Mulcahy 0.1 04/01/2002 First draft 1.1.1. Contributors My thanks to the following for their assistance with this article: Alan Danziger, Mark Curphey, Alan Faber, Elias Levy, Tony Northrup 1.2. Overview A number of general comparative articles have been written discussing the pros and cons of these two competing technological platforms. The intention of this paper is to discuss J2EE and .Net at a high level from a security perspective, examining the tools and methodologies the platforms use to provide secure development and deployment environments. This introduction section covers a brief, incomplete discussion of key features of both platforms. It will not discuss areas that are not analogous between platforms. For more information on both, see the references section of this document. Note that .Net is a product platform, whereas J2EE is a standard specification, which is implemented to varying degrees of fidelity by a number of vendors. For this reason, direct comparisons may be difficult in certain areas without going into vendor specifics. For the purposes of this article no real distinction is made between .Net and the .Net Framework, which forms one part of the .Net strategy. While Microsoft is pushing .Net as their strategy for Web Services, this document will not discuss the two platforms from the point of view of Web Services, nor does it describe COM+, as this is not part of the .Net Framework.
    [Show full text]
  • ARCHIVED: Developing and Deploying .NET Applications On
    Developing and Deploying .NET Applications on AWS July 2020 This version has been archived. For the most recent version, see https://docs.aws.amazon.com/whitepapers/latest/develop-deploy-dotnet- apps-on-aws/develop-deploy-dotnet-apps-on-aws.html Archived Notices Customers are responsible for making their own independent assessment of the information in this document. This document: (a) is for informational purposes only, (b) represents current AWS product offerings and practices, which are subject to change without notice, and (c) does not create any commitments or assurances from AWS and its affiliates, suppliers or licensors. AWS products or services are provided “as is” without warranties, representations, or conditions of any kind, whether express or implied. The responsibilities and liabilities of AWS to its customers are controlled by AWS agreements, and this document is not part of, nor does it modify, any agreement between AWS and its customers. © 2020 Amazon Web Services, Inc. or its affiliates. All rights reserved. Archived 2 Contents Abstract ................................................................................................................................ 5 Introduction .......................................................................................................................... 6 Working with Different Variants of .NET .......................................................................... 6 Running .NET Applications in the AWS Cloud ................................................................
    [Show full text]
  • Reiter István
    Reiter István C# 2009, 0.91 verzió 2 Tartalomjegyzék 1. Bevezet ő…………………………………………………………………………….......8 1.1. A jegyzet jelölései…………………………………………………………………8 1.2. Jogi feltételek………………………………………………………………………8 2. Microsoft .NET Framework…………………………………………………………...9 2.1. A .NET platform…………………………………………………………………….9 2.1.1. MSIL/CIL……………………………………………………………………...9 2.1.2. Fordítás/futtatás…………………………………………………………….9 2.1.3. BCL. …………………………………………………………………………10 2.2. A C# programozási nyelv……………………………………………………….10 2.3. Alternatív megoldások…………………………………………………………10 2.3.1. SSCLI………………………………………………………………………10 2.3.2. Mono…………………………………………………………………………10 2.3.3. DotGNU……………………………………………………………………..10 3. Fejleszt ői környezetek………………………………………………………………..12 3.1. Microsoft Visual Studio…………………………………………………………12 3.2. SharpDevelop…………………………………………………………………….13 3.3. MonoDevelop……………………………………………………………………..14 4. “Hello C#!”……………………………………………………………………………..16 4.1. A C# szintaktikája………………………………………………………………..17 4.1.1. Kulcsszavak……………………………………………………………….17 4.1.2. Megjegyzések……………………………………………………………..18 4.2. Névterek…………………………………………………………………………...18 5. Változók………………………………………………………………………………...20 5.1. Típusok…………………………………………………………………………….20 5.2. Lokális változók………………………………………………………………….21 5.3. Referencia- és értéktípusok……………………………………………………21 5.4. Boxing és Unboxing…………………………………………………………….22 5.5. Konstansok……………………………………………………………………….23 5.6. A felsorolt típus…………………………………………………………………..23 5.7. Null típusok………………………………………………………………………..24 6. Operátorok……………………………………………………………………………..25 6.1.
    [Show full text]