עבודה עם קבצים

קבצים הם משאב מערכת בדומה לזיכרון ולכן:

• צריך לפתוח קובץ לפני השימוש בו
• צריך לסגור קובץ בסוף השימוש בו
• אותן בעיות אשר צצות מניהול זכרון לא נכון עלולות לצוץ מניהול קבצים לא נכון

בדומה לעבודה עם הקלט והפלט הסטנדרטיים, קריאה וכתיבה מקבצים מתבצעת באמצעות $stream$-ים המוגדרים בספריה $fstream$.

• המחלקה $ofstream$ משמשת לכתיבה לקובץ
• המחלקה $ifstream$ משמשת לקריאה מקובץ

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

כתיבה וקריאה מתבצעות ע"י שימוש ב-$<<$ ו-$>>$ בדומה לקלט והפלט הסטנדרטיים ושאר הפעולות על ערוצי הפלט והקלט מתבצעות כשיטות(מטודות) של המחלקות. (למשל השיטה $eof()$ מחזירה האם הגענו לסוף הקובץ)

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

#include <fstream>
using namespace std;

int main()
{
	ofstream name("output.txt");
	name << "Hello, World!" << endl;
	return 0;
}

#include <fstream>

int main(int argc, char** argv)
{
	if (argc < 3)
	{
		cerr << "Not enough arguments..." << endl;
		return 1;
	}
	
	ifstream inFile(argv[1]);
	ofstream outFile(argv[2]);
	string s;
	
	while (!in_file.eof())
	{
		getline(in_file, s);
		out_file << s << endl;
	}
	
	return 0;
}

חלוקה למודולים

אורך החיים של הקוד יכול להיות עשרות שנים ולאורך תקופה זו יש לתחזק את הקוד:

• לתקן באגים
• להכניס תכונות חדשות
• להתאים להתקנים חדשים

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

בתכנות מודלרי אנו מחלקים את הקוד למודולים לפי תפקידם. זה מאפשר:

1. שימוש חוזר במודולים עבור תוכנות אחרות
2. הסתרת פרטי מימוש
3. הקטנת התלות בקוד עצמו

המודול

מודול תוכנה מחולק לשני חלקים: הממשק והמימוש.

הממשק ($interface$):

• מגדיר את הפעולות שניתן לעשות בעזרת המודול
• חלק זה חשוף למשתמש במודול

המימוש ($implementation$):

• מספק את המימוש לפעולות שניתן לבצע דרך ממשק המודול
• חלק זה (בדרך כלל) אינו חשוף למשתמש

ב-$C++$ הדרך בה אנו בונים מודול הוא באמצעות שני סוגי קבצים: קבצי $cpp$ וקבצי $h$.

קובץ $h$ יכל את הממשק:

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

קובץ $cpp$ יכיל את מימוש המודול:

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

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

#pragma once

struct vector2D
{
	double x;
	double y;
};

const vector2D zero_vector = {0, 0};

double length(const vector2D& v);

#include <cmath>
#include "vector2d.h"

using namespace std;

static double dot_product(const vector2D& v1, const vector2D& v2)
{
	return (v1.x * v2.x) + (v1.y * v2.y);
}

double length(const vector2D& v)
{
	return sqrt(dot_product(v, v));
}

הידור של מספר קבצים

כדי להדר מספר קבצים ניתן פשוט לרשום את כל הקבצים כפרמטרים לשורת הפקודה של $g++$:

g++ a.c b.c mytest.c

את ההידור ניתן לחלק לשלושה שלבים:

1. עיבוד מקדים - $Preprocessing$
2. הידור - $Compilation$
3. קישור - $Linking$

​

1. עיבוד מקדים

שלב העיבוד המקדים עור על קובץ הקוד ומבצע את ההוראות עבור ה-$preprocessor$ שהן כל השורות המתחילות ב-$\#$.
פעולות העיבוד המקדים הן כולן פעולות גזירה והדבקה פשוטות.

הגדרת מאקרו

#define <macro> <value>

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

הוספת תוכן קובץ

#include <filename>

מוסיף את תוכן הקובץ לתוך הקוד במיקום הנוכחי.

• הקוד שמתווסף עובר גם הוא עיבוד מקדים
• אם שם הקבוץ מופיע בתוך $<>$ ההתייחסות היא לקובץ מהספריה הסטנדרטית
• אם שם הקובץ מופיע במרכאות " " ההתייחסות היא לקובץ שנמצא עם שאר הקוד שכתבנו

2. הידור

שלב ההידור מקבל קבצי קוד מקור שעברו את העיבוד המקדים. הוא עדיין לא מקבל קבצי $h$ אלא רק קבצי $cpp$ (אשר אליהם הודבקו קבצי ה-$h$ בעיבוד המקדים)

לכל קובץ נוצר קובץ בינארי אשר מכיל את הקוד המהודר מקובץ הקוד. לקובץ זה קוראים object file ויומתו היא $.o$
ייתכן וחלק מהפונקציות שהוכרזו לא מומשו בקובץ הנוכחי ולכן קובץ ה-$object$ יכיל "חורים"

3. קישור

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

ייתכנו שגיאות בשלב זה הנקראות שגיאות קישור:

• לא נמצא מימוש עבור פונקציה מסויימת: a.c:11: undefined rerfence to 'my_function'
• נמצא יותר ממימוש אחד עבור פונקציה מסויימת:

  a.c:10: multiple definition of 'main'
  b.c:10: first defined here
  

בקישור של קובץ הרצה, רק אחד הקבצים צריך להכיל הגדרה של פונקציית $main$.

פונקציות סטטיות גלובליות

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

static int square(int n)
{
	return n * n;
}

וידוא הנחות בזמן ריצה

ישנו המקרו $assert$ אשר מאפשר לנו בזמן בדיקה בלבד לבדוק האם יש בעיות בקוד שלנו.

assert(<expression>);

המאקרו מוגדר בספרייה <cassert> ובזמן הריצה הביטוי מוערך ונבדק:

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

ניתן לכבות את המקרו $assert$ ע"י הידור התכנית עם הדגל -DNDEBUG. כך ניתן לשחרר גרסה סופית של הקוד שאינה מואטת ע"י הבדיקות ללא הסרתן ידנית.

מתי משתמשים ב-$assert$

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

לא משתמשים ב-$assert$ כדי לבדוק קלט מהמשתמש או עבור בדיקות שרוצים שיתבצעו גם בתוכנית הסופית.