שיחה:C++

בשביל מי שבעתיד ירצה לכתוב את מונחים ב-C++ (תרומת אלמוני):

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

המדובר ככל הנראה במצביע this. מלח השמים 19:52, 14 מרץ 2005 (UTC)

שכחתי לכתוב את השם... טרול רפאים 19:55, 14 מרץ 2005 (UTC)

c++

ערך בעייתי

אנציקלופדיה אמורה לכלול מידע אנציקלופדי, ולא להיות מדריך ל-CPP. בשביל יש את TC++PL. יש לתאר תכונות של השפה, ולא לתת פרטים בסגנון:

לכל מחלקה אפשר ליצור פונקציה בנאית (constructors), ששמה כשם המחלקה, שתפקידה לאתחל את משתנה המחלקה כאשר נוצר מופע של המחלקה, ופונקציה מפרקת (destructor), ששמה כשם המחלקה עם קידומת של תו תלתלית ~, שמופעלת כאשר המופע של המחלקה נמחק.

בכדי ליצור מופע של המחלקה יש להשתמש במילה השמורה new. בכדי לפנות בתוך המחלקה בפונקציות חבר, למשתנים פנימיים אפשר להשתמש במילה השמורה this.

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

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

ואם כבר אני מוציא טעויות, הנה עוד אחת שמצאתי ברפרוף:

מבנה struct הורחב ויכול לכלול בתוכו מלבד משתנים גם שיטות, והוא למעשה מוגדר כמחלקה class, עם בררת מחדל של גישה private.

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

בקיצור, הפרטים הטכניים בערך גם טרחניים ומיותרים (לדעתי), ולא מעט מהם גם פשוט שגויים. מי שרוצה לכתוב את הערך הזה יכול להציץ בערך המקביל בויקי האנגלית, על חצי המאמר עד לפרק Language features. ‏conio.h‏ • ‏שיחה‏ 02:34, 3 מאי 2006 (IDT)

אני מסכים עם העיקרון שמוצג כאן: יש להבדיל בין אנציקלופדיה לבין מדריך למשתמש. דוד שי 08:22, 3 מאי 2006 (IDT)

אני מסכים. עד כה קצרה ידי מלישם העניין. הא? 17:38, 3 מאי 2006 (IDT)

יגאל 10:56, 9 אפריל 2007 (IDT): מסכים שהפרטים המעשיים מיותרים. מישהו לפני כבר מחק אותם וטוב עשה. הוספתי STRONG TYPING ולדעתי רשימת התכונות עכשיו באמת מהווה הסבר עקרוני שממנו ניתן להתרשם מה מיוחד ומאפיין את השפה לעומת שפות אחרות. ממליץ להפסיק להתיחס כאל ערך בעיתי ולא לנסות להשלים את הנושאים החסרים כביכול המהווים אכן REFERENCE MANUAL

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

מהסיבה הזו אין מקום לתוכניות "דוגמה" ארוכות (פנייה למשתמש:84.108.228.114) כי דווקא יש להניח שקורא הערך הוא לא מתכנת C++. חוץ מזה ככל שהתוכנית תהיה מסובכת יותר, ספק שתתרום יותר לערך הזה. אם מחליפים "שלום עולם" בהדפסת משולש מכוכביות, אז למה לא להחליף להדפסת כוכבית מכוכביות? או משהו עוד יותר "מאגניב"? תוכנית "שלום עולם" קלאסית תספיק לדעתי.

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

מבקש תגובות בעד או נגד.

ybungalobill 18:46, 12 בפברואר 2008 (IST)

מוריד "ערך בעיתי | סיבה=כתוב בצורה של מדריך לחובבנים המלמד את השפה ולא כערך אנציקלופדי". (כבר) לא כתוב כמדריך ולא מצאתי משהו "חובבני". לדעתי, הערכים C ו-JAVA לא כתובים טוב יותר, כך שמי שבכל זאת מתעקש מתבקש לבדוק גם אותם. יגאל1 22:21, 8 במרץ 2008 (IST)

מחרוזות

"בנוסף, ספריית התבניות הסטנדרטית STL מכילה אובייקט string, המשמש לאיחסון מחרוזות. זהו אינו משתנה טבעי של השפה, אלא אובייקט המכיל למעשה מערך של משתנים מסוג char."

האם בסטנדרט של השפה (שאותו לא קראתי) כתוב כי אובייקט string חייב להיות ממומש באמצעות מערך של משתנים מסוג char? אם לא, אין לכתוב זאת כאן. גדי אלכסנדרוביץ' 18:13, 29 יוני 2006 (IDT)

כך זה ממומש, למיטב ידיעתי, בגרסה של Visual C++ 6 של מיקרוסופט, וקשה לי לחשוב על דרך פשוטה יותר לעשות את זה. קשה לי לחשוב על מתכנת שפוי בדעתו שישתמש בדרך אחרת לממש string. אפשר להחליף את המילה "למעשה" ב"בדר״כ". צחי 18:18, 29 יוני 2006 (IDT)

אבל ב-Visual studio C++ 6 למשל, מוגדרים בספריה "strstream" טיפוסים שנקראים "istrstream", "ostrstream", "strstream" שהם טיפוסים שמגדירים מחרוזת לקלט+פלט, לפלט ולקלט בהתאמה.--80.178.4.115 14:12, 18 יולי 2006 (IDT)

למיטב ידיעתי מדובר בספריה תקנית ולא באיזה הוקוס פוקוס של מיקרוסופט - אבל בכל מקרה אני מתקשה לראות את הרלוונטיות של זה לשאלת המימוש של הטיפוס string. גדי אלכסנדרוביץ' 14:18, 18 יולי 2006 (IDT)

זו שאלה של עובדות: עובדתית, SGI השתמשו במערך של char-ים כדי לממש את המחלקה string. ‏conio.h‏ • ‏שיחה‏ 18:19, 29 יוני 2006 (IDT)

תצטרך להיות פחות לאקוני (אני לא בקיא בתחום ולא מכיר את SGI). למיטב הבנתי, השאלה היא לא איך מישהו זה או אחר ביצע את המימוש, אלא איך כל מי שמתכוון לממש את זה חייב לבצע את המימוש. להחליף ל"בד"כ" אפשר. גדי אלכסנדרוביץ' 18:23, 29 יוני 2006 (IDT)

נעים להכיר: w:en:Silicon Graphics. :)

אלה החבר'ה שאחראים במקור ל-STL. בכ"א, בורלנד, MS וגנו מיישמים את string כמערך של תווים. זה אומר "למעשה" ולא "בדרך-כלל". ברגע שתהיה דוגמה נגדית של מימוש שלם של STL, שבו string ממומש אחרת אפשר יהיה לסייג ולכתוב "בדרך כלל". אני לא שמעתי על מימוש הזוי כזה. ‏conio.h‏ • ‏שיחה‏ 18:26, 29 יוני 2006 (IDT)

בעצם, אצל SGI לא הייתה מחלקת string. זה קיים רק בספריה הסטנדרטית של CPP. ל-SGI היו כל מיני מעקפים. ‏conio.h‏ • ‏שיחה‏ 18:28, 29 יוני 2006 (IDT)

מכיוון שמדובר בויכוח טרמינולוגי (אני מבין את "למעשה" בצורה שונה משאתה מבין אותו), אני חושב שיותר נבון לאמץ את הפתרון המקובל על שני הצדדים. עם זאת, אני לא אבצע את השינוי בעצמי כדי לא להרגיז אף אחד. גדי אלכסנדרוביץ' 18:32, 29 יוני 2006 (IDT)

מה דעתך על השינוי שביצעתי? לדעתי כל הסיפור על המימוש לא רלבנטי לערך הזה, גם ככה יש כאן מיליון פרטים טכניים מיותרים להחריד. מקסימום אפשר יהיה להכניס את זה להספריה הסטנדרטית של C++‎, כשייכתב. ‏conio.h‏ • ‏שיחה‏ 19:27, 29 יוני 2006 (IDT)

נראה לי בסדר גמור. גדי אלכסנדרוביץ' 19:31, 29 יוני 2006 (IDT)

יש בכלל מחלקה כזאת שקוראים לה string?
--80.178.4.163 18:33, 16 באוקטובר 2006 (IST)

מסכים, לא הכרחי לממש את string כמערך של char. ניתן לממש את זה בצורה טובה יותר, על ידי רשימה של קטעים קטנים יותר של המחרוזת, יש לזה יתרון עבור מחרוזות ארוכות. Ybungalobill 14:00, 19 במאי 2007 (IDT)

כן, יש מחלקה בשם string 5.28.176.87 22:14, 11 במרץ 2023 (IST)

אי דיוקים בפרק אודות טיפוסים

הועבר משיחת משתמש:הא?.

אפשר לדעת מה כל כך לא מדוייק במה שכתבתי בערך C++ שמחקת את הכל? צחי 20:57, 25 יוני 2006 (IDT)

אהם... צחי 00:51, 29 יוני 2006 (IDT)

הא?, אני חושב שכשאתה משחזר תוספת של משתמש רשום כדאי לך להסביר לו בדף השיחה למה שחזרת. ⌠צהוב עולה⌡ 01:14, 29 יוני 2006 (IDT)

אהם גם לך. :)

• הביטויים "דיוק יחיד" ו"דיוק כפול" הם תרגום לגמרי לא מוצלח של הביטויים single precision ו-double precision.
• ציוני הגדלים שגויים, מפני שהם תלויי פלטפורמה לחלוטין.
• הניסוח של הסעיף אודות char אינו אנציקלופדי.
• הפסקה אודות STL אינה במקומה, לפחות לא בצורתה דנן.

אכן היה זה עדיף אילו הייתי מפרט יותר במקור. סלחו לי. הא? 13:12, 29 יוני 2006 (IDT)

ולא היה יותר קל לתקן את זה, במקום לכתוב את ההסבר המפורט הזה? חשבתי שכך נבנית הויקיפדיה, על ידי תיקונים חוזרים ונשנים. אף אחד לא מצפה לטקסט מושלם בגרסה הראשונה. חוץ מזה, אני חולק על דבריך כאילו ציוני הגדלים שגויים. למיטב ידיעתי, רק long תלוי פלטפורמה, כפי שציינתי. צחי 18:02, 29 יוני 2006 (IDT)

כל הגדלים תלויי פלטפורמה. מה שמובטח הוא רק יחסי הסדר בין הגדלים. מה שכן, אני לא מבין מה רע ב"דיוק יחיד" ו"דיוק כפול" - או יותר נכון, מה התרגום המוצלח יותר. גדי אלכסנדרוביץ' 18:10, 29 יוני 2006 (IDT)

תיקנתי, לפי הספר "++C כשפת אם", מאת יצחק גרבר, שזה מה שיש לי בבית כרגע. צחי 18:12, 29 יוני 2006 (IDT)

אולי כדאי שתחליף את מה שיש לך בבית כרגע לספר של Stroustrup. הנה מה שיש לאחד מהמרצים בטכניון לומר על הספר של גרבר. גדי אלכסנדרוביץ' 18:20, 29 יוני 2006 (IDT)

אז אני מבין שאסור שיהיו טעויות בויקיפדיה? שכל ערך צריך לעלות בצורה מושלמת? צחי 02:06, 2 יולי 2006 (IDT)

כשאתה מנסח את זה ככה, כן... ‏conio.h‏ • ‏שיחה‏ 02:14, 2 יולי 2006 (IDT)

הניסוח שגוי. יש הבדל בין "אסור שיהיו טעויות" (שזה נכון) ובין "לעלות בצורה מושלמת". ערך לא מושלם (שבו חסר מידע, כתוב בצורה עילגת, מציג את הנושא בצורה שרק מקצוענים יצליחו להבין, מכסה את הנושאים בסדר לא הגיוני, מעוצב בצורה לא נוחה לקריאה, מתמקד בפרטים השוליים) לא בהכרח מכיל שגיאות עובדתיות. גדי אלכסנדרוביץ' 07:46, 2 יולי 2006 (IDT)

קשקוש. יש בויקיפדיה המון שגיאות. בגלל זה זה ויקי, כי כל הזמן מתקנים ומרחיבים, עד שמגיעים לערך ראוי. אם יש שגיאות, תתקנו, אל תמחקו! צחי 10:22, 2 יולי 2006 (IDT)

מה הקשקוש כאן? נכון, יש בויקיפדיה הרבה שטויות. זה לא משנה את זה שאסור שיהיו בויקיפדיה טעויות. אם יש טעויות, פירוש הדבר שנכשלנו במשימה לשמור את ויקיפדיה חפה מטעויות. זה לא אומר שזה בסדר. מכיוון שלא תמיד אפשר לתקן, לעתים עדיף למחוק. בפרט כשמישהו הוסיף טעויות ועוד מידע שהעורך אינו יודע אם הוא טעות או לא - מי שכבר טעה באותה התוספת ממש לא מעורר אמון רב ביחס לשאר התוספת. גדי אלכסנדרוביץ' 13:46, 2 יולי 2006 (IDT)

והמסקנה היא: גם בדפי שיחה יכולים להיות טעויות (ואני מקווה שלא ימחקו אותן...)--80.178.4.163 18:38, 16 באוקטובר 2006 (IST)

חלונות

דרך אגב, אתם יודעים שפותחה גרסה של C++ למערכת ההפעלה חלונות?--80.178.141.162 14:19, 10 יולי 2006 (IDT)

למה בדיוק כוונתך? גדי אלכסנדרוביץ' 16:42, 10 יולי 2006 (IDT)

תכנות ב-C++ ב-Windows API.
מקווה שהבנת
--80.178.89.116 15:39, 3 אוגוסט 2006 (IDT)

לקריאה נוספת:

• יסודות התכנות בחלונות עם C\C++ /הוצאת הוד-עמי
  
• המדריך השלם Visual C++ /הוצאת הוד עמי (ספר זה הוא ספר המשך לספר לעיל)
  

80.178.89.116 15:48, 3 אוגוסט 2006 (IDT)

לא אמרת בעצם כלום, אבל הרושם שאני מקבל הוא שאתה מבלבל בין "גרסה של C++", כלומר של השפה עצמה, ובין API לחלונות עבור C++. גדי אלכסנדרוביץ' 16:17, 3 אוגוסט 2006 (IDT)

מילים שמורות

האם abstract היא מילה שמורה של ++C? (אם כן, מאיזה תקן?) ומה קרה למילים כמו asm? הרשימה לא נראית לי רצינית. גדי אלכסנדרוביץ' 18:42, 9 בנובמבר 2006 (IST)

בסעיף "מילים שמורות" אני לא ראיתי שום רשימה ושום כלום.--17:04, 15 בנובמבר 2006 (IST)

כי רוקנתי את הסעיף. תוכל לראות מה היה בו על ידי מבט בגרסאות הקודמות. גדי אלכסנדרוביץ' 17:08, 15 בנובמבר 2006 (IST)

לא, מי שכתב את זה כתב שטויות. בכלל אין הרבה אנשים אשר יודעים C++ טהור, וחבל. עדכנתי את הרשימה לרשימה תקנית הכוללת 64 מילים שמורות, נלקח מספרו של סטראוסטרופ פרק A.2 בספר. Ybungalobill 18:56, 18 ביוני 2007 (IDT)

הגרסה החדשה נראית תקינה אבל המידע בה לא שלם (אין הסבר על הגרסאות השונות וחלק מהמילים השמורות אינן בשימוש מעשי יותר). טרול רפאים 19:25, 18 ביוני 2007 (IDT)

אאמם, אילו מילים שמורות לא בשימוש יותר? נכון שיש מילים שלא נתמכות על ידי מהדר זה או אחר (מי תומך בEXPORT למשל?). Ybungalobill 19:37, 20 ביוני 2007 (IDT)

auto למשל. טרול רפאים 19:46, 20 ביוני 2007 (IDT)

האמת הוא גם היחידי, לא במקרה קוראים לו "אוטומטי" :-). בVOLATILE ובREGISTER משתמשים פחות בתכנות לPC, אבל עדיין יש להם שימוש בתכנות לחומרה. כל השאר משתמשים. ובכל זאת אם כותבים אז יש לציין הכל. לא שאני בעד לכתוב פירוט על תחביר השפה בערך בויקיפדיה. Ybungalobill 19:55, 20 ביוני 2007 (IDT)

קיים המהדר של Comeau שאמור לתמוך ב-export, כך הם טוענים[1].ה-Front-End של EDG גם אמור לתמוך. המתעתק • שיחה 05:15, 24 ביוני 2007 (IDT)

יתרונות וחסרונות

• לא באמת קרובה עד כדי כך לשפת מכונה. הבדלים בביצועים בין קוד שקומפל בעזרת מהדרים שונים הם הוכחה חיה לכך. בניגוד ל-C‏, CPP כבר איננה "סט מאקרואים לאסמבלי".
• אי-אפשר באמת לכתוב קוד גדול ב-C ללא שימוש בספריות חיצוניות. זה סותר לחלוטין את הסעיף הקודם (פיתוח דרייברים בלי DDK וממשקי משתמש בלי ספריות גרפיות של מערכת ההפעלה).
• אין באמת צורך להמציא את הגלגל מחדש כשקיימות כל כך הרבה ספריות חיצוניות מצויינות (boost היא כמעט תקן בכל מקום שלא סובל מ-Not Invented Here).
• צורך בהבנה מעמיקה תמיד צריך, בכל תחום בו עוסקים. CPP אינה ייחודית מבחינה זו. גם מהנדס ביו-טכנולוגיה זקוק להבנה מעמיקה בביו-טכנולוגיה כדי להיות ביו-טכנולוג טוב. כשכותבים קוד high-level אין באמת צורך להתרכז ב"התחכמויות" של השפה.

וכו'. המתעתק • שיחה 15:36, 4 במאי 2007 (IDT)

מה זה הפרק הזה? יש לזה תקדים איפשהו? למה להציג ערך דווקא דרך זכוכית מגדלת של טוב ורע? זה מקצין דעות אישיות במקום להציג דברים כהוויתם. נראה לי מנוגד לרוח האנציקלופדית. מציע להחזיר לגרסה שלפני ואם לא אראה תשובות עניניות אכן אעשה כך. ―יגאל1 (שיחה | תרומות | מונה) לא חתם ‌ 00:00, 10 בינואר 2000 (IST) 22:41, 12 במאי 2007

מה הבעיה בפרק הזה? מטרה של אנציקלופדיה היא לתת מידע. האם הפרק הזה חוטא למטרה? האם אין הבדלים עקרוניים ומהותיים שיש לדסקס עליהם בין השפה לשפות אחרות? אם יש שגיאה בהבדלים אשמח שהדבר יתוקן. אשמח מאוד שאנשים שיש להם ידע טוב בשורה של שפות תכנות, יגרמו לפרק הזה להיות יותר מדוייק. אבל מכאן ולהשמיט אותו, איזה תועלת יש בדבר? --אפי ב. • שיחה • 23:43, 19 במאי 2007 (IDT)

ליגאל תודה על התיקונים שעשית. ראיתי שכתבת "דיבוג מייגע לבלתי מנוסים." לדעתי הוא גם למאוד מנוסים, מכיוון שהוא נובע בעיקר מצורתה וסגנונה הגמיש והפתוח של השפה לעומת שפות אחרות. בחברה שבה אני עובד יש מתכנתים מקצוענים ומאוד מנוסים בC++, שחלק גדול מאוד מזמנם התיכנותי מקדישים לבילוש ומרדף אחרי באגים מבאגים שונים. --אפי ב. • שיחה • 23:55, 19 במאי 2007 (IDT)

"אבל לדעתי" הוא בדיוק הסיבה שצריך למחוק את הפרק הזה. המתעתק • שיחה 00:04, 20 במאי 2007 (IDT)

למתעתק. כדאי שתקרא את הפסקה הזו שעברה שינויים גדולים בידי יגאל1. ותשנה עדיין את מה שצריך שינוי לדעתך. במקום מדיניות של מחיקה עדיף ללכת על מדיניות של שיפור וליטוש. לגבי קרבתה של CPP לשפת מכונה יתכן שיש ויכוח, אבל על זה שהיא low level לא נראה שיש ויכוח. ולגבי המורכבות והקושי של השפה לעומת שפות כמו VB, ג'אוה, C# וPHP, לא נראה לי שיש ויכוח. --אפי ב. • שיחה • 02:15, 20 במאי 2007 (IDT)

קראתי, והיא עדיי בעייתית. אני יכול להצביע על הבעיות, אבל לדעתי הן אינן ברות תיקון, ולכן לא אוכל לתקן אותן:

• יתרונות

  "ניצול משאבי המחשב באופן מיטבי, בשל הקירבה לשפת מכונה."

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

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

  כנ"ל. ובנוסף - לשפה אין "מהירות הרצה". אתה מוזמן לבדוק בעצמך את הבדל המהירות בין ציור חלון בעזרת GTK, .NET ו-WIN32API.

  "חוסר תלות. אפשרות לפיתוח ללא כל תלות בספריות חיצוניות ויצירת קבצים קטנים שמשתמשים במעט זכרון."

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

• חסרונות

  "קושי. הכותב ב ++C חייב להיות מקצוען תוכנה אמיתי ולא בוגר קורס קצר."

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

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

  כנ"ל.

  "דיבוג מייגע לבלתי מנוסים. הגמישות הרבה היא מקור לבאגים שונים וחמקמקים שקשה לאתרם. לעומת זאת מי שמשתמש בכלים החזקים של השפה כמו תבניות (templates) וטיפוסיות חזקה (strong typing) יכול להגיע למצב שקוד מקומפל רץ חלק כבר בפעם הראשונה."

  דיבוג הוא תמיד עניין מייגע, בכל שפה. זוהי פונקציה של גודל המערכת. חיפוש שגיאות, בכל מערכת שהיא, לאו דווקא מערכת תוכנה, הוא עניין מייגע. חוק 20-80 תקף בכל המקרים הללו. לעומת זאת, מי שמשתמש בכלים החזקים של השפה, כמו תבניות, יגלה שלא קיים ולו מהדר אחר בשוק היום שתומך בהם במלואם, לפי התקן (ל-EDG לקח 4 שנות-אדם לפתח תמיכה ב-template export, והם היחידים שתומכים בזה, לדוגמה). דיבוג של קוד שכולל תבניות הוא כמובן זוועה בפני עצמה. ניתוח הודעות השגיעה שאפשר לקבל כאשר משתמשים ב-STL הפך לשם דבר, והוביל לפיתוח כלים מיוחדים שמתרגמים את הודעות השגיאה הללו למסרים מובנים.

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

  טיעון איום ונורא בהתחשב בסעיף האחרון של היתרונות לכאורה.

לסיכום, צריך למחוק. המתעתק • שיחה 02:32, 20 במאי 2007 (IDT)

לגבי יעילות. הרבה יותר קרובה לשפת מכונה משפות אחרות, במיוחד כאלו שיש להם מנגנון קומפילציה של JIT. אולי לגבי ציור חלון אין הבדל משמעותי, אצלנו בדקנו בין קוד שניכתב בCPP לבין קוד שנכתב בVB.NET, טרנספורמציה של פריימים מעומק צבע של 24 ביט לגרייסקאל, והיו הבדלים משמעותיים בביצוע. לא לחינם בהרבה מקומות מעדיפים לכתוב את המנוע של התוכנה בCPP, ואילו את הממשק בשפה דוט נטית כמו C# או VB, ולחבר ביניהם.

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

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

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

הניסיון לטשטש את ההבדלים בין שפות תכנות ולומר שלכולן יש ביצועים דומים, באגים דומים, מורכבות דומה, נראה לי תמוה משהו. --אפי ב. • שיחה • 09:15, 20 במאי 2007 (IDT)

קודם כל, אומר שיש הבדל בין האמירה "קוד CPP פועל מהר יותר מקוד VB או C# מקביל" לבין "ניצול משאבי המחשב באופן מיטבי, בשל הקירבה לשפת מכונה". ליתר דיוק, אין שום קשר ביניהן. אי-אפשר להצדיק אחת בעזרת השנייה.

בכל אופן, לגבי חלק מהדברים לא ענית, ולגבי אלו שענית, פתחת ויכוחים שהאינטרנט מלא בהם. העובדה הזו בלבד מוכיחה שהטענות שכרגע כתובות בערך אינן נייטרליות, אינן אובייקטיביות, ולכן לא יכולות להישאר בו. המתעתק • שיחה 17:08, 22 במאי 2007 (IDT)

הכללת STL

לפי הידוע לי הספריה התקנית של C++ מוכללת כיום ללא הסיומת .h. סיומת זו היתה בגרסאות ישנות יותר של התקן ומסיבות שונות הורדו. בקבצים המוכללים בצורה: <iostream.h> יהיו כל הכלים גלובליים (מחוץ למרחב שם std), אולם לפי התקן האחרון לא חייבים המהדרים לתמוך בצורה זו של הכללה, במקום זאת יש לרשום <iostream> אלה אם כן בידינו מהדר מיושן. אני מציע שבערך C++ בויקיפדיה יצמדו לתקנים האחרונים, ולכן גם לא ידגימו שימוש בספריות כגון conio. אני מעלה את הדיון הזה כאן כדי שהעורכים הבאים יקפידו על הדבר ולא ישנו בחזרה, תודה.

ראו סטראוסטרופ (The C++ Programming Language 3rd):

9.2.2 Standard Library Headers

[...] No suffix is needed for standard library headers; they are known to be headers because they are included using the #include <...> syntax rather than #include "...". [...]

B.3.1 Headers

[...] Using the old .h names would have caused compatibility problems. The solution was to drop the .h suffix in standard header names. [...]

ybungalobill 10:25, 2 ביולי 2007 (IDT)

דרוש מקצוען C++ רהוט

הערך הזה זמן רב נמצא בשיממונו. אלו מוסיפים ואלו גורעים, והרבה לא זז. דרוש מקצוען מחשבים שידע לתת בסקירה מקיפה בלשון רהוטה את הדברים העיקריים שבשפה זו, וההבדלים המהותיים בינה לבין שפות אחרות, מבלי להכנס עמוק מדי לנבכי הטכנולוגיה שלה. --אפי ב. • שיחה • 13:30, 25 במרץ 2008 (IST)

תוספות מיותרות

strong typing

תוספת מיותרת: "למרות זאת עדיין ניתן להגדיר מצביע מסוג *void."

מטרת הערך להעביר עקרונות לא ללמד C++. העקרון הוא strong typing ואכן הוקשחו הכללים:

אי אפשר לבצע כמו ב C:

 ;int a
 ;void *p = &a
 ;int *b = p   (--> שגיאה ב++C אך לא בC)

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

אמנם ככה זה לא יעבוד, אבל מה אם תבצע reinterpret_cast? לירן (שיחה,תרומות) 16:43, 18 במאי 2008 (IDT)

אפשר לבצע reinterpret_cast בכל מקום ואפשר גם לשנות את שם הקובץ מ cpp. ל c. זה יותר מהר [יגאל1]

שפה יוקרתית

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

המשפט היה מיותר לחלוטין, אנחנו לא עוסקים בדירוגי שכר בערכים העוסקים במקצועות. מחקתי אותו. תודה. ‏odedee • שיחה 15:59, 6 במאי 2009 (IDT)

היית צודק אם היה מדובר במדריך לשפה. בגלל שמדובר בערך אנציקלופדי, דברים שנמצאים בערך כמו מילים שמורות, מזמן היו צריכות לעבור לויקיטקסט, וההתיחסות למתכנתי C++ בשוק דוקא מאוד רלבנטית. יכול להיות שמישהו למשל ישקול האם ללמוד שפה זו על פני אחרות כאשר הוא שוקל שיקולים תעסוקתיים או כלכליים, וצריך לתת לו מידע זה לא פחות מצורת ההורשה של השפה. --אפי ב. • התחברו לרגשותיכם • 21:40, 6 במאי 2009 (IDT)

אני מסכים עם odedee. טענות כאלה גם מוטות וקשה מאד לבסס אותן. יובל מדר - שיחה 21:48, 6 במאי 2009 (IDT)

שם מפתח השפה

עד כמה שידוע לי, את השם: Bjarne הוגים כ- "ביורן" (היינו Byorn) ולא כ-ביארן.. האם יש לי אור ירוק לשנות את השם בערך כולו? (+ תוספת של סוגריים עם השם בלעז בפעם הראשונה שהוא מופיע)?

לא. קוראים את זה כמו שכותבים, כולל ה-E שבסוף, פרט ל-R שלא שומעים אותה. אתה מוזמן לקרוא את ה-IPA בערך שבויקי האנגלית או לשמוע הקלטה שלו עצמו כאן: http://www2.research.att.com/~bs/bs_faq.html#pronounce בונגלו - שיחה 11:28, 2 באוקטובר 2010 (IST)

החכמתי, תודה!

בעקבות פרסום התקן החדש

צריך להוסיף פסקה על התקן הזה - זה האירוע המשמעותי ביותר שעברה השפה מאז סוף שנות השמונים. --אלעזר - שיחה 00:50, 13 בספטמבר 2011 (IDT)

העמסת אופרטורים - הבעת דעה בערך?

בפסקת "העמסת אופרטורים" יש קטע שלם (שמהווה למעשה את רוב הפסקה) שמתחיל במשפט "אך מבחינת תחבירית העמסת אופרטורים היא תכונה שנויה במחלוקת". לי זה נראה כמו הבעת דעה אישית, ויש דיונים שלמים באינטרנט לשני הצדדים. זה לא ערך שמדבר על שגיאות בתכנות (כמו הדוגמא שמובאת כאן), ואני לא חושב שהוא תורם דבר להכרות עם C++. וכמו שכבר כתבו לפני - זה לא מדריך לשפה ולא לתכנות נכון. לדעתי הקטע הזה צריך להימחק. Asdido - שיחה 14:14, 20 ביולי 2012 (IDT)

משוב מ-2 בדצמבר 2021

תודה רבה!! עזר לי מאוד!!

קישור לאתר הרשמי של cpp?

לcpp יש אתר רשמי? 5.28.176.87 22:08, 11 במרץ 2023 (IST)