سؤال

النظر في هذا الرمز، VC9 لا يكتشف التعرج:

typedef struct { int x, y; } vec_t;

void rotate_cw(vec_t const *from,
               vec_t       *to)
{
        /* Notice x depends on y and vice versa */
        to->x = from->y;
        to->y = -from->x;
}

/* ... */
vec_t a, b;
rotate_cw(&a, &b); /* OK, no aliasing */
rotate_cw(&a, &a); /* FAIL, aliasing is not detected */

الإصلاح الواضح هو استخدام مؤقت:

void rotate_cw(vec_t const *from,
               vec_t       *to)
{
        int temp = from->x;
        to->x = from->y;
        to->y = -temp;
}

هل هذا السلوك القياسي؟ كنت أتوقع أن يكون المترجم، ما لم يخبر بذلك، على حد سواء مؤشرات أن تكون على نحو مستعار.

هل كانت مفيدة؟

المحلول

تحقق من هذه الإجابة.

حاول وضع __بتقييد قبل المعلمات، يبدو أن الطريقة الوحيدة التي وجدها أي شخص من الحصول على MSVC لإعطاء أي تحذيرات.

نصائح أخرى

الرمز كما هو مكتوب صالح تماما، في C89 أو C99. إنه غامض، ولكن لا يوجد شيء للمترجم لتشخيصه، لذلك لا يشخص.

إذا كنت تستخدم C99 و "تقييد" على كلا المعلمين في الوظيفة، فستحصل على خطأ - إذا كان برنامج التحويل البرمجي يدعم C99. AFAIK، لا توجد نسخة حالية من MSVC بعد تدعم C99 بالكامل.

قبل أن اخترع C99 restrict التصفيات التصفيات، تضم بعض المغلغات C خيارات التحسين التي من شأنها توجيهها لإجراء افتراضات معينة حول استخدام المؤشر؛ الكتيبات التي رأيتها لهذه المحامرة حذر صراحة من أن مثل هذه التحسينات كانت ليس متوافق مع المعايير، وربما تسبب رمز تعسفي باستخدام بنيات معينة معينة تم تعريف سلوكها من قبل المعيار للتصرف بطريقة مخالفة لكل من نية المعايير والمبرمجة. من وجهة نظر الدليل، أخبرت التحسينات للمترجم أن تجميع مجموعة فرعية من C التي لم تحدد سلوك حالات ركنية معينة تم تعريفها في ج، ولكنها ستسمح بجيل أكبر قدر من الكود الكفؤية لهذه الحالات هل حددت.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top