double x;
scanf("%lg", &x);
printf("%lg", x);
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 и все !
Так что товарищи студенты учите С++ и классы
они облегчат вам жизнь :)
почти академический пример , хоть в учебник его ..
Чтение файла и вывод содержимого на экран
На С - в файле число 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 и все !
Так что товарищи студенты учите С++ и классы
они облегчат вам жизнь :)
Цитата:
Originally posted by bytez
надо признать этот пример не сходу и напишешь
надо признать этот пример не сходу и напишешь
Т.е? Ничего сложного в нем не вижу, или вы считаете за сложное сделать форматированный ввод-вывод данных?
Цитата:
Originally posted by bytez
так как все остальные fgets fgetc fread и проч и проч читают символы, а не числа!!
так как все остальные fgets fgetc fread и проч и проч читают символы, а не числа!!
Они читают байты, а не символы. А вот fscanf как раз воспринимает информацию в символьном виде в зависимости от заданного спецификатора формата. И выдает ее символьно, так сказать human-readable.
Кстати, для данного примера вовсе не обязательно открывать файл в двоичном режиме, я бы даже сказал, что это может породить ошибку при обработке текстовой информации.
Цитата:
Originally posted by bytez
Так что товарищи студенты учите С++ и классы
они облегчат вам жизнь :)
Так что товарищи студенты учите С++ и классы
они облегчат вам жизнь :)
Действительно, именно для этого и было придумано программирование на языках высокого уровня. Но не стоит забывать, что для каждого языка существует своя область применения.
Цитата:
Originally posted by pacific_7
Т.е? Ничего сложного в нем не вижу, или вы считаете за сложное сделать форматированный ввод-вывод данных?
Т.е? Ничего сложного в нем не вижу, или вы считаете за сложное сделать форматированный ввод-вывод данных?
А по моему примерчик очень показательный. Наглядно видно приэмущество ООП по сравнению с "классическим" стилем. И то что примерчик сам по себе не сложный, только увеличивает его наглядность.
Цитата:
Originally posted by AlexandrVSmirno
А по моему примерчик очень показательный.
А по моему примерчик очень показательный.
Про то, что он не показательный - ни кто и не говорил. Просто автор как-то так выразился, как будто написал нечто сложное, ну и в конце-концов: все же ошибка в режиме открытия файла.
Цитата:
Originally posted by AlexandrVSmirno
Наглядно видно приэмущество ООП по сравнению с "классическим" стилем.
Наглядно видно приэмущество ООП по сравнению с "классическим" стилем.
Вообще конечно, вы правы. Но у меня свое дурацкое ИМХО на этот счет - как у незабвенного Бобра с асмом. Было время, когда меня страшил вывод данных в стиле Си - пугала функция printf() :)(спецификаторы формата там разные всякие...).
Теперь, cin/cout использую обычно только в проверочных примерах - быстрее писать. А программках побольше - через printf().
Пара хвалебных слов функции printf(): всегда понятно, какую переменную (тип) мы выводим - даже без комментариев; при выводе на экран длинных строчек в исходниках они являются более удобочитаемыми чем с применением cout.
Но, конечно, это лишь частный случай а сама тема гораздо шире.
Интересно, а как ты вообще получаешь дробный результат, читая в переменную х целого типа?!
И откуда такая уверенность, что он double не читает?!
Чтобы переменные были читабельны, надо их называть соответственно.
Лично мне намного больше по душе потоковый ввод вывод. Давненько уже не пользовался fopen
И откуда такая уверенность, что он double не читает?!
Чтобы переменные были читабельны, надо их называть соответственно.
Лично мне намного больше по душе потоковый ввод вывод. Давненько уже не пользовался fopen
Цитата:
Originally posted by viv
Интересно, а как ты вообще получаешь дробный результат, читая в переменную х целого типа?!
Интересно, а как ты вообще получаешь дробный результат, читая в переменную х целого типа?!
Да ладно вам придираться. Как я понял, в примере мы видим лишь одно из воплощений экспериментаторских мук.
Цитата:
Originally posted by viv
И откуда такая уверенность, что он double не читает?!
И откуда такая уверенность, что он double не читает?!
Хоть это вопрос и не ко мне, но: можно мне у вас узнать спецификатор формата функции fscanf() для считывания значения double в формате 2.000000e+07 например? Я что-то не знаю, если есть, то расскажите. А через потоки - это все в легкую делается.
Цитата:
Originally posted by viv
Чтобы переменные были читабельны, надо их называть соответственно.
Чтобы переменные были читабельны, надо их называть соответственно.
Это точно ко мне :) Знаете, я лично ненавижу венгерскую нотацию. Ну не нравится и все тут. А называть каждую переменну типа unsig_int_j - это помоему лишнее, особенно в таких "серьезных" программах типа приведенной в начале. Да и знаете, я в своих программах еще ри разу не запутался (хвала комментариям), но иногда приходится и в чужие исходники смотреть. А они по одному моему желанию не хотят перестраиваться в удобочитаемый вид если до этого были написаны абы как.
А вот и я :)
Насколько мне известно использование ООП может замедлить скорость выполнения программы. Поэтому в серьезных програмах, типа 3д-движки такое довольно редко наблюдается. Не берусь, конечно, утверждать, но все что я видел, было написано без ООП.
Интересно, автор зарегистрировался на форуме, только чтобы сообщить всем новость - "учите ООП" :D или есть какя-то конкретная проблема?
Насколько мне известно использование ООП может замедлить скорость выполнения программы. Поэтому в серьезных програмах, типа 3д-движки такое довольно редко наблюдается. Не берусь, конечно, утверждать, но все что я видел, было написано без ООП.
Интересно, автор зарегистрировался на форуме, только чтобы сообщить всем новость - "учите ООП" :D или есть какя-то конкретная проблема?
Цитата:
Originally posted by Dart Bobr
Насколько мне известно использование ООП может замедлить скорость выполнения программы.
Насколько мне известно использование ООП может замедлить скорость выполнения программы.
Ага, начинается!
ООП - медленно, ибо отстой, настоящие мужчины не используют Паскаль, а крутые хаЦкеры пишут на асме. Кажется, ничего не забыл.
Людям почему-то страшно нравится хаять, что они не пробовали. Всем приятно ощущать себя аналитиками, разумеется. Если бы ум и опыт также просто давались...
Ты сколько лет на Бейсике программировал, чтобы утверждать, что ООП - медленно? ООП - это стиль мышления. Любой проект должен начинаться с постановки задачи, а ООП-проект с ООП-постановки задачи.
Не видел "серьезных проектов", говоришь? А зачем сразу поспешные выводы делать? Мне, например, это говорит только об одном - мало хороших аналитиков, а среди них еще меньше - хороших постановщиков задач. Вот и пишут, как придется.
ООП давно из игрушки ученых превратилось в инструмент массовой разработки. Полноценные ООП-компиляторы, которые ты так не любишь, генерят очень даже оптимальный код. Медленным ООП может быть только в одном случае - когда постановкой начинают заниматься кривоголовые кретины от проектирования. То, что у них рождается, или к ООП вообще никакого отношения не имеет, хоть и пишется на ЯВУ с поддержкой ООП, или представляет собой "ООП ради ООП". Последнее же суть паранойя.
Знакомый как-то рассказывал, что пришлось столкнуться с проектом, в котором работа была поделена на слои. К моменту его прихода было уже не то четыре, не то пять слоев, и шла разработка шестого. Знакомый был несказанно рад, когда сбежал из этого дурдома.
Мораль проста: все проблемы - от кривых рук. И еще. "Не грози Южному Централу, попивая сок в своем квартале", т. е. не старайся выглядеть умником.
Цитата:
Originally posted by Dart Bobr
Насколько мне известно использование ООП может замедлить скорость выполнения программы.
Насколько мне известно использование ООП может замедлить скорость выполнения программы.
Что-то тоже слышал такое. Но, насколько правда - не знаю.
Цитата:
Originally posted by Dart Bobr
Интересно, автор зарегистрировался на форуме, только чтобы сообщить всем новость - "учите ООП" :D или есть какя-то конкретная проблема?
Интересно, автор зарегистрировался на форуме, только чтобы сообщить всем новость - "учите ООП" :D или есть какя-то конкретная проблема?
Он был просто в эйфорическом состоянии от своего открытия и решил поведать эту тайну всем заблудшим душам.
Цитата:
Originally posted by Freeman
Ага, начинается!
ООП - медленно, ибо отстой, настоящие мужчины не используют Паскаль, а крутые хаЦкеры пишут на асме. Кажется, ничего не забыл.
Ага, начинается!
ООП - медленно, ибо отстой, настоящие мужчины не используют Паскаль, а крутые хаЦкеры пишут на асме. Кажется, ничего не забыл.
Как эмоционально однако! Теперь заводится Freeman :D
"Ребята, давайте жить дружно!" - любимый мультик детства.
Цитата:
Originally posted by pacific_7
можно мне у вас узнать спецификатор формата функции fscanf() для считывания значения double в формате 2.000000e+07 например?
можно мне у вас узнать спецификатор формата функции fscanf() для считывания значения double в формате 2.000000e+07 например?
%lg
Код:
2
2.1
2.123e+7
2.123e-07
Цитата:
Originally posted by Dart Bobr
ООП может замедлить скорость выполнения программы.
ООП может замедлить скорость выполнения программы.
А может и ускорить, если пользоваться им грамотно.
Цитата:
Originally posted by Freeman
Ага, начинается!
...
...
...
Ага, начинается!
...
...
...
Уважаемый Freeman, перестаньте, пожалуйста, переходить на личности. Сейчас вы снова начнёте ругаться с кем-нибудь (не скажу с кем).
Извините, что сам перехожу на личности, и вообще если что не так...
Цитата:
Originally posted by Dart Bobr
Насколько мне известно использование ООП может замедлить скорость выполнения программы.
Насколько мне известно использование ООП может замедлить скорость выполнения программы.
Смотря с чем сравнивать. Если к примеру взять некоторый идеальный код, избавленный от всех излишеств, которые привносит ООП, то да,- ООП замедляет скорость выполнения.
Но такого идеального кода НЕ СУЩЕСТВУЕТ, и все, что хоть несколько сложнее "Hello world" получается на столько запутанным, что практически не поддается оптимизации. Кроме того, реализация на ассемблере займет несравнимо больше времени на разработку, отладку и тестирование.
С другой стороны при использовании ООП мы получаем результат, пусть не идеальный, но относительно очень быстро и в понятных независимых терминах. Т.о. у нас гораздо больше возможности для её оптимизации.
Получается, что за одинаковое количество человеко-часов при использовании ООП мы получаем более оптимизированную, отлаженную и устойчивую систему, а сл-но и более быструю.
Цитата:
Originally posted by Dart Bobr
Поэтому в серьезных програмах, типа 3д-движки такое довольно редко наблюдается.
Поэтому в серьезных програмах, типа 3д-движки такое довольно редко наблюдается.
Значит, не многое наблюдал, говорю тебе, как человек в последнее время профессионально занимающийся разработкой игр.
Цитата:
Originally posted by Dart Bobr
Интересно, автор зарегистрировался на форуме, только чтобы сообщить всем новость - "учите ООП" :D или есть какя-то конкретная проблема?
Интересно, автор зарегистрировался на форуме, только чтобы сообщить всем новость - "учите ООП" :D или есть какя-то конкретная проблема?
Я думаю, к человеку пришло прозрение, и он решил с нами поделиться, а может и взять на себя роль миссии. :)
Цитата:
Originally posted by Green
Смотря с чем сравнивать. Если к примеру взять некоторый идеальный код, избавленный от всех излишеств, которые привносит ООП, то да,- ООП замедляет скорость выполнения.
Но такого идеального кода НЕ СУЩЕСТВУЕТ, и все, что хоть несколько сложнее "Hello world" получается на столько запутанным, что практически не поддается оптимизации. Кроме того, реализация на ассемблере займет несравнимо больше времени на разработку, отладку и тестирование.
С другой стороны при использовании ООП мы получаем результат, пусть не идеальный, но относительно очень быстро и в понятных независимых терминах. Т.о. у нас гораздо больше возможности для её оптимизации.
Получается, что за одинаковое количество человеко-часов при использовании ООП мы получаем более оптимизированную, отлаженную и устойчивую систему, а сл-но и более быструю.
Смотря с чем сравнивать. Если к примеру взять некоторый идеальный код, избавленный от всех излишеств, которые привносит ООП, то да,- ООП замедляет скорость выполнения.
Но такого идеального кода НЕ СУЩЕСТВУЕТ, и все, что хоть несколько сложнее "Hello world" получается на столько запутанным, что практически не поддается оптимизации. Кроме того, реализация на ассемблере займет несравнимо больше времени на разработку, отладку и тестирование.
С другой стороны при использовании ООП мы получаем результат, пусть не идеальный, но относительно очень быстро и в понятных независимых терминах. Т.о. у нас гораздо больше возможности для её оптимизации.
Получается, что за одинаковое количество человеко-часов при использовании ООП мы получаем более оптимизированную, отлаженную и устойчивую систему, а сл-но и более быструю.
Полностью согласен. И вот возникает "чисто теоретичекий" вопрос. "А что же это за зверь такой - оптимальный код?". Что мы вообще под этим подразумеваем. Быстроту исполнения? Мура. В современных условиях быстродействие компьютеров и следовательно быстрота исполнения существенно разняться и не могут быть объективным критерием. Возможность исполнения на любой, даже самой слабой конфигурации ПК?. Тоже нет. Посмотрите, как от этого страдают ОС (старая флудерская тема Windows vs Unix. Но страдают здесь обе системы). Минимальное количество требуемых ресурсов? Опять мимо. Иной раз больший объем ресурсов позволяет достичь более приемлемых результатов. Ну тут еще можно много говорить. А теперь даю профиль:
По моему "оптимальный" код это код, который позволяет:
1. Достичь необходимых результатов в заданное время.
2. Наиболее точно отражает предметную область.
3. Требует на свое создание минимальеное количество человеко-часов.
4. Легко исправляем и модернизируем.
5. Экономически обоснован. Т.е. способен приносить прибыль создателю.
5. Просто красив с эстетической точки зрения.
Цитата:
Originally posted by AlexandrVSmirno
"оптимальный" код это код, который позволяет:
1. Достичь необходимых результатов в заданное время.
2. Наиболее точно отражает предметную область.
3. Требует на свое создание минимальеное количество человеко-часов.
4. Легко исправляем и модернизируем.
5. Экономически обоснован. Т.е. способен приносить прибыль создателю.
5. Просто красив с эстетической точки зрения.
"оптимальный" код это код, который позволяет:
1. Достичь необходимых результатов в заданное время.
2. Наиболее точно отражает предметную область.
3. Требует на свое создание минимальеное количество человеко-часов.
4. Легко исправляем и модернизируем.
5. Экономически обоснован. Т.е. способен приносить прибыль создателю.
5. Просто красив с эстетической точки зрения.
Yes :!!!: Именно совокупность всего этого и даёт то, что делает программу продуктом. Ещё к этому списку хочу добавить между "первым пятым" пунктом и "вторым пятым" ешё один пятый :) пункт:
5. Надёжен (при замене версий ОС и т.п.).
Именно для этого и придумывали ООП.
PS вероятно, всего этого можно достичь и без ООП, только вот очень уж трудно...
Цитата:
Originally posted by AlexandrVSmirno
По моему "оптимальный" код это код, который...
По моему "оптимальный" код это код, который...
Давайте рассуждать, как инженеры (коими многие из нас являются или вскоре будут).
Оптимальный - наиболее подходящий выдвинутым критериям.
Поэтому нельзя однозначно говорить об оптимальности кода. Код оптимальный при одном наборе критериев может быть совершенно неоптимальным при другом наборе.
Другое дело,- возможность оптимизации, т.е. способность кода быть приспособленным для конкретных критериев. В этом понятии ООП, а тем более в совокупности с OOA&D, сильно выигрывает.
Цитата:
Originally posted by AlexandrVSmirno
1. Достичь необходимых результатов в заданное время.
1. Достичь необходимых результатов в заданное время.
Наиболее применимый критерий. Согласен.
Цитата:
Originally posted by AlexandrVSmirno
2. Наиболее точно отражает предметную область.
2. Наиболее точно отражает предметную область.
Неясно, что имелось в виду.
Цитата:
Originally posted by AlexandrVSmirno
3. Требует на свое создание минимальеное количество человеко-часов.
3. Требует на свое создание минимальеное количество человеко-часов.
Это лишь расширение первого критерия.
Цитата:
Originally posted by AlexandrVSmirno
4. Легко исправляем и модернизируем.
4. Легко исправляем и модернизируем.
Этот критерий не абсолютный. Иногда им пренебрегают в силу других, более важных в конкретных случаях. Но в большинстве случаев он имеет место.
Цитата:
Originally posted by AlexandrVSmirno
5. Экономически обоснован. Т.е. способен приносить прибыль создателю.
5. Экономически обоснован. Т.е. способен приносить прибыль создателю.
Все зависит от цели. Прибыль не всегда очевидна. Например, бесплатные продукты, учебные примеры, разнообразные внутренние утилиты и инструменты, ну и просто некоммерческие проекты.
Цитата:
Originally posted by AlexandrVSmirno
5. Просто красив с эстетической точки зрения.
5. Просто красив с эстетической точки зрения.
Эстетика - понятие растяжимое. Этот пункт поглащается пунктом 4.
Цитата:
Originally posted by AlexandrVSmirno
5. Надёжен (при замене версий ОС и т.п.).
5. Надёжен (при замене версий ОС и т.п.).
Во-первых, надежность - понятие относительное. Не бывает абсолютной надежности, поэтому определяют лишь приемлемый уровень.
Во-вторых, "при замене версий ОС и т.п." - очень частный критерий. Он имеет место в основном в очень небольших проектах.
А вообщето, есть очень хорошее правило "2 из 3":
Цитата:
Быстро, дешево, надежно - выбирайте два из трех.
Цитата:
Originally posted by sq_deep
%lg
понимает в любом формате:
2
2.1
2.123e+7
2.123e-07
%lg
Код:
double x;
scanf("%lg", &x);
printf("%lg", x);
scanf("%lg", &x);
printf("%lg", x);
2
2.1
2.123e+7
2.123e-07
Действительно - туплю. fscanf - то же самое в принципе, что и scanf, следовательно - спецификаторы те же.
Green
Не берусь спорить, просто ребята от ИД софтваре не используют почему-то ООП в своих движках.
Про оптимальный код, это скорее всего не совсем точно, так как компилятор вынужден добавлять некоторую "лишнюю" информацию. То есть размер программы растет. А если растет, то и скорость ее выполнения уменьшается. Хотя я не берусь утверждать что использование ООП внесет сильно ощутимый еффект в скорость, скорее наоборот, и это есть "плата" за удобство програмирования.
Freeman
Ну, почему ты так завелся? Разве я то-то плохое сказал. Просто высказал свое наблюдение. Ничего против ООП я не имею, тем более что идеи ООП универсальны, то-есть могут использоваться в любом языке высокого или низкого уровня.
Не берусь спорить, просто ребята от ИД софтваре не используют почему-то ООП в своих движках.
Про оптимальный код, это скорее всего не совсем точно, так как компилятор вынужден добавлять некоторую "лишнюю" информацию. То есть размер программы растет. А если растет, то и скорость ее выполнения уменьшается. Хотя я не берусь утверждать что использование ООП внесет сильно ощутимый еффект в скорость, скорее наоборот, и это есть "плата" за удобство програмирования.
Freeman
Ну, почему ты так завелся? Разве я то-то плохое сказал. Просто высказал свое наблюдение. Ничего против ООП я не имею, тем более что идеи ООП универсальны, то-есть могут использоваться в любом языке высокого или низкого уровня.
Цитата:
Originally posted by Dart Bobr
Ну, почему ты так завелся?
Ну, почему ты так завелся?
Хотел показать, что тоже человек. :D
Цитата:
Ну, почему ты так завелся? Разве я то-то плохое сказал.
А разве нет? :D Асм - рулез, ООП - тормоз. По-моему, укладывается в один модельный ряд. :D
Цитата:
Ничего против ООП я не имею, тем более что идеи ООП универсальны, то-есть могут использоваться в любом языке высокого или низкого уровня.
Гм. Еще скажи, что ОО-ассемблер пишешь. :D
Цитата:
Originally posted by Freeman
А разве нет? :D Асм - рулез, ООП - тормоз. По-моему, укладывается в один модельный ряд. :D
А разве нет? :D Асм - рулез, ООП - тормоз. По-моему, укладывается в один модельный ряд. :D
Почему же тормоз, просто чуть помедленнее.
Цитата:
Originally posted by Freeman
Гм. Еще скажи, что ОО-ассемблер пишешь. :D
Гм. Еще скажи, что ОО-ассемблер пишешь. :D
:D Не, но попробую.
Цитата:
Originally posted by Dart Bobr
ребята от ИД софтваре не используют почему-то ООП в своих движках.
ребята от ИД софтваре не используют почему-то ООП в своих движках.
Никогда не был в Id Software, но абсолютно уверен, что они используют и ООП, и CASE средства (которые сегодня невозможны без ООП), и design templates (которые во многом предполагают объектный подход), и далее по всем пунктам современных технологий разработки систем. И не только программных, а любых. Иначе они не смогли бы поддерживать свой продукт в постоянно меняющемся мире на протяжении 15 лет... мир-то состоит из объектов.
Цитата:
Originally posted by Dart Bobr
Про оптимальный код, это скорее всего не совсем точно, так как компилятор вынужден добавлять некоторую "лишнюю" информацию.
Про оптимальный код, это скорее всего не совсем точно, так как компилятор вынужден добавлять некоторую "лишнюю" информацию.
Блин... ну как об стенку горох...
Ты можешь себе представить программу значительно больше и сложнее, чем "Hello world" ?
Так вот в них действуют иные законы разработки.
Перечитай мой пост, начинающийся со слов "Смотря с чем сравнивать".
Цитата:
Originally posted by Dart Bobr
То есть размер программы растет. А если растет, то и скорость ее выполнения уменьшается.
То есть размер программы растет. А если растет, то и скорость ее выполнения уменьшается.
А какая зависимость? :)
Обычно зависимость обратная. :)
Цитата:
Originally posted by Dart Bobr
Хотя я не берусь утверждать что использование ООП внесет сильно ощутимый еффект в скорость, скорее наоборот, и это есть "плата" за удобство програмирования.
Хотя я не берусь утверждать что использование ООП внесет сильно ощутимый еффект в скорость, скорее наоборот, и это есть "плата" за удобство програмирования.
Не... ты точно постов моих не читаешь.
Или пока ещё не понимаешь.
Цитата:
Originally posted by Green
какая зависимость? :)
какая зависимость? :)
— Алло, это Иван Петрович?
— Нет, это Исаак Авраамович.
— ... это номер 123456?
— Нет, это 123457.
— Надо же... ошибка в шестом знаке... а какой эффект!..
(c) анекдот.ру, хотя я эту хохму слышал много лет назад.
Почему то именно этот метод мало где применяют.
Из десятка книжек по С/С++ ,что у меня имеются, только в одной автор сразу начинает применять потоки и iostream
остальные printf scanf fread и тд сила привычки чтоли ...
Кстати маленькое замечение :) Пример на С получился весом в 180кб , а на С++ 544кб
вот чем наверно приходится жертвовать ...
А откомпилив пример в линуксе получилось 5,5кб :)) ндаа
Из десятка книжек по С/С++ ,что у меня имеются, только в одной автор сразу начинает применять потоки и iostream
остальные printf scanf fread и тд сила привычки чтоли ...
Кстати маленькое замечение :) Пример на С получился весом в 180кб , а на С++ 544кб
вот чем наверно приходится жертвовать ...
А откомпилив пример в линуксе получилось 5,5кб :)) ндаа
Цитата:
Originally posted by bytez
Почему то именно этот метод мало где применяют.
Почему то именно этот метод мало где применяют.
Да ну? :)
Цитата:
Originally posted by bytez
Из десятка книжек по С/С++ ,что у меня имеются, только в одной автор сразу начинает применять потоки и iostream
остальные printf scanf fread и тд сила привычки чтоли ...
Из десятка книжек по С/С++ ,что у меня имеются, только в одной автор сразу начинает применять потоки и iostream
остальные printf scanf fread и тд сила привычки чтоли ...
Возможно, книжки не те... ;)
Сила привычки - страшная сила.
Но и автор "генеального" примера, тож грешит... глобальными переменными. Причем подобное использование глобальных переменных может быть опасным.
Цитата:
Originally posted by bytez
Кстати маленькое замечение :) Пример на С получился весом в 180кб , а на С++ 544кб
вот чем наверно приходится жертвовать ...
Кстати маленькое замечение :) Пример на С получился весом в 180кб , а на С++ 544кб
вот чем наверно приходится жертвовать ...
В релизе собери.
Цитата:
Originally posted by bytez
Пример на С получился весом в 180кб , а на С++ 544кб
Пример на С получился весом в 180кб , а на С++ 544кб
Это у вас, наверно, DEBUG версия. Пример на С в RELEASE должен иметь размер порядка десятков К, а на C++ — порядка сотни К. Да и в любом случае жертва невелика: 1Gb дискового пространства стоит примерно доллар, а уж про занятую оперативную память и говорить нечего. Что 100К, что 1000 — один чёрт в память вашей машины поместиться должно...
Цитата:
Originally posted by sq_deep
Это у вас, наверно, DEBUG версия. Пример на С в RELEASE должен иметь размер порядка десятков К, а на C++ — порядка сотни К. Да и в любом случае жертва невелика: 1Gb дискового пространства стоит примерно доллар, а уж про занятую оперативную память и говорить нечего. Что 100К, что 1000 — один чёрт в память вашей машины поместиться должно...
Это у вас, наверно, DEBUG версия. Пример на С в RELEASE должен иметь размер порядка десятков К, а на C++ — порядка сотни К. Да и в любом случае жертва невелика: 1Gb дискового пространства стоит примерно доллар, а уж про занятую оперативную память и говорить нечего. Что 100К, что 1000 — один чёрт в память вашей машины поместиться должно...
Ага дебуг версия - откомпилив в линуксе пример на С , получилось 5,5кб
а пример на С++ 7,5кб с использованием lstdc++
Green Читаю ваши посты и понимаю, просто, по-моему у нас разное представление об оптимальном коде.
Пост перечитал, еще раз, согласен со всем, кроме того что такой оптимальный код не существует. Все зависит от навыка того, кто этот код пишет. Поэтому, когда дело доходит до оптимизации, оптимизировать алгоритм легче когда программа структурирована, но если опуститься до ассемблерной оптимизации, то скорее-всего все наоборот.
Пост перечитал, еще раз, согласен со всем, кроме того что такой оптимальный код не существует. Все зависит от навыка того, кто этот код пишет. Поэтому, когда дело доходит до оптимизации, оптимизировать алгоритм легче когда программа структурирована, но если опуститься до ассемблерной оптимизации, то скорее-всего все наоборот.
Цитата:
Originally posted by Dart Bobr
просто, по-моему у нас разное представление об оптимальном коде.
просто, по-моему у нас разное представление об оптимальном коде.
Чтож, тогда повторю ещё раз определение оптимальности:
Цитата:
Оптимальный - наиболее соответствующий заданному набору критериев.
"Оптимальный" предполагает набор критериев оптимальности и несколько вариантов удовлетворения этих критериев, из которых выбирается один "самый-самый".
Пример вариантности: "на безрыбье и рак - рыба". Т.к. других вариантов нет, то в данной ситуации он - самая оптимальная рыба.
Пример набора критериев: есть трактор, есть мотоцикл. Один из них оптимален в поле, а другой на трассе. Т.е. один удовлетворяет набору критериев "мощность, проходимость", а другой - "скорость, маневренность".
Цитата:
Originally posted by Dart Bobr
Пост перечитал, еще раз, согласен со всем, кроме того что такой оптимальный код не существует.
Пост перечитал, еще раз, согласен со всем, кроме того что такой оптимальный код не существует.
Какой "такой"?
Вопрос: что значит "ОПТИМАЛЬНЫЙ КОД"?
Ответ: НИЧЕГО, если нет набора критериев.
Оптимальность же ВООБЩЕ (т.е. удавлетворяющая любому бесконечному набору критериев) называется идеальностью, а ничего идеального в этом Мире не существует.
Назови мне ИДЕАЛЬНЫЙ автомобиль или ИДЕАЛЬНЫЙ компьютер, или покажи ИДЕАЛЬНЫЙ код. И не составит труда доказать обратное.
Цитата:
Originally posted by Dart Bobr
Поэтому, когда дело доходит до оптимизации, оптимизировать алгоритм легче когда программа структурирована, но если опуститься до ассемблерной оптимизации, то скорее-всего все наоборот.
Поэтому, когда дело доходит до оптимизации, оптимизировать алгоритм легче когда программа структурирована, но если опуститься до ассемблерной оптимизации, то скорее-всего все наоборот.
Это почему ещё?
В помойной яме легче разобраться, чем на прилавке магазина?
Цитата:
Originally posted by Green
В помойной яме легче разобраться, чем на прилавке магазина?
В помойной яме легче разобраться, чем на прилавке магазина?
Зато такой кайф! :D :D :D
Цитата:
Originally posted by Dart Bobr
Поэтому, когда дело доходит до оптимизации, оптимизировать алгоритм легче когда программа структурирована, но если опуститься до ассемблерной оптимизации, то скорее-всего все наоборот.
Поэтому, когда дело доходит до оптимизации, оптимизировать алгоритм легче когда программа структурирована, но если опуститься до ассемблерной оптимизации, то скорее-всего все наоборот.
Первый закон программирования:
Если хочется оптимизировать - не оптимизируй:!!!:
Второй закон программирования:
Новая версия программы всегда хуже предыдущей:!!!:
Цитата:
Originally posted by Green
Чтож, тогда повторю ещё раз определение оптимальности:
"Оптимальный" предполагает набор критериев оптимальности и несколько вариантов удовлетворения этих критериев, из которых выбирается один "самый-самый".
Чтож, тогда повторю ещё раз определение оптимальности:
"Оптимальный" предполагает набор критериев оптимальности и несколько вариантов удовлетворения этих критериев, из которых выбирается один "самый-самый".
Хорошо. Представим себе - есть программа. Размер програмки ХХХ байт, скорость выполнения УУУ секунд для самого плохого случая. Програмка, которая выдает такие же выходные даные, как и эта при заданых одних и тех же входных даных будет оптимальней первой если:
-она занимает не больше ХХХ-1 байт или
-выполняется не дольше чем УУУ-1 секунд.
В таком случае, каждая лишняя инструкция, вставленая компилятором все больше и больше делает нашу програмку "неоптимальной".
Поправьте меня, если я не прав. Но, я понимаю это так.
Цитата:
Originally posted by Green
Какой "такой"?
Вопрос: что значит "ОПТИМАЛЬНЫЙ КОД"?
Ответ: НИЧЕГО, если нет набора критериев.
Оптимальность же ВООБЩЕ (т.е. удавлетворяющая любому бесконечному набору критериев) называется идеальностью, а ничего идеального в этом Мире не существует.
Какой "такой"?
Вопрос: что значит "ОПТИМАЛЬНЫЙ КОД"?
Ответ: НИЧЕГО, если нет набора критериев.
Оптимальность же ВООБЩЕ (т.е. удавлетворяющая любому бесконечному набору критериев) называется идеальностью, а ничего идеального в этом Мире не существует.
Хм, я подумаю...
Цитата:
Originally posted by Green
Это почему ещё?
В помойной яме легче разобраться, чем на прилавке магазина?
Это почему ещё?
В помойной яме легче разобраться, чем на прилавке магазина?
По-моему это не очень подходящее сравнение. Ведь задача компилятора - перевести "прилавок магазина" в "помойку". И чем больше портируемость кода, тем больше получается "помойка". То-есть оригинальный алгоритм, необходимый для решения данной задачи, разбавляется чем-нибудь еще, что может влиять на ассемблерную оптимизацию.
Вот мои рассуждения. Есть к примеру задача: найти минимальный путь в графе, или какая-нибудь другая задача, неважно. С точки зрения оптимальности есть алгоритм, который делает это за оптимальное время. Теперь, добавим в этот алгоритм всего-лишь вывод, к примеру, результата и этот код перестанет быть оптимальным, так-как в нем уже присутствует код, не относящийся к решению даной задачи, просто какой-то код для интерфейса. Продолжим мысль. Теперь нам уже надо решить несколько другую задачу: например ту же самую, только вывод результата на экран нам жизненно необходим. Тогда вторая программа будет для нас оптимальной, а первая - нет, так-как в ней не реализован весь алгоритм полностью. Теперь возьмем две программы. Одна - написана с использованием ООП, другая - без. Обе - рабочие. С точки зрения простого юзера, какая программа будет оптимальней? Наверное та, которая по размеру, хоть на байт меньше и выполняется, хоть на секунду быстрее. Отсюда вывод для него есть оптимальней задача написаная без использования ООП. С точки зрения разработчика даной программы оптимальней является первая программа, так как он старается минимизировать не только время работы программы и ее размер, а и свое время разработки даной программы, ее портируемость, отлаживаемость.
Цитата:
Originally posted by Dart Bobr
Отсюда вывод для него есть оптимальней задача написаная без использования ООП. С точки зрения разработчика даной программы оптимальней является первая программа, так как он старается минимизировать не только время работы программы и ее размер, а и свое время разработки даной программы, ее портируемость, отлаживаемость.
Отсюда вывод для него есть оптимальней задача написаная без использования ООП. С точки зрения разработчика даной программы оптимальней является первая программа, так как он старается минимизировать не только время работы программы и ее размер, а и свое время разработки даной программы, ее портируемость, отлаживаемость.
Это допущение сегодняшнего дня. Нет пока процессора, поддерживающего объектность аппаратно. Вот хохма-то будет, когда появится.
Мы недавно на работе спорили насчет программирования на Java. Пришли к выводу, что для мобильных телефонов, где Java реализована аппаратно (или почти аппаратно) - самый правильный инструмент разработки. А вот для PC - нет.
Поэтому твои рассуждения о неэффективности ООП хоть и понятны, но тоже являются частным случаем.
Цитата:
Originally posted by Freeman
Это допущение сегодняшнего дня. Нет пока процессора, поддерживающего объектность аппаратно. Вот хохма-то будет, когда появится.
Мы недавно на работе спорили насчет программирования на Java. Пришли к выводу, что для мобильных телефонов, где Java реализована аппаратно (или почти аппаратно) - самый правильный инструмент разработки. А вот для PC - нет.
Поэтому твои рассуждения о неэффективности ООП хоть и понятны, но тоже являются частным случаем.
Это допущение сегодняшнего дня. Нет пока процессора, поддерживающего объектность аппаратно. Вот хохма-то будет, когда появится.
Мы недавно на работе спорили насчет программирования на Java. Пришли к выводу, что для мобильных телефонов, где Java реализована аппаратно (или почти аппаратно) - самый правильный инструмент разработки. А вот для PC - нет.
Поэтому твои рассуждения о неэффективности ООП хоть и понятны, но тоже являются частным случаем.
Так, я про то и говорю! Фу, наконец-то меня кто-то понял :)
А аппаратная обьектность это действительно хохма. Хотя, наверное, нет ничего невозможного.
Цитата:
Originally posted by Dart Bobr
Так, я про то и говорю! Фу, наконец-то меня кто-то понял :)
Так, я про то и говорю! Фу, наконец-то меня кто-то понял :)
Разумеется. Только подобные рассуждения об эффективности похожи больше на бухтение старого ворчуна, мол, бывали раньше времена, и люди были настоящими, не то, что нонешняя молодежь. Если речь идет о микроконтроллерах и прочей встроенной лабудени, еще можно понять, а вот на настольных компах - глупо.
Как раз потому, что еще существуют подобные рассуждения, нет даже попыток сделать объектный процессор. Чего хотим, то и получаем. Продолжаем "жрать дерьмо с кончика лопаты", так сказать.
Цитата:
Originally posted by Freeman
Разумеется. Только подобные рассуждения об эффективности похожи больше на бухтение старого ворчуна, мол, бывали раньше времена, и люди были настоящими, не то, что нонешняя молодежь. Если речь идет о микроконтроллерах и прочей встроенной лабудени, еще можно понять, а вот на настольных компах - глупо.
Как раз потому, что еще существуют подобные рассуждения, нет даже попыток сделать объектный процессор. Чего хотим, то и получаем. Продолжаем "жрать дерьмо с кончика лопаты", так сказать.
Разумеется. Только подобные рассуждения об эффективности похожи больше на бухтение старого ворчуна, мол, бывали раньше времена, и люди были настоящими, не то, что нонешняя молодежь. Если речь идет о микроконтроллерах и прочей встроенной лабудени, еще можно понять, а вот на настольных компах - глупо.
Как раз потому, что еще существуют подобные рассуждения, нет даже попыток сделать объектный процессор. Чего хотим, то и получаем. Продолжаем "жрать дерьмо с кончика лопаты", так сказать.
Почему старого? Вот, впрочем, читал, что бывали времена и люди неделю сидели ночами оптимизируя и без того оптимизированый ассемблерный код, что-бы в конце-концов уменьшить его размер на один байт. А сейчас всем пофиг на ресурсы? Лозунг практически всех програмеров и контор?
Хотите юзать нашу программу? - Берите компы мощнее!
По-моему это уже чересчур!
А про аппаратную поддержку, так это, извините, все же бред! Вот к примеру как тогда с программами, которые написаны без ООП? Или с ООП, но криво написаны? По-моему это аналогично встраиванию в процессор програмиста.
Цитата:
Originally posted by Dart Bobr
Вот к примеру как тогда с программами, которые написаны без ООП? Или с ООП, но криво написаны? По-моему это аналогично встраиванию в процессор програмиста.
Вот к примеру как тогда с программами, которые написаны без ООП? Или с ООП, но криво написаны? По-моему это аналогично встраиванию в процессор програмиста.
Программы, написанные без ООП, и представляющие самостоятельную ценность, могут с успехом выполняться старыми процессорами. Не исчезнут же они в одночасье! Например, бессмертные программы под ДОС и сама ДОС сейчас еще с успехом живут в некоторых применениях.
А криво написанные программы надо переписывать, вне зависимости от того, на чем они написаны. Кстати, так не только я считаю. Об этом еще много лет назад Вирт писал.
А возвращаясь к теме экономии ресурсов, могу повторить еще раз слова про аппаратную Джаву. То, что сейчас имеет место большой дисбаланс между используемыми средствами разработки и средствами выполнения, совершенно не означает, правильный выбор средств решения задачи - пустой звук. Кстати, по теории "аппаратной Джавы" под современные настольные ОС и процессор надо писать на Асме и Си. Если полностью опираться на теорию. Хи-хи-хи!
Цитата:
Originally posted by Freeman
Программы, написанные без ООП, и представляющие самостоятельную ценность, могут с успехом выполняться старыми процессорами. Не исчезнут же они в одночасье! Например, бессмертные программы под ДОС и сама ДОС сейчас еще с успехом живут в некоторых применениях.
А криво написанные программы надо переписывать, вне зависимости от того, на чем они написаны. Кстати, так не только я считаю. Об этом еще много лет назад Вирт писал.
А возвращаясь к теме экономии ресурсов, могу повторить еще раз слова про аппаратную Джаву. То, что сейчас имеет место большой дисбаланс между используемыми средствами разработки и средствами выполнения, совершенно не означает, правильный выбор средств решения задачи - пустой звук. Кстати, по теории "аппаратной Джавы" под современные настольные ОС и процессор надо писать на Асме и Си. Если полностью опираться на теорию. Хи-хи-хи!
Программы, написанные без ООП, и представляющие самостоятельную ценность, могут с успехом выполняться старыми процессорами. Не исчезнут же они в одночасье! Например, бессмертные программы под ДОС и сама ДОС сейчас еще с успехом живут в некоторых применениях.
А криво написанные программы надо переписывать, вне зависимости от того, на чем они написаны. Кстати, так не только я считаю. Об этом еще много лет назад Вирт писал.
А возвращаясь к теме экономии ресурсов, могу повторить еще раз слова про аппаратную Джаву. То, что сейчас имеет место большой дисбаланс между используемыми средствами разработки и средствами выполнения, совершенно не означает, правильный выбор средств решения задачи - пустой звук. Кстати, по теории "аппаратной Джавы" под современные настольные ОС и процессор надо писать на Асме и Си. Если полностью опираться на теорию. Хи-хи-хи!
Эх, вот выучу джаву, и стану миллионером :)
Криво написанные проги надо переписывать, только кто этим займется? Лично я не буду :D .
А вот аппаратный OpenGl и DirectX как-то не делают экономию ресурсов менее актуальной...
Цитата:
Originally posted by Dart Bobr
Криво написанные проги надо переписывать, только кто этим займется? Лично я не буду :D
Криво написанные проги надо переписывать, только кто этим займется? Лично я не буду :D
Вот пойдешь на работу, и будет она тебе вместо армии. :D Про вирье даже думать времени не будет.
Цитата:
А вот аппаратный OpenGl и DirectX как-то не делают экономию ресурсов менее актуальной...
Так там динамика совершенно другая. Каждая новая версия ускорителя открывает новые возможности перед программистами, которые начинают их использовать. Т. е. налицо пример решения компьютером проблемы, им же созданной. :D
Хотя, ничего странного в такой постановке нет. Ибо игровая индустрия - одна большая проблема, становящая больше с каждым годом. :D Такова уж постановка задачи.
Цитата:
Originally posted by Freeman
Вот пойдешь на работу, и будет она тебе вместо армии. :D Про вирье даже думать времени не будет.
Так там динамика совершенно другая. Каждая новая версия ускорителя открывает новые возможности перед программистами, которые начинают их использовать. Т. е. налицо пример решения компьютером проблемы, им же созданной. :D
Хотя, ничего странного в такой постановке нет. Ибо игровая индустрия - одна большая проблема, становящая больше с каждым годом. :D Такова уж постановка задачи.
Вот пойдешь на работу, и будет она тебе вместо армии. :D Про вирье даже думать времени не будет.
Так там динамика совершенно другая. Каждая новая версия ускорителя открывает новые возможности перед программистами, которые начинают их использовать. Т. е. налицо пример решения компьютером проблемы, им же созданной. :D
Хотя, ничего странного в такой постановке нет. Ибо игровая индустрия - одна большая проблема, становящая больше с каждым годом. :D Такова уж постановка задачи.
Как вас всех тут от темы далеко унесло :)