سؤال عن الدالة malloc() وسؤالان آخران!

و عليكم السلام و رحمة الله و بركاته,

عزيزي, الكلام يطول لبعد الأسئلة عن بعضها و لكن باختصار.

اقتباس

في لغة السي يلجأ المبرمجون لمثل هذا الكود مرات كثر

malloc و أخواتها يمثلان الـ heap memory في C. هناك stack memory و هناك static memory. النوع الثاني و الثالث, يعتبران ضمن قواعد اللغة نفسها. بينما الـ heap memory تعتبر شيئاً يوفر عبر المكتبات, و لأهميته القصوى فهو ضمن المكتبات القياسية المعدودة على أصابع اليد. بالطبع لا يوجد شيء اسمه خاطئ و شيء اسمه صحيح لهذه الحالة, هذه هي فلسلفة C منذ أربعين عام, و لها فوائدها و لها محدودياتها.

اقتباس

قمت بتعريف مؤشر من نوع float وحجزت له مساحة ذاكرية بحجم مضاعف للنوع int ...

لغة C لا تمنع المبرمج من فعل شيء بشكل خاطئ. هذا الأمر له فوائد و له أضرار أيضاً, أحد أضراره أنه you can shoot your self in the foot. الأمر الجيد هو الحرية المطلقة التي يحتاجها المبرمج في أماكن كثيرة من أعلى المعالج وصولاً إلى الطبقة التي توجد تحت التطبيقات. هناك الكثير من الأمور التي لن تحتاجها في طبقة التطبيقات! و هناك طرق لكتابة كود خاطئ في C أكثر من الطرق الصحيحة. باختصار هي لغة للمختصين بشكل عام. و هذه هي فلسفتها! الـ Type Safety مكلفة في بعض الأحيان و في C هناك قاعدة تقول بأن اللغة يجب أن تتبع zero-overhead principle لكي يكون الكود الناتج مماثلاً أو قريباً جداً مما لو كتبت الكود بالأسمبلي. لا تسألني لماذا يبني بها المبرمجون تطبيقات أيضاً, ربما لأنها أعظم لغة في التاريخ :blink:

اقتباس

هل ما يقابل الدالة malloc في السي ++ هو العامل new.. ! وهل يسمى "عامل" أم "معامل" أم "مؤثر" !

malloc و أخواتها ضمن المكتبة القياسية الموجودة في ++C التي ينص على أنها مطابقة لمكتبة C. أحد الظواهر التي تدل على أن ++C تملك مرونة C و أكثر في الحقيقة هو أن الـ heap memory مضمنة ضمن مفاهيم اللغة نفسها عن طريق new operator و delete operator بنسختيهما الخاصة بالمتغيرات و الخاصة بالمصفوفات. و لكنك في نفس الوقت يمكنك أن توفر مكتبة كـ memory manager دون تعديل اللغة نفسها!

اقتباس

هل تحتلف هذه المصرّفات (compilers) عن بعضها تماما وتشترك فقط في تطبيق معابير اللغة النضرية فقط!

ماذا تعني بمقاييس اللغة "النظرية"؟ هناك طريقتان لتعريف لغة برمجة. في الحالة المشهورة يتم عمل reference implementation لسهولة الموضوع من ناحية و كون هناك عدة dialects من اللغة في عدة مترجمات. اللغات الكبيرة يتم عمل standardization لها لكي يكون مرجع للجميع. إذا لم يكن المترجم الذي تستخدمه يتبع المواصفات فهو ليس بمترجم ++C أصلاً! جميع المترجمات التي أعرفها تتبع المواصفات حرفياً, و إذا كان هناك خلل فهو يعتبر bug لا أكثر!

VC و GCC و clang و Comeau و مترجم بورلاند الذي لا اعرف ماذا يسمى الآن و غيرهم من المترجمات الموجودة من أصغر المنصات للـ super computer platforms.

اقتباس

ربما أستطيع أن أسأل هل أكواد اﻷسمبلي الناتجة من ترجمة كود سي++ بمصرّفين مختلفين تكون مختلفة! أم لا يشترط ذلك!

هل تعلم يا صديقي أنك لو قمت بترجمة الملف ثم قمت بتعديل مسافة فيه لا تؤثر على الكود إطلاقاً ثم قمت بترجمة البرنامج مرة أخرى قد لا ينتج الكود نفسه بالضبط؟! طبعاً هذا غير وارد الحدوث إلا نادراً جداً و لكنه قد يحصل. عملية الترجمة ليست عملية deterministic إلا نظرياً. بينما في الحقيقة المترجمات تتأثر بكمية الذاكرة الموجودة في غيرها من العوامل و قد يوثر ذلك على تفعيل عملية Internal Optimization مكلفة.

تحياتي...

اقتباس

هل تعلم يا صديقي أنك لو قمت بترجمة الملف ثم قمت بتعديل مسافة فيه لا تؤثر على الكود إطلاقاً ثم قمت بترجمة البرنامج مرة أخرى قد لا ينتج الكود نفسه بالضبط؟! طبعاً هذا غير وارد الحدوث إلا نادراً جداً و لكنه قد يحصل. عملية الترجمة ليست عملية deterministic إلا نظرياً. بينما في الحقيقة المترجمات تتأثر بكمية الذاكرة الموجودة في غيرها من العوامل و قد يوثر ذلك على تفعيل عملية Internal Optimization مكلفة.

رد جميل وكافي ... لكن لدي تعليق فقط وهو ... أن المسافة وغيرها يتجاهله المترجم تماماً ... صحيح أن تغيير جزية بسيطة في الكود قد ينتج عنه شئ مختلف تماماً ... لكن المسافات وغيرها أو ما يعرف بالWhite-space يتجاهلها المترجم كلياً ...

وشكرا :)

اقتباس

رد جميل وكافي ... لكن لدي تعليق فقط وهو ... أن المسافة وغيرها يتجاهله المترجم تماماً ... صحيح أن تغيير جزية بسيطة في الكود قد ينتج عنه شئ مختلف تماماً ... لكن المسافات وغيرها أو ما يعرف بالWhite-space يتجاهلها المترجم كلياً ...

أهلاً بك أخي بندر :)

ربما كلامي كان غامضاً قليلاً, و لكن لم أقصد أن معنى البرنامج سيتغير. ماقصدته أن عملية الترجمة ليست عملية reversible كما يعتقد البعض إلا في الـ toy compilers. كان هناك سؤال في SO حول الموضوع, و من كلام الـ gurus يبدو أن الموضوع أعقد مما تصورته أنا في البداية. كان هناك شخص يسأل, بأنه قام بترجمة الكود مرات متتالية و تغاضى عن الـ timestamps الموضوعة في الـ executable النهائي, و مع ذلك نتج كود مختلف! الذي تم توضيحه أن المترجمات قد تقوم بتفعيل بعض الـ optimizations في حالة وجود ذاكرة في لحظة من اللحظات و قد تقوم بعدم تطبيقها لعدم توفر ذاكرة كافية.

بالنسبة للمسافة فسأعقد الموضوع قليلاً و أقول بأنها تعتمد على قواعد اللغة نفسها :P

في ++C ربما تكون المسافة غير مؤثرة و لكنها في Python مؤثرة في نحو اللغة.

تحياتي...

Khaled.Alshaya كتب:

أهلاً بك أخي بندر :)

ربما كلامي كان غامضاً قليلاً, و لكن لم أقصد أن معنى البرنامج سيتغير. ماقصدته أن عملية الترجمة ليست عملية reversible كما يعتقد البعض إلا في الـ toy compilers. كان هناك سؤال في SO حول الموضوع, و من كلام الـ gurus يبدو أن الموضوع أعقد مما تصورته أنا في البداية. كان هناك شخص يسأل, بأنه قام بترجمة الكود مرات متتالية و تغاضى عن الـ timestamps الموضوعة في الـ executable النهائي, و مع ذلك نتج كود مختلف! الذي تم توضيحه أن المترجمات قد تقوم بتفعيل بعض الـ optimizations في حالة وجود ذاكرة في لحظة من اللحظات و قد تقوم بعدم تطبيقها لعدم توفر ذاكرة كافية.

بالنسبة للمسافة فسأعقد الموضوع قليلاً و أقول بأنها تعتمد على قواعد اللغة نفسها :P

في ++C ربما تكون المسافة غير مؤثرة و لكنها في Python مؤثرة في نحو اللغة.

تحياتي...

حياك الله

وأتفق معك

وقد كنت أقصد لغة ال++C ... حيث أنها تتجاهل المسافات ...

وشكراً لك

Adban كتب:

• ما فاءدة أن يكون المؤشر من نوع float وله مساحة int ! الذي لم أفهمه لماذا نقوم بتعريف نوع للمؤشر اذا كنا سنتحكم بالمساحة التي سنحجزها له!

نوع المؤشر مفيد في مقدار القفزة التي ستقفزها مع كل زيادة لذلك المؤشر. لاحظ التالي:

int *p;
p=malloc(1000*sizeof(char));
p++;

تسبب الزيادة الأخيرة في المؤشر p انتقاله من عنوانه الأولي إلى عنوان جديد ، تكون السعة بين العنوانين هي حجم نوع المؤشر (قفزة بحجم int).

Khaled.Alshaya كتب:

و عليكم السلام و رحمة الله و بركاته,

عزيزي, الكلام يطول لبعد الأسئلة عن بعضها و لكن باختصار.

malloc و أخواتها يمثلان الـ heap memory في C. هناك stack memory و هناك static memory. النوع الثاني و الثالث, يعتبران ضمن قواعد اللغة نفسها. بينما الـ heap memory تعتبر شيئاً يوفر عبر المكتبات, و لأهميته القصوى فهو ضمن المكتبات القياسية المعدودة على أصابع اليد. بالطبع لا يوجد شيء اسمه خاطئ و شيء اسمه صحيح لهذه الحالة, هذه هي فلسلفة C منذ أربعين عام, و لها فوائدها و لها محدودياتها.

لغة C لا تمنع المبرمج من فعل شيء بشكل خاطئ. هذا الأمر له فوائد و له أضرار أيضاً, أحد أضراره أنه you can shoot your self in the foot. الأمر الجيد هو الحرية المطلقة التي يحتاجها المبرمج في أماكن كثيرة من أعلى المعالج وصولاً إلى الطبقة التي توجد تحت التطبيقات. هناك الكثير من الأمور التي لن تحتاجها في طبقة التطبيقات! و هناك طرق لكتابة كود خاطئ في C أكثر من الطرق الصحيحة. باختصار هي لغة للمختصين بشكل عام. و هذه هي فلسفتها! الـ Type Safety مكلفة في بعض الأحيان و في C هناك قاعدة تقول بأن اللغة يجب أن تتبع zero-overhead principle لكي يكون الكود الناتج مماثلاً أو قريباً جداً مما لو كتبت الكود بالأسمبلي. لا تسألني لماذا يبني بها المبرمجون تطبيقات أيضاً, ربما لأنها أعظم لغة في التاريخ :blink:

malloc و أخواتها ضمن المكتبة القياسية الموجودة في ++C التي ينص على أنها مطابقة لمكتبة C. أحد الظواهر التي تدل على أن ++C تملك مرونة C و أكثر في الحقيقة هو أن الـ heap memory مضمنة ضمن مفاهيم اللغة نفسها عن طريق new operator و delete operator بنسختيهما الخاصة بالمتغيرات و الخاصة بالمصفوفات. و لكنك في نفس الوقت يمكنك أن توفر مكتبة كـ memory manager دون تعديل اللغة نفسها!

ماذا تعني بمقاييس اللغة "النظرية"؟ هناك طريقتان لتعريف لغة برمجة. في الحالة المشهورة يتم عمل reference implementation لسهولة الموضوع من ناحية و كون هناك عدة dialects من اللغة في عدة مترجمات. اللغات الكبيرة يتم عمل standardization لها لكي يكون مرجع للجميع. إذا لم يكن المترجم الذي تستخدمه يتبع المواصفات فهو ليس بمترجم ++C أصلاً! جميع المترجمات التي أعرفها تتبع المواصفات حرفياً, و إذا كان هناك خلل فهو يعتبر bug لا أكثر!

VC و GCC و clang و Comeau و مترجم بورلاند الذي لا اعرف ماذا يسمى الآن و غيرهم من المترجمات الموجودة من أصغر المنصات للـ super computer platforms.

هل تعلم يا صديقي أنك لو قمت بترجمة الملف ثم قمت بتعديل مسافة فيه لا تؤثر على الكود إطلاقاً ثم قمت بترجمة البرنامج مرة أخرى قد لا ينتج الكود نفسه بالضبط؟! طبعاً هذا غير وارد الحدوث إلا نادراً جداً و لكنه قد يحصل. عملية الترجمة ليست عملية deterministic إلا نظرياً. بينما في الحقيقة المترجمات تتأثر بكمية الذاكرة الموجودة في غيرها من العوامل و قد يوثر ذلك على تفعيل عملية Internal Optimization مكلفة.

تحياتي...

أخي خالد - صاحب الكلمات الذهبية - هل يمكن أن نقول أن قوة اللغة في الجوهر تكمن في قوة معاييرها؟