شما عضو نیستید, برای دسترسی کامل به سایت لطفا از طریق این لینک ثبت نام نمائید.     close
 

تالارهای گفتمان جی تاک

جدیدترین موضوعات انجمنها دانلود تولبار جی تاک


بازگشت   تالارهای گفتمان جی تاک برنامه نویسی , طراحی وب و موضوعات مرتبط برنامه نویسی C, C++ and Visual C
ارسال موضوع جدید  پاسخ
 
لینک مستقیم ابزارهای موضوع جستجو در موضوع
قدیمی 5th February 2009   #1

Hesam

عضو پيشكسوت

 Hesam آواتار ها

تاریخ عضویت: Jan 1970
محل سکونت: PeRsIaN
نوشته ها: 1,156
تشکر از دیگران: 1,131
تشکر شده 3,412 بار در 1,128 پست

حالت
Procrastinating

 

محاوره ای ++C

سلاح‌ مخفي‌ محبوبترين‌ زبانهاي‌ اسكريپتينگ‌، پشتيباني‌ آنها از يك‌ حالت‌
محاوره‌اي‌ است‌. سيستمهاي‌ LISP و BASIC به‌ اين‌ دليل‌ محبوب‌ شده‌اند
كه‌ در آنها عبارات‌ مي‌توانند تايپ‌ شده‌ و بلافاصله‌ ارزيابي‌ شوند، بدون‌ شك‌
آنها خصوصيات‌ ديگري‌ نيز دارند اما اگر اينقدر تعاملي‌ نبودند چندان‌ مورد
توجه‌ قرار نمي‌گرفتند. البته‌ اين‌ مسئله‌ بيشترين‌ نمود را در زبانهائي‌ نظير
LISP دارد كه‌ در آنها هر چيزي‌ داراي‌ ارزشي‌ است‌ حتي‌ اگر صفر باشد، با اين‌
وجود تقريبا هر زبان‌ برنامه‌ نويسي‌ مي‌تواند بصورت‌ تعاملي‌ مورد استفاده‌
قرار گيرد. چنين‌ نحوه‌ اجرائي‌ از يك‌ سبك‌ برنامه‌ نويسي‌ "محاوره‌اي‌"
پشتيباني‌ مي‌كند كه‌ در آن‌ واكنش‌ كامپيوتر عملا آني‌ است‌. عليرغم‌
محدوديتهاي‌ سيستمهاي‌ تعاملي‌ نظير LISP، APL و يا FORTH، برنامه‌
نويسان‌ هنگام‌ كار با آنها بازدهي‌ بسيار خوبي‌ داشتند.
تنها ضرورت‌ اين‌ است‌ كه‌ زبان‌ برنامه‌ نويسي‌ مبتني‌ بر تابع‌ باشد. در
اينصورت‌ حتي‌ پاسكال‌ نيز مي‌تواند بصورت‌ تعاملي‌ تفسير شود. Eiffel و
Java مشكلاتي‌ را بروز خواهند داد زير آنها مبتني‌ بر كلاس‌ هستند. يك‌
اجراي‌ تعاملي‌ از جاوا ضرورتا با فشار بر روي‌ زبان‌ انجام‌ خواهد شد.
تفاوت‌ بزرگ‌ ميان‌ دو محيط دسته‌اي‌ (Batch) و تعاملي‌ در اين‌ است‌ كه‌
محيطهاي‌ دسته‌اي‌ بايستي‌ جريان‌ تلفيقي‌ خود را حفظ كنند، در حاليكه‌
محيطهاي‌ تعاملي‌ نيازمند حفظ جريان‌ ارزشيابي‌ هستند. معمولا سيستمهاي‌
تعاملي‌ با بروز اولين‌ خطا، تلاش‌ خود براي‌ كامپايل‌ نمودن‌ را متوقف‌ مي‌كنند.
كامپايلرهاي‌ ++C به‌ آساني‌ گيج‌ مي‌شوند و اين‌ مسئله‌ باعث‌ گيج‌ شدن‌
برنامه‌ نويس‌ مي‌شود كه‌ واقعا نيازمند آن‌ است‌ كه‌ اول‌ گزارش‌ خطا را مشخص‌
نمايد. اين‌ مسئله‌ خصوصا در مورد برنامه‌ نويسان‌ تازه‌ كار صحت‌ دارد. من‌
در ابتدا كارم‌ را با سيستمهاي‌ محاوره‌اي‌ ++C شروع‌ كردم‌ زيرا احساس‌
مي‌كردم‌ آنها ابزارهاي‌ بسيار مفيدي‌ براي‌ مبتدياني‌ باشند كه‌ در حال‌ يادگيري‌
اين‌ زبان‌ هستند. آزادي‌ در كاوش‌، يكي‌ از قسمتهاي‌ اساسي‌ جريان‌ آموزش‌
است‌ و يادگيري‌ زبان‌ انساني‌ در ابتدا با صحبت‌ كردن‌ آغاز مي‌شود، نه‌ با
خواندن‌ و يا نوشتن‌.

Hesam آفلاين است  
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiTweet this Post!
پاسخ با نقل قول
4 کاربر از شما به خاطر پست مفیدتان تشکر کرده اند :
قدیمی 5th February 2009   #2

Hesam

عضو پيشكسوت

 Hesam آواتار ها

تاریخ عضویت: Jan 1970
محل سکونت: PeRsIaN
نوشته ها: 1,156
تشکر از دیگران: 1,131
تشکر شده 3,412 بار در 1,128 پست

حالت
Procrastinating

 

++C در مقايسه‌ با BASIC براي‌ كارهاي‌ تعاملي‌ مناسبتر است‌ زيرا
عبارات‌ آن‌ مي‌توانند بيانهاي‌ معتبر باشند. براي‌ مثال‌ شما مي‌توانيد يك‌
تكليف‌ را تايپ‌ كنيد، ارزش‌ آن‌ به‌ شما نشان‌ داده‌ خواهد شد. همچنين‌ متغيرها
نيز بيانهاي‌ معتبر ++C هستند. آنچه‌ مي‌خواهم‌ در اين‌ مقاله‌ به‌ شما نشان‌
دهم‌، قدرت‌ استفاده‌ از ++C در اين‌ حالت‌ تعاملي‌ بصورت‌ عملي‌ است‌، و
اينكه‌ اين‌ كار چگونه‌ مي‌تواند بطور بالقوه‌ بازدهي‌ برنامه‌ نويسان‌ را تقويت‌
نمايد.
++C تعاملي‌ به‌ يك‌ هماهنگي‌ نسبتا ملايم‌ نياز دارد. در ++C
استانداردبيانها مي‌توانند با ساير توضيحات‌ تركيب‌ شوند، اما تنها در بدنه‌
توابع‌ و يا كلاسها. در ++C تعاملي‌ تعاريف‌ توابع‌ مي‌توانند بصورت‌
مفهومي‌ عمومي‌ با بيانها تركيب‌ شوند.
} ;x*x return { (x double)sqr double >;
;(٢)sqr >;
٠.٤ (double)
;٢ = x double >;
;x >;
٠.٢=x (double)
تمام‌ اينها بيانهاي‌ معتبر ++C هستند، با اين‌ استثنا كه‌ هيچ‌ محدوديت‌
مفهومي‌ در استفاده‌ از آنها وجود ندارد. در اينجا دوست‌ قديمي‌ و بدنام‌ ما
(پردازنده‌) بسيار مفيد مي‌شود. براي‌ مثال‌ من‌ براي‌ استفاده‌ از بيان‌ IF
هميشگي‌، عموما يك‌ ماكرو را تعريف‌ مي‌كنم‌:
(++i ;(n) < i ;٠=i int)for (n,i)FOR define# >;
;endl << i << cout (٥,i)FOR >;
٠
١
٢
٣
٤ اين‌ دليل‌ ديگري‌ بر اين‌ مسئله‌ است‌ كه‌ ++C زبان‌ تعاملي‌ بهتري‌ نسبت‌ به‌
پاسكال‌ (و حتي‌ بيسيك‌) است‌. اين‌ يك‌ زبان‌ مختصر و مفيد است‌ كه‌ مي‌تواند
با ماكروها حتي‌ از اين‌ هم‌ فشرده‌تر شود.
در حال‌ حاضر ايجاد كردن‌ مفاهيم‌ خودتان‌ در ++C رسمي‌ اصولا ايده‌ خوبي‌
نيست‌. اما در يك‌ مضمون‌ محاوره‌اي‌، مي‌توانيد از يك‌ سبك‌ غير رسميتر
استفاده‌ كنيد. در يك‌ سند قانوني‌ رسمي‌ به‌ زبان‌ انگليسي‌، نبايستي‌ از
اختصارها (نظير "t'don") استفاده‌ كنيد. اما در طول‌ يك‌ نشست‌ تعاملي‌ براي‌
پيگيري‌ سريعتر تعامل‌، ممكن‌ است‌ از هر موردي‌ كه‌ از نظر نحوي‌ قانوني‌
باشد، به‌ كرات‌ استفاده‌ كنيد:
()end.(ls),()begin.(ls) (ls)ALL define# >;
;(arr,(ls)ALL)COPY >;
من‌ اصولا در هنگام‌ تهيه‌ كدها تمايلي‌ به‌ انجام‌ اينكار ندارم‌.
استفاده‌ از ++C در يك‌ شيوه‌ تفسيري‌، بيش‌ از حد پيچيده‌ در نظر گرفته‌
مي‌شد اما اين‌ يك‌ مشكل‌ تاريخي‌ است‌ كه‌ بايستي‌ در مسيري‌ كه‌ برنامه‌ در
ابتدا بكار گرفته‌ مي‌شد، انجام‌ شود: پردازنده‌، مترجم‌ (به‌ C)، كامپايلر (به‌
اسمبلي‌)، اسمبلر (به‌ كد ابجكت‌) و لينكر (به‌ كد قابل‌ اجرا). يك‌ مفسر مدرن‌
نظير UnderC، ورودي‌ را از طريق‌ يك‌ Tokenizer پيش‌ پردازشي‌
دريافت‌ مي‌كند، و آن‌ را مستقيما به‌ Pcode كامپايل‌ مي‌كند كه‌ بلافاصله‌ پس‌
از آن‌ اجرا مي‌شود. اين‌ كد بطور آشكاري‌ كندتر از نتيجه‌ يك‌ كامپايلر واقعي‌
است‌، اما سيستمهاي‌ تعاملي‌ تنها بايد از زمان‌ واكنش‌ انسان‌ سريعتر باشند.
اصولا اگر شما بتوانيد كاري‌ را در كمتر از ١٥٠ ميلي‌ ثانيه‌ انجام‌ دهيد، شما
بعنوان‌ يك‌ عملگر آني‌ در نظر گرفته‌ مي‌شويد. اين‌ مسئله‌ كه‌ در اجراهاي‌
تعاملي‌ يك‌ مبدله‌ پيچيدگي‌/سرعت‌ وجود دارد، افسانه‌اي‌ است‌ كه‌ واقعيت‌
ندارد.

Hesam آفلاين است  
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiTweet this Post!
پاسخ با نقل قول
4 کاربر از شما به خاطر پست مفیدتان تشکر کرده اند :
قدیمی 5th February 2009   #3

Hesam

عضو پيشكسوت

 Hesam آواتار ها

تاریخ عضویت: Jan 1970
محل سکونت: PeRsIaN
نوشته ها: 1,156
تشکر از دیگران: 1,131
تشکر شده 3,412 بار در 1,128 پست

حالت
Procrastinating

 

++C به‌ اندازه‌ كافي‌ موجز است‌، اما شايد براي‌ استفاده‌ بصورت‌ تعاملي‌ بيش‌
از حد نحوي‌ است‌. من‌ مي‌پذيرم‌ كه‌ تايپ‌ بيان‌ For چندان‌ آسان‌ نيست‌، به‌
همين‌ دليل‌ پيشنهاد كردم‌ كه‌ ماكرو FOR را تعريف‌ كنيد تا تمام‌ كاري‌ را كه‌
بايد تايپ‌ كنيد برايتان‌ انجام‌ دهد. همچنين‌ استفاده‌ از ماكرو FOR كمتر
مستعد خطا است‌; من‌ بارها به‌ خاطر عوض‌ شدن‌ يك‌ i با يك‌ j در حلقه‌هاي‌ تو
در تو گير افتاده‌ام‌. بطور عادي‌ مردم‌ به‌ سرعت‌ به‌ سراغ‌ تعريف‌ توابع‌ و كلاسها
نمي‌روند (در صورتيكه‌ اينكار را انجام‌ دهند تسهيلاتي‌ براي‌ كپي‌ نمودن‌ و
رونويسي‌ آنها در يك‌ فايل‌ و يا به‌ كليپ‌ بورد وجود دارند)، كارهاي‌ پيچيده‌
در يك‌ فايل‌ تايپ‌ خواهد شد و در صورت‌ نياز بارگذاري‌ مي‌شوند.
يك‌ پرسش‌ جالبتر اين‌ است‌ كه‌ آيا ++C به‌ اندازه‌ كافي‌ گويا هست‌؟ مطمئنا
پاسكال‌ چنين‌ نيست‌ (همانطور كه‌ به‌ اندازه‌ كافي‌ موجز نيست‌). مردم‌ از
زبانهاي‌ ويژه‌ كاربرد استفاده‌ مي‌كنند زيرا تنها چند ضرب‌ كليد با تمامي‌
ابزارهاي‌ حرفه‌ خاص‌ خود فاصله‌ دارند. يكي‌ از كاربردهائي‌ كه‌ اين‌ نكته‌ را
نشان‌ مي‌دهد، الگوسازي‌ الگوريتم‌ پردازش‌ سيگنال‌ است‌.
++C بخاطر قابليت‌ آن‌ در تعريف‌ دقيق‌ معاني‌ زباني‌ به‌ نحو مطلوب‌، براي‌
اينگونه‌ كاربردها كاملا مناسب‌ است‌. توابع‌ مي‌توانند بردارهاي‌ Passed
باشند و ممكن‌ است‌ بردارهائي‌ را برگردانند. محاسبات‌ با اعداد پيچيده‌ از
نمادهاي‌ معمولي‌ استفاده‌ مي‌كند. براي‌ مثال‌ يك‌ سيستم‌ تعاملي‌ ++C
مي‌تواند به‌ پيش‌الگوها امكان‌ دهد تا طيف‌ قدرت‌ اختلافهاي‌ مابين‌ دو بردار
داده‌ با يك‌ خط را نشان‌ دهند، نظير: ;((y+x)fft)abs)plot >;.
اين‌ شيوه‌ مناسبي‌ براي‌ شكستن‌ اعداد نيست‌، اما اين‌ مسئله‌ در اينجا چندان‌
بحراني‌ نيست‌. در واقع‌ از مفسر استفاده‌ شده‌ است‌ تا تركيبات‌ تابعي‌ را به‌
يكديگر بچسباند. خود تركيبات‌ بايستي‌ بصورت‌ كتابخانه‌هاي‌ اشتراكي‌ بكار
گرفته‌ شوند كه‌ با يك‌ كامپايلر بهينه‌ سازي‌، ساخته‌ شده‌اند.
اين‌ نوع‌ كاربردهاي‌ مهندسي‌ ممكن‌ است‌ تخصصي‌ به‌ نظر برسند، اما اكثر انواع‌
پروژه‌ها مي‌توانند از پيش‌ الگوهاي‌ تعاملي‌ سود ببرند. در هسته‌ بزرگترين‌
پروژه‌ها، طراحيهاي‌ ناشناخته‌اي‌ وجود دارند كه‌ بايستي‌ مورد كاوش‌ قرار
گيرند. به‌ نظر مي‌رسد برنامه‌ نويسي‌ اكتشافي‌ با روند دقيق‌ مهندسي‌ نرم‌افزار
تناقض‌ زيادي‌ داشته‌ باشد، اما مي‌تواند به‌ اقسام‌ گوناگوني‌ در طراحي‌ و
اجراي‌ پروژه‌ها مشاركت‌ نمايد. به‌ گفته‌ Sheil .A.B برنامه‌ نويسي‌ اكتشافي‌
به‌ دنبال‌ تقويت‌ برنامه‌ نويسان‌ است‌، در حاليكه‌ شيوه‌هاي‌ ساختار يافته‌
طراحي‌ شده‌اند تا برنامه‌ نويسان‌ را مهار كنند. هر دو اين‌ شيوه‌ها در روند
توسعه‌ نرم‌افزار داراي‌ جايگاه‌ خاص‌ خود هستند. جايگاه‌ ديگري‌ كه‌ حالت‌
تعاملي‌ در توسعه‌ دشوار دارد، آزمايش‌ است‌. من‌ متوجه‌ شدم‌ كه‌ كلاسها
مشكلاتشان‌ را در جين‌ محاوره‌ آشكار مي‌كنند. بدون‌ شك‌ شما نياز داريد
آزمونهاي‌ ثابتي‌ را براي‌ بررسيهاي‌ بعدي‌ ايجاد نمائيد، اما ...
در مورد اين‌ حقيقت‌ كه‌ حجم‌ زيادي‌ از اطلاعات‌ هدر بايستي‌ در بر گرفته‌
شوند، راهي‌ وجود ندارد و اين‌ هدرها بزرگترين‌ قسمت‌ از متن‌ برنامه‌ را كه‌
كامپايلر بايستي‌ با آن‌ سر و كار داشته‌ باشد تشكيل‌ مي‌دهند. يك‌ برنامه‌
كوچك‌ ٣٠ خطي‌ ++C استاندارد كه‌ با رشته‌ها و جريانهاي‌ O/I سر و كار
دارد كامپايلر را درگير نزديك‌ به‌ ٩٠٠٠ خط فايلهاي‌ هدر مي‌كند. توسعه‌
وابستگي‌ مابين‌ بخشهاي‌ برنامه‌هاي‌ بزرگ‌ تا ساختن‌ آنها بطور تغيير ناپذيري‌
يك‌ فرآيند كسالت‌ آور است‌.

Hesam آفلاين است  
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiTweet this Post!
پاسخ با نقل قول
4 کاربر از شما به خاطر پست مفیدتان تشکر کرده اند :
قدیمی 5th February 2009   #4

Hesam

عضو پيشكسوت

 Hesam آواتار ها

تاریخ عضویت: Jan 1970
محل سکونت: PeRsIaN
نوشته ها: 1,156
تشکر از دیگران: 1,131
تشکر شده 3,412 بار در 1,128 پست

حالت
Procrastinating

 

در يك‌ نشست‌ تعاملي‌ ++C، هدرها مي‌توانند از پيش‌ بارگذاري‌ شده‌ و
حجم‌ بيشتري‌ از كامپايل‌ مجدد مي‌تواند بطور سريعتري‌ انجام‌ شود زيرا اين‌
هدرها از قبل‌ در سيستم‌ حاضر هستند. هيچ‌ مرحله‌ لينكي‌ وجود ندارد، تمام‌
شيوه‌هاي‌ UnderC مراجعات‌ غير مستقيمي‌ به‌ Pcode واقعي‌ دارند بنابراين‌
نيازي‌ به‌ عبور از تمام‌ مراجعات‌ تابعي‌ كه‌ آدرسها را متصل‌ مي‌كنند وجود
ندارد. اين‌ ويژگي‌ خصوصا هنگاميكه‌ هدرها براي‌ سيستم‌ وارد شده‌اي‌ هستند
كه‌ به‌ ندرت‌ تغيير مي‌كند، بسيار خوب‌ عمل‌ مي‌كنند. هنگاميكه‌ هدرها به‌ يك‌
نشست‌ تعاملي‌ بارگذاري‌ مي‌شوند، برنامه‌هاي‌ آزمايش‌ VTK در ++C
مي‌توانند در عرض‌ چند ميلي‌ ثانيه‌ مجددا كامپايل‌ شوند. اين‌ مسئله‌ باعث‌ شد
براي‌ سازماندهي‌ محيط اسريپتينگ‌ ++C بطور موثر، راهي‌ به‌ ذهن‌ من‌
برسد: مفسر بعنوان‌ سرور، مقيم‌ مي‌ماند و يك‌ راه‌انداز اسكريپت‌ مشتري‌
كوچك‌ با آن‌ ارتباط برقرار مي‌كند و از آن‌ براي‌ اجراي‌ اسكريپتها استفاده‌
مي‌كند. وضعيت‌ كامپايلر ثابت‌ مي‌ماند و هدر نياز دارند كه‌ تنها در اولين‌ اجرا
به‌ حساب‌ آورده‌ شوند. اين‌ مي‌تواند يك‌ اجراي‌ فوق‌العادي‌ براي‌ يك‌ كاربرد
اسكريپتينگ‌ CGI باشد. خود اسكريپتها مي‌توانند برنامه‌هاي‌ اصلي‌ كوچكي‌
باشند كه‌ مابقي‌ سيستم‌ فراخواني‌ مي‌كنند و وضعيت‌ بايستي‌ بطور خودكار
مابين‌ ارتباطات‌ مجزا حفظ شود.
با اين‌ شيوه‌، مشكل‌ وابستگي‌ نيز بيشتر قابل‌ كنترل‌ است‌. براي‌ مثال‌ يك‌ تغيير
عمومي‌ بر روي‌ كلاس‌، يك‌ شيوه‌ ديگر است‌. با وجود آنكه‌ ممكن‌ است‌ آن‌
تعريف‌ كلاس‌ در سرتاسر سيستم‌ مورد نياز باشد (احتمالا صدها هزار خط و يا
بيشتر)، ما تنها با كامپايل‌ مجدد خود كلاس‌ نياز داريم‌ زيرا طرح‌ كلي‌ كلاس‌
تغيير نكرده‌ است‌. در واقع‌ شما تنها نياز داريد خود شيوه‌ را كامپايل‌ نمائيد.
پس‌ اين‌ امكان‌ وجود دارد كه‌ محيطي‌ را ايجاد كنيد كه‌ سيستمهاي‌ بزرگ‌
++C، اغلب‌ در عرض‌ چند ميلي‌ ثانيه‌ (بجاي‌ دقيقه‌ها و ساعتها) در آن‌ قابل‌
ويرايش‌ باشند. يك‌ انتقاد در اين‌ مورد اين‌ است‌ كه‌ شما را تشويق‌ به‌
Hacking مي‌كند، اما در عين‌ حال‌ اين‌ شيوه‌ شما را به‌ آزمايش‌ كل‌ سيستم‌
نيزتشويق‌ مي‌كند. برنامه‌نويسي‌ اكتشافي‌ مشوق‌ يك‌ انتقال‌ از فكر كردن‌ به‌ قابل‌
اجراهاي‌ يكپارچه‌ است‌. در اينجا "برنامه‌اي‌" كه‌ "راه‌اندازي‌" شده‌ باشد وجود
ندارد. در عوض‌ شما در داخل‌ سيستم‌ قرار داريد. من‌ متوجه‌ شده‌ام‌ كه‌ در
هنگام‌ اشكال‌زدائي‌ كاربردهاي‌ GUI در محيطهاي‌ سنتي‌ زمان‌ بسيار زيادي‌
به‌ هدر مي‌رود كه‌ جاي‌ آزمايش‌ شما را مي‌گيرد. اما در داخل‌ سيستمهاي‌
تعاملي‌، كد مي‌تواند در هنگاميكه‌ سيستم‌ در حال‌ اجرا است‌ اصلاح‌ شود.
چيزيكه‌ در مورد اين‌ امكانات‌ متوجه‌ شدم‌ اين‌ است‌ كه‌ يك‌ زبان‌ شي‌گراي‌
سنتي‌ مانند ++C هنوز مي‌تواند در يك‌ سبك‌ اكتشافي‌ مورد استفاده‌ قرار
گيرد و ما مي‌توانيم‌ از مشكلاتي‌ كه‌ واقعا در اجراهاي‌ سنتي‌ پيش‌ مي‌آيند
عبور كنيم‌.

Hesam آفلاين است  
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiTweet this Post!
پاسخ با نقل قول
4 کاربر از شما به خاطر پست مفیدتان تشکر کرده اند :
پاسخ


کاربران در حال دیدن موضوع: 1 نفر (0 عضو و 1 مهمان)
 
ابزارهای موضوع جستجو در موضوع
جستجو در موضوع:

جستجوی پیشرفته

مجوز های ارسال و ویرایش
شما نمیتوانید موضوع جدیدی ارسال کنید
شما امکان ارسال پاسخ را ندارید
شما نمیتوانید فایل پیوست در پست خود ضمیمه کنید
شما نمیتوانید پست های خود را ویرایش کنید

BB code is فعال
شکلک ها فعال است
کد [IMG] فعال است
کد HTML غیر فعال است
Trackbacks are فعال
Pingbacks are فعال
Refbacks are فعال



ست مروارید عشق

بهترین هدیه برای دختران و خانم ها :
زیبا ترین و جذاب ترین هدیه سال برای دختر خانم ها و بانوان محترم

تولد – سالگرد ازدواج –هدیه آشنایی - روز عشق و ....

خودتان مروارید داخل صدف زنده كه در كنسرو شیشه ای بسته بندی شده است را در بیاورید و در قسمت مخصوصش در گردنبند قرار دهید

» برای مشاهده توضیحات و تصاویر بیشتر اینجا را کلیک کنید ...
 

روش خرید: برای خرید پس از کلیک روی دکمه زیر و تکمیل فرم سفارش، ابتدا محصول مورد نظر را درب منزل یا محل کار تحویل بگیرید، سپس وجه کالا و هزینه ارسال را به مامور پست بپردازید. جهت مشاهده فرم خرید، روی دکمه زیر کلیک کنید.

قیمت: 8900 تومان

 


Powered by vBulletin Version 3.8.6 & Our Members
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.5.2
Host & Support By Kimiahost Co
© Copyright 2005-2010 Gtalk.ir
سایت سرگرمی و تفریحی * ثبت هاستینگ و دامنه * سایت سرگرمی و عکس های جالب * فروشگاه تکچین ، فروشگاه اینترنتی تکچین هدایای جالب و لوکس * ست مروارید عشق * سایت یک در یک ، فال و طالع بینی ، عکس ، مقالات آموزشی، پیامک های جالب *آموزش لاغری در 10 دقیقه *شارژ موبایل با باطری قلمی *بهترین هدیه روز مادر و روز زن *راه های افزایش قد + حرکات جادویی *ساعت LED آدیداس adidas *ساعت بدون عقربه Gucci *دستگاه کپی SMS و شماره تلفن *ست چاقوی میراکل بلید *دماسنج عشق *سایت هدفمند سازی یارانه ها *برچسب ضد اشعه امواج مضر موبایل * ساعت و گردنبند جادویی آرامبخش *مجله اینترنتی پی سی پارسی *بزرگترین شهر دانلود *فال و طالع بینی -تاروت *دانلود *پک سفیدکننده دندان اصل Whitelight *پاتوق تفريحي ايرانيان *سرگرمی و تفریحی شهرشب * کرم موبر باله آ اصل - Balea Cream *توپترينها *موبفا-مرجع تخصصی موبایل *قره جه طیار ، انتخابات گنبد *عکسهای بازیگران * درج آگهي و تبليغات *مجله تاپ مگ *هاست ایرانی ، میزبانی ملی *خرید زیور آلات ، بدلیجات ، مروارید *پنل ارسال sms *عکس *پاتوق اینترنتی *عکس *مجله تفریحی خبری فان فارس *تبادل لینک با ما - رنک 3 به بالا