ลูกค้าให้ความสำคัญกับผลิตภัณฑ์ Aspose ซึ่งช่วยให้สามารถจัดการกับโปรโตคอลและไฟล์ของรูปแบบยอดนิยมได้ ซึ่งเกิดจากการพัฒนาเริ่มต้นใน.NET ในเวลาเดียวกัน ในขณะเดียวกัน แอปพลิเคชันทางธุรกิจสำหรับรูปแบบไฟล์ทำงานในสภาพแวดล้อมที่แตกต่างกัน บทความนี้จะอธิบายถึงวิธีที่เราประสบความสำเร็จในการตั้งค่าการเปิดตัวผลิตภัณฑ์ Aspose สำหรับ C++ โดยการสร้างกรอบสำหรับการแปลโค้ดจาก C# การรักษาความสามารถของเวอร์ชัน .NET สำหรับผลิตภัณฑ์เหล่านี้เป็นเรื่องที่ท้าทายทางเทคนิค
เราได้พัฒนาโครงสร้างพื้นฐานที่จำเป็นเอง ทำให้สามารถแปลโค้ดระหว่างภาษาและจำลองฟังก์ชันของไลบรารี .NET โดยทำเช่นนี้เราได้แก้ปัญหาที่มักถูกพิจารณาว่าเป็นเรื่องทางวิชาการ สิ่งนี้ช่วยให้เราเริ่มต้นการเปิดตัวผลิตภัณฑ์ .NET รายเดือนสำหรับภาษา C++ โดยใช้โค้ดจากเวอร์ชัน C# ที่เกี่ยวข้อง นอกจากนี้ การทดสอบที่ครอบคลุมโค้ด C# ต้นฉบับถูกแปลพร้อมกัน โดยให้ความสำคัญในการตรวจสอบฟังก์ชันของโซลูชันที่ได้รับผลลัพธ์ อย่างเทียบเท่ากับการเขียนการทดสอบเฉพาะใน C++
ความสำเร็จของตัวแปลโค้ดจาก C# ไปยัง C++ ขึ้นอยู่กับประสบการณ์ที่ประสบความสำเร็จของทีม CodePorting ในการตั้งค่าการแปลโค้ดจาก C# ไปยัง Java อัตโนมัติ โครงสร้างที่สร้างขึ้นสามารถแปลงคลาส C# เป็นคลาส Java โดยที่มีการแทนที่เรียกใช้งานไลบรารีระบบอย่างถูกต้อง
มีวิธีการที่แตกต่างกันที่ได้รับการพิจารณาสำหรับกรอบงาน การพัฒนาเวอร์ชันของ Java สำหรับการใช้งานจากต้นฉบับจะต้องใช้ทรัพยากรมากเกินไป หนึ่งในตัวเลือกคือการเรียกใช้งานจากโค้ด Java ไปยังสภาพแวดล้อม .NET แต่สิ่งนี้จะจำกัดชุดแพลตฟอร์มการเขียนโปรแกรมที่เราสามารถสนับสนุนในอนาคต ในช่วงนั้น .NET มีอยู่บน Windows เท่านั้น การเรียกใช้งานจากโค้ด Java ไปยัง .NET มีประโยชน์ในกรณีที่มีการเรียกใช้งานที่เกิดขึ้นนาน ๆ และใช้งานประเภทข้อมูลที่ใช้กันอย่างแพร่หลาย แต่มันกลายเป็นซับซ้อนเมื่อทำงานกับวัตถุจำนวนมากและประเภทข้อมูลที่กำหนดเอง
แทนที่นั้น เราสงสัยว่าจะแปลโค้ดที่มีอยู่ในรูปแบบใหม่ โดยเป็นปัญหาที่น่าสนใจเนื่องจากการย้ายโค้ดต้องทำทุกเดือนและสำหรับผลิตภัณฑ์ทั้งหมด ซึ่งส่งผลให้มีการเปิดตัวผลิตภัณฑ์ที่มีคุณสมบัติที่คล้ายกัน
แผนการแก้ปัญหาถูกแบ่งออกเป็นสองส่วน:
ข้อความต่อไปนี้ยืนยันว่าแผนการเป็นไปได้ทางเทคนิค:
System.Net และ System.Drawingเราจะไม่ลงรายละเอียดเพิ่มเติมเกี่ยวกับตัวแปลภาษา C# เป็น Java นี้ ซึ่งต้องการบทความที่เป็นส่วน Dedicated ในสรุป การแปลผลิตภัณฑ์ C# เป็น Java ได้กลายเป็นปฏิบัติการประจำของบริษัท ด้วยความขอบคุณต่อตัวแปลรหัสที่สร้างขึ้น ตัวแปลได้เติบโตจากตัวแปลข้อกำหนดข้อกำหนดที่ใช้กฎเพียงครั้งเดียวเป็นตัวสร้างรหัสที่ซับซ้อนที่ทำงานกับ AST representation ของรหัสต้นฉบับ
ความสำเร็จของตัวแปล C# เป็น Java ช่วยให้เราเข้าสู่ตลาด Java และเกิดความสนใจในการเริ่มต้นการเปิดตัวสำหรับ C++ โดยใช้สถานการณ์เดียวกัน
เพื่อทำให้เป็นไปได้ในการเปิดตัว C++ ของผลิตภัณฑ์ของเรา จำเป็นต้องสร้างกรอบที่จะช่วยให้เราแปลรหัส C# เป็น C++ คอมไพล์ ทดสอบ และส่งให้กับลูกค้า รหัสเป็นชุดของไลบรารี แต่ละไลบรารีมีขนาดไม่เกินหลายล้านบรรทัด ส่วนประกอบของตัวแปลรหัสต้องครอบคลุมดังนี้:
หลายคนที่อ่านอาจสงสัยว่าทำไมเราไม่คิดจะใช้โซลูชันที่มีอยู่แล้ว เช่นโครงการ Mono มีหลายเหตุผลที่ทำให้เราไม่เลือกใช้:
ในทฤษฎีเราสามารถใช้ตัวแปลงของเราในการแปลโซลูชันที่มีอยู่เป็นภาษา C++ ได้ แต่นี้จำเป็นต้องมีตัวแปลงที่ทำงานได้เต็มรูปแบบตั้งแต่ต้น โดยเพราะเราไม่สามารถแก้ไขโค้ดที่ถูกแปลแล้วโดยไม่มีไลบรารีระบบ นอกจากนี้ ปัญหาในการปรับปรุงจะมีความสำคัญมากขึ้นกว่าโค้ดของผลิตภัณฑ์ที่ถูกแปล โดยเพราะการเรียกใช้ไลบรารีระบบมักเป็นจุดขีดจำกัด
เรามากลับมาที่ความต้องการของเราสำหรับตัวแปลโค้ดกันบ้างครับ ด้วยเหตุผลที่ไม่สามารถแมปประเภทของ .NET ไปยัง STL ได้ เราตัดสินใจใช้ประเภทของ Library ที่กำหนดเองแทน ไลบรารีถูกพัฒนาขึ้นเป็นชุดของอะแดปเตอร์ที่อนุญาตให้ใช้คุณสมบัติของไลบรารีของบุคคลที่สามผ่าน API ที่คล้ายกับ .NET (เหมือนในภาษา Java)
เมื่อเราแปลไลบรารีด้วย API ที่มีอยู่แล้ว ความต้องการสำคัญสำหรับโค้ดที่ถูกแปลคือ โค้ดที่ถูกแปลควรทำงานภายในแอปพลิเคชันของลูกค้าใด ๆ ดังนั้นเราไม่สามารถใช้การเก็บขยะสำหรับโค้ดที่ถูกแปลได้ เนื่องจากมันจะครอบคลุมทั้งแอปพลิเคชัน แทนที่นั้น รูปแบบการจัดการหน่วยความจำของเราต้องเป็นชัดเจนสำหรับนักพัฒนา C++ การใช้ smart pointers ถูกเลือกเป็นการตัดสินใจที่สอดคล้องกัน ในบทความที่แตกต่างกันเราจะอธิบายว่าเราได้ประสบความสำเร็จในการเปลี่ยนรูปแบบการจัดการหน่วยความจำ
CodePorting มีวัฒนธรรมในการทดสอบที่แข็งแกร่ง และความสามารถในการใช้ทดสอบที่เขียนสำหรับโค้ด C# กับผลิตภัณฑ์ C++ จะทำให้การแก้ปัญหาง่ายขึ้นอย่างมาก ตัวแปลโค้ดต้องสามารถแปลทดสอบได้เช่นกัน
ตั้งต้น การแก้ไขโค้ด Java ที่ถูกแปลด้วยวิธีทำด้วยมือช่วยให้เราสามารถเร่งความเร็วในการพัฒนาและเผยแพร่ผลิตภัณฑ์ อย่างไรก็ตามในระยะยาว สิ่งนี้ทำให้ค่าใช้จ่ายในการเตรียมรุ่นแต่ละรุ่นสำหรับการเผยแพร่เพิ่มขึ้นอย่างมาก เนื่องจากต้องแก้ไขข้อผิดพลาดในการแปลทุกครั้งที่มีการแสดงออก สามารถจัดการได้โดยให้โค้ด Java ที่ได้รับผลลัพธ์กับแพทช์ที่คำนวณจากความแตกต่างระหว่างผลลัพธ์ของตัวแปลที่สร้างขึ้นสำหรับสองรุ่นของโค้ด C# ต่อเนื่อง แทนที่จะแปลโค้ดใหม่ทุกครั้ง อย่างไรก็ตาม ตัดสินใจในการแก้ไขโค้ดของ C++ มาก่อนการแก้ไขโค้ดที่ได้รับผลลัพธ์ ซึ่งจะแก้ไขข้อผิดพลาดในการแปลเพียงครั้งเดียวเท่านั้น