דרוש תרגום ל-STL

[אלדד28]

דרוש תרגום ל-STL

איך אני עושה את זה בעזרת אלגוריתם?

for (unsigned i = 0; i < m_nLength; i++) m_pArray &= other.m_pArray;​

 

[annefan]

transform

כיוון שזה לא שיעורי בית...

#include <iostream> #include <algorithm> #include <vector> using namespace std; int bitand(int a, int b) { return a&b; } void print (int elem) { cout << elem << ' '; } int main() { vector<int> array1; vector<int> array2; vector<int> dest; dest.reserve(4); array1.push_back(1); array1.push_back(2); array1.push_back(3); array1.push_back(4); array2.push_back(1); array2.push_back(1); array2.push_back(1); array2.push_back(1); transform(array1.begin(), array1.end(), array2.begin(), array1.begin(), bitand); for_each(array1.begin(), array1.end(), print); return 0; }​

 

[eyalbd]

עדיף functor ע"פ פונקציה

struct BitAnd { int operator() (int a, int b) { return a & b; } };​

ולגבי ההדפסה אין צורך בפונקציה print אלא ב ostream_iterator:

copy(v1.begin(), v1.end(), ostream_iterator<int>(" "));​

 

[annefan]

לגבי הראשון אני לא בטוח

לגבי השני, אני כל הזמן שוכח אותו... תודה

 

[אלדד28]

אוקיי, תודה.

חשבתי שאולי אני אצא מזה בזול, בלי FUNCTOR

את transform אני מכיר, אבל רציתי איזו שורה אחת יפה שתחליף את ה-for ההוא שם. נו מילא

תודה!

 

[yoash17]

מה אם FOR_EACH ?

מה אם FOR_EACH ? לא קיים מושג כזה ?

 

[אלדד28]

יש, אבל הוא עוד יותר בעייתי,

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

 

[חובבן]

תעבור ל LISP

נידמה לי שב #C הבאה עלינו לטובה (גירסא 2) יהיה ניתן לעשות זאת ביותר קלות.

 

[אלדד28]

חחחחחחחחחחחחח

חזק, חזק, אין ספק

 

[barakbl]

תראה, אם היית יודע LISP טוב אולי

לא היית מזלזל כל כך ב EMACS, עורך הטקסט הטוב בעולם מבחינת רבים וטובים

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

 

[אלדד28]

תגובתי לא הייתה כלפי LISP

אלא כלפי $C. 1. LISP שפה מצוינת 2. אני דווקא כן מכיר אותה, כמו כל חובב AI ראוי לשמו 3. לא יודע מה הקשר ל-EMACS אבל אני מעדיף VI

 

[חובבן]

אז ככה

1. בקשר ל EMACS, זה לא עורך. זאת תוכנית C קטנה יחסית שמריצה לולאת ביצוע של LISP. למעשה זה מזכיר מערכת הפעלה. כל מה שניראה כמו EMACS, כמו buffers, frames, modes וכו' הן למעשה חבילות LISP חיצוניות. מכיוון שקל להוסיף, לשנות ולקמפל קוד LISP, ה"עורך" מהווה כר אין סופי לתוספות ושינויים. 2. אני מתייחס לגירסא הבאה של #C שמתוארת כאן. בין השאר היא כוללת גירסא משלה ל templates ו unname function בצורה שהיא טובה לפחות כמו (וכנראה יותר) ממה שיש ב ++C.

 

[אלדד28]

נמשיך...

1. אוקיי, יפה, לא ידעתי

2. זה ממש לא משנה מה היכולות הסינטקטיות של השפה - מה שחשוב זה שהיא לא מהירה כמו NATIVE CODE. אגב, שמעתי שב-LONGHORN הולכת MICROSOFT לעשות ככה שקוד של #C ירוץ ב-130% מהמהירות של NATIVE CODE. =============> MICROSOFT הולכים להאט במכוון כל טכנולוגיה אחרת מ - $C. לא ייאמן.

 

[barakbl]

לא נשמע הגיוני.

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

 

[אלדד28]

המספר הזה

הוא פרסום של מיקרוסופט. עכשיו בוא נעשה 1+1 ביחד - קוד NATIVE רץ ישירות מול מערכת ההפעלה, ואילו קוד $C צריך לרוץ בתוך הסביבה המוגנת שלו. אם נמשיך בתרגום, קוד פשוט של $C צריך לעשות יותר פעולות מקוד NATIVE. ==> הדרך היחידה להבטיח שקוד MANAGED ירוץ יותר מהר מקוד NATIVE היא להאט בכוונה תחילה את קוד ה-NATIVE. ולגבי מה שאתה אומר, זה נכון, תיאורטית, אבל אתה שוכח שמדובר ב-MICROSOFT - חברה שאינה בוחלת באמצעים כדי לקדם את מטרותיה. משמעות הדבר היא שאוקיי, ברק ינופף בידיו ויצעק ש-LONGHORN יותר איטית מ-XP לרוב האפליקציות, אבל אז יבואו MS ויגידו שזה לא בדיוק ככה וחוץ מזה אפשר לכתוב ב-$C שתהיה הרבה יותר מהירה, "בטוחה", יעילה וכו'. בקיצור, כולי תקווה שהחברה הזו תושפל עד עפר ומוטב מוקדם ממאוחר. הם פשוט עוברים כל גבול אפשרי.