Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Какую среду разработки мне установить  (Прочитано 13127 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Olegator
Команда клуба

ru
Offline Offline
Пол: Мужской

« : 04-01-2006 20:35 » 

У меня стоит VS6.0. Изучаю С++.

Сейчас есть возможность установить VS.NET 2003 architect-версия с MSDN и VISIO. Но там, наверное, C#.
Может мне пока продолжать С++ изучать. А потом, на C# перейти. Всё таки учебник по С++. Или лучше сразу C#.
Записан
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #1 : 04-01-2006 21:43 » 

Ничего не мешает поставить VS.NET и работать с C++! На win9x не ставиться - нужна винда серии NT!
Кстати, обратная прорблема: VS6 трудно поставить на XP. Тупой инсталер хочет "обновить" MS JVM и без этого не может продолжить. Зачем мне MS JVM от 98-ой винды, если у меня стоит свежайшая Sun JVM?
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Olegator
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #2 : 04-01-2006 21:46 » 

Ничего не мешает поставить VS.NET и работать с C++!
Так там вроде C#.
Записан
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #3 : 04-01-2006 21:53 » 

Visual Studio - это среда разработки (IDE по буржуйски) и к языкам имеет косвенное отношение.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Джон
просто
Администратор

de
Offline Offline
Пол: Мужской

« Ответ #4 : 04-01-2006 22:12 » 

Olegator, там ВСЁ! И С++ тоже есть. Или не веришь? Ага
Записан

Я вам что? Дурак? По выходным и праздникам на работе работать. По выходным и праздникам я работаю дома.
"Just because the language allows you to do something does not mean that it’s the correct thing to do." Trey Nash
"Physics is like sex: sure, it may give some practical results, but that's not why we do it." Richard P. Feynman
"All science is either physics or stamp collecting." Ernest Rutherford
"Wer will, findet Wege, wer nicht will, findet Gründe."
Olegator
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #5 : 04-01-2006 22:25 » 

Верю. Я подумал вы меня не так поняли. Мне показалось как-то странно. Зачем там С++?
Записан
Alf
Гость
« Ответ #6 : 04-01-2006 23:12 » 

C++ там для совместимости с предыдущими версиями. ТОчно так же, как и MFC. Для того, чтобы разработать новый софт в среде .NET, нужно время (и деньги), а чем старше организация, тем больше в ней накопилось старых программ, которые нужно продолжать эксплуатировать, а то и развивать.

У меня у самого есть тяжелое наследие в виде программы-монстра на C++/MFC, написанной лет 6 назад моими предшественниками почти на чистом С, которую до сих пор приходится сопровождать, а иногда и писать дополнения (под клятвенные заверения заказчика, что это в самый-пресамый последний раз). Не могут мне никак дать полгода переписать ее как следует с нуля, все время находится что-то более срочное.

Вот на этот самый случай в Studio .NET и присутствует старый добрый компилятор C++. Он дает запас времени на переучивание людей и переход на новую платформу, который не за один день делается. С нуля его учить, конечно, большого резона не вижу, ну а продолжать пользоваться тем, кто уже умеет, - почему бы и нет? Главное - не забывать, что это временная мера, и не сесть в калошу, как это было не так давно с упертыми разработчиками софта под DOS, которые вовремя не перешли на новую платформу. Ибо есть немалая вероятность, что в следующей Студии мы не найдем поддержки C++/MFC, как когда-то недосчитались привычных 16-разрядных компиляторов.
Записан
Olegator
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #7 : 04-01-2006 23:14 » 

Кстати, обратная прорблема: VS6 трудно поставить на XP.
Странно. У меня поставилась на XP SP1 без проблем. Хотя может от комплектации зависит.
Записан
Olegator
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #8 : 04-01-2006 23:17 » 

С нуля его учить, конечно, большого резона не вижу, ну а продолжать пользоваться тем, кто уже умеет, - почему бы и нет?
Так что же делать. Бросать учебник по С++ и начинать учить C#?
Мне тут не понятны некоторые моменты:
1. Ты как-то писал о том, что в C# придёться забыть про структурное программирование.
Как я понял про него придётся забыть по причине того, что он не поддерживается языком C#. Но само по себе структурное программирование стоит забывать.?
2. И вообще, если не учитывать, что придётся поддерживать старое программное обеспечение, стоит ли не думая бросать С++.
Или есть всё-таки что-то, о чём стоит сожалеть при оставлении С++.
« Последнее редактирование: 05-01-2006 00:09 от Olegator » Записан
Alf
Гость
« Ответ #9 : 05-01-2006 01:09 » 

Так что же делать. Бросать учебник по С++ и начинать учить C#?

Я говорил о том, что не вижу большого резона изучать С++ с нуля. Если ты недалеко ушел от нуля, то вполне можно подумать о переходе на C#. Если же успел изрядно продвинуться, двигайся дальше, иначе так до пенсии и будешь прыгать - пока освоишь C#, уже выдумают какой-нибудь C$, и работать будет просто некогда.

Мне тут не понятны некоторые моменты:
1. Ты как-то писал о том, что в C# придёться забыть про структурное программирование.
Как я понял про него придётся забыть по причине того, что он не поддерживается языком C#. Но само по себе структурное программирование стоит забывать.?

Забывать из того, что знал, вообще ничего не следует. Нужно лишь четко осознавать границы применимости той или иной парадигмы.

Основная идея структурного программирования - разбить основную задачу на ряд более простых и реализовывать каждую из них как отдельную процедуру. Каждая подзадача, в свою очередь, также делится на более простые, и так до тех пор, пока не выйдем на уровень тривиальных операций, которые легко выражаются средствами языка программирования. Таким образом, структурная программа - это набор взаимосвязанных процедур и структур данных, которые ими обрабатываются.

Объектная парадигма предлагает совсем другой взгляд на программу. Теперь программа - это набор объектов, которые обмениваются сообщениями. Каждый объект имеет собственный интерфейс, который определяет, какие сообщения объект может корректно обрабатывать. Кроме того, объект имеет набор обязательств перед другими объектами. Если в первом случае основу программы составляли процедуры, выполняющие действия над данными, то теперь мы имеем вместо этого объекты, посылающие друг другу сообщения, то есть акцент смещен с алгоритмов на сущности.

В C# (равно как и в Java) ты просто не сможешь создать отдельную процедуру, как мог в C++ или Pascal. Нужно просто привыкнуть к новому стилю программирования, и тогда ты не станешь пользоваться одиночными функциями, даже если пишешь на C++.

2. И вообще, если не учитывать, что придётся поддерживать старое программное обеспечение, стоит ли не думая бросать С++.
Или есть всё-таки что-то, о чём стоит сожалеть при оставлении С++.

Сам по себе С++ не так уж плох. Но, к сожалению, программы на чистом языке можно встретить лишь в учебниках (да и то не во всех). Если ты пишешь в среде MS Windows, тебе нужно создавать окна и элементы управления на них, запускать потоки и синхронизировать их и так далее. Но все эти средства уже не входят в стандарт С++ (да и не могли бы, поскольку зависят от операционной системы). И вот тут-то ты и поймешь всю разницу между красивой и гладкой программой из учебника Страуструпа и настоящей работающей программой в Visual C++.

Собственно, у тебя есть два основных выбора. Во-первых, ты можешь вызывать WinAPI. На API можно сделать практически все, но практически все там делать трудно, поскольку интерфейс весьма низкоуровневый. Поэтому помимо своей задачи тебе придется манипулировать хэндлами и громоздкими структурами, отлавливать низкоуровневые сообщения, и не дай тебе господь перепутать последовательность вызовов функций или забыть разыменовать указатель, - будешь вылизывать программу по шагам в отладчике, интерпретируя невразумительные сообщения об ошибках, ежели таковые будут.

Во-вторых, ты можешь использовать библиотеку MFC. По недоразумению некоторые считают ее объектно-ориентированной, но ты очень быстро убедишься, что это не так, - если структуры объявить классами и прилепить к ним несколько методов, объектами они от этого не станут. На каждом шагу ты будешь видеть торчащие уши тех же хэндлов и структур, постоянно будешь прибегать к помощи всевозможных визардов, которые будут набивать твой код невразумительными цепочками макросов, и т.д.

В общем, мое мнение такое. Сам по себе язык С++ в том виде, как его задумал Страуструп, весьма неплох (со скидкой на почтенный возраст, конечно). Но то, что мы имеем в виде MS VC++, продукт не самый приятный, и лично я расстаюсь с ним без малейшего сожаления. После него C#/.NET - как глоток свежего воздуха.
Записан
Olegator
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #10 : 05-01-2006 01:26 » 

Основная идея структурного программирования - разбить основную задачу на ряд более простых и реализовывать каждую из них как отдельную процедуру. Каждая подзадача, в свою очередь, также делится на более простые, и так до тех пор, пока не выйдем на уровень тривиальных операций, которые легко выражаются средствами языка программирования. Таким образом, структурная программа - это набор взаимосвязанных процедур и структур данных, которые ими обрабатываются.

Объектная парадигма предлагает совсем другой взгляд на программу. Теперь программа - это набор объектов, которые обмениваются сообщениями. Каждый объект имеет собственный интерфейс, который определяет, какие сообщения объект может корректно обрабатывать. Кроме того, объект имеет набор обязательств перед другими объектами. Если в первом случае основу программы составляли процедуры, выполняющие действия над данными, то теперь мы имеем вместо этого объекты, посылающие друг другу сообщения, то есть акцент смещен с алгоритмов на сущности.
Пока я не вижу большой разницы между разбиением на подзадачи и разбиением на объекты.
Пока в чём я вижу разницу:
1.   При разбиении на подзадачи я фактически разбиваю только на действия. А при разбиении на объекты я рабиваю и на действия и на данные, которые эти действия обрабатывают. Правда преимуществ этого подхода я не вижу.
Записан
Alf
Гость
« Ответ #11 : 05-01-2006 01:28 » 

Вопрос на засыпку: Бадда читал?
Записан
Olegator
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #12 : 05-01-2006 01:54 » 

Далее диалог пошёл по ICQ
 Olegator (04:30:47 5/01/2006)
Начал читать.
 Alf (04:32:56 5/01/2006)
Пересказ основ объектного проектирования займет сотню немаленьких постов, наверное.
 Alf (04:34:05 5/01/2006)
Сейчас ты учишь язык, а язык - лишь инструмент. Если я дам тебе ящик инструментов автослесаря, разве ты по виду гаечных ключей поймешь устройство двигателя?

 Olegator (04:36:02 5/01/2006)
Так что надо делать кроме изучения языка?

 Alf (04:37:00 5/01/2006)
Изучать методологию программирования. Язык - дело десятое. Я могу одно и то же написать на С++, Шарпе и Яве. Не в языке главное.
Это как для писателя язык. КАкая разница, что Шекспир писал на английском, а Толстой - на русском? Можно то же самое без проблем н алюбом языке сказать, если он достаточно развит.

 Olegator (04:41:13 5/01/2006)
Это я всё и раньше понимл.
Только раньше я понимл так "главное алгоритм"
А по отношению к ООП как сказать?

 Alf (04:41:49 5/01/2006)
Сценарий, прецедент.

Недавно в одной книжке хороший пример читал.
Преподаватель заканчивает лекцию и говорит студентам, что лекция окончена.
Простые студенты знают, что могут отдохнуть в течение перемены, а потом идти в аудиторию, где будут следующие занятия.
А старосты должны подойти к нему за журналом, в котором он отмечал отсутствующих.

Это и есть объектный подход: преподаватель отправил сообщение "урок окончен", а каждый объект сам знает, что делать в этом случае.

Согласно структурному подходу преподаватель должен был бы сам в цикле перебрать всех студентов и указать каждому из них, что ему делать дальше.

Вот в этом и состоит главное отличие.

 Olegator (04:47:32 5/01/2006)
Круто. Я начинаю понимать.
И ещё вопрос. В чём недостатки ООП?

 Alf (04:48:42 5/01/2006)
Насчет недостатков я не в курсе.

Вот еще пример. Ты написал письо и кинул конверт в почтовый ящик.
Почтальон увидел его и принес на почтамт.
Адрес на конверте - это сообщение для сортировщика. Тебе без разницы, кто и как будет его доставлять.
У тебя есть интерфейс - конверт. Передав его почтовым службам, ты знаешь, что они его доставят. Они отвечают за это.

Процедурный вариант - ты должен был бы описать алгоритм: вынуть письмо из ящика, принести на сортировку, собрать пакет на Васюки, отправить его с поездом номер 345...

Вместо набора алгоритмов у тебя есть набор объектов - черные ящики, которые знают, что делать при получении сообщения.

 Olegator (04:53:06 5/01/2006)
Я понял. Большая абстрогированность.
Т.е. из тех людей которые выискивают недостатки, все не правы.

 Alf (04:53:49 5/01/2006)
Если ты отдашь пакет дворнику, он не знает, что делать с письмом. В этом случае ты нарушил интерфейс - отправил сообщение объекту, который данное сообщение не понимает.
В лучшем случае он с ним ничего не будет делать. А может и испортить. Это сбой, твое письмо не дойдет до адресата.

Не просто абстрагированность. Каждый объект отвечает за свои действия. Преподаватель не говорит старостам собрать журналы групп, они сами знают, что это нужно сделать, получив сообщение "конец урока". Если не делают, значит, они неправильно работают.

 Olegator (04:58:08 5/01/2006)
Разве это и не есть абстрогированность.

 Alf (04:59:16 5/01/2006)
Абстрагированность - слишком общее понятие, оно подразумевает еще много чего. У ООП есть более конкретные черты.
Например, объект следит за целостностью своего состояния. У него есть внутренние переменные состояния, к которым невозможен прямой доступ извне.

Ты главную-то идею уловил?

 Olegator (05:07:58 5/01/2006)
Уловил

Легче всё учесть?

 Alf (05:08:28 5/01/2006)
Объектная парадигма ближе к естественным процессам, чем структурная.

Например, утром ты едешь на работу на автобусе.
Твоя задача - сесть на нужный маршрут. Водить автобус ты не умеешь, для этого есть специально обученный водитель. Ты просто пользуешься объектом "автобус 23", чтобы добраться до места.
По ходу дела водитель отправляет пассажирам сообщения - объявляет остановки. Он не знает, где выходишь лично ты. Ему все равно, у него своя работа.
Каждый пассажир принимает сообщения, и если это его остановка, он выходит из автобуса. Опять же он знает, как выйти. Задача водителя - подъехать к остановке и открыть дверь.
Потом ты по дороге покупаешь пачку жвачки. Отправляешь сообщение продавцу - деньги и марку жвачки, в ответ получаешь сдачу и жвачку. Водитель автобуса тебе жвачку не продаст - не умеет он обрабатывать такие сообщения.
Вот так ты строишь модель реальности, а потом она начинает жить своей жизнью, ты ей только сообщения подкидываешь извне.

 Olegator (05:14:30 5/01/2006)
Я понял, что и при структурном и при ОО прогрммировании всё равно приходиться всё учитывать. Но при ОО это делать проще. Как ты не раз говорил в других темах не надо держать в голове всё.

 Alf (05:15:02 5/01/2006)
Конечно, в конечном итоге ты все сам пишешь, комп - очекнь старательный тупица, ничего не знает сам.
Имено так работают мои модели телефонной станции - на входе звонки, на выходе соединения.
Но в каждый конкретный момент времени ты имеешь дело с чем-то одним. Если у тебя есть работающий объект, ты только шлешь ему сообщения, тебе неважно, что у него внутри. И самое главное - он не примет чужое сообщение, если ты ошибся.

А функция - дура. Если она вычисляет квадратный корень, она вычислит его и из денежной суммы, и из количества ворон на ветке. Больше возможности для ошибки.

 Olegator (05:19:11 5/01/2006)
Но его можно плохо сделать? Хотя всё, что угодно можно плохо сделать. Но всё-таки допустим у нас есть две плохо сделанные программы. Одна структурно другая ОО. В каком случае мне проще предпренимать дальнейшие действия?

 Alf (05:20:09 5/01/2006)
А чем они плохи? Они работают, но написаны некрасиво? Или не выполняют свою работу?

 Olegator (05:20:46 5/01/2006)
Пускай будет 4 ситуации.

 Alf (05:21:55 5/01/2006)
Ну если они не работают, их просто нужно выбросить. У тебя нет программ по существу, только бессмысленная писанина. Нужно с нуля начинать.
Если же работают правильно, то можно подвергнуть их рефакторингу. В этом случае при прочих равных условиях ОО программа лучше.

 Olegator (05:28:04 5/01/2006)
А если неизвестно где ошибка?

 Alf (05:31:13 5/01/2006)
Если точно знаешь, какой объект за что отвечает, найти ее нетрудно. Например, объект получает список оценок за семестр и выдает среднюю. Ты можешь проверить среднее на калькуляторе, и если нон выдается неправильно, ты точно знаешь, что виноват этот объект. А если на вход поступают уже испорченные оценки, виноват не он, а тот, кто отправлял сообщение. И так далее.

 Olegator (05:34:03 5/01/2006)
Если допустим я писал бы структурно и мне по работе требовалось хорошее знание алгоритмов изложенных в книге Кнута, то при переходе на ОО мне бы это для моей работы всё равно было бы нужно? Или всё-таки что-то не потребовалось бы?

 Alf (05:36:16 5/01/2006)
Разумеется, что-то не потребуется, но заранее ты ведь не можешь знать. Хотя в любом случае я бы не стал зубрить 101 вариант сортировки наизусть. Используй Кнута как справочник, зная, что ты всегда найдешь там детали.

 Olegator (05:37:45 5/01/2006)
Я имел ввиду именно при ипользовании ООП, а не сама по себе книга.
Это понятно что что-то мне не потребуется.

 Alf (05:40:28 5/01/2006)
Ты не забывай, что методы на самом деле - это тоже функции, даже ОО программы без алгоритмов не обойдутся. Где-то тебе придется отсортировать данные, где-то найти максимум-минимум-среднее... Просто алгоритмы из самоцели превращаются во вспомогательные действия при использовании ООП.
Ну и сам их вид меняется, конечно. Классический алгоритм - это рецепт, что и в какой последовательности делать. В случае ООП это больше похоже на слаженный коллектив - каждый хорошо знает свои обязанности, добросовестно их выполняет, получает указания и необходимую информацию и сам выдает их подчиненным.

« Последнее редактирование: 05-01-2006 02:45 от Olegator » Записан
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines