رندرگر های نرم افزاری(Graphics API = Software)

[1485159]

سلام
من میخوام اطلاعاتی در این مورد داشته باشم میشه راهنمایی کنید؟
برای رسم از چه چیزی استفاده میکنن؟ توابع ویندوز؟ کدوم توابع؟
به چه دردی میخورن؟ وقتی oepngl و دایرکت هست چرا باید خودمون بنویسیم؟
برای ساخت یه بازی 2 بعدی به درد میخورن؟

[SeganX]

موتورهای کمی هستن که از رندرگر های نرم افزاری در مواقع نیاز استفاده می کنن. معمولا هم نه برای بازی بلکه برای بعضی کارهای علمی و شبیه سازی و اینا ... چون بار محاسباتی رندگرهای نرم افزاری تماما روی CPU هستش و از GPU استفاده نمی کنن.

در بازی ها معمولا برای رسم نهایی از رندرگر نرم افزاری استفاده نمیشه مگر برای استفاده در بعضی سیستم های خاص مثل مشخص کردن اشیا پنهانی که نباید رسم شوند ( Occlusion Culling ) که بجای استفاده از query های سخت افزاری یک سیستم رسم نرم افزاری می نویسن و جایگزین می کنن. مثلا موتور cryengine از یک همچین سیستمی استفاده میکنه.

برای نوشتن رندرگرهای نرم افزاری از توابع ویندوز استفاده نمی کنن. چون در الگوریتم هایی که واسه رندر استفاده میشه توابع ویندوز به کار نمیاد. در کل توابع رسم ویندوز توابع سطح بالایی هستن و سرعت بالایی ندارن.

اینکه برای بازی های دو بعدی به درد بخورن یا نه بستگی به قدرت رندرگر و انتخاب خودت داره.
اینجا می تونی یه نمونه ساده از یک سیستم رسم نرم افزاری رو پیدا کنی.
http://seganx.com/?p=298

[1485159]

سلام
یه زمانی من یه وبلاگ فارسی دیده بودم که عکس زیر مربوط به اون وبلاگ هست:
http://seganx.com/wp-content/uploads/2010/05/Software_Rasterizer_3-150x120.jpg
آدرس وبلاگ رو میدونید؟

[SeganX]

سلام
اون وبلاگ خودم بود.
http://www.seganx.com/engine/
این ادرسشه. اما دیگه آپدیتش نمی کنم. تصمیم گرفتم که توسعه موتور رو با دلفی رها کنم و همه چیزو از اول ولی آروم آروم با سی شروع کنم.

[1485159]

سلام
اون وبلاگ خودم بود.
http://www.seganx.com/engine/
این ادرسشه. اما دیگه آپدیتش نمی کنم. تصمیم گرفتم که توسعه موتور رو با دلفی رها کنم و همه چیزو از اول ولی آروم آروم با سی شروع کنم.
چرا دلفی رو رها کردین؟ من قبلا با سی مینوشتم ولی الان با دلفی. زبان جالبیه دلفی.

[SeganX]

آره. زبان دلفی همون پاسکال هستش که گسترشش دادن. من خودم تا همین چند وقت پیش روی دلفی تعصباتی هم داشتم و موتوری که داشتم می نوشتم خیلی قسمت هاش تموم شده بود.

اما واقعیت امر اینه که دلفی برای برنامه نویسی نیتیو مناسب نیست و خیلی از سیستم ها رو خودش مدیریت و اپتیمایز میکنه. درکل دست برنامه نویس تا حدودی بستس. دلفی بعضی از امکانات و انعطافات سی رو نداره. از اونجا که خیلی از سیستم ها مثل مدیریت حافظه، مدیریت سرنخها و ... رو خود دلفی به عهده داره سطح پرفورمنسش هم مشخص و محدود هستش. منظورم اینه که تعیین و افزایش پرفرمنس کاری برنامت زیاد دست خودت نیست و سرعت اجرای برنامت نمی تونه بیشتر از یه حد خاصی بشه. اما توی سی دست برنامه نویس کاملا بازه و بسته به توانایی های برنامه نویس، پرفورمنس نهایی می تونه بالا و بالاتر بره.

به علاوه کتابخونه هایی که برای بازی سازی و بازی نویسی توسط شرکت های بزرگ منتشر می شن همه با سی هستند. اگر بخوای با دلفی کار کنی خیلی چیزارو مجبوری خودت از سی به دلفی دوباره نویسی کنی و خیلی دردسر داره.

بهت پیشنهاد میدم پیش از آنکه خیلی دیر بشه برگردی به سراغ سی :لبخندساده:

[1485159]

من که تاحاله نشده که کاری رو با سی بکنم ولی با دلفی نشه!
اما در مورد اینکه کتابخونه برای سی بشتره قبول دارم.
--------
اگه ممکنه چنتا از وبلاگ های ایرانی در مورد انجین نویسی که برتون جالب هستن رو معرفی کنید.

[sajjadgameactor]

آره. زبان دلفی همون پاسکال هستش که گسترشش دادن. من خودم تا همین چند وقت پیش روی دلفی تعصباتی هم داشتم و موتوری که داشتم می نوشتم خیلی قسمت هاش تموم شده بود.

اما واقعیت امر اینه که دلفی برای برنامه نویسی نیتیو مناسب نیست و خیلی از سیستم ها رو خودش مدیریت و اپتیمایز میکنه. درکل دست برنامه نویس تا حدودی بستس. دلفی بعضی از امکانات و انعطافات سی رو نداره. از اونجا که خیلی از سیستم ها مثل مدیریت حافظه، مدیریت سرنخها و ... رو خود دلفی به عهده داره سطح پرفورمنسش هم مشخص و محدود هستش. منظورم اینه که تعیین و افزایش پرفرمنس کاری برنامت زیاد دست خودت نیست و سرعت اجرای برنامت نمی تونه بیشتر از یه حد خاصی بشه. اما توی سی دست برنامه نویس کاملا بازه و بسته به توانایی های برنامه نویس، پرفورمنس نهایی می تونه بالا و بالاتر بره.

به علاوه کتابخونه هایی که برای بازی سازی و بازی نویسی توسط شرکت های بزرگ منتشر می شن همه با سی هستند. اگر بخوای با دلفی کار کنی خیلی چیزارو مجبوری خودت از سی به دلفی دوباره نویسی کنی و خیلی دردسر داره.

بهت پیشنهاد میدم پیش از آنکه خیلی دیر بشه برگردی به سراغ سی :لبخندساده:


منظورت c هست یا c++???

[SeganX]

چون فارسی تایپ می کردم پلاس پلاسش جا افتاده :چشمک:

[1485159]

منظورت c هست یا C++‎???
فکر نکنم برای بازی سازی سی و سی++ فرقی داشته باشن

[SeganX]

بستگی به انتخاب خودت داره. یه کم در موردش مطلب بخونی به راحتی می تونی انتخاب کنی.
پیشنهاد خیلی ها سی پلاس پلاس هست.

[1485159]

پیشنهاد خیلی ها سی پلاس پلاس هست.
پیشنهاد من هم سی ++ هست ولی فعلا با دلفی حال میکنم..:لبخند: و قصد من هم از انجین نویسی حال کردنه:لبخند:

[1485159]

میشه بگین برای رسم از چه توایع باید استفاده کنم؟

[مصطفی ساتکی]

اما واقعیت امر اینه که دلفی برای برنامه نویسی نیتیو مناسب نیست و خیلی از سیستم ها رو خودش مدیریت و اپتیمایز میکنه. درکل دست برنامه نویس تا حدودی بستس. دلفی بعضی از امکانات و انعطافات سی رو نداره. از اونجا که خیلی از سیستم ها مثل مدیریت حافظه، مدیریت سرنخها و ... رو خود دلفی به عهده داره سطح پرفورمنسش هم مشخص و محدود هستش. منظورم اینه که تعیین و افزایش پرفرمنس کاری برنامت زیاد دست خودت نیست و سرعت اجرای برنامت نمی تونه بیشتر از یه حد خاصی بشه. اما توی سی دست برنامه نویس کاملا بازه و بسته به توانایی های برنامه نویس، پرفورمنس نهایی می تونه بالا و بالاتر بره.
این نظر شخصی شماست. شما اگر ضعف برنامه نویسی دارید به گردن دلفی نیدازید .مدیریت حافظه و Thread چه ربطی داره به سرعت بالا. اگر بحث فنی باشه همچین چیزی گفته نمیشه اونم از طرف یه دلفی کار .خود کلاس thread اومده api رو encapsulate کرده که شما ناراحت سرعتی دوست داری از اون کلاس استفاده نکن pure api کار کن .اگر مثالی دارید مشابه تو c++ که پیاده سازی اون تو دلفی زمانگیر تر رو در تالار دلفی مطرح کنید تا کد معادل دلفی رو با همون سرعت و یا راه داشته باشه با سرعت با لاتر تحویل بگیرید .البته هم چیز به برنامه نویسش بستگی داره.

[hi.alir]

فکر نکنم برای بازی سازی سی و سی++ فرقی داشته باشن
یه دفعه بیا کلن Object Oriented رو ببر زیر سوال دیگه

اگر میخوای بازی ساز بشی، بهترین پیشنهاد C++‎/C هست. تمامی کتابخانه های گرافیکی نظیر Direct3D و OpenGL و یا کتابخانه صوتی چون DirectSound و OpenAL و سایر کتابخانه های مرتبط با این موضوع، در اولویت اول برای این زبان در نظر گرفته میشند و بیشترین سازگاری را با این زبان دارند، چرا این کتابخانه ها هم با همین زبان نوشته میشه.
از سوی دیگه تمامی موتور های تجاری نظیر Unreal و Cryengine نیز با این زبان کار می کنند.

[1485159]

یه دفعه بیا کلن Object Oriented رو ببر زیر سوال دیگه
منظورم از لحاظ سرعت بود!

[1485159]

رندرگر های نرم افزاری برای رسم از چی استفاده میکنن؟

[pswin.pooya]

اگر از ++C به صورت C استفاده کنید ، از لحاظ سرعت فرقی ندارن.
ولی وقتی از امکانات خود ++C مانند Object Oriented استفاده کنید ، باعث افت سرعت در بعضی موارد میشه.
البته این افتی که میگم درحد خیلی کم است.
شما حتی میتونید Object Oriented رو با C شبیه سازی کنید. ولی کار دشواری میشه.
ولی در کل ++C برای این کار بهتره.

کی گفته که شی گرایی باعث کاهش سرعت میشه. تقریبا از لحاظ سرعت هیچ فرقی نمی کنه. پیشنهاد میکنم که یه کتاب برای زبانهای برنامه نویسی بخونی. تنها تفاوت این هستش که یه پارامتر اضافه که توی C++ به اسم this میشناسن به توابع ارسال میشه و متدها توی کامپایل به توابع C تبدیل میشن. شما اگر از C خالی هم استفاده کنی مجبوری که اشاره گرها رو به توابع ارسال کنی (مثلا برای یک آرایه).

[hi.alir]

Software Rendering in Wikipedia (http://en.wikipedia.org/wiki/Software_rendering)


رندرگر های نرم افزاری برای رسم از چی استفاده میکنن؟
CPU دیگه.

[1485159]

CPU دیگه.
عجب جوابی دادی! اینو که خودم میدونم! تز چه توابعی استفاده میکنن؟

[hi.alir]

وقتی که داری device رو تو Direct3D میسازی اونجا مشخص می کنی که از چی استفاده کنه.


HRESULT IDirect3D9::CreateDevice(
UINT Adapter,
D3DDEVTYPE DeviceType,
HWND hFocusWindow,
DWORD BehaviorFlags,
D3DPRESENT_PARAMETERS *pPresentationParameters,
IDirect3DDevice9** ppReturnedDevicelnterface);


پارامتر D3DDEVTYPE DeviceType مربوط به همین کار هست.
واسه Software device از D3DDEVTYPE_SW معادل عدد 3 در این نوع استفاده میشه.

[1485159]

وقتی که داری device رو تو Direct3D میسازی اونجا مشخص می کنی که از چی استفاده کنه.
بازم که برگشتیم سرخونه اول!

[hi.alir]

کدوم خونه اول اخه عزیز من، می خوای رندر نرم افزار بکنی این راهشه.

[pswin.pooya]

پارامتر D3DDEVTYPE DeviceType مربوط به همین کار هست.
واسه Software device از D3DDEVTYPE_SW معادل عدد 3 در این نوع استفاده میشهمنظور دوستمون این نیستش. این امکان دایرکت که توی حالتهایی هست که سخت افزار ساپورت نمی ده و با استفاده از یه دستگاه نرم افزاری که اگر اشتباه نکنم REF گفته میشه رندر میکنه که تنها توسعه دهنده میتونه ازش استفاده کنه (چون فقط روی SDK دایرکت هستش).

بعضی ها بنا به دلایل زیادی که دارن از شتاب دهندههای سخت افزاری (مثل کارت گرافیک و GPU) برای رندرینگ استفاده نمی کنن مثل حالتهای خاصی از رندررهای نرم افزار مکس و مایا و به جای اون رندرینگ رو روی CPU انجام میدن. در کنار این هم بعضی از گیم انجینها مخصوصا اونهایی که برای پلتفرهایی طراحی میشن که شتابدهنده سخت افزاری ندارن مجبورن که خودشون رندرر رو بنویسن. اگر از شیدرها استفاده کرده باشین با اضافه کردن مراحلی دیگه ای به اونها که ff داره مثل رستری کردن و یا کوتاه سازی و همینطور یکسری از عملیات per fragment مثل blending میتونین یک همچین رندرری رو طراحی کنین اما با توجه به نیازهای بازار و سیستمهای رندرینگی مثل OpenGL ES که embded system هستن روز به روز نیاز به همچین رندررهایی کمتر میشه الان OpenGL ES رو میشه روی ARM و بعضی از AVRها نصبش کرد(در مورد AVR مظمئن نیستم وتنها یکی از دوستانم اسم یکی دو مدل رو برد که میشد روش اینکار رو کرد) و نمونه بارز اون گوشهای نوکیا و اپل هستن.

به طور خلاصه پیشنهاد میکنم که سراغ اینجور رندرینگ نرین مگر اینکه واقعا بهش نیاز داشته باشید.

در جواب این دوستمون که اونها از چی استفاده میکنن:
توی این نوع رندررها یه آرایه از پیکسلها درست میشه و رنگ هر کدوم مشخص میشه. بعد از این مهم نیستش که از چه چیزی برای نمایش استفاده کنن چون اصل کار توی هموت پردازشهای گرافیکی هستش.
1. برخیشون از API سیستم عامل (تنها برای رسم پیکسلها)
2. درایورهای سخت افزاری (اگر کار طرف درست باشه)
3. نرم افزارهایی مثل مایا یا مکس از یک کنترل image استفاده میکنن.
4. حتما لازم نیست روی مانیتور نشون بدن میتونن داخل فایل هم ذخیره کنن.

[1485159]

برخیشون از API سیستم عامل (تنها برای رسم پیکسلها)
مشکل منم اینه دیگه! از کدوم تابع؟

[hi.alir]

مشکل منم اینه دیگه! از کدوم تابع؟
+GDI (http://msdn.microsoft.com/en-us/library/ms533798(VS.85).aspx) توابعی هست که ویندوز برای انجام چنین کارهایی در نظر گرفته.
اگر باز هم پاسخ بی ربط دادم شرمنده.

[pswin.pooya]

(http://msdn.microsoft.com/en-us/library/ms533798%28VS.85%29.aspx)+GDI (http://msdn.microsoft.com/en-us/library/ms533798%28VS.85%29.aspx) توابعی هست که ویندوز برای انجام چنین کارهایی در نظر گرفته.
اگر باز هم پاسخ بی ربط دادم شرمنده.
اگر اشتباه نکنم GDI+ برای دات نت هستش. به راحتی بتونی با دستورات GDI اینکار رو انجام بدی. حتی میتونی از خود دستورات GL هم استفاده کنی. یه سرچ در مورد رسم بیت مپ با GDI بزن.

[hi.alir]

اگر اشتباه نکنم GDI+ برای دات نت هستش
اگر اون لینک MSDN که داده بودم رو نگاه کرده بودید، الان این حرف رو نمی زدید.

[pswin.pooya]

اگر اون لینک MSDN که داده بودم رو نگاه کرده بودید، الان این حرف رو نمی زدید.

شرمنده ظاهرا اشتباه کردم. همون طورهم که گفتم مطمئن نبودم انگار یه جا شنیده بودم و یا داخل یه مطلب اینو خونده بودم.

[pswin.pooya]

عزیز من این مشکل برنامه نویسی شما هستش. اگر به سازنده احتیاج نداری چرا داخلش کد میزنی؟! . قبل از کد زنی باید دقیقا دقت کنی که به چه چیزی نیاز داری.

فرض کن من یه کلاس رنگ داشته باشم به شکل زیر:


class Color
{
public:
Color()
{
memset( v,,0,4 *sizeof(float));
};

Color (float r,float g,float b,float a)
: red(r), green(g), blue(b), alpha(a)
{
};

float* getRGBA(){return v;};

void set(float r,float g,float b,float a)
....


اگه از دید شما بخوام نگاه کنم من یه overhead اضافی دارم. اما این overhead من این اطمینان رو میده که همیشه من رنگ سیاه رو به صورت پیش فرض داشته باشم. که توی مثال شما هم برای رشته 1234 همین اطمینان رو میده. اما به قول شما من ساختار یافته رفتار میکنم که سرعت بیشتر داشته باشم:


struct ColorS
{
float red;
float green;
float blue;
float alpha;
};

void main()
{
ColorS *c = new ColorS[1000];
...
Color *c2 = new Color[1000];
...
}

سرعت ساخت c مسلما بیشتر از سرعت ساخت c2 هستش اما من مطمئن هستم که توی c2 تمامی رنگها سیاه هستن اما نمی تونم همچین تظمینی برای c بدم و امکان داره هر ترکیب رنگی داخلش باشه. اگر برای من رنگ اولیه اهمیتی نداشته باشه و مطمئن باشم که همیشه set فراخوانی میشه (قبل از استفاده از getRGBA ) میتونم خیلی راحت کد سازنده پیش فرض رو حذف کنم. در غیر این صورت برای امنیت بالاتر بهتره که سازنده رو بذارم بمونه.

کدوم یکی رو ترجیح میدی؟ c یا c2

در مورد کلاس شما هیچ نظری ندارم فقط میتونم بگم که کلاس رو با توجه به نیازهای دقیقت طراحی کن. اگر نیازی به سازنده نداری بیخیال اون شو. اگر گاهی اوقات نیازی بهش نداری و این گاهی زیاد تکرار میشه و هزینه سازنده زیاد هستش دو تا کلاس مجزا بساز. کلا کلاس یک تعریف انتزاعی هستش که شما از یه نمونه شی میکنی. نمی تونی به خاطر استثناءها تعریف رو بهم بریزی مگر اینکه اونها زیاد باشن.

هیچ وقت اشتباه های برنامه نویسی رو نمیشه به یه زبان و یا API ربطش داد. این مثل الگوریتم نیستش که بدترین حالت رو بهش ربط داد. موقع برنامه نویسی خیلی باید دقت کرد چون یه دیزاین اشتباه و یا یک اشتباه کوچولو میتونه باعث افت شدید کارایی و یا خسارتهای غیر قابل جبران دیگه ای بشه. اگر دیزاینت درست و مطابق خواسته مساله باشه موردی پیش نمیاد ولی اگر دیزاین اشتباه داشته باشی برنامتت به طور کل تعطیل میشه.

داخل دانشگاه یه درسی ارائه میدن (3 واحد هستش) به اسم زبانهای برنامه نویسی( یا طراحی زبانهای برنامه نویسی). توی این درس در مورد همین مسائل صحبت میشه و معیارهای سنجش زبانها رو مطرح میکنن. این درس دید خیلی ها رو در مورد مقایسه های زبانهای برنامه نویسی عوض میکنه و به اونها یاد میده که معیارهای درستی رو برای مقایسه، ساخت و یا طراحی زبانهای برنامه نویسی مطرح کننن

[pswin.pooya]

ولی وقتی بخواد از یک Libraryی که کسه دیگه ای اون رو ایجاد کرده استفاده کنه چی ؟ خوب این برای c هم صادق هستش. کلا افرادی که میخوان از کتابخونه های آماده استفاده کنن مجبورا همه چی اونها (کاهش کارایی یا موارد دیگه) رو هم بجون بخرن. و به خاطر همین مسائل هستش که گیم انجینهای حرفه ای سعی میکنن کتابخونه ها شون (حداقل اونهایی که باهاشون زیاد سروکار دارن) رو خودشون بنویسن. شما سپول رو نگاه کن با اینکه std::map هستش و میشه گفت از نظر safe بودن و یا مسائل دیگه 100 مورد اطمینان هستش نشست و کلاس hrmmap خودش رو نوشت تا سرعت بیشتری رو داشته باشه. یا مثلا توی گیم انجین خودم با اینکه std::string هستش من با کلی مصیبت کلاس رشته خودم رو نوشتم تا بتونم از انواع قالبها به صورت یه کلاس استفاده کنم (utf8، ut16 و یا ANSI) و یا حتی با اینکه کتابخونه ای مثل FTGL هستش من برای پرفرمانس بالاتر سیستم فونت خودم رو مستقیما با کتابخونه FreeType نوشتم.

[pswin.pooya]

منظور من همین بود که الان فکر میکنم فهمیدی.
کلا در بعضی موارد که ما به Constructor ها یا Destructor ها احتیاجی نداریم ، به صورت اجبار Invoke میشن.
لبته راه حلی هم که به ذهنم میرسه این که با تابع malloc میشه این صعف رو درست کرد.
ولی اگر کلاس مورد نظر Method های Virtual داشته باشه اون وقت اوضاع خراب میشه. بازم که برگشتی سر نقطه اول. شما میگی C++‎ میتونه از C کندتر باشه. خب این مساله چه ربطی به کتابخونه های جانبی داره؟ من میگم اگر دیزاین کاملا درست باشه مشکلی پیش نمیاد. و اگر به کتابخونه ها نگاه کنیم همین overhead هم میتونه توی کتابیخونه های C هم وجود داشته باشه. و اشاره کردم که نیاز مساله باید تامین بشه. سپول بیشتر سازگاری و safe بودن و ... نیاز به سرعت داشت پس سعی کرد خودش نیازش رو بر طرف کنه. من بیشتر از سرعت و safe بودن و... نیاز به یکپارچه بودن یک رابط کلی داشتم پس نتیجه این شد که به جای این همه کلاس string موجود مال خودم رو نوشتم.

این مساله ربطی به زبان نداره. دقیقا به برنامه نویسی مرتبط هستش. ما نمی تونیم بگیم که C++ کندتر هستش چون سازنده رو فراخوانی میکنه. خوب چون نیاز به اون هست فراخوانی میشه و اگر نیاز نباشه از فراخوانی اون جلوگیری میشه.

روزهای اول C++ یک سوپرست (super set( بودش که روی c مینشست و با یه ابزار به کد سی تبدیل می شد و بعد از اون با کامپایلر C کامپایل میشدش. همین نشون میده که تمام کلاسهای داخل C++ در مرحله کامپایل به توابع تبدیل میشن. مثلا برای متد set کلاس Color من اسمی به صورت زیر در نظر گرفته میشه :

Color::Set یا Color_set و یا هر چیز دیگه و یه پارامتر به اولش اضافه میشه که اشاره گر ساختمان داده (همون اطلاعات داخل color رو ) بهش داده میشه تا تابع ساخته شده بتونه کارش رو شی انجام بده. خب شما اگر بخوایین یه همچین متدی رو بسازین مجبورین همین کار رو بکنین و یک پارامتر اضافی برای ساختمان داده تون داخل C کنار بذارین که اشاره گر اون رو براش ارسال کنید.

[SeganX]

سلام
حرف در مورد OOP زیاده. اینکه OOP یه مقدار خیلی کمی ( در تست های بالای 100 میلیون ) باعث کاهش سرعت میشه که شکی نیست. (دلیلش پیدا کردن درست this در هنگام صدا کردن متد ها و ست کردش هست اونهم در متد های virtual) اما دلیلی که شما ارایه میدین و می گین سازنده و مخرب در بعضی موارد ناخواسته صدا زده می شه خیلی دلیل مرتبطی نیست. شما به راحتی می تونی از این کار جلو گیری کنی. اگر هم با کتابخونه های دیگه این مشکل رو داری بازم مقصرش سی پلاس پلاس نیست. می تونی کتابخونه ای بنویسی یا کتابخونه ای پیدا کنی که متد های مختلفی را برای ساخت کلاس ها استفاده کرده باشه که Invoke نداشته باشه.

در برنامه نویسی باید دقت کرد که چه چیزی می دیم و چه چیزی دریافت می کنیم. استفاده از OOP چنان مزیت های مفید و بیشماری آرایه میده که اصلا نیازی به فکر کردن در مورد افت سرعتش نیست.

[SeganX]

کلا درد من اینه که کاش میشد در مواقع لازم طوری یک Instance از کلاس رو ایجاد کرد که Constructor های اون صدا نشن و Instanceی که بوجود میان Virtual Function های Valid داشته باشن.و بشه در موقع آزاد کردن همون Instance با delete همین توانایی رو داشت.


به جای new/delete از malloc/free استفاده کن تا constructor صدا زده نشن.

[SeganX]

بعد از استفاده از alloc/free برای گرفتن حافظه به اندازه کلاسی که درست کردی، 2 تا راه داری تا از توابع virtual استفاده کنی.
فرض کن کلاس T2 را با alloc درست کردی و t2 آدرسشه و حالا می خوای تابع F رو که virtual هستش صدا بزنی:


t2->T2::F();
یا اینکه برای یک بار constructor رو دستی صدا کنی تا جدول توابع virtual ست بشه


t2->T2::T2();
t2->F();