четверг, 27 марта 2008 г.
Кое какие изменения
Кардинально меняем курс - поВтыкав кучу статей обзоров и прочего , посоветовавшись not at words гуру , решил сделать кое какие изменения. Подробней завтра. Ибо пятница выходной.
суббота, 22 марта 2008 г.
День 2
Части программы на языке С++
Всё начинается с препроцессора - # . Никогда бы не подумал что отдельно такой маленький значок что то значит - вот что значит читать книги.
Любая программа начинается с директивы препроцессора #include (значит мы можем иметь дело не только с ключевым словом include , директив наверняка много).
Так вот наша директива подключает необходимые нам файлы - библиотеки которыми пользуются к примеру объекты. Вот объект cout использует библиотеку iostream иначе он у нас просто не будет работать. Так же не стоит забывать добавлять волшебную строчку
std::cout; перед использованием или
using namespace std; до объявления функции main () ;
Самое интересное что у меня cin и cout работают даже без этих инструкций - может глюк компилятора (проверяю на DevC++ 4 нечего другого сейчас под рукой нету).
Также указывать пространство имён (так называется using namespace std; по русски ) необходимо для того чтоб сработал endl; к примеру (Конец строки).
Вернёмся к функция main () о которой успели упомянуть обращается напрямую к операционной системе , об этом в прошлый раз шёл разговор, и возвращает ей значение (смысл возврата этих значений пока нераскрыт - будем копать, а после дополнять). Хотя есть идея - в конце любой функции должен быть оператор return который возвращает значение этой функции . Если его нет функция вернёт значение типа void (пустое). В книге рассмотрен пример - по моему недоработанный какой-то потому как сложно уследить смысл передаваемых переменных . Разберём его :
#include
int Add (int first, int second)
{
std::cout << "In Add(), received " << first << " and " << second << "\n";
return (first + second);
}
int main()
{
using std::cout;
using std::cin;
cout << "I'm in main()!\n";
int a, b, c;
cout << "Enter two numbers: ";
cin >> a;
cin >> b;
cout << "\nCalling Add()\n";
c=Add(a,b);
cout << "\nBack in main().\n";
cout << "c was set to " << c;
cout << "\nExiting...\n\n";
return 0;
}
Сначала выполняются действия находящиеся в функции main(). Переменные а и b получают свои значения - потом они передаются функции Add - где свои значения передают переменным first и second. После вычислений оператор return возвращает функции main (возвращает функции main ? ) результат сложения двух переменных и присваивает его переменной с. По сути в функции Add всё равно нужно было определять новые переменные и если бы их назвали a и b - это были бы уже ДРУГИЕ переменные . Хм сам ответил на свой вопрос зачем их так нужно было называть. Но всё же я бы их назвал к примеру firstA, secondB. Или в таких вариациях. =)
В скобках у имени функции размещаются её параметры.
Параметр - это объявление типа данных , передаваемых функции.
Реальные значения, передаваемые функции при её вызове - называются параметрами. Примерно так записано в книге.
Очень много деталей появляется которые надо помнить - создам отдельный пост в котором по пунктам будут записаны эти детали.
Практическая часть (Прям как лабораторки ) ) :
Особо с функциями ввода вывода не распишешься - поэтому нечего умнее как выводом фигурок заняться нене придумалпридумал - использовал и табуляции и просто пробелы - интересно так получилось =)
Всё начинается с препроцессора - # . Никогда бы не подумал что отдельно такой маленький значок что то значит - вот что значит читать книги.
Любая программа начинается с директивы препроцессора #include (значит мы можем иметь дело не только с ключевым словом include , директив наверняка много).
Так вот наша директива подключает необходимые нам файлы - библиотеки которыми пользуются к примеру объекты. Вот объект cout использует библиотеку iostream иначе он у нас просто не будет работать. Так же не стоит забывать добавлять волшебную строчку
std::cout; перед использованием или
using namespace std; до объявления функции main () ;
Самое интересное что у меня cin и cout работают даже без этих инструкций - может глюк компилятора (проверяю на DevC++ 4 нечего другого сейчас под рукой нету).
Также указывать пространство имён (так называется using namespace std; по русски ) необходимо для того чтоб сработал endl; к примеру (Конец строки).
Вернёмся к функция main () о которой успели упомянуть обращается напрямую к операционной системе , об этом в прошлый раз шёл разговор, и возвращает ей значение (смысл возврата этих значений пока нераскрыт - будем копать, а после дополнять). Хотя есть идея - в конце любой функции должен быть оператор return который возвращает значение этой функции . Если его нет функция вернёт значение типа void (пустое). В книге рассмотрен пример - по моему недоработанный какой-то потому как сложно уследить смысл передаваемых переменных . Разберём его :
#include
int Add (int first, int second)
{
std::cout << "In Add(), received " << first << " and " << second << "\n";
return (first + second);
}
int main()
{
using std::cout;
using std::cin;
cout << "I'm in main()!\n";
int a, b, c;
cout << "Enter two numbers: ";
cin >> a;
cin >> b;
cout << "\nCalling Add()\n";
c=Add(a,b);
cout << "\nBack in main().\n";
cout << "c was set to " << c;
cout << "\nExiting...\n\n";
return 0;
}
Сначала выполняются действия находящиеся в функции main(). Переменные а и b получают свои значения - потом они передаются функции Add - где свои значения передают переменным first и second. После вычислений оператор return возвращает функции main (возвращает функции main ? ) результат сложения двух переменных и присваивает его переменной с. По сути в функции Add всё равно нужно было определять новые переменные и если бы их назвали a и b - это были бы уже ДРУГИЕ переменные . Хм сам ответил на свой вопрос зачем их так нужно было называть. Но всё же я бы их назвал к примеру firstA, secondB. Или в таких вариациях. =)
В скобках у имени функции размещаются её параметры.
Параметр - это объявление типа данных , передаваемых функции.
Реальные значения, передаваемые функции при её вызове - называются параметрами. Примерно так записано в книге.
Очень много деталей появляется которые надо помнить - создам отдельный пост в котором по пунктам будут записаны эти детали.
Практическая часть (Прям как лабораторки ) ) :
Особо с функциями ввода вывода не распишешься - поэтому нечего умнее как выводом фигурок заняться нене придумалпридумал - использовал и табуляции и просто пробелы - интересно так получилось =)
Temp
Сегодня по сути 7 день изучения =) Значит так - изучать С++ возможно а вот вести блог с описанием - довольно сложно , если учитывать все те факторы про которые описал раньше. В течении дня опишу недостающие дни + выложу что написал .
ps / потом что, сегодня выходной )
ps / потом что, сегодня выходной )
вторник, 18 марта 2008 г.
Python \=)
Dao_work> в чём плюсы питона по сравнению с С++
Dao_work> хотя наверно это тоже самое что говорить в чём плюсы динамического языка от компилируемого
Antoni> *сейчас начнется :-))
Antoni> итак!
Antoni> интерпретатор, динамичность позволяет сделать язык выше по уровню, воплотить любую фантазию автора. Компилятор же должен быть разумной сложности, ибо необходимость транслировать в четкий машинный код накладывает ограничения на язык - Python гораздо выше по уровню, чем C++
Dao_work> И где его стоит применять ?
Antoni> фантазия нужна :-) Если говорить о прикладном программировании на языках высокого уровня. Чем ближе язык и удобнее для человека - тем эффективнее будет процесс написания программы . Также надо учитывать что постоянно дорабатываются взгляды на то каким должен быть язык программирования, прогресс идет. Си++ очень старый язык.
Dao_work> мне нужна программа проверить листов 10 а4 и найти мне там все Ип за определённое число отсортировать и оформив вынести в отдельный фаил - что лучше ? С++ или Питон )
Antoni> конечно Python! Найти все ipшки на нем будет так:
print filter(lambda s: '18.03.2008' in s, open('file.log','rt').readlines()) все :-)
Даже если чуть усложнить чтобы лучше вывод был то все равно 1-3 строки будет .
rint map(lambda s: s.split('\t')[0], filter(lambda s: '18.03.2008' in s, open('file.log','rt').readlines()))
допустим что в логе все разделяется табами и ip идет первым :-)
Dao_work> А вот если нам надо рассчитать сложный интеграл С++ или Питон )
Antoni> рассчитать интеграл на Python тоже несложно :-) функциональный язык вычислений вообще удобнее подходит
Dao_work> функциональный язык вычислений ?
Antoni> функциональные языки более математичны и изначально лучше подходят для записи расчетов :-) так вот, рассмотрим разные параметры языков
во первых синтаксис , современный взгляд таков, что хороший синтаксис позволяет программисту лучше и быстрее воспринимать программу и делать меньше ошибок
короткий синтаксис уменьшает время на набор кода у Си++ синтаксис "плохой" (можно найти аналитические статьи, это подробно обсуждалось уже не первый год)
Dao_work> конечно лучше набрать puts "Hello !" чем мучатся как в Java )) (Андрей Привет ;) )
Antoni> на Python это: print 'Hello!' и никаких мучений :-) Дальше парадигмы, в Python (как и во многих современных языках) больше парадигм, чем в Си++
раньше языки были с меньшим числом парадигм: чисто процедурные или ООП максимум, или чисто функционально. Сейчас модно смешивать стили
это вместе с синтаксисом приводит к тому, что на Python тот же алгоритм обычно в 3 - 5 раз меньше строк чем на Си++ в современных динамических языках меньше системной работы - автоматическое управление памятью и меньше "лишних" структур например задача найти сумму чисел -
на процедурном языке это будет так:
1. создать массив и заполнить его: a[0] = 3; a[1] = 5; a[2] = 7
2. создать временную переменную для накопления суммы s
3. пройти цикл по массиву и получить результат во временной переменной
в функциональном языке половины этого не надо print reduce(lambda a,b: a+b, [3,5,7],0) во первых не надо создавать массивов почти никогда, все делается на лету списковыми структурами во вторых не нужны временные переменные, информация может передаваться напрямую из функции в функцию. Между прочим временные переменные увеличивают вероятность ошибки в программе, ибо случайно в них можно что-то не то в другом месте программы присвоить. Если временных переменных много за ними трудно следить в разных частях процедуры.
Всё же моё личное мнение – пока С++ остаётся неплохим языком для того чтобы начать изучать программирование. Гораздо лучше Паскаля.
Dao_work> хотя наверно это тоже самое что говорить в чём плюсы динамического языка от компилируемого
Antoni> *сейчас начнется :-))
Antoni> итак!
Antoni> интерпретатор, динамичность позволяет сделать язык выше по уровню, воплотить любую фантазию автора. Компилятор же должен быть разумной сложности, ибо необходимость транслировать в четкий машинный код накладывает ограничения на язык - Python гораздо выше по уровню, чем C++
Dao_work> И где его стоит применять ?
Antoni> фантазия нужна :-) Если говорить о прикладном программировании на языках высокого уровня. Чем ближе язык и удобнее для человека - тем эффективнее будет процесс написания программы . Также надо учитывать что постоянно дорабатываются взгляды на то каким должен быть язык программирования, прогресс идет. Си++ очень старый язык.
Dao_work> мне нужна программа проверить листов 10 а4 и найти мне там все Ип за определённое число отсортировать и оформив вынести в отдельный фаил - что лучше ? С++ или Питон )
Antoni> конечно Python! Найти все ipшки на нем будет так:
print filter(lambda s: '18.03.2008' in s, open('file.log','rt').readlines()) все :-)
Даже если чуть усложнить чтобы лучше вывод был то все равно 1-3 строки будет .
rint map(lambda s: s.split('\t')[0], filter(lambda s: '18.03.2008' in s, open('file.log','rt').readlines()))
допустим что в логе все разделяется табами и ip идет первым :-)
Dao_work> А вот если нам надо рассчитать сложный интеграл С++ или Питон )
Antoni> рассчитать интеграл на Python тоже несложно :-) функциональный язык вычислений вообще удобнее подходит
Dao_work> функциональный язык вычислений ?
Antoni> функциональные языки более математичны и изначально лучше подходят для записи расчетов :-) так вот, рассмотрим разные параметры языков
во первых синтаксис , современный взгляд таков, что хороший синтаксис позволяет программисту лучше и быстрее воспринимать программу и делать меньше ошибок
короткий синтаксис уменьшает время на набор кода у Си++ синтаксис "плохой" (можно найти аналитические статьи, это подробно обсуждалось уже не первый год)
Dao_work> конечно лучше набрать puts "Hello !" чем мучатся как в Java )) (Андрей Привет ;) )
Antoni> на Python это: print 'Hello!' и никаких мучений :-) Дальше парадигмы, в Python (как и во многих современных языках) больше парадигм, чем в Си++
раньше языки были с меньшим числом парадигм: чисто процедурные или ООП максимум, или чисто функционально. Сейчас модно смешивать стили
это вместе с синтаксисом приводит к тому, что на Python тот же алгоритм обычно в 3 - 5 раз меньше строк чем на Си++ в современных динамических языках меньше системной работы - автоматическое управление памятью и меньше "лишних" структур например задача найти сумму чисел -
на процедурном языке это будет так:
1. создать массив и заполнить его: a[0] = 3; a[1] = 5; a[2] = 7
2. создать временную переменную для накопления суммы s
3. пройти цикл по массиву и получить результат во временной переменной
в функциональном языке половины этого не надо print reduce(lambda a,b: a+b, [3,5,7],0) во первых не надо создавать массивов почти никогда, все делается на лету списковыми структурами во вторых не нужны временные переменные, информация может передаваться напрямую из функции в функцию. Между прочим временные переменные увеличивают вероятность ошибки в программе, ибо случайно в них можно что-то не то в другом месте программы присвоить. Если временных переменных много за ними трудно следить в разных частях процедуры.
Всё же моё личное мнение – пока С++ остаётся неплохим языком для того чтобы начать изучать программирование. Гораздо лучше Паскаля.
понедельник, 17 марта 2008 г.
Парадигмы языков программирования :-)
В дополнение к Первым дням конспекта лекций дополнительный матерьял - цикл назову Беседы с "Гордоном" \=]
Собеседник - python программист Antoni ,)
Dao_work> как говорится - Привет Корпоративным Программистам
Dao_work> не очень занят ? -)
угу не очень :-)
Dao_work> тогда вот
Dao_work> http://daodev.blogspot.com/
Dao_work> 8-))))
Dao_work> День 0 и День 1 =)
Dao_work> Интерпретатор, ... инструкции программы . Компилятор ... исходный код программы . Чувствуете разницу +))
ну скажем так - компилятор делает программу а интерпретатор сам программа :-) т.е. после компиляции для работы программы компилятор больше не нужен а интерпретатор нужен, он всегда запускается для работы программы
Dao_work> компилятор делает временный .obj или .o фаил
Dao_work> )
Dao_work> Antoni только если язык Интерпретируемый
Dao_work> Ибо далее работает ещё компоновщик
Dao_work> )
ну в целом, компилятор создает независимые программы. Они не отличаются от самого компилятора :-)
а интерпретатор всегда идет в комплект :-)
...
в общем компилятор создает независимую программу. И дальше эта программа в компиляторе не нуждается. А интерпретатор программу не делает, он сам запускается и поддерживает ее выполнение :-)
м.. идеи парадигм языков удобно рассмотреть в их историческом развитии :-) т.е. почему и зачем возникало то или иное течение. Сначала (когда появились первые цифровые ЭВМ, ведь до этого были еще и аналоговые! :-) ) появились процедурные (императивные) и почти одновременно функциональные (аппликативные).Языки - это соотественно Fortran (процедурная концепция) и LISP (функциональная)
эти два языка ооочень старые и есть основоположники , разница концепций такова: процедурная ближе к архитектуре машины и эффективнее выполняется. А языки функциональные более абстрактны, логичны и красивы с математической стороны. Но выполняются очень медленно. (и раньше умели делать только интерпретаторы для них) это решило дело: популярными в проф. среде стали именно процедурные а LISP применялся для каких то специфических вещей "типа исследования искусственного интеллекта". OCAML (это кажется первый функциональный язык, для которого сумели сделать компилятор.
Dao_work> кстати - сколько ещё ты знаешь компилируемых языков кроме С++ и С ?
Есть еще языки которые близки к компиляторам, но с хитростями и частично интерпретируются: Pascal, Forth и т.п.
Dao_work> паскаль и дельфи оставим
Угу как раз дельфи не совсем компилятор, там внутри этих хитростей хватает чисто компиляторов что-то не вспоминается больше :-) так вот все стали в основном работать на процедурных языках. И тут выяснилось, что большие программы делать на них очень сложно. И трудно отлаживать. Структура проекта теряется и можно повеситься. Поэтому придумали "принципы структурированного программирования", которые спасли положение (на нек. время)
В эти принципы входил запрет использовать прямые переходы GOTO, так же ввели локальные переменные и контекст процедур. В структурированное программирование входят if блоки и цикл блоки дальше придумали модульность, как красиво разбивать исходный текст на файлы и потом компилировать вместе так вот классика структурированного программирования это Pascal. Как раз он и был создан по всем этим требованиям. Так же принципы быстро включили во все языки в какие смогли.
Dao_work> почему использование GOTO недопустимо ?
Потому что это нелогичный прыжок в программе, который трудно анализировать (человеку). Он может идти в любое место программы и ищи свищи. Если применять GOTO то можно быстро испоганить весь исходник станет как кубик рубика. Поэтому это первое что запретили.
В Си и Си++ структурированные принципы тоже включили, но не так строго как в Паскале структурированное программирование это не только возможности языка, а методика работы самого программиста - как надо оформлять программу что лучше делать и что нельзя благодаря этому стало возможно легко разрабатывать программы крупнее на порядок :-) но все равно есть потолок, когда проект опять теряется и запутывается
поэтому развитие шло дальше , во первых прорабатывалась и углублялась мысль о модульном программировании (Modula-2, Ada и т.п. автор тот же что и Паскаль написал).
Модульность а вот потом придумали ООП поначалу как совсем отдельный тип языков программирования - классика Smalltalk потом сообразили, что оно может внедряться и в старые языки и стали внедрять
тут было много воплей и споров потому что придумали теорию ООП и строгий стандарт. А в языки включали часто не точно по стандарту, иногда вообще искаженно и упрощенно. (в некоторые языки полностью ООП и фиг включишь так просто) (Smalltalk то специально создавался как ООП язык) поэтому были споры о первоначальных "правильных" ООП языках. И не до ооп отклонениях. Очень много можно ругани на Си++ найти (в нем куча отклонений от стандарта). Но с другой стороны (а это уже 80ые годы пошли) появилась эйфория - ООП это панацея от всех бед, позволяется делать на порядки больше проекты. Мол ООП это счастье навсегда. Было выпущено тонны книг о "новом ООП проектировании" и т.п. Потом параллельно шла разработка темы: что есть программирование - текст или график программа это текста, а ее блок-схема - графическое отображение. И появилась мысль о CASE средствах - можно ли сделать такую среду разработки что писать текст вообще не надо было, только рисовать. Были очень интересные штуки гм... но в результате это ввели немного во все популярные студии программирования и успокоились. (типа VisualBasic Delphi и т.п. ) Первоначально же были экспериментальные CASE среды, в которых натурально графически проектировалась структура программы и набивать текст почти не надо было. И те среды канули в прошлое, но идеи наработки частично используются почти везде идем по истории дальше . 90ые годы. Появилась нехилая мысль: сделать такие языки чтобы программа запускалась без переделки в любой ОС на любом процессоре. Кросс-платформенные языки: Java, Ruby, Python
Dao_work> угу только Java кажись раньше был чем тот же руби
ну да "первый блин комом" но он первый %-) хотя до Java тоже были эксперименты
Dao_work> + Java есть идея использования виртуальной машины
Dao_work> Руби и питон это всё таки интерпретаторы ближе к Перл пожалуй
неа, питон и руби чистые интерпретаторы. дальше появились виртуальные среды с одной стороны, и способы соединять разнородные проги с другой (CORBA) А Perl jit-компилятор :-)
дальше еще одно направление: компьютеры стали "очень мощными" и стало реально возможно работать на функциональных (которые тоже были на заре давно, как помним, но не были популярны) и логических языках
CORBA это отдельная свободная технология связи разнородных программ по сети в одну. И в каждый язык сделали поддержку этой технологии и стали писать "есть CORBA@"
Так вот стали более популярны функциональные языки (логические пока на заднем плане, но в будущем все еще может развернуться :-) )Во многие языки стали вводить элементы функциональных как в Python например. Вообще много появилось мульти-парадигменных языков и конечно OCAML это прорыв мощный, настоящий компилятор чисто функциональный. И скорость не уступает Си , круто в общем ну вот и все пока приехали :-)(а на логических языках потихоньку что-то делают супер профессиональное, например на Mercury в Англии написали автодиспетчерские службы в аэропортах)
Dao_work> В чём основное отличие
Dao_work> ну самый яркий практический пример
Dao_work> логического языка
Prolog . Основное отличие вот в логическом языке программа рассматривается как совокупность логических утверждений (тождеств). Причем тождество работает в обе стороны автоматически. И все это как система уравнений. Т.е. ты пишешь действий и команд, алгоритма тоже нет в программе.
Ты вводишь связанные условия задачи, по которым транслятор рассчитывает поведение программы и результаты :-)
Dao_work> сложи на логике а + б )
легко
x есть a + b
a есть 3
b есть 2
после ввода первой строки x станет неопределенной от минус до плюс бесконечности
после второй появятся ряды возможных значений x и b одновременно
после третьей результат станет полностью конкретным
особенностью логических языков является то, что ответ всегда есть, просто не четкий или множественный. (а не только в конце программы, как в обычных языках)
Dao_work> я вижу плюс в том что ненужно указывать тип переменной
тут вообще нет переменных принципиально :-) (не то что типов, просто нет переменных %-)
Dao_work> НО вопрос - это не может привести к нелогичному использованию памяти ? Обычно ведь заранее область памяти резервируется под что-то + там ещё переполнение буфера обмена
) в таких языках все управление памятью идет полностью автоматически. нее переполнения буфера в ФП и ЛП не бывает там это решается очень просто - все строки неизменяемы поэтому переполнить буфер невозможно
поэтому ФП (и ЛП наверное) более безопасные языки чем процедурные хакерам там труднее. Я написал не = а "есть" слово чтобы подчеркнуть дух языков - нет переменных. Это тождество а не присваивание а x, a, b не переменные, а символические имена, обозначающие некую искомую сущность %-) что соотествует математическому понятию переменной
Dao_work> Такс - думаю на этой ноте надо остановится )
Собеседник - python программист Antoni ,)
Dao_work> как говорится - Привет Корпоративным Программистам
Dao_work> не очень занят ? -)
угу не очень :-)
Dao_work> тогда вот
Dao_work> http://daodev.blogspot.com/
Dao_work> 8-))))
Dao_work> День 0 и День 1 =)
Dao_work> Интерпретатор, ... инструкции программы . Компилятор ... исходный код программы . Чувствуете разницу +))
ну скажем так - компилятор делает программу а интерпретатор сам программа :-) т.е. после компиляции для работы программы компилятор больше не нужен а интерпретатор нужен, он всегда запускается для работы программы
Dao_work> компилятор делает временный .obj или .o фаил
Dao_work> )
Dao_work> Antoni только если язык Интерпретируемый
Dao_work> Ибо далее работает ещё компоновщик
Dao_work> )
ну в целом, компилятор создает независимые программы. Они не отличаются от самого компилятора :-)
а интерпретатор всегда идет в комплект :-)
...
в общем компилятор создает независимую программу. И дальше эта программа в компиляторе не нуждается. А интерпретатор программу не делает, он сам запускается и поддерживает ее выполнение :-)
м.. идеи парадигм языков удобно рассмотреть в их историческом развитии :-) т.е. почему и зачем возникало то или иное течение. Сначала (когда появились первые цифровые ЭВМ, ведь до этого были еще и аналоговые! :-) ) появились процедурные (императивные) и почти одновременно функциональные (аппликативные).Языки - это соотественно Fortran (процедурная концепция) и LISP (функциональная)
эти два языка ооочень старые и есть основоположники , разница концепций такова: процедурная ближе к архитектуре машины и эффективнее выполняется. А языки функциональные более абстрактны, логичны и красивы с математической стороны. Но выполняются очень медленно. (и раньше умели делать только интерпретаторы для них) это решило дело: популярными в проф. среде стали именно процедурные а LISP применялся для каких то специфических вещей "типа исследования искусственного интеллекта". OCAML (это кажется первый функциональный язык, для которого сумели сделать компилятор.
Dao_work> кстати - сколько ещё ты знаешь компилируемых языков кроме С++ и С ?
Есть еще языки которые близки к компиляторам, но с хитростями и частично интерпретируются: Pascal, Forth и т.п.
Dao_work> паскаль и дельфи оставим
Угу как раз дельфи не совсем компилятор, там внутри этих хитростей хватает чисто компиляторов что-то не вспоминается больше :-) так вот все стали в основном работать на процедурных языках. И тут выяснилось, что большие программы делать на них очень сложно. И трудно отлаживать. Структура проекта теряется и можно повеситься. Поэтому придумали "принципы структурированного программирования", которые спасли положение (на нек. время)
В эти принципы входил запрет использовать прямые переходы GOTO, так же ввели локальные переменные и контекст процедур. В структурированное программирование входят if блоки и цикл блоки дальше придумали модульность, как красиво разбивать исходный текст на файлы и потом компилировать вместе так вот классика структурированного программирования это Pascal. Как раз он и был создан по всем этим требованиям. Так же принципы быстро включили во все языки в какие смогли.
Dao_work> почему использование GOTO недопустимо ?
Потому что это нелогичный прыжок в программе, который трудно анализировать (человеку). Он может идти в любое место программы и ищи свищи. Если применять GOTO то можно быстро испоганить весь исходник станет как кубик рубика. Поэтому это первое что запретили.
В Си и Си++ структурированные принципы тоже включили, но не так строго как в Паскале структурированное программирование это не только возможности языка, а методика работы самого программиста - как надо оформлять программу что лучше делать и что нельзя благодаря этому стало возможно легко разрабатывать программы крупнее на порядок :-) но все равно есть потолок, когда проект опять теряется и запутывается
поэтому развитие шло дальше , во первых прорабатывалась и углублялась мысль о модульном программировании (Modula-2, Ada и т.п. автор тот же что и Паскаль написал).
Модульность а вот потом придумали ООП поначалу как совсем отдельный тип языков программирования - классика Smalltalk потом сообразили, что оно может внедряться и в старые языки и стали внедрять
тут было много воплей и споров потому что придумали теорию ООП и строгий стандарт. А в языки включали часто не точно по стандарту, иногда вообще искаженно и упрощенно. (в некоторые языки полностью ООП и фиг включишь так просто) (Smalltalk то специально создавался как ООП язык) поэтому были споры о первоначальных "правильных" ООП языках. И не до ооп отклонениях. Очень много можно ругани на Си++ найти (в нем куча отклонений от стандарта). Но с другой стороны (а это уже 80ые годы пошли) появилась эйфория - ООП это панацея от всех бед, позволяется делать на порядки больше проекты. Мол ООП это счастье навсегда. Было выпущено тонны книг о "новом ООП проектировании" и т.п. Потом параллельно шла разработка темы: что есть программирование - текст или график программа это текста, а ее блок-схема - графическое отображение. И появилась мысль о CASE средствах - можно ли сделать такую среду разработки что писать текст вообще не надо было, только рисовать. Были очень интересные штуки гм... но в результате это ввели немного во все популярные студии программирования и успокоились. (типа VisualBasic Delphi и т.п. ) Первоначально же были экспериментальные CASE среды, в которых натурально графически проектировалась структура программы и набивать текст почти не надо было. И те среды канули в прошлое, но идеи наработки частично используются почти везде идем по истории дальше . 90ые годы. Появилась нехилая мысль: сделать такие языки чтобы программа запускалась без переделки в любой ОС на любом процессоре. Кросс-платформенные языки: Java, Ruby, Python
Dao_work> угу только Java кажись раньше был чем тот же руби
ну да "первый блин комом" но он первый %-) хотя до Java тоже были эксперименты
Dao_work> + Java есть идея использования виртуальной машины
Dao_work> Руби и питон это всё таки интерпретаторы ближе к Перл пожалуй
неа, питон и руби чистые интерпретаторы. дальше появились виртуальные среды с одной стороны, и способы соединять разнородные проги с другой (CORBA) А Perl jit-компилятор :-)
дальше еще одно направление: компьютеры стали "очень мощными" и стало реально возможно работать на функциональных (которые тоже были на заре давно, как помним, но не были популярны) и логических языках
CORBA это отдельная свободная технология связи разнородных программ по сети в одну. И в каждый язык сделали поддержку этой технологии и стали писать "есть CORBA@"
Так вот стали более популярны функциональные языки (логические пока на заднем плане, но в будущем все еще может развернуться :-) )Во многие языки стали вводить элементы функциональных как в Python например. Вообще много появилось мульти-парадигменных языков и конечно OCAML это прорыв мощный, настоящий компилятор чисто функциональный. И скорость не уступает Си , круто в общем ну вот и все пока приехали :-)(а на логических языках потихоньку что-то делают супер профессиональное, например на Mercury в Англии написали автодиспетчерские службы в аэропортах)
Dao_work> В чём основное отличие
Dao_work> ну самый яркий практический пример
Dao_work> логического языка
Prolog . Основное отличие вот в логическом языке программа рассматривается как совокупность логических утверждений (тождеств). Причем тождество работает в обе стороны автоматически. И все это как система уравнений. Т.е. ты пишешь действий и команд, алгоритма тоже нет в программе.
Ты вводишь связанные условия задачи, по которым транслятор рассчитывает поведение программы и результаты :-)
Dao_work> сложи на логике а + б )
легко
x есть a + b
a есть 3
b есть 2
после ввода первой строки x станет неопределенной от минус до плюс бесконечности
после второй появятся ряды возможных значений x и b одновременно
после третьей результат станет полностью конкретным
особенностью логических языков является то, что ответ всегда есть, просто не четкий или множественный. (а не только в конце программы, как в обычных языках)
Dao_work> я вижу плюс в том что ненужно указывать тип переменной
тут вообще нет переменных принципиально :-) (не то что типов, просто нет переменных %-)
Dao_work> НО вопрос - это не может привести к нелогичному использованию памяти ? Обычно ведь заранее область памяти резервируется под что-то + там ещё переполнение буфера обмена
) в таких языках все управление памятью идет полностью автоматически. нее переполнения буфера в ФП и ЛП не бывает там это решается очень просто - все строки неизменяемы поэтому переполнить буфер невозможно
поэтому ФП (и ЛП наверное) более безопасные языки чем процедурные хакерам там труднее. Я написал не = а "есть" слово чтобы подчеркнуть дух языков - нет переменных. Это тождество а не присваивание а x, a, b не переменные, а символические имена, обозначающие некую искомую сущность %-) что соотествует математическому понятию переменной
Dao_work> Такс - думаю на этой ноте надо остановится )
воскресенье, 16 марта 2008 г.
День 1
The One
Первая Глава столь замечательной книги - Освой самостоятельно С++ за 21 день - 5 издание - Джесс Либерти, Брэдли Джонс - прошла на Ура. Прочёл за минут 40 , заостряя внимания на мелочах . Пора перестать читать книги поверхностно
Дало свою пользу. Выпишу такой мини конспект и самое интересное.
Языки бывают
Интерпретируемыми (Интерпретатор, последовательно, превращает инструкции программы в команды машинного кода ), и
Компилируемыми (Компилятор преобразует исходный код программы в некоторую промежуточную форму - объектный фаил.)
Здесь стоит сделать два замечания :
1. Интерпретатор, ... инструкции программы . Компилятор ... исходный код программы . Чувствуете разницу - если внимательно вчитывается то можно заметить такие тонкие нюансы.
2. Когда-то умные дядьки говорили что Компилятор создаёт .ехе фаил - а теперь мы видим что это несовсем так . Пометка : Исправляем неточности.
- Язык С++ Объектно ориентированный язык программирования выросший из С (Си) , благодаря стараниям Бьёрна Страуструпа (Bjarne Stroustrup).
- Язык компилируемый. Что значит создаёт независимые .ехе файлы .
- Типы программирования
- Процедурное, Структурное , Объектно-ориентированное
С процедурным неувязочка вышла - описано довольно смутно, пол абзаца. Ну мы не обижаемся и обязательно прочтём что это такое - Гугл.
Структурное - "разделяй и властвуй", разбиваем большую задачу на под задачи, потом ещё меньше , и ещё , и в итоге чему равна половинка от половинки - Половинке половинки ?
Уважаю , примерно так и в реальной жизни происходит решение каких либо повседневных задач
ООП - Всё есть объект. Каша. Каша состоящая из :
Инкапсуляция - ...
Наследование и многократное использование - ...
Полиморфизм - ...
Я специально оставил пустые места. Суть некоторых вещей мне , примерно, понятна, доходчивые примеры, но ! Что бы оставаться политкорректным дополню со временем.
Нужно ли изучить сначала язык С?
Авторы говорят нет. У меня есть несколько книг по С (Си), купленных мной время назад, если что можно будет взять задачи от туда, сравнить решения на Си и С++, что эффективнее и к месту применения конкретной задачи. Не проподать же добру ?
Управляемые расширения для языка С++
Что меня удивило так это возможность интеграции С++ с платформой .NET. Смутно себе это представляю, так как .NET как и JAVA это по сути виртуальные машины в которых и исполняются программы, написанные на языках ориентированных на ЭТИ среды. Интересно Flash Player и Silverlight можно отнести к этому семейству ? ;)
Ход создания программы :
Код -> Компиляция (Создание .obj файла) -> Компоновка (Собрать все необходимые файлы: .obj, библиотеки, в один .ехе фаил.)
#include
int main ()
{
std::cout << "Hello World!\n"; return 0; }
Интересные детали :
iostream сокращённо от Input-Output-Stream , соответственно и хранятся в этой библиотеке объекты (!) cout и cin. Тоже сокращённо от Console-Output , Console-Input. Когда разъясняешь столь простые вещи то становится ГОРАЗДО понятней - чем давать без смысловой нагрузки.
Если функция main() возвращает что-то то нужно писать int main () и в тексте программы в самом конце return 0; (пока что условимся на этом, как что узнаю обязательно дополню), если она нечего не возвращаем то можно писать void main().
Избегать писать void main() если main() что-то возвращает системе, даже если компилятор позволяет так делать.
Смутно понимаю зачем системе что либо вообще возвращать ? Гугл.
Инструменты :
Visual Studio 2008 Professional. IDE (Integrated Development Environment - Интегрированная среда разработки).
Почему взял такой сложный IDE дорогой ?! Мог взять DevC++ но там непонятная история с версиями IDE , с бетой 5 версии которая в режиме (currently beta) уже более 2 лет а по обещаниям разработчиков вот вот будет готова. Если что поставлю 4 версию и буду проверять спорные моменты там. А Microsoft по отзывам с VS 6 C++ стал только лучше Будем надеется
Быстрый запуск программы
main() должен быть один !
Звучит как Фраза из Горца. Для новичка такого как я кажется что достаточно создать новый проект и в нём уже создавать отдельные .cpp файлы и их компилировать. Но увы при создании двух файлов Hello1.cpp Hello2.cpp и их дальнейшеё компиляции (создании .obj файла) получаю сообщение Error 1 error LNK2005: _main already defined in hello1.obj hello2.obj Hello .
Нужно создавать новый проект. Умные люди говорят - main() должен быть один ! Есть способ как в 1 проекте компилировать множество .cpp файлов, но пока он мне неизвестен.
суббота, 15 марта 2008 г.
День 0
Приветствие - Здравствуйте!
Зачем этот блог:
Хочу научиться программировать. Горячо стремлюсь к этому знанию - жарко просто неистово =) . Для самоконтроля и не отлынивания решил всё документировать.
На чём:
На С++. Поставил Visual Studio 2008 но думаю параллельно поставить ещё какой компилятор - а то от знания среды VS много что зависит.
Почему - ?
Потому что это классика. Да и сколько нечитаешь какого либо литературу всюду натыкаешься – С/С++ like like like
Что буду писать:
А + б и привет мир - Дискриминанты, площади фигур , функция x от (y) =) А вообще мечта светлая такая - 1 олимпиадная задачка в день - хотя бы школьная или районная -) Так незабываем пролистать учебники по математике - так памятка.
Планы:
Вот на столе лежит книга - Освой самостоятельно С++ за 21 день – 5 издание – Джесс Либерти, Брэдли Джонс. Каждый день буду проходить по главе из этой книги – получится за 21 день или нет, посмотрим, потому ставлю метку на эти записи “21”.
Так же надо усилить математический аппарат – потому произведение Джесс Либерти неединственная книжка которая тут засветится.
Цели:
По ходу роста количества знаний и увеличению кривизны мозговых извилин добавлю ещё некоторые вещи что хочу изучить.
Веские-Замечания:
У меня есть работа. Рабочий день с 8 утра и до 17 вечера, + повседневные дела, тренировки.
Но, несмотря на это, найти время всегда можно - и все отговорки остаются отговорками в оправдание собственной лени.
Ну и если там ещё что придумаю, отпишу потом.
Спасибо, искренне ваш Борец за права ветряных мельниц.
.. и главное не забыть - математика математика математика !!!
Зачем этот блог:
Хочу научиться программировать. Горячо стремлюсь к этому знанию - жарко просто неистово =) . Для самоконтроля и не отлынивания решил всё документировать.
На чём:
На С++. Поставил Visual Studio 2008 но думаю параллельно поставить ещё какой компилятор - а то от знания среды VS много что зависит.
Почему - ?
Потому что это классика. Да и сколько нечитаешь какого либо литературу всюду натыкаешься – С/С++ like like like
Что буду писать:
А + б и привет мир - Дискриминанты, площади фигур , функция x от (y) =) А вообще мечта светлая такая - 1 олимпиадная задачка в день - хотя бы школьная или районная -) Так незабываем пролистать учебники по математике - так памятка.
Планы:
Вот на столе лежит книга - Освой самостоятельно С++ за 21 день – 5 издание – Джесс Либерти, Брэдли Джонс. Каждый день буду проходить по главе из этой книги – получится за 21 день или нет, посмотрим, потому ставлю метку на эти записи “21”.
Так же надо усилить математический аппарат – потому произведение Джесс Либерти неединственная книжка которая тут засветится.
Цели:
По ходу роста количества знаний и увеличению кривизны мозговых извилин добавлю ещё некоторые вещи что хочу изучить.
Веские-Замечания:
У меня есть работа. Рабочий день с 8 утра и до 17 вечера, + повседневные дела, тренировки.
Но, несмотря на это, найти время всегда можно - и все отговорки остаются отговорками в оправдание собственной лени.
Ну и если там ещё что придумаю, отпишу потом.
Спасибо, искренне ваш Борец за права ветряных мельниц.
.. и главное не забыть - математика математика математика !!!
Подписаться на:
Сообщения (Atom)
