[ Pobierz całość w formacie PDF ]
.The declarations and theevent handlers for these buttons appear next.Note that you can declare the buttons withinthe class, but you must initialize them within a method.The example uses the constructor toinitialize and configure the buttons.It also assigns an event handler for the click event ofeach button using the add_Click() method.After the code initializes and configures the buttons, it configures the form.Adding an icon tothe form means creating one using Resource View and then assigning the resulting file to anIcon control.Notice that you must assign the buttons to the form using the Controls->Add()method call.Here s what the resulting dialog box looks like:A Look at the Intermediate Language (IL)The previous section concentrated on the programming language aspect of the.NETFramework.It s important to realize that.NET is more than just a change to theprogramming language it changes everything the language produces as well.That bringsus to the IL.The IL is important because it defines a method for compiling the applicationthat doesn t rely on a specific platform.The IL represents a means for transporting the code to more than one platform in a mannersimilar to Java.Like Java,.NET relies on a platform-dependent runtime engine.Unlike Java,.NET compiles the application code.A Just-in-Time (JIT) compiler accepts the IL as inputand creates a platform-specific executable.As a result, you only pay for the JIT compilationonce and gain the full benefit of compiled code thereafter.We ll discuss the CommonLanguage Runtime (CLR) in the Understanding the Common Language Runtime for VisualStudio section of this chapter.As Visual C++ developers, you have more than a passing interest in the low-level features ofthe applications you develop.Many Visual C++ developers are as familiar with theassembler version of their code as they are with the C++ code.Disassembling Visual C++ soyou can see how it works is part of many debugging sessions.That s the reason manyVisual C++ developers will find managed code disconcerting there isn t any nativeassembler code to view.We initially discussed the Intermediate Language Disassembler (ILDASM) utility in Chapter2.However, console applications, especially those with mixed code, don t lend themselvesto easy disassembly.In addition, the console application output makes less sense than theoutput from a fully managed application.Figure 12-1 shows the results of using ILDASM withthe example application in the previous section.Notice that the disassembly is laid out muchthe same as the application. Figure 12-1: Using ILDASM can reveal low-level details about your code.Each assembly element has a specific purpose and a symbol associated with it.Forexample, the red right arrow represents a module heading.ILDASM uses it for informationdirective, class declarations, and manifest information.Likewise, ILDASM uses a shield fornamespaces, purple squares for methods, diamonds for fields, up arrows for properties, anddown arrows for events.If you double-click any of the entries shown in Figure 12-1, you ll see a disassembly of thatelement.The disassembly is useful only for managed code you ll find it nearly useless foranything else, even in a mixed environment.Figure 12-2 shows an example of thedisassembly for the Test_Click() event handler.Figure 12-2: Use code disassembly to see how the compiler turns your code into IL.As you can see, the output really does look similar to assembly language.CLR uses a stack-based approach to working with data there aren t any registers.If an application wants toadd two numbers, it must first load the two numbers on the stack, then call the add routine.The add routine will pop the two numbers from the stack, add them, and then push the resultback onto the stack.Of course, CLR also relies on memory to store objects only valuesappear on the stack.If you look at the source code for the Test_Click() event handler again, you ll notice itcontains a single call to MessageBox::Show().The call requires four arguments in thiscase.Look at the series of instructions shown in Figure 12-2.The LD* instructions load thestack with the data required for the call to MessageBox::Show().However, there s moregoing on in the disassembly than a single call.Notice the LDSFLDA (load static field)instruction.The next instruction is a call to NEWOBJ.The NEWOBJ call boxes the static text found in the source code and creates a System.String object.The two LDC (loadconstant) calls push numeric values onto the stack.The final call is to theMessageBox::Show() method.This call is rather long, and you can t see the result in Figure12-2.Here s the disassembled version of that call:Unlike with disassemblers you used in the past, creating IL file isn t a one-way trip.You canalso use the Intermediate Language Assembler (ILASM) to compile the content of an IL fileinto working code.Theoretically, this would allow you to disassemble code, tweak it, andthen compile it into an application again.Most developers will find using the standard.NETtools easier.It does bring up the possibility of third party developers writing compilers tocreate the required IL file and then calling ILASM to complete the task.This section also demonstrates a potential problem with.NET.Many developers fear thatthird parties will steal their code by disassembling it.Worse still, some developers see thepotential for crackers to distribute virus-ridden code in their name.Hopefully, Microsoft willfind a cure for this problem in the near future.We ll see in Chapter 13 that there s a partialsolution for the problem now in the use of strong names.You create a strong name byadding a key value to the AssemblyInfo.CPP file of a component or application.Why Change a Great Language?We still haven t discussed the reasons for using.NET.Yes, it helps you produce coderelatively quickly and in a straightforward manner.The use of IL brings many advantages(and many disadvantages as well).However, new isn t necessarily better unless there s anoverriding reason for the change [ Pobierz całość w formacie PDF ]
zanotowane.pl doc.pisz.pl pdf.pisz.pl odbijak.htw.pl
.The declarations and theevent handlers for these buttons appear next.Note that you can declare the buttons withinthe class, but you must initialize them within a method.The example uses the constructor toinitialize and configure the buttons.It also assigns an event handler for the click event ofeach button using the add_Click() method.After the code initializes and configures the buttons, it configures the form.Adding an icon tothe form means creating one using Resource View and then assigning the resulting file to anIcon control.Notice that you must assign the buttons to the form using the Controls->Add()method call.Here s what the resulting dialog box looks like:A Look at the Intermediate Language (IL)The previous section concentrated on the programming language aspect of the.NETFramework.It s important to realize that.NET is more than just a change to theprogramming language it changes everything the language produces as well.That bringsus to the IL.The IL is important because it defines a method for compiling the applicationthat doesn t rely on a specific platform.The IL represents a means for transporting the code to more than one platform in a mannersimilar to Java.Like Java,.NET relies on a platform-dependent runtime engine.Unlike Java,.NET compiles the application code.A Just-in-Time (JIT) compiler accepts the IL as inputand creates a platform-specific executable.As a result, you only pay for the JIT compilationonce and gain the full benefit of compiled code thereafter.We ll discuss the CommonLanguage Runtime (CLR) in the Understanding the Common Language Runtime for VisualStudio section of this chapter.As Visual C++ developers, you have more than a passing interest in the low-level features ofthe applications you develop.Many Visual C++ developers are as familiar with theassembler version of their code as they are with the C++ code.Disassembling Visual C++ soyou can see how it works is part of many debugging sessions.That s the reason manyVisual C++ developers will find managed code disconcerting there isn t any nativeassembler code to view.We initially discussed the Intermediate Language Disassembler (ILDASM) utility in Chapter2.However, console applications, especially those with mixed code, don t lend themselvesto easy disassembly.In addition, the console application output makes less sense than theoutput from a fully managed application.Figure 12-1 shows the results of using ILDASM withthe example application in the previous section.Notice that the disassembly is laid out muchthe same as the application. Figure 12-1: Using ILDASM can reveal low-level details about your code.Each assembly element has a specific purpose and a symbol associated with it.Forexample, the red right arrow represents a module heading.ILDASM uses it for informationdirective, class declarations, and manifest information.Likewise, ILDASM uses a shield fornamespaces, purple squares for methods, diamonds for fields, up arrows for properties, anddown arrows for events.If you double-click any of the entries shown in Figure 12-1, you ll see a disassembly of thatelement.The disassembly is useful only for managed code you ll find it nearly useless foranything else, even in a mixed environment.Figure 12-2 shows an example of thedisassembly for the Test_Click() event handler.Figure 12-2: Use code disassembly to see how the compiler turns your code into IL.As you can see, the output really does look similar to assembly language.CLR uses a stack-based approach to working with data there aren t any registers.If an application wants toadd two numbers, it must first load the two numbers on the stack, then call the add routine.The add routine will pop the two numbers from the stack, add them, and then push the resultback onto the stack.Of course, CLR also relies on memory to store objects only valuesappear on the stack.If you look at the source code for the Test_Click() event handler again, you ll notice itcontains a single call to MessageBox::Show().The call requires four arguments in thiscase.Look at the series of instructions shown in Figure 12-2.The LD* instructions load thestack with the data required for the call to MessageBox::Show().However, there s moregoing on in the disassembly than a single call.Notice the LDSFLDA (load static field)instruction.The next instruction is a call to NEWOBJ.The NEWOBJ call boxes the static text found in the source code and creates a System.String object.The two LDC (loadconstant) calls push numeric values onto the stack.The final call is to theMessageBox::Show() method.This call is rather long, and you can t see the result in Figure12-2.Here s the disassembled version of that call:Unlike with disassemblers you used in the past, creating IL file isn t a one-way trip.You canalso use the Intermediate Language Assembler (ILASM) to compile the content of an IL fileinto working code.Theoretically, this would allow you to disassemble code, tweak it, andthen compile it into an application again.Most developers will find using the standard.NETtools easier.It does bring up the possibility of third party developers writing compilers tocreate the required IL file and then calling ILASM to complete the task.This section also demonstrates a potential problem with.NET.Many developers fear thatthird parties will steal their code by disassembling it.Worse still, some developers see thepotential for crackers to distribute virus-ridden code in their name.Hopefully, Microsoft willfind a cure for this problem in the near future.We ll see in Chapter 13 that there s a partialsolution for the problem now in the use of strong names.You create a strong name byadding a key value to the AssemblyInfo.CPP file of a component or application.Why Change a Great Language?We still haven t discussed the reasons for using.NET.Yes, it helps you produce coderelatively quickly and in a straightforward manner.The use of IL brings many advantages(and many disadvantages as well).However, new isn t necessarily better unless there s anoverriding reason for the change [ Pobierz całość w formacie PDF ]