เมื่อดูเผินๆ อาจดูเหมือนว่านักแปลมีวิธีการใช้งานเพียงวิธีเดียว นั่นคือ ด้วยการป้อนโค้ด C# เราคาดว่าจะได้รับโค้ด C++ ที่เทียบเท่าเป็นเอาต์พุต แน่นอนว่าวิธีนี้เป็นวิธีที่พบได้บ่อยที่สุด แต่ก็ห่างไกลจากวิธีเดียว ด้านล่างนี้คือโหมดอื่นๆ ที่ได้รับจากเฟรมเวิร์กการแปลโค้ดและยูทิลิตี้ที่เกี่ยวข้อง
ผลิตภัณฑ์ได้รับการพัฒนาโดยโปรแกรมเมอร์ที่ต้องการเรียนรู้รายละเอียดของขั้นตอนการแปลโค้ดเป็นภาษาอื่นและข้อจำกัดที่เกี่ยวข้อง เป็นผลให้สถานการณ์เกิดขึ้นเมื่อถูกต้องจากมุมมองของการเปลี่ยนแปลง C# ที่ทำโดยนักพัฒนาผลิตภัณฑ์ทำให้กระบวนการเผยแพร่สำหรับภาษาอื่นหยุดชะงัก
ในระหว่างการพัฒนาโครงการ เราได้ลองหลายวิธีในการตรวจหาปัญหาดังกล่าวโดยอัตโนมัติ:
การจำกัดเวอร์ชันภาษา C# ต้องได้รับวินัยจากโปรแกรมเมอร์ C# และมักจะไม่สะดวก เพื่อแก้ไขข้อจำกัดเหล่านี้ การแปลสามารถทำได้ในสองขั้นตอน ขั้นแรก แทนที่โครงสร้างของภาษา C# เวอร์ชันสมัยใหม่ด้วยแอนะล็อกที่ได้รับการสนับสนุนจากมาตรฐานในอดีต จากนั้นจึงดำเนินการแปลโดยตรง
เมื่อใช้นักแปลที่ใช้ตัวแยกวิเคราะห์ที่ล้าสมัย การลดสามารถทำได้โดยใช้เครื่องมือภายนอกเท่านั้น (เช่น ยูทิลิตี้ที่เขียนบนพื้นฐานของ Roslyn) ในทางกลับกัน นักแปลที่ใช้ Roslyn ดำเนินการทั้งสองขั้นตอนตามลำดับ ซึ่งอนุญาตให้ใช้รหัสเดียวกันทั้งเมื่อแปลรหัสโดยพวกเขาและเมื่อเตรียมรหัสสำหรับการแปลโดยเครื่องมือรุ่นเก่า
สิ่งนี้คล้ายกับการแปลรหัสผลิตภัณฑ์ แต่มีนัยถึงข้อกำหนดที่แตกต่างกันบ้าง เมื่อแปลไลบรารี่จำนวนหลายสิบล้านบรรทัด สิ่งที่สำคัญที่สุดคือต้องปฏิบัติตามพฤติกรรมของโค้ด C# ต้นฉบับอย่างเคร่งครัดที่สุดเท่าที่จะเป็นไปได้ แม้ว่าจะต้องเสียค่าใช้จ่ายในการอ่านก็ตาม โค้ดที่เรียบง่ายกว่าแต่มีผลกระทบต่างกัน ได้รับการแก้ไขอีกต่อไป ในทางกลับกัน ตัวอย่างของการใช้โค้ดที่แปลควรดูเรียบง่ายที่สุดเท่าที่จะเป็นไปได้ ทำให้ชัดเจนถึงวิธีใช้โค้ดในภาษา C++ แม้ว่าจะไม่สอดคล้องกับพฤติกรรมของตัวอย่างต้นฉบับที่เขียนด้วย C# ก็ตาม
ตัวอย่างเช่น เมื่อสร้างวัตถุชั่วคราว โปรแกรมเมอร์ C# มักจะใช้usingคำสั่ง เพื่อหลีกเลี่ยงการรั่วไหลของทรัพยากรและเคร่งครัด กำหนดช่วงเวลาปล่อยตัวโดยไม่ต้องพึ่ง GC การแปลที่เข้มงวดของ using ให้โค้ด C++ ที่ค่อนข้างซับซ้อนเนื่องจากมีความแตกต่างหลายประการ “หากมีข้อยกเว้นเกิดขึ้นในบล็อกคำสั่ง using และ Dispose() ก็ส่งข้อยกเว้นเช่นกัน ซึ่งอันใดจบลงในบริบทที่ตรวจจับได้” รหัสดังกล่าวจะทำให้โปรแกรมเมอร์ C++ เข้าใจผิดเท่านั้น สร้างความประทับใจว่าการใช้ไลบรารีเป็นเรื่องยาก แต่ในความเป็นจริงแล้ว มันก็เพียงพอแล้วที่จะมีตัวชี้อัจฉริยะบนสแต็ก ซึ่งในเวลาที่เหมาะสมจะลบวัตถุและทำให้ทรัพยากรว่าง
ไลบรารีที่มี API สามารถจัดทำเป็นเอกสารผ่านข้อคิดเห็น XML ตามแนวทางปฏิบัติ C# การถ่ายโอนความคิดเห็นไปยัง C++ ในรูปแบบ Doxygen ไม่ใช่เรื่องเล็กน้อย นอกจากมาร์กอัปแล้ว จำเป็นต้องแทนที่การอ้างอิงถึงประเภทต่างๆ (เนื่องจากในชื่อเต็มของ C# เขียนด้วยจุด ใน C++ มีโคลอนคู่) สมาชิกของพวกเขา และในกรณีของการใช้คุณสมบัติ ก็ต้องเข้าใจด้วยว่า เป็นผู้ทะเยอทะยานหรือผู้เซต นอกจากนี้ ให้แปลส่วนของโค้ดที่ไม่มีความหมายและอาจไม่สมบูรณ์
งานนี้ได้รับการแก้ไขทั้งโดยตัวแปลเองและโดยยูทิลิตี้ภายนอกเช่นโดยการวิเคราะห์เอกสาร XML ที่สร้างขึ้นและเตรียมส่วนเพิ่มเติมเช่นตัวอย่างการใช้วิธีการ
ดังที่เราเห็น กรอบงานระดับมืออาชีพสำหรับการแปลงโค้ด นอกเหนือจากการแปลโค้ด C# เป็น C++ คุณภาพสูงแล้ว ควรจะสามารถกำหนดความสามารถในการแปลของซอร์สโค้ด ลดเวอร์ชันภาษาลงหากจำเป็น แปลตัวอย่างการใช้เวอร์ชันที่แปลงแล้ว ห้องสมุดและเอกสารประกอบของพวกเขา