ما هو التصميم المفضل لوظيفة القالب التي تتطلب قيمة معلمة افتراضية؟

Question

أنا أعمل حاليًا على تنظيف واجهة برمجة تطبيقات مليئة بقوالب الوظائف ، وكان لدي رغبة قوية في كتابة الكود التالي.

template <typename T, typename U, typename V>
void doWork(const T& arg1, const U& arg2, V* optionalArg = 0);

عندما أدعو هذا القالب ، أود أن أفعل ذلك على النحو التالي.

std::string text("hello");
doWork(100, 20.0, &text);
doWork('a', text);         // oops!
doWork<char, std::string, void>('a', text);  // to verbose!

لسوء الحظ ، لا يتم تجميع الاحتجاج الثاني نظرًا لأن المترجم لا يمكنه استنتاج نوع المعلمة الاختيارية. هذا أمر مؤسف ، لأنني لا أهتم حقًا ما هو نوع المعلمة ، بل أن قيمته فارغة. أيضا ، أود تجنب مسار الاحتجاج الثالث لأنه يعوق قابلية القراءة.

هذا يقودني لمحاولة جعل حجة القالب V احصل على نوع افتراضي ، والذي لا يعمل أيضًا لأنه لا يمكنك تطبيق نوع افتراضي على وسيطة قالب الوظيفة (على الأقل باستخدام VC ++ 9.0).

template <typename T, typename U, typename V = void>  // oops!
void doWork(const T& arg1, const U& arg2, V* optionalArg = 0);

خياري المتبقي الوحيد هو تقديم حمولة زائدة من doWork هذا لا يعرف شيئًا عن حجة القالب V.

template <typename T, typename U>
void doWork(const T& arg1, const U& arg2)
{
    doWork(arg1, arg2, 0);
}

template <typename T, typename U, typename V>
void doWork(const T& arg1, const U& arg2, V* optionalArg);

هل هذا هو أفضل طريقة لحل هذه المشكلة؟ العيب الوحيد الذي أراه هو أنه من المحتمل أن أقدم العديد من وظائف إعادة التوجيه التافهة إذا كان قالب الوظيفة العديد من المعلمات التي لها افتراضات مناسبة.

Answer 1

أعتقد أن وظيفة إعادة التوجيه الخاصة بك هي حل مناسب تمامًا ، على الرغم من أنه في الحل الخاص بك ، ألن تضطر إلى تحديد معلمات القالب بشكل صريح؟ (0 هو ثابت عدد صحيح يمكن تغطيته لأي V* النوع.) أيضا doWord ضد doWork?

كقاعدة عامة ، حاول تجنب المعلمات الاختيارية حيث لا يتمتعون بدفع قوي للغاية.

هو - هي ربما يكون من الأسهل إجبار العملاء على العمل على إضافة ملف , (void*)0 إذا كانت ملائمة من الإضافة إلى الكثير من الآلية الإضافية لدعم كل من المعلمة ونسخة معلمة ثلاثة من القالب. ذلك يعتمد على الاستخدامات المتوقعة.

Answer 2

من وجهة نظر رمز العميل ، إذا لم يكن لديها معلمة ثالثة ، فلماذا تحتاج إلى ابتكار واحد؟

لذلك إذا كنت تهدف إلى قابلية الاستخدام وقابلية القراءة ، فأنا أتفق مع طريقة التفاف الخاصة بك: إنه أمر منطقي تمامًا ، واللفائف أنت كتب مسؤول عن قيمة لائقة للمعلمة الثالثة أنت ضروري.

علاوة على ذلك ، يجعل من الممكن استخدام افتراضي مختلف لتخصصات مختلفة ، إذا لزم الأمر.

Answer 3

أحد الاحتمالات هو إعادة ترتيب وسيطات القالب ، وبالتالي فإن الاختياري يأتي أولاً.

template <typename V, typename T, typename U>
void doWork(const T& arg1, const U& arg2, V* optionalArg = 0);

doWork<void>('a', text); 

إعادة التوجيه تبدو جيدة أيضًا.

ولكن يبدو أن الوسائط والقوالب الافتراضية لا تتطابق بشكل جيد.