لماذا قررتم بناء المحرك من الصفر؟

اعتقد بغرض التعلم,

هناك مقولة: لا تعد اختراع العجلة, الا اذا اردت تعلم المزيد عن العجلات

لا اعرف من قائلها الاصلي .. ربما Jeff Astwood

http://www.codinghorror.com/blog/archives/001145.html

اقتباس

هناك مقولة: لا تعد اختراع العجلة, الا اذا اردت تعلم المزيد عن العجلات

صحيح, Jeff هو القائل, و لكن ألا تعتقد أن بناء مكتبة للتعامل مع الملفات هو إعادة اختراع للعجلة و الطريق في آن واحد -_-

ربما بناء محرك ألعاب هو إعادة اختراع للعجلة, و لكن ماذا عن بناء مكتبات للملفات و التعامل مع XML و خلافه؟ هل هي بالفعل من ضمن مهام محرك الألعاب.

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

تحياتي,,

الهدف الأساسى من بناء هذا الحرك هو هدف تعليمى بحت وتطبيقى فى نفس الوقت فكل المشتركين فى المشروع لديهم جوانب قوه و جوانب ضعف و كل ما نهدف إليه هو ان نكمل نقاط الضعف بكل منا عن طريق تبادل خبارتنا فى كل جوانب المشروع.

بالنسبه لموضوع عدم الإستعانه بمكتبات خارجيه فالسبب بذلك هو اننا نريد ان نعرف كل جزء كيف تم عمله و لماذا تم بهذا الإسلوب و إلا فما الهدف من كون المشروع تعليمى.

اقتباس

لكن ألا تعتقد أن بناء مكتبة للتعامل مع الملفات هو إعادة اختراع للعجلة و الطريق في آن واحد

لا اتفق معك فى هذه النقطه اخى خالد فإذا افترضنا ان المكتبه ستعمل داخل ويندوز فقط فـ أخر ما نريد الإستعانه به هو مكتبة الملفات القياسيه لإنها بكل الأحوال ابطء من المتوفره بنظام التشغيل حيث ستجد فى المرتبه الأوله دوال التعامل مع الملفات للقراءة و الكتابه يليها الـ File Mapping يليها مكتبة الملفات القياسيه و حيث ان التعامل مع الملفات هو عنصر اساسى داخل اى محرك فلابد من ان تكون فئاته على اكبر قدر من السرعه، ايضا نحن لا نقوم بصناعة الدوال الخاصه بالتعامل مع الملفات و لكننا فقط نقوم بعمل تغليف لتلك الدوال داخل فئات حتى نستطيع استغلالها بأفضل شكل ممكن و نوفر على انفسنا عنا اعادة كتابة كود موجود من قبل كقراءة نوع int32 من ملف او كتابته.

كنت ابحث فى وقت ما عن مكتبة لحساب الـ Checksum للملفات و وجدت موضوع على CodeProject قام صاحبه بعمل اختبار بإستخدام 4 اساليب، ادخل على الموضوع من هنا لترى النتيجه، ستجدها فى اخر الموضوع.

صراحة انا من محبى Win32API و لكن هذا لا يعنى ان اتركها إلا ان كان هناك افضل منها فيما تفعله و لكنه ليس المكتبه القياسيه بالتأكيد او على الأقل اجزاء منها.

كما ترى فقد تم تقسيم المشروع على مرحلتين الأولى تعليميه بشكل كبير حيث يتم مناقشة الأمور دون الإستعانه بأى مكتبات خارجيه ثم تنفيذها و اختبارها و لذا بانتهاء المرحله الأولى ستجد ان كل منا اصبح على درايه كافيه بكيفية سير العمل فى المشروع و متطلباته و حتى كيفية التعاون مع الأخرين فى انجاز المهام المختلفه و بالتالى عند بدء المرحله الثانيه و التى اعتبر انها هى المشروع نفسه ستحدث الكثير من التغيرات التى لم تكن ملائمه فى المرحله الأولى.

اقتباس

هناك مقولة: لا تعد اختراع العجلة, الا اذا اردت تعلم المزيد عن العجلات

يمكنك اضافة إلى الجمله السابقه: او صنع عجله بإمكانيات افضل من الموجوده او لتتعلم كيف تمت صناعة العجله الموجوده لتستفيد اكبر استفاده من امكانياتها.

اخوانى فى الله:

فى البدايه و النهايه نحن نتعلم و لا ضرر من ان نعيد صناعة العجله حتى ان كانت متطابقه مع الموجوده، و لكن بعد صناعتك لتلك العجله ستجد انك على درايه بها اكثر من اى شخص اخر لإنك صانعها و لست مستخدمها و هناك فرق كبير بينهم.

و الله ولى التوفيق

السلام عليكم،

أوافق الأخ خالد بشدة فيما قاله، ولقد عرضت بدأ مشروع مشابه جداً في موقع AGDN حاولت الدفع فيه نحو المستوى الأعلى ولكن لم أحصل على التشجيع الكافي لأستمر (كان الأمر أيضاً محاولة لجس النبض خاصة وإن تلك الفترة كانت فترة نشطة جداً هناك).

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

أما إمكانية أن نقوم بتصميم عجلة أفضل من تلك الموجودة التي تم تصميمها وصقلها على مدى عشرات السنين من قبل عدد كبير من المبرمجين هي إمكانية ضئيلة جداً تكاد تكون صفر، هل أتجرأ وأقول إنها إمكانية مستحيلة أيضاً؟

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

آسف إن كان كلامي قاسياً. :unsure:

السلام عليكم ...

شكراً على التوضيح السريع :)

مكتبات الـ IO هي من أصعب المكتبات من ناحية التصميم و الـ Implementation. لست مقتنعاً حقيقة بأنه يمكنك بناؤها على جنب مع مكتبة ألعاب. لاحظ أني لا أنتقص من قدركم, فأنا أبديت إعجابي الشديد بالمحرك :)

و لكن ما تريدون فعله يحتاج إلى مجهود سنين. ببساطة مكتبات الـ IO و مكتبات الـ Math, و المكتبات الـ General Purpose بشكل عام, ربما تبدو سهلة من الوهلة الأولى, و لكنها الأكثر صعوبة و تحتاج إلى أكثر المبرمجين خبرة.

ببساطة, رأيي أنها لا تصلح أن تكون مشروعاً تعليمياً, و أنكم تضيعون وقتكم الثمين, في فرعيات, لالزوم لها. أتمنى أن أرى المحرك يصبح حقيقة.

أخي محمد,

أختلف معك حول "مفهوم السرعة". هل تعتقد أن بإمكانك توفير مكتبات IO أفضل من التي توفرها Microsoft لمبرمجين ++C في Visual Cpp؟

ثانياً أن تضمن جميع أدوات الـ IO التي يعرفها "كل" من يبرمج بـ ++C, مهما كانت المنصة التي يعمل عليها.

عموماً, المقال نتائجه ليست دليلاً على شيء, لأن هناك عدة ثغرات في النتائج.

المقارنة يجب أن لا تتم بين fstream و الدوال المذكورة من Win API. الـ fstream يوفر وظائف لا توفرها تلك الدوال, و هما أصلاً ليسا نداً حتى يتم مقارنتهما!

عندما تريد أن تقارن دوال الوصول إلى الملفات, قارنها بـ filebuf مع ضبط حجم الـ Buffer المناسب, و حينها لنرى الفرق الذي أظهره المقال.

لماذا تريد مقارنة text stream بـ binary file؟! قارن binary file بـ binary file.

عموماً أنا موضوع التعلم لا يقتصر على السرعة لوحدها. أهم شيء هو نظافة الكود و التأكد من عمله بشكل صحيح. و لا أعتقد أن عشرين مبرمجاً يكفون لبناء مكتبة General Purpose كالتي تحاولون بناءها.

أتمنى أن يتم التركيز على المحرك, الذي أرى أنكم أصحاب معرفة في هذا الفرع من البرمجة, و أكملوا, و أنا أول مستخدم و داعم لهذه المكتبة :)

تحياتي...

بعيدا عن هذا الموضوع

اخوانى خالد و سلوان انا افرح عندما ارى مشاراكتكم، لإنكم على خلاف الكثير كلامكم واضح و صريح و لا يهم مدى قسوته لإنه فى النهايه هدفكم هو توضيح حقائق قد اكون اجلها ايضا لكم وجهة نظر مختلفه كثيرا عن وجهة نظرى فى بعض الأمور لذلك فأنتم اكثر الأشخاص افادة لي فشكرا لكم

و اريد ايضا ان اقول لكلاكما شئ و هو انى احبكما فى الله.

نعود للموضوع

اقتباس

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

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

اقتباس

أما إمكانية أن نقوم بتصميم عجلة أفضل من تلك الموجودة التي تم تصميمها وصقلها على مدى عشرات السنين من قبل عدد كبير من المبرمجين هي إمكانية ضئيلة جداً تكاد تكون صفر، هل أتجرأ وأقول إنها إمكانية مستحيلة أيضاً؟

العجله التى تم تصميمها على مدى عشرات السنين تم صنعها بإستخدام ادوات هى بدورها تم صنعها من عشرات السنين و ما يحدث الأن هو اضافة على هذه العجله، اما الأن فتوجد اداوت احدث و اقوى و قد تقوم بصنع قلب هذه العجله بشكل جديد و اسرع و ايسر فلما لا.

و اذا نظرت لكود دوال الملفات فى مكتبات الـ C (بالطبع مترجم مفتوح المصدر) ستجد انها فى النهايه تتعامل مع الهارد وير بشكل مباشر (كنت قد درست مترجم C بسيط و هو Small C).

اقتباس

لنتوقف رجاءاً عن الخوف من المجهول، الخوف من المرحلة التي سنحتاج أن نتعامل فيها مع أشياء لم نتعلمها أو نتعامل معها بعد، لأن تلك المرحلة هي المرحلة المفيدة فعلاً،

انا معك اخى فى هذا الأمر.

اقتباس

مكتبات الـ IO هي من أصعب المكتبات من ناحية التصميم و الـ Implementation. لست مقتنعاً حقيقة بأنه يمكنك بناؤها على جنب مع مكتبة ألعاب

كلامك صحيح اخى خالد فتصنيع مكتبة للتعامل مع IO لا علاقة لها بمحرك العاب إلا من بعيد، و ساعود و أقول مره اخرى هدفنا صنع فئات للتعامل مع الملفات لتتوافق مع احتياجاتنا البسيطه داخل المحرك.

----------------------------------------------------

انا لا اناقض نفسى و لكن احيانا المفاهيم تختلط مع بعضها، فأنا اوافقكم فييما يتعلق في تركيز الجهود لإنتاج محرك العاب و ليس مكتبة للتعامل مع المفات فهم موجودين بالفعل، و لكنى اعتراضى هو ان نستخدم الموجود كما هو، بمعنى ان ما اريد قوله اننا يمكننا صنع فئات مبنيه على الفئات الموجوده و تختصر العمليات التى نحتاجها.

اقتباس

اتمنى أن يتم التركيز على المحرك, الذي أرى أنكم أصحاب معرفة في هذا الفرع من البرمجة

اتمنى انا ذلك ايضا اخى خالد.

و عذرا على الإطاله.

و الله ولى التوفيق