אפשר הסבר על קבצי LIB?
- פותח הנושא ilankt
- פורסם בתאריך
LIB , קיצור של LIBRARY, כשמו כן הוא
ספריה של פונקציות או אובייקטים לשימוש. מספר שימושים עיקריים האחד, מודולריות, כאשר מפרידים מודולים שונים של התוכנה לספריות שונות (לרוב בתצורת DLL עם קובץ LIB לקישור) על מנת לאפשר מודולריות, אפשרות תיקון, וקיצור תהליכים, כאשר עובדים רק על מודול אחד ולא על כל התוכנה. תארו לעצמכם מצב שבו MS WORD כתוב בקובץ EXE אחד. קצת אבסורדי, לא מציאותי, ויהיה מאד קשה לתקן באגים אם בכל פעם שיש תיקון נהיה חייבים להוריד את כל קובץ ה EXE כולו. בנוסף, מאחר ומספר תוכנות משתמשות באותן פונקציות/אובייקטים, ניתן לגרום לשתי תוכנות שונות להשתמש באותו ה DLL או LIB, ולחסוך בפיתוח. אפשרות נוספת - אתה מתכנן איזו אפליקציה, שאמורה לבצע פעילות מאד מורכבת. מאחר וזמן הפיתוח הוא יקר, ומאחר ולעיתים מישהו כבר המציא את הגלגל לפניך, ניתן פשוט לקנות או להשתמש בספרית רכיבים או פונקציות חיצונית, שתביא אותך לנקודת התחלה טובה יותר. דיברתי פה על LIB ו DLL יחד. השימוש בגדול זהה. LIB היה קיים פעם, וקיים גם היום, כאשר מצרפים את הספריה באופן סטטי אל קובץ ה EXE, כלומר כל המידע נשמר בקובץ אחד. ה DLL לעומת זאת מאפשר חלוקה לוגית ופיזית של התוכנה, לקבצים נפרדים, אשר מועלים בזמן הרצת התוכנה באופן דינמי. לרוב, גם כאשר משתמשים בDLL, ישנו קובץ LIB שמקושר סטטית לתוכנית, אשר מכיל בעצם את כל ההגדרות של ה DLL ומאפשר עבודה עם הDLL בזמן ריצה. מקווה שזה עוזר לך במשהו.
ספריה של פונקציות או אובייקטים לשימוש. מספר שימושים עיקריים האחד, מודולריות, כאשר מפרידים מודולים שונים של התוכנה לספריות שונות (לרוב בתצורת DLL עם קובץ LIB לקישור) על מנת לאפשר מודולריות, אפשרות תיקון, וקיצור תהליכים, כאשר עובדים רק על מודול אחד ולא על כל התוכנה. תארו לעצמכם מצב שבו MS WORD כתוב בקובץ EXE אחד. קצת אבסורדי, לא מציאותי, ויהיה מאד קשה לתקן באגים אם בכל פעם שיש תיקון נהיה חייבים להוריד את כל קובץ ה EXE כולו. בנוסף, מאחר ומספר תוכנות משתמשות באותן פונקציות/אובייקטים, ניתן לגרום לשתי תוכנות שונות להשתמש באותו ה DLL או LIB, ולחסוך בפיתוח. אפשרות נוספת - אתה מתכנן איזו אפליקציה, שאמורה לבצע פעילות מאד מורכבת. מאחר וזמן הפיתוח הוא יקר, ומאחר ולעיתים מישהו כבר המציא את הגלגל לפניך, ניתן פשוט לקנות או להשתמש בספרית רכיבים או פונקציות חיצונית, שתביא אותך לנקודת התחלה טובה יותר. דיברתי פה על LIB ו DLL יחד. השימוש בגדול זהה. LIB היה קיים פעם, וקיים גם היום, כאשר מצרפים את הספריה באופן סטטי אל קובץ ה EXE, כלומר כל המידע נשמר בקובץ אחד. ה DLL לעומת זאת מאפשר חלוקה לוגית ופיזית של התוכנה, לקבצים נפרדים, אשר מועלים בזמן הרצת התוכנה באופן דינמי. לרוב, גם כאשר משתמשים בDLL, ישנו קובץ LIB שמקושר סטטית לתוכנית, אשר מכיל בעצם את כל ההגדרות של ה DLL ומאפשר עבודה עם הDLL בזמן ריצה. מקווה שזה עוזר לך במשהו.
חסכון במשאבים
ספריות lib מקושרות בסופו של דבר לקובץ ההרבה באופן סטאטי - משמע הקוד עצמו נמצא בתוך הקובץ. שיטה זו מבזבזת מקום, מכיוון שהמון קבצים מכילים את אותו קוד. בנוסף, אם רוצים לעדכן את הספריה צריך לבנות מחדש את כל קבצי ההרצה שמשתמשים בה. ספריות עם קישור דינאמי (dll) מקושרות לתוכנית בזמן הריצה, ומאפשרות ביזור של המערכת על כמה קבצים, חיסכון במקום איכסון, ושימוש של כמה תוכניות בקוד שנמצא פעם אחת בזיכרון (במקום מצב שכל תוכנית טוענת עותק משלה של הספריה לזיכרון). DirectX עושה שימוש בקישור סטאטי (lib), והפונקציות שבספריות הללו דואגות לקשר את התוכנית שלך לספריות הדינאמיות באופן עצמאי.
ספריות lib מקושרות בסופו של דבר לקובץ ההרבה באופן סטאטי - משמע הקוד עצמו נמצא בתוך הקובץ. שיטה זו מבזבזת מקום, מכיוון שהמון קבצים מכילים את אותו קוד. בנוסף, אם רוצים לעדכן את הספריה צריך לבנות מחדש את כל קבצי ההרצה שמשתמשים בה. ספריות עם קישור דינאמי (dll) מקושרות לתוכנית בזמן הריצה, ומאפשרות ביזור של המערכת על כמה קבצים, חיסכון במקום איכסון, ושימוש של כמה תוכניות בקוד שנמצא פעם אחת בזיכרון (במקום מצב שכל תוכנית טוענת עותק משלה של הספריה לזיכרון). DirectX עושה שימוש בקישור סטאטי (lib), והפונקציות שבספריות הללו דואגות לקשר את התוכנית שלך לספריות הדינאמיות באופן עצמאי.
למה צריך LIB כשיש DLL -
DLL הוא ספריה מלונקג'ת דינאמית, מה שאומר שהאפליקציה מלנקג'ת את הספריה ON DEMAND, בדיוק כשרוצים את ה-DLL הזה. כדי לעשות את זה, צריך לקרוא ל-LoadLibrary כדי לקשר ל-DLL, ואח"כ לקרוא ל-GetProcAddress כדי להגיע לפונקציה מסוימת בתוך ה-DLL. זה מאוד נחמד, כי ככה בעצם אתה לא חייב לדעת אפילו את שם ה-DLL ואת שם הפונקציה כשאתה כותב את התוכנה שלך, אלא רק את ה-PROTOTYPE של הפונקציה שאתה צריך ("מקבלת שלושה פרמטרים, int, char ו-bool"). תחשוב על השימושים - אפשר לעשות plugin לתוכנה, וכו'. הבעיה היא שהעסק הנ"ל הוא מסורבל. תשווה את זה למשל לעשות include לקובץ H ולקבל את כל מה שבתוכו - אפילו אם מדובר ב-LIB, אתה יכול לעשות include ו-pragma - וזהו. בשיטה שתיארתי, אתה צריך לדעת איך הפונקציה מעוטרת (decorated) כדי לדעת מה השם המדויק שלה וכו'. ובכל זאת, יש יתרונות ב-DLL על פני LIB רגיל - היתרונות צוינו בשרשור כבר. אז כדי להקל עליך עד הסוף, באו מיקרוסופט ואמרו - אם אתה יודע איזה DLL דרוש לך, אתה יכול להתייחס אליו כאילו הוא LIB, ולקבל אוטומטית את כל היתרונות שנובעים מ-DLL. כשאתה כותב DLL ואתה מגדיר בתוכו מה מיוצא ממנו, אתה יכול לבקש מ-VS לייצר בשבילך קובץ LIB, שהוא בעצם אוסף של STUB-ים - פונקציות שכל מטרתן לקרוא לפונקציות "האמיתיות". ככה קל לך - בתור משתמש ב-DLL - להשתמש ב-DLL, אבל אתה מקבל את היתרונות שצוינו.
DLL הוא ספריה מלונקג'ת דינאמית, מה שאומר שהאפליקציה מלנקג'ת את הספריה ON DEMAND, בדיוק כשרוצים את ה-DLL הזה. כדי לעשות את זה, צריך לקרוא ל-LoadLibrary כדי לקשר ל-DLL, ואח"כ לקרוא ל-GetProcAddress כדי להגיע לפונקציה מסוימת בתוך ה-DLL. זה מאוד נחמד, כי ככה בעצם אתה לא חייב לדעת אפילו את שם ה-DLL ואת שם הפונקציה כשאתה כותב את התוכנה שלך, אלא רק את ה-PROTOTYPE של הפונקציה שאתה צריך ("מקבלת שלושה פרמטרים, int, char ו-bool"). תחשוב על השימושים - אפשר לעשות plugin לתוכנה, וכו'. הבעיה היא שהעסק הנ"ל הוא מסורבל. תשווה את זה למשל לעשות include לקובץ H ולקבל את כל מה שבתוכו - אפילו אם מדובר ב-LIB, אתה יכול לעשות include ו-pragma - וזהו. בשיטה שתיארתי, אתה צריך לדעת איך הפונקציה מעוטרת (decorated) כדי לדעת מה השם המדויק שלה וכו'. ובכל זאת, יש יתרונות ב-DLL על פני LIB רגיל - היתרונות צוינו בשרשור כבר. אז כדי להקל עליך עד הסוף, באו מיקרוסופט ואמרו - אם אתה יודע איזה DLL דרוש לך, אתה יכול להתייחס אליו כאילו הוא LIB, ולקבל אוטומטית את כל היתרונות שנובעים מ-DLL. כשאתה כותב DLL ואתה מגדיר בתוכו מה מיוצא ממנו, אתה יכול לבקש מ-VS לייצר בשבילך קובץ LIB, שהוא בעצם אוסף של STUB-ים - פונקציות שכל מטרתן לקרוא לפונקציות "האמיתיות". ככה קל לך - בתור משתמש ב-DLL - להשתמש ב-DLL, אבל אתה מקבל את היתרונות שצוינו.
LIB מול DLL
טוב אני מזמן לא מתכנת בחלונות אבל משנים של תכנות בגועל נפש הזה אני זוכר כמה דברים. LIB יכול להיות אחד משני דברים: ספריה סטטית או ספרית קישור לספריה דינמית. מה שאומר שכאשר אתה משתמש ב DLL לצורך הפיתוח אתה חייב קובץ LIB מתאים שיעשה עבורך את הקישור, במקרה הזה בקובץ LIB יהיו רק פונקציות קישור ולא הפונקציות עצמן.
טוב אני מזמן לא מתכנת בחלונות אבל משנים של תכנות בגועל נפש הזה אני זוכר כמה דברים. LIB יכול להיות אחד משני דברים: ספריה סטטית או ספרית קישור לספריה דינמית. מה שאומר שכאשר אתה משתמש ב DLL לצורך הפיתוח אתה חייב קובץ LIB מתאים שיעשה עבורך את הקישור, במקרה הזה בקובץ LIB יהיו רק פונקציות קישור ולא הפונקציות עצמן.
Allow me to retort
תכנות בלינוקס: "הרבה יותר כיף" - תגדיר כיף, כדבר אובייקטיבי, ונמשיך את הדיון. "הרבה יותר אתגרי" - למה? וחוץ מזה, "אתגר" זה גם יכול להיות "האתגר בלמצוא איך להכניס איבר ל-TREE ב-QT". זה לא אומר שזה דבר חיובי. "הרבה יותר תוכנות" - מה?! "הרבה יותר כלי פיתוח" - לא יודע מה איתך, אבל לי מספיק כלי פיתוח אחד. יתרה מכך, ריבוי כלי פיתוח הוא בעיה חמורה, שאומר למעשה שאף אחד מהם אינו בשל באמת (מה שנכון בלינוקס). "הרבה יותר דוגמאות" - אתה בטוח? יש מעט מאוד ספרים ואתרים על תכנות בלינוקס. רובם מסתמכים על ספרי תכנות ביוניקס, שברובם אינם עדכניים לדברים החמים ביותר (NPTL, Futexes, והרשימה עוד ארוכה). קוד פתוח הוא לא בהכרח קוד שכדאי ללמוד ממנו. דוגמאות שליליות הן עוד יותר גרועות מחוסר דוגמאות. "והכי חשוב קהילה שכיף להיעזר בה" - כמות התוכניתנים ב-WINDOWS עולה בהרבה על כמות התוכניתנים בלינוקס, והסיכוי שתמצא גורו ב-WINDOWS הוא גדול עשרות מונים מהסיכוי שתמצא גורו בלינוקס. אז אוקיי, יש פה (בפורום לינוקס) מספר גורואים כמו מוליקס, אבל בפורום שלנו פה יש עוד יותר גורואים ל-WINDOWS. אוסיף ואומר שכיף לי לעבוד על לינוקס, ללא ספק. זה עולם חדש שפשוט כיף לי לחקור אותו. אבל מכאן ועד לומר שתכנות בלינוקס הוא הרבה יותר כיף מתכנות ב-WINDOWS זה כבר פשוט עניין של טעם (מאזוכיסטי לטעמי). לכל מערכת הפעלה יש את היתרונות והחסרונות שלה כשזה מגיע לתכנות. אל תיתן לדעה הכללית שיש לך על $M לעוות לך את מאזני הצדק האובייקטיביים.
תכנות בלינוקס: "הרבה יותר כיף" - תגדיר כיף, כדבר אובייקטיבי, ונמשיך את הדיון. "הרבה יותר אתגרי" - למה? וחוץ מזה, "אתגר" זה גם יכול להיות "האתגר בלמצוא איך להכניס איבר ל-TREE ב-QT". זה לא אומר שזה דבר חיובי. "הרבה יותר תוכנות" - מה?! "הרבה יותר כלי פיתוח" - לא יודע מה איתך, אבל לי מספיק כלי פיתוח אחד. יתרה מכך, ריבוי כלי פיתוח הוא בעיה חמורה, שאומר למעשה שאף אחד מהם אינו בשל באמת (מה שנכון בלינוקס). "הרבה יותר דוגמאות" - אתה בטוח? יש מעט מאוד ספרים ואתרים על תכנות בלינוקס. רובם מסתמכים על ספרי תכנות ביוניקס, שברובם אינם עדכניים לדברים החמים ביותר (NPTL, Futexes, והרשימה עוד ארוכה). קוד פתוח הוא לא בהכרח קוד שכדאי ללמוד ממנו. דוגמאות שליליות הן עוד יותר גרועות מחוסר דוגמאות. "והכי חשוב קהילה שכיף להיעזר בה" - כמות התוכניתנים ב-WINDOWS עולה בהרבה על כמות התוכניתנים בלינוקס, והסיכוי שתמצא גורו ב-WINDOWS הוא גדול עשרות מונים מהסיכוי שתמצא גורו בלינוקס. אז אוקיי, יש פה (בפורום לינוקס) מספר גורואים כמו מוליקס, אבל בפורום שלנו פה יש עוד יותר גורואים ל-WINDOWS. אוסיף ואומר שכיף לי לעבוד על לינוקס, ללא ספק. זה עולם חדש שפשוט כיף לי לחקור אותו. אבל מכאן ועד לומר שתכנות בלינוקס הוא הרבה יותר כיף מתכנות ב-WINDOWS זה כבר פשוט עניין של טעם (מאזוכיסטי לטעמי). לכל מערכת הפעלה יש את היתרונות והחסרונות שלה כשזה מגיע לתכנות. אל תיתן לדעה הכללית שיש לך על $M לעוות לך את מאזני הצדק האובייקטיביים.
ננסה להסביר
קודם כל כיף הוא דבר סוביקטיבי, אני אישית מאד נהנה מזה. הרבה יותר תוכנות זה עניין אוביקטיבי אני מכיר המון תוכנות להמון מטרות בלינוקס בעוד בחלונות לכל מטרה יש בדרך כלל תוכנה אחת, הדבר המדהים הוא שלמטרות המקובלות ביותר יש בדרך כלל מבחר מצומצם יותר של תוכנות במקום שיהיה ההפך. הרבה כלי פיתוח זה דבר חשוב מאד מאחר ולכל כלי היתרונות שלו, אני מעדיף שיהיה לי מבחר של כלים לבחור מהם. הרבה יותר דוגמאות זה מאד פשוט, הרי הקוד הוא פתוח ולכן כל אחת מתוכנות המערכת היא דוגמה בפני עצמה. מאחר ויש כל כך הרבה הסברים ברשת וכל כך הרבה דוגמאות מימי לא נזקקתי לספרים ולכן איני יודע לגבי עדכניות שלהם. קוד פתוח הוא בהחלט דבר שכדאי ללמוד ממנו, הרי אדם שפותח את הקוד לא יעשה זאת עם תכנה שכתובה גרוע. מעבר לכך אם אתה מסתכל על קוד כמו של לינוקס עצמו אז אני באמת לא מבין על מה אתה מדבר קוד שלא כדאי ללמוד ממנו. אם אתה מסתכל על הקוד של GNOME גם כן לא ברור לי למה לא ללמוד ממנו. לגבי תכניתנים ללינוקס מצאתי בעולם הרבה יותר תכניתנים ללינוקס שעזרו לי מאשר אי פעם בחלונות וכן פיתחתי די הרבה שנים בחלונות. היה מאד כיף להעזר בתכניתנים מכל העולם כולל בארץ. נכון, הזכרת את מולי כן הוא אחד הטובים בארץ בתכנות לקרנל אבל הוא לא היחיד שיודע לתכנת ללינוקס בארץ יש עוד רבים כמוהו. קהילת הלינוקס בארץ ובעולם מאד אוהבת לעזור לכן כתבתי "קהילה שכיף להעזר בה" גורואים ב windows בהחלט יש אבל תמיד תמיד יחסר להם משהו ולא כי הם לא טובים, הם טובים מאד אבל... הם חסומים בקיר של הקוד שאינו פתוח בפניהם. האמת צריך מאד להעריך אותם שלמרות שהקוד חסום בפניהם הם מצליחים להגיע לרמה גבוהה.
קודם כל כיף הוא דבר סוביקטיבי, אני אישית מאד נהנה מזה. הרבה יותר תוכנות זה עניין אוביקטיבי אני מכיר המון תוכנות להמון מטרות בלינוקס בעוד בחלונות לכל מטרה יש בדרך כלל תוכנה אחת, הדבר המדהים הוא שלמטרות המקובלות ביותר יש בדרך כלל מבחר מצומצם יותר של תוכנות במקום שיהיה ההפך. הרבה כלי פיתוח זה דבר חשוב מאד מאחר ולכל כלי היתרונות שלו, אני מעדיף שיהיה לי מבחר של כלים לבחור מהם. הרבה יותר דוגמאות זה מאד פשוט, הרי הקוד הוא פתוח ולכן כל אחת מתוכנות המערכת היא דוגמה בפני עצמה. מאחר ויש כל כך הרבה הסברים ברשת וכל כך הרבה דוגמאות מימי לא נזקקתי לספרים ולכן איני יודע לגבי עדכניות שלהם. קוד פתוח הוא בהחלט דבר שכדאי ללמוד ממנו, הרי אדם שפותח את הקוד לא יעשה זאת עם תכנה שכתובה גרוע. מעבר לכך אם אתה מסתכל על קוד כמו של לינוקס עצמו אז אני באמת לא מבין על מה אתה מדבר קוד שלא כדאי ללמוד ממנו. אם אתה מסתכל על הקוד של GNOME גם כן לא ברור לי למה לא ללמוד ממנו. לגבי תכניתנים ללינוקס מצאתי בעולם הרבה יותר תכניתנים ללינוקס שעזרו לי מאשר אי פעם בחלונות וכן פיתחתי די הרבה שנים בחלונות. היה מאד כיף להעזר בתכניתנים מכל העולם כולל בארץ. נכון, הזכרת את מולי כן הוא אחד הטובים בארץ בתכנות לקרנל אבל הוא לא היחיד שיודע לתכנת ללינוקס בארץ יש עוד רבים כמוהו. קהילת הלינוקס בארץ ובעולם מאד אוהבת לעזור לכן כתבתי "קהילה שכיף להעזר בה" גורואים ב windows בהחלט יש אבל תמיד תמיד יחסר להם משהו ולא כי הם לא טובים, הם טובים מאד אבל... הם חסומים בקיר של הקוד שאינו פתוח בפניהם. האמת צריך מאד להעריך אותם שלמרות שהקוד חסום בפניהם הם מצליחים להגיע לרמה גבוהה.
Copyright©1996-2021,Tapuz Media Ltd. Forum software by XenForo® © 2010-2020 XenForo Ltd.