لم تم قياس معمارية الحاسب بهذه الطريقة؟

بدأه mhewedy في 14 يوليو 2010 · 10 رد · 865 مشاهدة · في لغة C و ++C

#114 يوليو 2010 في 03:53 صاحب الموضوع

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

وجدت في بعض الأكواد, تم حساب معمارية الحاسب بهذه الطريقة البسيطه:

printf("Architecture:   %ld-bit\n", 8 * (long)sizeof(void *));

أوليس حجم الكلمة (word) و الذي هو int هو ما يحسب عليه معمارية الحاسب؟؟؟

شكرا أخي الأستاذ خالد على ردك.

معني هذا, أن السطر الذي أدرجته أنا من الأفضل أن يكتب بهذه الطريقه:

printf("Architecture:   %ld-bit\n", CHAR_BIT * (long)sizeof(void *));

؟ و إن كان كذلك, فلماذا لم يستخدم sizeof(int) ؟ فهذا هو السؤال.....

هل لأن void* يمثل وحده واحده كامله من الذاكره؟

ننتظر موضوعك على أحر من الجمر :D

#214 يوليو 2010 في 08:36

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

سؤال جميل أخي هويدي :)

دعني أوضح لك شيئاً في البداية. لغة C عندما صممت, وضع في الحسبان أنها ستعمل على أنظمة مختلفة جذرياً. حتى افتراض أن الـ Byte يحتوي على 8 bits لا يفترض في لغة C! لغة C و ++C تعملان "فعلياً" على أنظمة حيث عدد الـ Bits في الـ Byte الواحدة يمكن 8 أو غير ذلك. مثال ذلك, بعض الـ DSP-Digital Signal Processors التي تحتوي على byte بحجم 40 bits. أنواع البيانات تكون من مضاعفات الـ Byte, و لا تنسى أننا قلنا بأن الـ Byte لا يفترض أن يكون أصلاً 8 bits. بالطبع, ربما لن ترى في حياتك كلها تلك المنصات حيث الـ byte لا يتكون من 8 bits. أصبحت الـ Byte مرادفاً لـ 8 bits رغم أن المصطلح الأدق هو octet.

حسناً, ماذا عن أنواع البيانات؟

أنواع البيانات أيضاً لم يتم تحديد حجمها(يجب أن تكون من مضاعفات الـ Byte الخاص بالمنصة, و لا يمكن أن تكون كسور). السبب بسيط جداً, و هو أن لدى مصنع المترجم الحرية في توزيع أنوع البيانات بحيث يحصل على أكبر مساحة لتوفير efficiency. لا تنسى أن كتابة كود generic سيصبح صعباً(و يجب أن يكون لديك خبرة كبيرة في C حتى تكتب كود يمكن الإعتماد عليه في أكثر من منصة). و لكن المردود كبير أيضاً. خذ مثلاً Sqlite و Lua, كلاهما يعملان حيث يوجد مترجم C بغض النظر عن المنصة, و ترجمتهما على أي منصة يعطي نفس الكفاءة تقريباً, لأنه ليس هناك افتراضات حول أحجام البيانات. هذه النقطة تحتاج لتوضيح أكثر, بإذن الله سوف أطرح لك مثال عن متى نحتاج و كيف نستطيع كتابة كود لا يعتمد على حجم معين للأنوع الأولية.

سأعود لإكمال الموضوع, لأنه كبير جداً, و لكن سأحاول طرح مثال بإذن الله. حالياً, يمكنك معرفة عدد الـ bits في أي نوع بالطريقة التالية:

#include <stddef.h> /* size_t   */
#include <limits.h> /* CHAR_BIT */

int main()
{
	/* How many bytes in int and void*
	   Note that CHAR_BIT is the number of bits in a byte */
	size_t bits_in_int = sizeof(int) * CHAR_BIT;
	size_t bits_in_void_ptr = sizeof(void*) * CHAR_BIT;
}

بالنسبة لإجابة سؤالك, فهو أنه ليس هناك شيء اسمه قياس المعمارية, و لكن "اصطلح" على أن يكون النوع int هو النوع الذي يوافق حجم الـ registers في المنصة التي سوف يعمل عليها البرنامج. و هذا الافتراض أصبح معتمد رغم أنه ليس مطلوباً في الحقيقة.

تحياتي...

Follow me on bitbucket

#314 يوليو 2010 في 12:48

اقتباس
هل لأن void* يمثل وحده واحده كامله من الذاكره؟

في الحقيقة, أن المؤشرات ليست أنواع أولية بالمعنى "الدقيق". و كما قلت لك سابقاً, اصطلح على تعريف int على أنه الـ word الخاصة بالـ machine التي يعمل عليها البرنامج. و لكن هذا ليس شرطاً مطلوباً. أما *void فهي عبارة عن مؤشرات خاصة, تستطيع حمل أي نوع من أنواع المؤشرات الأخرى, و بالتالي, يجب أن تكون كبيرة كفاية لحمل أي نوع مؤشرات. و هذا باعتقادي سبب استخدامها في الكود الذي وضعته. برأيي الشخصي, استخدام int أفضل, لأن هذا هو الاستخدام الشائع. لاحظ أن *void أو أي مؤشر ليس من الضرورة أن يكون نوعاً بسيطاً, فربما يكون نوعاً مركباً بكل بساطة. هل تذكر أيام Segmentations و خلافه؟ المؤشر كان عبارة عن قسمان قسم للـ Segmentation و قسم للـ offset. و بالتالي, سيكون حجم المؤشر يختلف عن حجم الـ word في المنصة. حالياً, مع انتشار الـ Virtual Memory فالأمر أصبح شبه معتمد بأن المؤشرات عبارة عن أنواع بسيطة. و لكن نعود من جديد للنقطة الأساسية, و هي أن الـ C و ++C كـ Standards لاتفترضان أياً مما نتحدث عنه على شكل شروط.

يعتقد البعض أن C سيئة في هذه الناحية, من حيث أننا لا نستطيع معرفة حجم المتغير(العددي على سبيل المثال) الذي نتعامل معه, و هذا يعطي أفضلية للغات الأخرى. بالطبع هذا لو كنا نتكلم في مادة programming 1 :)

سأريك شيئاً في ++C, و يمكنك فعل نفس الشيء في C. للأسف مترجم Microsoft لايدعم ذلك الأمر للغة C.(المكتبة غير متوفرة افتراضياً لـ VC و لكن هناك مكتبة يمكن تحميلها بكل بساطة لفعل الأمر):

#include <boost/integer.hpp>
int main()
{
	boost::uint8_t  octet;
	boost::uint16_t two_octets;
	boost::uint32_t four_octects;
	boost::uint64_t eight_octets;
	boost::uintmax_t max_int; // maximum unsigned integer type available.
}

هل ترى, لدينا الأنواع ذات الأحجام المحددة في C و ++C :)

هل تريد رؤية مزيد من المرونة:

boost::int_t<32>::exact exactly_32_bits;
boost::int_max_value_t<9999>::fast this_variable_can_hold_9999_for_sure;

يمكن الحصول على ما تريد بكل بساطة, و بمرونة غير موجودة في أي مكان آخر. و لكن لاحظ, أن هذه الأشياء مفيدة على مستوى الـ system programming و بكل بساطة ليس هناك فائدة منها عندما تريد بناء برنامج شؤون الموظفين. لايجب الخلط بين مهمة C و ++C و بين الحاجة إلى abstractions أعلى. في ++C يمكنك الحصول على Abstractions كالموجودة في أي لغة أخرى, أما في C فهي بطبعها low level.

متى نحتاج إلى هذه المرونة؟

بالطبع, لن تقضي حياتك كلها مع أحجام البيانات :) سأضرب لك مثالاً, تعلمته من مكتبة نار على علم بلغة C, و أحاول تطبيقه في مكتبتي الجديدة uint و لكن بـ ++C.

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

الأعداد العملاقة التي لا يمكن تمثيلها بالأنواع الأولية في أي لغة, يتم تحويلها إلى base آخر. ربما يستخدم كل octet أو byte إن أحببت تسميته كـ خانة. بالتالي تصبح كل خانة قادرة على حمل الأعداد من 0 إلى 255. ببساطة نتعامل مع أعداد base 256. أو يمكننا أن نعمل على خانات عملاقة. بحيث تكون كل خانة عبارة int. الآن, من المعلوم أنك إذا أردت أقصى سرعة حسابية في المعالج, فالمفروض أن تعمل على حجم الـ registers. بالتالي, يمكننا تمثيل كل خانة بـحجم register واحد. و لكن كيف نقوم بذلك portably؟ هنا تأتي فكرة عدم تحديد أحجام البيانات في C. فيمكننا ترك عملية تحديد حجم الخانة, لكل مترجم, و بالتالي سنعمل على حجم الـ register و الذي في الغالب هو حجم int كما تكلمنا سابقاً. هذه هي الفكرة. سأدع طريقة الحصول على الحجم المطلوب لأنها تحتاج إلى الكثير من الكود في C و لننظر إلى خوارزمية جمع الأعداد العملاقة عندما نقوم بكتابتها بشكل generic في C:

component carry = 0;
for(size_t i = 0; i < components; ++i)
{
	double_component sum = (double_compoenet)lhs + rhs + carry;
	lhs = component_sum(sum);
	carry  = component_carry(sum);
}

الآن لو استطعنا جعل كل مترجم يقوم باختيار الأنواع المناسبة لـ component و double_component بحيث يكون حجم الثاني ضعف حجم الأول, مع الأخذ في الحسبان أننا نريد أكبر أحجام ممكنة على المنصة التي نترجم لها, سنحصل على أكبر efficiency ممكنة دون أن نلجأ للـ Assembly الخاصة بالمنصة.

كيفية الحصول على أكبر حجم ممكن إضافة إلى نوع بنصف ذلك الحجم متروك كتمرين للقارئ العزيز :lol:

إذا كان الكلام مشتتاً فلاتقلق, أنت تسير على الطريق الصحيح, كل ما عليك أن تصبر قليلاً, و سنرى مبرمج C ماهر بيننا بإذن الله.

تحياتي...

تم تعديل هذه المشاركة بواسطة Khaled.Alshaya في 14 يوليو 2010 في 12:59

Follow me on bitbucket

#414 يوليو 2010 في 15:20

السلام عليكم

اقتباس
أصبحت الـ Byte مرادفاً لـ 8 bits رغم أن المصطلح الأدق هو octet.

أليس الـ byte هو نفسه octet !؟

اقتباس
بالنسبة لإجابة سؤالك, فهو أنه ليس هناك شيء اسمه قياس المعمارية, و لكن "اصطلح" على أن يكون النوع int هو النوع الذي يوافق حجم الـ registers في المنصة التي سوف يعمل عليها البرنامج. و هذا الافتراض أصبح معتمد رغم أنه ليس مطلوباً في الحقيقة.

1-هل أقهم من كلامك أن حجم int ربما لا يساوي حجم الـ registers في بعض المنصات ...!؟

2-ماذا تقصد بـ "حجم الـ registers في المنصة" أو "حجم المسجل داخل البروسسور" !؟

اقتباس
يعتقد البعض أن C سيئة في هذه الناحية, من حيث أننا لا نستطيع معرفة حجم المتغير(العددي على سبيل المثال) الذي نتعامل معه, و هذا يعطي أفضلية للغات الأخرى

ألا يُعد هذا لصالح لغة السي ؟

لأن لغة السي لا تحدد لك حجم البيانات لأنواع البيانات و لكنها تحدد القيمه العطمى و الصغرى للأنواع الرقميه و ذلك للحفاظ على ميزة المحمولية.

ما رأيك ؟

تم تعديل هذه المشاركة بواسطة محمد علاء الدين عبد العزيز في 8 سبتمبر 2010 في 21:50

الــ GC بين حرية الماضي و قيود الحاضر !

اقطعوا يد السارقة ..

#514 يوليو 2010 في 16:15

اقتباس
أليس الـ byte هو نفسه octet !؟

لا يا عزيزي, الـ octet عبارة عن حالة خاصة من الـ byte عندما يكون عدد الـ bits في الـ byte ثمانية بالضبط. و لكن الاستخدام الشائع لكلمة byte يقصد به 8 bits, لأن أكثر من 99% من الأجهزة التي ستتعامل معها تعتمد على ذلك. هناك معالجات صغيرة جداً, كالموجودة في التلفاز أو الغسالة أو الـ super computers أو .... و هكذا هذه ربما يكون فيها الـ byte أكبر أو أصغر, و في الغالب أكبر. أذكر عند دراسة بروتوكولات الشبكات, فإن حجم أجزاء الـ headers يحدد بالـ bits, و لم أذكر أن صادفتنا كلمة byte, لأنها لا تعني بالضرورة 8 bits.

اقتباس
1-هل أقهم من كلامك أن حجم int ربما لا يساوي حجم الـ registers في بعض المنصات ...!؟

نعم هذا ممكن. عند الترجمة لـ x64 باستخدام VC, حجم int يكون 4 bytes. بينما حجم size_t يكون 8 bytes, بينما عند الترجمة لـ x86 فإن الحجم يكون 4 في كلا النوعين. ابحث عن سبب كون int عبارة عن 4 bytes :)

اقتباس
2-ماذا تقصد بـ "حجم الـ registers في المنصة" أو "حجم المسجل داخل البروسسور" !؟

عزيزي, المعالجات لا تتعامل مع bytes و إنما مع words. و حجم تلك الـ words هو حجم الـ register نفسه. ببساطة عندما تقوم بالتعامل مع byte واحد, ففي أحسن الأحوال إن كنت تعمل على معالج مثل x86 سيقوم المعالج بعمل عمليات shifting للتخلص من الـ bytes الغير لازمة و إعطائك الـ byte الأول فقط. في معالجات أخرى كـ Motorola 68K سيرمى exception في وجه المبرمج!

اقتباس
ألا يُعد هذا لصالح لغة السي ؟
لأن لغة السي لا تحدد لك حجم البيانات لأنواع البيانات و لكنها تحدد القيمه العطمى و الصغرى للأنواع الرقميه و ذلك للحفاظ على ميزة المحمولية.
ما رأيك ؟

لغة C و ++C لاتحددان لا القيم الصغرى و لا القيم الكبرى. ببساطة, لاتحددان سوى التالي:

char <= short int <= int <= long

إضافة إلى أن جميع الأنواع أحجامها من مضاعفات char, و هذا يعني أنه من الممكن أن تكون جميع الأنواع بنفس حجم char! و لكن هذا ليس شائعاً.

هو بالفعل في صالح C. و لذلك C و ++C تستخدمان كـ Infrastructure. و لكن مع هذا يأتي وجع الرأس, و القواعد الغريبة أحياناً للغة لجعلها Super Portable. أي أنه trade-off و لكن في هذه الناحية, بالطبع هو من صالح C إن كنت تستخدم C بالطريقة الصحيحة.

تم تعديل هذه المشاركة بواسطة Khaled.Alshaya في 14 يوليو 2010 في 16:31

Follow me on bitbucket

#614 يوليو 2010 في 16:55

السلام عليكم

اقتباس
لا يا عزيزي, الـ octet عبارة عن حالة خاصة من الـ byte عندما يكون عدد الـ bits في الـ byte ثمانية بالضبط. و لكن الاستخدام الشائع لكلمة byte يقصد به 8 bits, لأن أكثر من 99% من الأجهزة التي ستتعامل معها تعتمد على ذلك. هناك معالجات صغيرة جداً, كالموجودة في التلفاز أو الغسالة أو الـ super computers أو .... و هكذا هذه ربما يكون فيها الـ byte أكبر أو أصغر, و في الغالب أكبر. أذكر عند دراسة بروتوكولات الشبكات, فإن حجم أجزاء الـ headers يحدد بالـ bits, و لم أذكر أن صادفتنا كلمة byte, لأنها لا تعني بالضرورة 8 bits.

هل أفهم من كلامك أن octet=8 bits بينما الـ byte ليس بالضرورة أن يكون كذلك !؟

اقتباس
نعم هذا ممكن. عند الترجمة لـ x64 باستخدام VC, حجم int يكون 4 bytes. بينما حجم size_t يكون 8 bytes, بينما عند الترجمة لـ x86 فإن الحجم يكون 4 في كلا النوعين. ابحث عن سبب كون int عبارة عن 4 bytes :)

ما هو x64 و x68 و size_t , ياريت توضح أكثر :blush:

اقتباس
عزيزي, المعالجات لا تتعامل مع bytes و إنما مع words. و حجم تلك الـ words هو حجم الـ register نفسه. ببساطة عندما تقوم بالتعامل مع byte واحد, ففي أحسن الأحوال إن كنت تعمل على معالج مثل x86 سيقوم المعالج بعمل عمليات shifting للتخلص من الـ bytes الغير لازمة و إعطائك الـ byte الأول فقط. في معالجات أخرى كـ Motorola 68K سيرمى exception في وجه المبرمج!

ماذا تقصد بـ words !؟ أرجو التوضيح :blush:

اقتباس
و حجم تلك الـ words هو حجم الـ register نفسه

يا ريت تشرح هذا السطر.

اقتباس
لغة C و ++C لاتحددان لا القيم الصغرى و لا القيم الكبرى

كيف يا أستاذي الفاضل ...!؟

الكلام ليس من بنات فكري و إنما أخذتُه من الأستاذ محمد علاء الدين:

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

للمزيد أرجو أن تقرأ الموضوع التالي:

تساؤل حول أحجام البيانات في لغتي السي و السي++

تحياتي :)

الــ GC بين حرية الماضي و قيود الحاضر !

اقطعوا يد السارقة ..

#714 يوليو 2010 في 18:09

السلام عليكم

اقتباس
لغة C و ++C لاتحددان لا القيم الصغرى و لا القيم الكبرى. ببساطة, لاتحددان سوى التالي:
char <= short int <= int <= long

هذه المعلومه غير دقيقه اخى خالد، صحيح ان اللغه تشترط ان الأنواع التى ذكرتها لابد أن تكون النسبه بين أحجامهم المذكوره كما أسلفت و لكن ايضا تشترط ان يستطيع كل نوع ان يمثل مدى معين من الأرقام، دعنا نراجع الفقرتين التاليتين من الجزء [basic.fundamental] الخاص بالإصدار 1998 و 2003 و C++0x:

اقتباس
2 - There are four signed integer types: “signed char”, “short int”, “int”, and “long int.” In this list, each type provides at least as much storage as those preceding it in the list. Plain ints have the natural size suggested by the architecture of the execution environment³⁹⁾ ; the other signed integer types are provided to meet special needs.
3 - For each of the signed integer types, there exists a corresponding (but different) unsigned integer type: “unsigned char”, “unsigned short int”, “unsigned int”, and “unsigned long int,” each of which occupies the same amount of storage and has the same alignment requirements (3.9) as the corresponding signed integer type⁴⁰⁾ ; that is, each signed integer type has the same object representation as its corresponding unsigned integer type. The range of nonnegative values of a signed integer type is a subrange of the corresponding unsigned integer type, and the value representation of each corresponding signed/unsigned type shall be the same
----------------------------------
39) that is, large enough to contain any value in the range of INT_MIN and INT_MAX, as defined in the header <climits>.
40) See 7.1.5.2 regarding the correspondence between types and the sequences of type-specifiers that designate them.

بالنسبه للغة الـ C فبداخل الـ Draft Standard بتاريخ 25-7-2010 الجزء 6.2.5 و عنوانه Types تجد الفقرات التاليه:

اقتباس
5 - An object declared as type signed char occupies the same amount of storage as a ‘‘plain’’ char object. A ‘‘plain’’ int object has the natural size suggested by the architecture of the execution environment (large enough to contain any value in the range INT_MIN to INT_MAX as defined in the header <limits.h>).

ايضا داخل الجزء 5.2.4.2.1 و عنوانه Sizes of integer types <limits.h> ينص على التالى:

اقتباس
1 - The values given below shall be replaced by constant expressions suitable for use in #if preprocessing directives. Moreover, except for CHAR_BIT and MB_LEN_MAX, the following shall be replaced by expressions that have the same type as would an expression that is an objec correhe corresponding type converted according to the integer promotions. Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign.
— number of bits for smallest object that is not a bit-field (byte)
CHAR_BIT 8
— minimum value for an object of type signed char
SCHAR_MIN -127 // −(27 − 1)
— maximum value for an object of type signed char
SCHAR_MAX +127 // 27 − 1
— maximum value for an object of type unsigned char
UCHAR_MAX 255 // 28 − 1
— minimum value for an object of type char
CHAR_MIN see below
— maximum value for an object of type char
CHAR_MAX see below
— maximum number of bytes in a multibyte character, for any supported locale
MB_LEN_MAX 1
— minimum value for an object of type short int
SHRT_MIN -32767 // −(2¹⁵ − 1)
— maximum value for an object of type short int
SHRT_MAX +32767 // 2¹⁵ − 1
— maximum value for an object of type unsigned short int
USHRT_MAX 65535 // 2¹⁶ − 1
— minimum value for an object of type int
INT_MIN -32767 // −(2¹⁵ − 1)
— maximum value for an object of type int
INT_MAX +32767 // 2¹⁵ − 1
— maximum value for an object of type unsigned int
UINT_MAX 65535 // 2¹⁶ − 1
— minimum value for an object of type long int
LONG_MIN -2147483647 // −(2³¹ − 1)
— maximum value for an object of type long int
LONG_MAX +2147483647 // 2³¹ − 1
— maximum value for an object of type unsigned long int
ULONG_MAX 4294967295 // 2³² − 1
— minimum value for an object of type long long int
LLONG_MIN -9223372036854775807 // −(2⁶³ − 1)
— maximum value for an object of type long long int
LLONG_MAX +9223372036854775807 // 2⁶³ − 1
— maximum value for an object of type unsigned long long int
ULLONG_MAX 18446744073709551615 // 2⁶⁴ − 1
2 - If the value of an object of type char is treated as a signed integer when used in an expression, the value of CHAR_MIN shall be the same as that of SCHAR_MIN and the value of CHAR_MAX shall be the same as that of SCHAR_MAX. Otherwise, the value of CHAR_MIN shall be 0 and the value of CHAR_MAX shall be the same as that of UCHAR_MAX.20) The value UCHAR_MAX shall equal 2CHAR_BIT − 1.

بالنسبه لأحجام البيانات داخل الـ Standard للغة الـ Cpp مكتوب داخل الجزء [expr.sizeof] و الذى هو تعريف المعامل sizeof التالى: (جزء من الفقره 1)

اقتباس
sizeof(char), sizeof(signed char) and sizeof(unsigned char) are 1; the result of sizeof applied to any other fundamental type (3.9.1) is implementation-defined. [Note: in particular, sizeof(bool) and sizeof(wchar_t) are implementation-defined.69) ] [Note: See 1.7 for the definition of byte and 3.9 for the definition of object representation. ]

الجزء 3.9.1 مفتاحه هو [basic.fundamental] و عنوانه Fundamental types و الأنواع الموجوده به هى (قمت بتجميعها):

char - signed char - unsigned char - short int - int - long int - unsigned short int - unsigned int - unsigned long int - wchar_t - float - double - long double.

و الـ C++0x تضيف لهم:

long long int - unsigned long long int

بالنسبه للرقم 1 الذى يعاد عند استخدام المعامل sizeof مع النوع char (بأى من الصيغ الخاصه به) فهو 1 بايت (و البايت يحتوى على عدد معين من bits و التى يتم معرفتها من الثابت CHAR_BIT)

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

مدونتي: C++ Tips and Tricks

#814 يوليو 2010 في 18:52

أهلاً أخي محمد,

اقتباس
39) that is, large enough to contain any value in the range of INT_MIN and INT_MAX, as defined in the header <climits>.

هذه عبارة عن implementation defined constants. و 03++C تعتمد على C89, و Cpp0x تعتمد على C99. و في كلا الحالتين, مدى الأنواع متروك للـ Implementation. هذا بالنسبة لـ ++C و أنا متأكد منه.

المعلومة الجديدة, و بصراحة انا متفاجئ منها :lol: هي المتعلقة بآخر C draft. هل من مكان لتحميله بعد إذنك. رغم أن الـ C standards الحالية تعتبر هي لغة C, و لكن من الغريب أن تقوم C بتعريف أصغر مدى للأنواع. سأقرأه و ربما نتوصل إلى نقاش مثمر بإذن الله.

تعديل:

-------

أخ محمد كيف يكون آخر draft في 25-7-2010 ربما تقصد 25-6-2010 :P

جاري القراءة...

تحياتي...

تم تعديل هذه المشاركة بواسطة Khaled.Alshaya في 14 يوليو 2010 في 19:01

Follow me on bitbucket

#914 يوليو 2010 في 19:12

أخ محمد بالفعل, آخر draft لـ C يحدد "أصغر" مدى ممكن لتلك الأنواع و يترك للـ implementation الحرية في أن يكون المدى أكبر من ذلك!

لم أكن أعرف ذلك صراحة, و هذه أحد نقاط الإختلاف الجديدة بين ++C و C :)

بدأت الأسلاك تتشابك في عقلي, سأعود لهذه النقطة بعد قليل من القراءة.

تحياتي...

Follow me on bitbucket

#1014 يوليو 2010 في 19:18

اقتباس
أخ محمد كيف يكون آخر draft في 25-7-2010 ربما تقصد 25-6-2010 :P

ههه، صحيح كيف هذا :lol: ، خلاص عليه العوض فى عينيه شكلى طبقت المقوله لا ارى لا اسمع لا اتكلم فعليا.

اقتباس
في كلا الحالتين, مدى الأنواع متروك للـ Implementation. هذا بالنسبة لـ ++C و أنا متأكد منه.

و انا اثق فى كلامك، هل من الممكن افهامى اياها؟ و شكرا لك

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

مدونتي: C++ Tips and Tricks

#1114 يوليو 2010 في 19:42

يا محمد, عملتلي شورت في آخر فيوز كان عندي :lol:

كلامك تمام و صحيح 100%. لم أكن أعرف أن هناك Ranges مطلوبة من الـ standards! دائماً, كنت أعتقد أن قواعد الأحجام هي المطبقة, و عندما قرأت مشاركتك أول مرة اعتقدت أنها تتعارض مع قواعد الأحجام!

هنا تلخيص للـ standards الخاصة بـ ++C:

http://stackoverflow.com/questions/271076/what-is-the-difference-between-an-int-and-a-long-in-c/271132#271132

عموماً, لابد أن أرفع لك القبعة الآن :happy:

Follow me on bitbucket

مواضيع مشابهة

سؤال عن كيفية ربط الة قياس ميكانيكى بالحاسب ؟1 رد · 25 أبريل 2010
اريد انشاء نسخة من كائن بهذة الطريقة4 رد · 31 ديسمبر 2010
مالفرق بين تعريف المصفوفة بهذه الطريقة M() As Integer1 رد · 19 سبتمبر 2007
ما رأيكم في الاتصال بقاعدة البيانات بهذه الطريقة1 رد · 10 أبريل 2007
هل يمكن عرض البيانات بهذه الطريقة في التقرير10 رد · 24 أغسطس 2007
كيف أستطيع عرض ال DB بهذه الطريقة2 رد · 17 أكتوبر 2005

لم تم قياس معمارية الحاسب بهذه الطريقة؟

مواضيع مشابهة

عدد الزوار حالياً