C и C++ различия - пример
почти академический пример , хоть в учебник его ..
Чтение файла и вывод содержимого на экран
На С - в файле число 4
#include<stdio.h>
int main()
{
int x;
FILE *pf=NULL;
if ((pf=fopen("do.txt","rb"))!=NULL)
{
fscanf(pf,"%d",&x);
printf("x=%d",x);
fclose(pf);
}
else printf( "Problem opening the file\n" );
return 0;
}
причем double она не читает , а читает float
надо признать этот пример не сходу и напишешь
так как все остальные fgets fgetc fread и проч и проч читают символы, а не числа!!
Теперь пример на С++
#include<fstream>
#include<iostream>
using namespace std;
ifstream infile("input.txt",ios_base::in);
void main()
{
if(!infile)
{
cerr<<"Cann't open file";
}
else
{
double num;
infile >> num;
cout << num;
}
}
гениально ! причем пофиг double int char float
просто переписываешь тип num и все !
Так что товарищи студенты учите С++ и классы
они облегчат вам жизнь :)
Вот мои рассуждения.
<skip>
В твоем действии как минимум три действующих лица:
Заказчик (пользователь), программист и ЭВМ.
Заказчику нужна программа, которая в первую очередь делает то, что ему надо, а во вторую - как можно быстрее. Что именно должна делать программа заказчик в большинстве случаев до конца и сам не знает, а уж темболее как она это должна делать.
Программист хочет удовлетворить желания заказчика. При этом он толком не знает, что именно это за желания потому, что и сам заказчик этого до конца не знает, и в процессе общения заказчик не может выразить конкретно свое желание словами (типа "хочу чтоб было красиво").
ЭВМ абсолютно пофиг, она ничего не хочет.
Теперь рассмотрим процесс разработки, но представим, что мы строим самолет. Что мы сделаем первым делом? Узнаем общие и уточненные (по возможности) желаемые характеристики. Далее мы, как ты наверное понимаешь, не будем клепать самолет, а начнем с изучения различных аспектов: подумаем над профилем и длинной крыла, тягой двигателей и т.п.
При этом мы будем строить малюсенькие макеты и продувать их в трубе, ломать, рвать, бросать и в большинстве случаев выбрасывать на свалку, пока не найдем что-то более-менее подходящее (но не идеальное, об этом мы уже говорили). Эту модельку, пока еще нелетающую, но очень красиво раскрашенную мы покажем заказчику. Допустим она ему в основном понравится, а может и нет, тогда мы опять будем рвать, бросать, обдувать и т.д.
Далее мы построим опытный образец, будем его испытовать и доводить, дорабатывать напильником, пока он не полетит. Потом мы покажем его заказчику. Заказчик скажет, что это не совсем то, что он хотел, и мы либо поработаем напильником над тем, что есть, либо опять идем к нашим игрушечным самолетам.
В конце концов мы втюхаем наше создание заказчику, даже убедим его, что он доволен.
Смысл всего этого повествования: разработка - процесс итеративный, с постоянным поиском и переработкой.
Думаю, не нужно довазывать, что чем больше моделек мы построим и испытаем, тем наш самолет будет лучше?
Вернемся к программированию. Здесь процесс в принципе не отличается от авиастроения, вот только модель программы - это сама программа.
Надеюсь, ты уже не будешь спорить, что писать программу, доводить её и модифицировать легче на языках высокого уровня (они собственно для того и созданы). Получается, то мы сможем сделать больше моделек и испытать их. И в конечном итоге они будут надежнее, быстрее и меньше, чем однажды созданная модель на ассемблере.
Теперь перейдем к заказчику. Получается, что он косвенно заинтересован в ЯВУ (языке высокого уровня), т.к. он хочет по-быстрее посмотреть что же получается, и он заинтересован в конечном продукте.
Что же касается ЭВМ, то ей пофиг. Зачастую ассемблеровский код получается более массивным, трудноповоротливым и медленным, чем его ЯВУ аналог.
Еще раз повторю: ассемблер на реальных проектах не дает выигрыша по памяти и скорости, но при этом однозначно проигрывает в скорости разработки.
Потому что разработка - процесс ИТЕРАЦИОННЫЙ.
Теперь, добавим в этот алгоритм всего-лишь вывод
Ну это совсем неправильно. Вывод на экран ни как не относится к бизнесс-логике. Это надо уметь разделять.
Как раз потому, что еще существуют подобные рассуждения, нет даже попыток сделать объектный процессор.
А нафига он нужен. ООП нужен программисту, а не процессору.
Вот, впрочем, читал, что бывали времена и люди неделю сидели ночами оптимизируя и без того оптимизированый ассемблерный код, что-бы в конце-концов уменьшить его размер на один байт.
И называлось это "шаманством", а люди были счастливые, ибо времени у них было до-пупа.
А сейчас всем пофиг на ресурсы? Лозунг практически всех програмеров и контор?
Ты знаешь размер оперативки у Sony PS2?
32Mb
Криво написанные проги надо переписывать, только кто этим займется?
Конкретно, я этим занимаюсь.
И кому, как ни мне знать, что в процессе рефакторинка какого-нибудь старого кода оптимизированного до полной нечитабельности получается стройный код, из которого убрано столько мусора, что он начинает бегать раза в три быстрее, не смотря на то, что теперь он написан на С++, а не на связке С и ассемблер.
Хорошо. Представим себе - есть программа. Размер програмки ХХХ байт, скорость выполнения УУУ секунд для самого плохого случая. Програмка, которая выдает такие же выходные даные, как и эта при заданых одних и тех же входных даных будет оптимальней первой если:
-она занимает не больше ХХХ-1 байт или
-выполняется не дольше чем УУУ-1 секунд.
Поправьте меня, если я не прав. Но, я понимаю это так.
Поправляю. Код занимает ХХХ байт. Урезаю статически отведенный буфер на 100 байт. Получаю код размером ХХХ-100байт. По твоему определению это оптимальный код, но на самом деле далеко не так.
Программирование очень многоплановая и многоуровневая отрасль деятельности человека и его как Россию "простым аршином не измерить". У тебя слишком примитивные критерии оптимальности. И истекают они именно из asm-а. Это вообще стремление всех, кто программирует на asm. Сводить все к мифической оптимальности программ на asm-е, используя очень примитивные критерии.
В твоем действии как минимум три действующих лица:
<skip>
Ого, мыслишь как прожект менеджер. Кстати я и не спорил с тем что на языках высокого уровня ЛЕГЧЕ разрабатывать приложения.
Ну это совсем неправильно. Вывод на экран ни как не относится к бизнесс-логике. Это надо уметь разделять.
Нет, но относится к скорости выполнения проги. Например забрав в цикле строку, которая выводит на экран текущий прогрес приложения мы можем секономить очень много процессорного времени.
А нафига он нужен. ООП нужен программисту, а не процессору.
ГЫ. Наверное, чтоб програмисты еще больше обленились и процес програмирования сводилсяк такому или похожему коду:
-создать клас ххх
-вызвать методы yyy,zzz класса ххх
-удалить клас
Где клас пришлось описывать уже не програмистам а разработчикам процов, аппаратно :)
И называлось это "шаманством", а люди были счастливые, ибо времени у них было до-пупа.
И кому это все мешало?
Конкретно, я этим занимаюсь.
И кому, как ни мне знать, что в процессе рефакторинка какого-нибудь старого кода оптимизированного до полной нечитабельности получается стройный код, из которого убрано столько мусора, что он начинает бегать раза в три быстрее, не смотря на то, что теперь он написан на С++, а не на связке С и ассемблер.
Ну, батенька, это уже кто какой код пишет...
Поправляю. Код занимает ХХХ байт. Урезаю статически отведенный буфер на 100 байт. Получаю код размером ХХХ-100байт. По твоему определению это оптимальный код, но на самом деле далеко не так.
Позвольте возразить: статически отведенные буфера никто не удаляет, их просто резервируют на максимально нужный размер и не байтом больше.
Программирование очень многоплановая и многоуровневая отрасль деятельности человека и его как Россию "простым аршином не измерить". У тебя слишком примитивные критерии оптимальности. И истекают они именно из asm-а. Это вообще стремление всех, кто программирует на asm. Сводить все к мифической оптимальности программ на asm-е, используя очень примитивные критерии.
Хм, с этим не поспоришь...
Ого, мыслишь как прожект менеджер.
Ну, собственно, чем и занимаюсь.
Кстати я и не спорил с тем что на языках высокого уровня ЛЕГЧЕ разрабатывать приложения.
Что значит "легче"?
Прям как в анекдоте: "Кто самый сильный шахматист? Ответ: Майк Тайсон."
Использование ООП делает процесс разработки не "легким", а более эффективным.
ГЫ. Наверное, чтоб програмисты еще больше обленились
Не обленились, а тратили свое время на реальные задачи. "Время - деньги", слышал наверное такое выражение.
И кому это все мешало?
Бизнесу. Конкуренция, прогресс..
Ты, просто, пока не являешься профессиональным программистом и тебе трудно это принять.
(Справка: профессонал - человек, который в отличие от любителя занимается каким-либо делом, как специалист, владеющий профессией, и зарабатывающий этой профессией.)
Ну, батенька, это уже кто какой код пишет...
Вернемся к баранам...
Используя ООП получается более структурированный, понятный, модернизируемый и повторноиспользуемый код.
Ты пойми, что затачиваясь на ассемблер ты отсекаешь себя от реального программирования. То что ты приводишь примеры - это любительство или "академическое программирование", далекое от реального представления дел. Ты просто не можешь пока представить какой огромный пласт знания и навыков лежит над ООП. ООП - это лишь имплементационная база более глобальных вещей, которыми оперирует программист. Я говорю сейчас о OOA&D. Современный программмист оперирует несколько более глобальными понятиями, чем класс. Например, моделями, паттернами и т.д.
Общаясь с программистами, я не оперирую понятиями "буфер", "байт" и т.п., это слишком примитивно. Обсуждение идет на уровне шаблонов проектирования.
Что значит "легче"?
Прям как в анекдоте: "Кто самый сильный шахматист? Ответ: Майк Тайсон."
Легче, значит быстрее, не напрягая лишний раз мозги...
Бизнесу. Конкуренция, прогресс..
Ты, просто, пока не являешься профессиональным программистом и тебе трудно это принять.
(Справка: профессонал - человек, который в отличие от любителя занимается каким-либо делом, как специалист, владеющий профессией, и зарабатывающий этой профессией.)
Ну, есс-но. Во-первых я только студент, заканчиваю 3 курс. А во вторых в нашем городе никому ничего кроме веба не надо, никаких серьезных проэктов. А через нет я искать не пробовал. То что мне под силу - на том опыт не заработаешь. А то что одному не под силу - так не с кем програмить. Вот и ушел в асму...
Вернемся к баранам...
Используя ООП получается более структурированный, понятный, модернизируемый и повторноиспользуемый код.
Ты пойми, что затачиваясь на ассемблер ты отсекаешь себя от реального программирования. То что ты приводишь примеры - это любительство или "академическое программирование", далекое от реального представления дел. Ты просто не можешь пока представить какой огромный пласт знания и навыков лежит над ООП. ООП - это лишь имплементационная база более глобальных вещей, которыми оперирует программист. Я говорю сейчас о OOA&D. Современный программмист оперирует несколько более глобальными понятиями, чем класс. Например, моделями, паттернами и т.д.
Общаясь с программистами, я не оперирую понятиями "буфер", "байт" и т.п., это слишком примитивно. Обсуждение идет на уровне шаблонов проектирования.
Ну ясное дело, что до байт никто не будет опускаться. Я вот к примеру начал читать книгу, которую ты мне порекомендовал - Александреску. Довольно интересно. Вспоминаю Гради Буч.Нам по нем С читали. Все же лезть вглубь тоже интересно. Чем глубже в асм тем лучше представляешь как работает любая прога. А чем больше углубляешься в ООП, тем меньше это тебя интересует. Ясное дело, что это по потребностям рынка. Нужен код за минимальное время, платят бабки и чихать как он там выполняется. Главное, что он спроектирован, разработан, реализован, портируемый и работает...
А не приведет ли эта вся абстракция к тому, что програмировать сможет каждый второй, если не первый?
А не приведет ли эта вся абстракция к тому, что програмировать сможет каждый второй, если не первый?
Обязательно приведёт, причём довольно скоро. На ваш век, Dart Bobr, точно не хватит.
Так что тем, кто не хочет изо дня в день "точить одни и те же гайки", надо двигаться в сторону, в которую указывает Green: шаблоны проектирования, управление проектом, объекты, CASE-технологии, базы данных и т.д. и т.п. Там надо море знаний.
Как говорил один мой знакомый — талантливейший программист — «это вам не код гнать, тут думать надо» ;)
Как говорил один мой знакомый — талантливейший программист — «это вам не код гнать, тут думать надо» ;)
5 баллов... по себе знаю - кодить могу, а вот как доходит до программирования - мозгов не хватает. потому и ушел в админы :)
5 баллов... по себе знаю - кодить могу, а вот как доходит до программирования - мозгов не хватает. потому и ушел в админы :)
Так скоро дойдет до массового использования графических языков програмирования...
Так скоро дойдет до массового использования графических языков програмирования...
Эта тема уже обсуждалась. Если интересно, пойдите сюда и найдите слово "токаря". Если отбросить эмоции, то в обсуждении можно найти много нетривиальных мыслей.
Гм. Еще скажи, что ОО-ассемблер пишешь. :D
Слушай, а ты masm32 то видел? там между прочим специальный пакет для ООП на асме, с несколькими неплохими примерами, скачай - пордйся.
скачай - пордйся.
Мне лично он на фиг не нужен. Есть просто три идеи, постоянно будоражащие умы "продвинутых начинающих":
- разработка собственной ОС
- разработка собственного компилятора
- разработка собственного языка программирования
По последнему пункту чаще курят "гибрид ассемблера и ЯВУ" и "ОО-ассемблер". :D
Мне лично он на фиг не нужен. Есть просто три идеи, постоянно будоражащие умы "продвинутых начинающих":
- разработка собственной ОС
- разработка собственного компилятора
- разработка собственного языка программирования
По последнему пункту чаще курят "гибрид ассемблера и ЯВУ" и "ОО-ассемблер". :D
угу... постоянно является очередной "мессия", который считает, что уж он то... надоело. а сами пишут с ошибками :)
Мне лично он на фиг не нужен. Есть просто три идеи, постоянно будоражащие умы "продвинутых начинающих":
- разработка собственной ОС
- разработка собственного компилятора
- разработка собственного языка программирования
По последнему пункту чаще курят "гибрид ассемблера и ЯВУ" и "ОО-ассемблер". :D
ГЫ. Значит я уникал. Меня всегда интересовал вопрос о написании вирусов. :)
Слушай, а ты masm32 то видел? там между прочим специальный пакет для ООП на асме, с несколькими неплохими примерами, скачай - пордйся.
Вещь неплохая, особенно в редакции Hutch'a. Только на продукте сием тяжелая печать Баала. :)
ГЫ. Значит я уникал. Меня всегда интересовал вопрос о написании вирусов. :)
Да нет, просто, Freeman забыл эту "идею" указать, как и идею написания своей "игрухи".
Freeman забыл эту "идею" указать, как и идею написания своей "игрухи".
Это уже не курят, это пьют. :D Залпом, иначе не вставляет.