• בית
• מאמרים ב־RSS
• תגובות ב־RSS
• ‏פיתוח ב־RSS
• כניסה

מאמרים בנושא "פיתוח"

תסריט פיתון להחלפת namespace של Boost.

הכנתי תסריט קטן שמאפשר שינוי גורף של Namespace עץ הקוד של Boost ל־Namespace חילופי כדי למנוע התנגשות בין גרסאות Boost שונות: http://art-blog.no-ip.info/files/rename.py.

הרצה:

./rename.py /path/to/boost/tree new_namespace_name

עכשיו כל ה־defineים וכל הסימבולים יימצא ב־namespace אחר ואפשר יהיה לבנות רכיבים ללא תלות בגרסת Boost.

הערות:

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

את התסריט כתבתי לפתרון אפשרי לבעיה שהצגתי במאמר הקודם

דברים שלא נאמרים על Boost.

או ליתר דיוק, לא מודגשים לגביו.

http://boost.org היא אחת הספריות הפופולריות ביותר ב־C++‎, היא מהווה ל־C++‎ מה ש־JDK מהווה ל־Java, מה ש־RTL ו־‏FCL מהווים ל־FreePascal, היא מה ש־Python Standard Library מהווה ל־Python.

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

• תמיכה ב־Threads.
• עבודה עם socketים.
• כלי עיבוד טקסט.
• ביטויים רגולריים.
• עבודה עם זיכרון משותף.
• ועוד.

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

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

המשך...

השוואת FPC ושפות אחרות

נתחיל מהטבלה שמשוואה מספר שפות תכנות פופולריות: Python, Java, C, C++‎ ו־FPC.‏ כאשר אני מתמקד במספר רבדים: תכונות שפה מרכזיות, סגנונות פיתוח ותכנות אפשריים, ספריות וספקים.

השוואה לפי תכונות:

Feature	Python	Java	C	C++	FreePascal
Core:
Memory man.	Automatic	Automatic	Manual	Semi-Automatic	Manual
Resources man.	Automatic1	Manual	Manual	Semi-Automatic	Manual
Inheritence	Multiple	Sinlge	No	Multiple	Single
Polymorphizm	Duck	Dynamic	No	Dynamic+Static	Dynamic
Reflection	Yes	Yes	No	No	No
Language Features
Generic Programming	Irrelevant	Limited	No	Turing Complete	Limited
Generic methods	Irrelevant	Yes	No	Yes	No
Requires interfece	Irrelevant	Yes	-	No	No
Functional Programming	Yes	Very Limited	No	C++03 Limited C++0x Full	None
Libraries:
Standard:	Rich	Rich	Poor	Limited	Rich
conteiners	Yes	Yes	No	Yes	Yes
threading	Yes	Yes	No	No	Yes FCL
GUI	Yes	Yes	No	No	Yes LCL
3rd party libs.:	Rich	Rich	Rich	Rich	Poor
Other:
Standards	None	Yes	Yes	Yes	Outdated
Implementations:	CPython, Jthon, IronPython	GNU, Sun, IBM	Lots	Many: GNU, MS, HP, Sun, Intel...	Single
Defacto-Vendor	Yes: CPython	Yes: Sun	None	None	FPC
Performance	Poor	Medium	High	High	High

הערות:

1. רק ב־CPython.

סיכום:

1. Python: נותנת לעבוד עם כל סגנונות פיתוח אפשריים, קל לפיתוח וניהול משאבים, אבל סובל משתי בעיות עיקריות: ביצועים ו־vendor lock in.‏
2. Java: שפה יחסית מגבילה מבחינת הגישה שלה, אבל בטוחה לפיתוח ותכנות בזכות: GC, ספריה סטנדרטית מאוד עשירה פשטות השפה.
3. C: שפה שכמטע ולא מספקת כלים "מודרניים"… כבודה במקומה מונח, ועדיין יש לה המון יישומים במיוחד בתחום embedded, או כל תחום אחר בו צריך לרדת לרמת תכנות נמוכה ולשמור על קומפקטיות וקריאות של הקוד.
4. C++‎: שפה מאוד עשירה, הרכיבים המודרניים היחידים שחסרים לה זה: העדר Reflection, העדר GC מלא (אם כי ב־C++‎‏ RAII מחליף אותו בהצלחה) ואולי צורך בספריות צד ג'. כמובן עם הכוח בא גם החיסרון: שפה מסובכת שלוקח זמן ללמוד אותה לעומק ולהבין את הרבדים השונים שלה.
5. עכשיו הגיע תורה של FPC:‏ היא נמצאת איפשהו בין C לבין Java:
   • מצד אחד, אין לה GC ומצד שני אין לה גם RAII שיש ב־C++‎, ניהול המשאבים שם ידני לחלוטין ממש כמו ב־C.
   • יכולות הירושה מוגבלות לירושה בסגנון C#/Java.
   • תמיכה ב־Generics מוגבלת, אין תכנות פונקציונלי (במובן lambda calculus) וגם אין Reflection.
   • ספריה סטנדרטית די עשירה (אם לוקחים גם FCL ו־LCL), אבל העדר ספריות צד ג' כואב, הרבה יותר

נשאלת השאלה: מהו הערך המוסף ש־FreePascal נותנת מעבר לתחביר שנחשב לקצת יותר קריא? נדמה שלא הרבה.

לרגל שחרורו של gcc-4.4... חידושים ושיפורים.

לפני כחודש שוחררה גרסה חדשה של gcc:‏ 4.4. אחד הדברים המעניינים זה התקדמות בתמיכה בתקן C++‎ החדש C++0x. הנה כמה תכונות מאוד מעניינות שכבר מזמן חיכיתי להן:

• סוף־סוף, הגיע אחת התכונות הנחשקות ביותר — תמיכה ב־auto, שחוסכת המון הקלדה מיותר ומקלה בצורה משמעותית על כתיבת קוד בלתי תלוי בקונטיינרים. לדוגמה, היום כך כותבים לולאה שמדפיסה איברי הרשימה:

  for(list<int>::contst_iterator p=numbers.begin();p!=numbers.end();++p)
  {
      cout<< *p <<endl;
  }
  

  ואם רוצים לשנות את סוג הקונטיינר מ־list ל־vector צריך לשנות את list ל־vector בלולאה. עם טיפוס auto זה מתקצר בצורה משמעותית:

  for(auto p=numbers.begin();p!=numbers.end();++p)
  {
      cout<< *p <<endl;
  }
  

  ובנוסף ל"קיצור" הכתיבה, אין שום אזכור של סוג הקונטיינר בלולאת for.

• טיפוסי תווים חדשים. בסטנדרט הנוכחי יש בעיה משמעותית בהגדרת תווי unicode, או ליתר דיוק העדר הגדרה ראויה שלהם. כך wchar_t למעשה יכול להיות בגודל של 32 ביטים, 16 ביטים ואפילו 8 ביטים. למעשה, בסביבת Windows, ‏wchar_t הוא בגודל של שני בתים ומייצג utf-16 (או ucs-2), כאשר בכל סביבות ה־UNIX, ‏wchar_t מייצג נקודת קידוד בודדת והוא בגודל של 32 ביט. זה יוצר לא מעט בעיות בטיפול במחרוזות unicode. כי הקידוד של std::wstring לא ברור.

  התקן החדש הגדיר שני טיפוסי תווים חדשים: char16_t ו־char32_t שמונעים את האי בהירות בנושא. כך שהעבודה עם std::u16string ו־std::u32string הופכת להרבה יותר שקופה. כך, בנוסף הוגדר ייצוג חדש למחרוזות:

  std::string normal="שלום"; // encoded as 8 bit
  std::wstring wide=L"שלום"; // utf16 or utf32 depending on your OS
  std::u16string utf16=u"שלום"; // utf16 encoded
  std::u32string utf32=U"שלום"; // utf32 encoded
  

• כמובן, לא צריך לשכוח את התמיכה ב־Variadic templates שהתווספה ב־gcc-4.3, המאפשרת לבנות פונקציות typesafe עם מספר משתנה של פרמטרים בצורה בטוחה, קצרה ומהירה. התמיכה בהן מקצרת בצורה בסדר גודל את זמן הקומפילציה של תבניות כמו std::function או std::bind.

מבחינתי, יש עוד מספר תכונות שאני מחכה להן:

• תמיכה בביטויי למבדא.
• תמיכה ב־delegating and inheriting constructors שמקצרת בצורה משמעותית את הכתיבה של overloaded constructors.
• תמיכה ב־Concepts שייאפשר לספק פלט שגיאות הרבה יותר ידידותי.
• תמיכה מלאה ב־STL החדש, כולל regular expressions.

אני מקווה שזה לא ייקח הרבה זמן…

האם אתה מוכן לבינאום ולוקליזציה?

הכנתי שאלון קצת שמאפשר לכם לבדוק… האם אתם מוכנים לכתיבת תכנה שתהיה מוכנה להתאמה לתרבויות שונות?

1. אני רוצה לייצג מחרוזת, כ־char *some_text. מהו המידע שחסר לי?
2. יש לי מחרוזת wchar_t *text או String text ב־Java, אני רוצה לקחת את התו הראשון שלה:

    wchar_t c=text[0]; // C
    Char c=text.charAt(0); // Java
   

   האם זהו קוד נכון?
3. אני כותב את הקוד הבא:

    if n==1:
        print translate("You have one aplle")
    else:
        print translate("You have %d apples") % n
   

   מה לא בסדר בקוד הזה?
4. מה לא בסדר בקוד הבא:

    #include <stdio.h>
    #include <time.h>
   
   int main()
   {
           time_t now_t=time(NULL);
           struct tm *now=localtime(&now_t);
           char str_time[32];
           strftime(str_time,sizeof(str_time),"%d/%m/%y",now);
           printf("Today is %s\n",str_time);
           return 0;
   }
   

5. מהו גודל הזכרון הנדרש לשמירת תו unicode בודד?
6. מהו גודל של wchar_t? (למתכנתי C++/C)‏?
7. מהי גודל של תו unicode בשפת התכנות שאתה אוהב?
8. מהו קידוד של מחרוזת (unicode) בשפת התכנות/toolkit שאתה אוהב?
9. מה הבדל בין utf-8,‏ utf-16, ‏utf-32?‏
10. מהו אורך התו הארוך ביותר ב־utf8?‏
11. בניתי ספרייה עם שתי פונקציות בלבד. מה לא בסדר בקוד הבא (שתי בעיות לפחות)?

    extern Char32 to_upper_char(Char32);
    void to_upper(String str)
    {
            for(int i=0;i<str.size();i++)
                    str[i]=to_upper(str[i]);
    }
    

12. מה לא בסדר בקוד הבא:

    def print_error_message(message):
        print translate("Error occured: ")+"“"+translate(message)+"”"
    

13. מה לא בסדר בקוד הזה:

    <?php $rtl_langs=array("he","ar","pa"); ?>
    ...
    <div <?php if(in_array($lang,$rtl_langs) echo 'dir="rtl"'; ?> >
    ...
    </div>
    

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

    // Cut nice pice of text
    wstring cut_nicely(wstring const &orig,int n)
    {
       if(orig.size()<=n) return orig;
       return orig.substr(orig.find_first_of(L" \r\n\t\f",n));
    }
    

המשך...

תנאי שימוש

אלא אם נאמר אחרת, התכנים באתר זה מופצים תחת רישיון ייחוס-שיתוף זהה 1.0 ישראל של Creative Commons‏.

צור קשר

העיצוב מבוסס על תבנית וורדפרס OrangeSky של Naoko McCracken.