מציאת גודל מערך מסוג שלם(int) בC++

[barakr]

בתגובה ל Moonblade :

תודה על התגובה המפורטת.

כמה דברים:

לגבי ריצה על מערכות שונות - אם אתה יצרן תוכנה שהיעילות מאוד חשובה לו, אתה תספק התקנה לפלטפורמות שונות. בסך הכל יש מעט פלטפורמות ובוודאי שהיום אין בעיה לספק DVD התקנה שמן.

לגבי דליפות זיכרון - אני יודע שקוד שצריך לרוץ בעומס יקרוס מאוד מהר אם יש דליפות זיכרון. כאשר אתה קורא לפונקציה מאות אלפי פעמים זה מצטבר. בוודאי שכאשר זיכרון לא מנוהל נכון גם יכולה להיות טעות של פניה לזכרון שלא קיים כבר.

רק כאשר מדובר במקרה מאוד איזוטרי דליפת זכרון יכולה לשרוד בדיקות איכות והפצה למאות אלפי לקוחות.

לגבי ניהול הזיכרון של השפה - כולם פה חוזרים על העניין שמי שמנהל את הזיכרון זו מערכת ההפעלה. מה שאני אמרתי זה שמבחינת השפה שבה עובדים באותו רגע, אם יש תקן מסודר כמו שיש לשפות המרכזיות שקיימות הרבה שנים, אז ישנן פונקציות של הקצאת זיכרון שכלולות בשפה וצורת עבודתן מוגדרת היטב. מה שאמרתי הוא שאיך פונקציות אלה ממומשות זה דבר שיכול להשתנות. אבל גם בצורה מועטה בין מערכת למערכת.

לגבי השימוש בזכרון - בשפה PHP - השפה עצמה מנהלת את הזכרון ואין לי שום שליטה על זה כמתכנת. השפה עצמה מבקשת הקצאות זיכרון מהמערכת, ובדר"כ גם לא מחזירה כשמדובר בתהליך ארוך. לעומת זאת כשעובדים ב C - ברור שעדיף להחזיק זכרון בהתאם לצרכים החזויים מאשר לבקש הקצאת זיכרון בכל פעם משום שבטווח של שברי מילי-שניות בקשה להקצאת זיכרון עדיין לוקחת יותר זמן.

מתכנת שיודע מה ההקשר והמטרות של התוכנית שהוא כותב יודע כיצד לחזות את הצרכים של המשאבים של התוכנית שלו יותר טוב מכל אלגוריתם חכם שהוא. אפשר כמובן לכתוב אלגוריתם לומד לניהול זיכרון של תוכניות שונות, אבל אז עלול להיווצר משהו שלא יהיה יעיל וזריז.

הערה קטנה לגבי מה שאמרת על כל הנושא של lookup table וכדומה. גם אני עשיתי את הקורסים האלה. העניין הוא שבתור מתכנת זה לא מעניין אותי כי אין לי השפעה על זה. אלא אם כן אני עובד ברמה הזו. (ואני ספציפית לא - וגם לא בעתיד כנראה). כל מה שאני יכול לעשות זה לכתוב קוד שאולי יכול להתחשב בזה, או לראות איך צורות שונות של כתיבה משפיעות על ביצועים בהקשר נתון.

וזהו - אני מקווה שדיברתי לעניין ועניתי על הכל.

[שניצל]

לגבי דליפות זיכרון - אני יודע שקוד שצריך לרוץ בעומס יקרוס מאוד מהר אם יש דליפות זיכרון. כאשר אתה קורא לפונקציה מאות אלפי פעמים זה מצטבר. בוודאי שכאשר זיכרון לא מנוהל נכון גם יכולה להיות טעות של פניה לזכרון שלא קיים כבר.

רק כאשר מדובר במקרה מאוד איזוטרי דליפת זכרון יכולה לשרוד בדיקות איכות והפצה למאות אלפי לקוחות.

אוווו תתפלא. ייתכן בהחלט שדליפת זכרון מתגלה רק בשימושים מסויימים בתוכנה (שימושים שהמפתחים בכלל לא העלו על דעתם), או שנובעים רק במצבי עומס מסויימים. חוץ מזה, עצם זה שאתה צריך לנהל זכרון בעצמך זו תקורה שפוגעת בזמן הפיתוח שלך.

מתכנת שיודע מה ההקשר והמטרות של התוכנית שהוא כותב יודע כיצד לחזות את הצרכים של המשאבים של התוכנית שלו יותר טוב מכל אלגוריתם חכם שהוא. אפשר כמובן לכתוב אלגוריתם לומד לניהול זיכרון של תוכניות שונות, אבל אז עלול להיווצר משהו שלא יהיה יעיל וזריז.

כן, אם מתכנתים היו מושלמים. באופן מעשי, המערכת (או ליתר דיוק, מי שבנה אותה) יודעת ברוב המקרים איך בדיוק לנהל את המשאבים באופן יעיל הרבה יותר מהמתכנתים שמשתמשים בה.

[Hellgrace]

בסך הכל יש מעט פלטפורמות

אתה מוזמן לבוא לעולם הembedded ולגלות עד כמה המשפט הזה לא נכון

, אז ישנן פונקציות של הקצאת זיכרון שכלולות בשפה וצורת עבודתן מוגדרת היטב

הפונקציות האלה עושות מעט מאוד מעבר לעטיפה של הקריאה לAPI. למשל אם תסתכל במימוש של malloc בכל הC runtimes לוינדוס - תראה שאין לך הרבה מעבר לטיפה assertים (בגרסאת הדיבאג כמובן) וקריאה ל HeapAlloc().

הן יכולות להשתנות מקצה לקצה בין מערכת למערכת - אפילו ראיתי מימושים לmalloc בכמה runtimes לבקרים (אני חושב זה היה לאיזה בקר ישן של אטמל, אבל אל תתפוס אותי פה) שבסך הכל מקצים חלק מmemory pool גלובלי. למה הם עשו את זה ככה? מהסיבה הפשוטה שהבקר לא מריץ מערכת הפעלה, אין לו שום מנגנון של memory protection חומרתי, ושום דבר שאפילו דומה לheap וניהול הקצאות דינמיות.

מבחינת המשתמש הקריאה לmalloc זהה - מבחינת מה שקורה בתכלס - זה מאוד מאוד תלוי פלטפורמה.

לגבי שפות garbage-collected שמנהלות בעצמן את הזיכרון - תלוי מאוד איזה סוג קוד אתה כותב. בהסתכלות ריאלית על התכנות - יש מלא מתארים שבהם עדיף לך לשלם את התקורה של הGC מאשר להקלע למצב שהפרויקט עומד בפני deadline והמתכנתים נאבקים בקריסות הזויות שלוקח ימים לדבג.

אין מה לעשות, יש מודולים שעדיף שיכתבו בשפה A מאשר B, ולהפך - כל תוכנה עם השיקולים שלה. (אמנם הייתי בוחר לבנות תוכנת אנטרפרייז ב.Net - אבל הייתי משתין בקשת על מישהו שהיה בונה לי אלגוריתם לעיבוד וידאו בקצב של 25fps בכל שפה managed )

[barakr]

אוווו תתפלא. ייתכן בהחלט שדליפת זכרון מתגלה רק בשימושים מסויימים בתוכנה (שימושים שהמפתחים בכלל לא העלו על דעתם)' date=' או שנובעים רק במצבי עומס מסויימים. חוץ מזה, עצם זה שאתה צריך לנהל זכרון בעצמך זו תקורה שפוגעת בזמן הפיתוח שלך.

[/quote']

לא צריך להגזים. מה שהצעתי זה שבמקרים מסוימים צריך לקחת אחריות על הנושא. לא בכל התוכנה ולא כל הזמן, אלא בדברים שהם קריטיים.

זה בדיוק מאותה סיבה שאתה יכול לכתוב תוכנה בסביבת פיתוח מתקדמת ומתוחכמת כלשהי, אבל תכתוב חלקים מסויימים ב C או איפלו באסמבלי כי אתה חייב לקבל ביצועים באותם מקומות. אז כנ"ל לגבי זיכרון[br]פורסם בתאריך: 27.07.2010 בשעה 21:00:34

---

אתה מוזמן לבוא לעולם הembedded ולגלות עד כמה המשפט הזה לא נכון

תשמע, מעריך את הדברים שלך, אבל אני לא עובד בעולם הזה. ואני כותב תוכנות שרצות על שרתי אינטרנט ועל מחשבים אישיים. ולזה יש בסה"כ שתי חברות בגדול שמייצרות מעבדים - אינטל ו AMD. והמערכות הפעלה שעבדתי איתן עד היום היו לינוקס וחלונות. וזהו.

המעבדים שנתקלתי בהם עד היום היו של שתי אלה. כשאני אחליף תחום עבודה אולי זה ישתנה.

היה לי קומודור 64 פעם אבל זה לא נחשב.

אבל ברור שכשאתה עובד עם סביבות שונות מבחינת משאבים ותשתית כללי המשחק משתנים לכל מיני כיוונים.

באשר לבחירת כלי פיתוח - גם אני מעדיף שלא לכתוב ב C כשאני יכול להימנע מזה. אבל לפעמים אין ברירה. ואז אם אני כבר בעניין אני מחפש איפה אפשר לזרז עניינים.

[Ghosthunter]

אבל הייתי משתין בקשת על מישהו שהיה בונה לי אלגוריתם לעיבוד וידאו בקצב של 25fps בכל שפה managed )

תתחיל לשתות הרבה

[DOGMA]

תתחיל לשתות הרבה

בעיקר בירה

הספריות שיש היום בJAVA לעיבוד תמונה, OCR וOOR, עולות גם בביצועים וגם ביכולות על כמעט כל ספריה קניינית שתוכל היום למצוא.

ב.NET עבודה עם Managed DirectX והעברת הנטל לכרטיס הגראפי עדיפה בהרבה ממה שתוכל לכתוב היום בכל שפת low level אחרת.

אני יגיד לך שאצלנו עושים מערכות Home Land Security ב.Net וזה כולל עיבוד תמונה ממקורות CCTV בזמן אמת, במקרה הגרוע ביותר קונים איזה ספריה שעושה את זה בשבילך, ועד כמה שעצוב היום רובן כבר כתובות או בManaged C++ או ב.Net טהור.

[Ghosthunter]

העברת הנטל לכרטיס הגראפי

בידיוק.

[gor84]

תקנו אותי אם אני טועה, עבור הקצאה דינאמית - גם היא מוקצאת לוגית (רק שהפעם על גבי הערימה), כך שניתן לבדוק האם הכתובת הלוגית הבאה היא חלק מהמערך שלך או לא...

אם תחרוג תקבל SIGFAULT, אחרת זה יש מצב (קטן) שהתחברת למערך דינאמי אחר שהקצאת בתוכני או כל הקצאה דינאמית כזו או אחרת,

לכן אפשר לקבל חסם סביר כלשהו(בהתחשב ואתה יודע כמה הקצאת כבר דינאמית). אם הקצאת רק פעם אחת בצורה דינאמית, קיבלת בוודאות את הגודל שאתה מחפש...

[Hellgrace]

דובי \ UINT - וואלה. יפה לשמוע של.Net יש יכולות מרשימות כאלה כיום

(בזמנו שהתעסקתי עם עיבודי וידאו זה היה דרך אשפה של DirectShow וCOM - איכס אחד גדול)

gor84 - תקרא את האשכול.