Я начинаю переводить свой рабочий проект на dot NET вообще и C# в частности. Недавно смотрел VS 2005. Написал на ней первую прогу (достаточно серьезную), где опробовал все интересующие меня технологии. Сказать что VS2005 мне очень понравилась - ничего не сказать. Все просто супер. Язык безусловно очень мощный. Очень удобно использовать интерфейсы в программе, создавать мощные многопоточные приложения со сложной синхронизации потоков - достаточно просто и удобно. Работать с данными тоже очень удобно. Во многих местах - даже удобнее и проще и быстрее чем в Fox'е. Например источником данных может являться не только запрос с SQL сервера, но и объект или коллекция объектов. Нужно просто реализовать в своей коллекции определенный интерфейс. Еще касательно данных: грядет расширение C# - LinQ (DLinQ и XLinQ).

По поводу Fox'а: Да язык простой и достаточно удобный, но совершенно не надежный. Сложные приложения, где часто создаються и разрушаються объекты - постоянно вылетают с ошибкой C5 (доступ к памяти), как ты их не пиши (нет возможности по настоящему контролировать их разрушение). Опять же нельзя реализовать многопоточность.

О себе: Пишу на Fox'e 6 лет. Паралельно в Delphi. Никогда не писал серьезных приложений на C++ по причине его ущербности и МНИМОЙ объекто-ориентированности. C# совершенно другое дело. Обратите на него внимание.

автор
VS 2005 вышел в начале ноября, за полтора месяца автор "написал первую прогу
(достаточно серьезную)". Теперь у всех его юзверей стоит фреймворк NET 2 и
всё летает и прекрасно работает. А, да, он ещё за полтора месяца это всё
протестировал.

********
хорош свистеть


Не дадо ерничать. Я полагаю что фразу построил правильно и вы меня поняли. Тем кто не понял поясняю:
Я написал прогу для себя, что бы опробовать возможности C# 2.0 и комфортность разработки программ на этом языке. Серьезность этой проги заключаеться в технологиях которые использовались при написании. Тяжелые алгоритмы расчета рентабельности были обернуты в потоки выполняющиеся одновременно и использующие и изменяющие одни и теже данные. Т.е. тестировалась многопоточность и средства синхронизации потоков в dot Net
Также была реализована библиотека классов и общих интерфейсов. И много чего еще, чего сейчас не вспомню.

Для тех кто в танке: Возможность писать на dot Net 2.0 появилась этак на пол года раньше ноября.

2 Sergey Ch

Имелась ввиду.
1. Его "натянутая на уши" ООП. Public поля вместо свойств с аксессорами доступа это ужасно.
2. Ужастно сложные и неудобные MFC,ATL
3. "Не удобный" с моей точки зрения интерфейс, куча incude в коде.
4. Натянутая на уши "визуальность"

В общем те кто писал на Delphi меня сдесь прекрастно должны понять.

В общем к VC++ у меня сразу как я его попробовал образовалась стойкая неприязнь за его неудобство и излишнюю трудоемкость.

Ну в общем чувствую что у многих сложилось впечатление что писать проги на C# (произносится Си-шарп) долго. Это совершенно неверное впечатление. Писать можно достаточно быстро и самое главное удобно. Заслуга оболочки VS2005. Очень дельный Intelli Sence, сразу подставляет нужные слова, создает по требованию заглушки в коде, подсказывет форматы вызовов перегруженных методов. Много возможностей в самой оболочке, например использование стандартных или написание своих снипетов.
В общем как и было заявлено MS'ом VS2005 экономит программеру кучу времени и снижает кол-во строк кода на несколько десятков процентов.

Один из показателей: C# чуствителен к регистру, но я это почувствовал всего несколько раз, поскольку IS переформатировал строчки и блоки кода, а также заканчивал слова.

Я точно не угрюмый:). Просто мне не понравилась тема в которую заводили некоторые ответы на мой пост и я ощетинился :).

Конкретно на этом примере ты прав. В VFP это можно сделать быстрее, чем на любом другом языке. Обобщая можно сказать, что на VFP быстрее чем на каком либо другом языке можно создать работающую версию приложения. Но вот то что с этим приложением происходит дальше в VFP мне никогда не нравилось. На определенном этапе развития приложения начинают сказываться недостатки FoxPro. В их число я вношу следующие:

1. Однопоточность.
2. Неполная власть над экземплярами объектов. (уничтожение объекта и то что должно быть методом в VFP обычно событие. Например Create. Отсутствие конструктора класса и.т.д.)
3. Можно написать класс как бы с 0 в prg, прописав в Create создание внутренних объектов, а в Destroy их уничтожение через Release, хранить в приложении ссылки на этот объект в нескольких местах, я так делал но... Приложение сыпется. Частенько совершенно в разных местах в разное время вылетает C5. Кроме того внутренние объекты тебе не показывает IntelliSence в designtime, а частенько и в runtime. Реально сложный объект, с множеством внутренних классов на Fox'е написать не получиться.
4. Fox слижком уж высокоуровневый для меня (это не недостаток а особенность). Многие вещи мне приходилось делать ActiveX'ом на Delphi.
5. Небогатая библиотека интерфейсных компонент (В 9 фоксе жить в принципе можно уже за счет полезных добавленных свойств на компоненты). В других средах я имею возможность написать интерфейсный компонент с 0 такой какой мне надо или переделать функциональность уже существующих. В Фоксе только один выход: Приобретать готовый ActiveX за деньги.
6. Достаточно медленное появление в FoxPro новых технологий в программировании.

В общем VFP вполне хорош для своей ниши и только. Когда приложение уже работает и эксплуатируется часто (у меня постоянно) встает вопрос о его выдвижении на качаственно новый уровень. Интерфейс получше, логика по круче, опять же многопоточность. И тут приложение приходиться полностью переписывать на другом языке.

ИМХО лучше затратить дополнителтное время в самом начале проекта на реализацию библиотеки классов приложения и базовой функциональности на должном уровне на таком языке как C#, чем "быстро" написать приложение на фоксе, а потом решать постоянно возникающие проблемы с недостатком функциональности.

PS. Программируя в VS2005 я испытывал реальный кайф от мощи и удобства этого языка, чего никогда не испытывал кодя на Фоксе и что-то подобное давно испытывал программируя на Delphi

PPS. По примеру: выбрать две таблицы с сервера, а затем уже на клиенте заджоинить их примерно таким же кол-вом строчек будет возможно в C# 3.0 с появлением LinQ. Коротко это расширение языка позволяет писать SQL для чего угодно не важно таблицы это на сервере или объекты в приложении.

автор1) А у меня не вылетают! Странно, не правда ли :) Может в консерватории надо
чего-то подправить :)

2) Механизм сборки мусора - ИМЕННО сборки мусора - ибо это в "старом добром"
C++ идёт "удаление объектов" (а потом Access Violation при обращении по
"дохлой" ссылке :) ) - в NET убиваются ссылки и "потом" уже работает код
реально убивающий объекты - так вот ЭТО в VFP и в C# - близнецы-братья. Так
что говорить о каких-то коренных отличиях - по меньшей мере
непрофессионально :( Видимо ты не понял ещё этой фишки NET-а (что может
быть), либо не понимаешь как работает фокс со ссылками и объектами (что
странно если ты на нём 6 лет пишешь)...

Дело в привычке и в стиле программирования. Я знаю все или почти все про механизмы сборки мусора и доступ по nil указателям и то как этого избегать. И вообще про внутреннию кухню ПО. Паралельно с Фоксом я всегда програмил на делфи. И что характерно ни в делфи ни теперь в дот нет мои готовые и отлаженные программы никогда не вылетали с этой ошибкой. И в фоксе порядок создания и уничтожения объектов весь выверен и тем не менее вылетает. Живых ссылок нет но что то где то остаеться висеть.

автор
Опять же нельзя реализовать многопоточность
Ну не упирается всё в многопоточность! Большинство аглоритмов по своей сути однопоточные, и не распараллеливаются, и "расщепив" их на кучу потоков, а
потом вставив массу "синхронизирующего" кода, дабы алгоритм считал как
положено, а не "летал в облаках" - мы никакого прироста скорости не
получим - скорее наоборот.

Совершенно верно. Большинстов алгоритмов трудно распаралелить. Но ведь ничего не должно мешать пользователю во время длительного запроса работать с какими либо другими функциями проекта.

авторКроме того на фоксе можно (пускай и не "напрямую", и с дополнительными
компонентами и затратами) создать многопоточное приложение (если уж очень
приспичит).

Я так и делаю. Создаю ком сервер на Delphi.

авторБолее того - ты возможно удивишься, но "внутри" фокс вовсе не однопоточен -
это твой User Code в одном потоке исполняется - а сама среда их имеет
несколько.
Вы меня за школьника принимаете? Конечно я не удивлюсь,ведь я всегда это знал.

авторИ конструктор у объектов в фоксе имеется, и деструктор, и проблем с
использованием этих самых объектов никаких существенных нету...

Это где это интересно он имееться ?. Вы наверное очень удивитесь узнав что "методы" Init и Destroy по сути являються событиями. Помимо других ярко выраженных признаков что вы думаете должно произойти напиши я в конструкторе nodefault? Ладно Destroy еще куда ни шло можно принять за деструктор, но где конструктор? Init? неа, ведь Load вызываеться перед Init'ом. Load? тоже нет. Он ведь есть только у формы и формсета. Кроме того явно сказано что load это event. Внутренняя кухня объектов в Фоксе от програмера скрыта. Смиритесь с этим. Нельзя на фоксе сделать полнофункциональный контрол. Вы когданибудь пытались засунуть компоненты в ячейки грида? Наверняка пытались. Теперь вы понимаете что я хочу сказать?. Я засунул и впринципе можно пользоваться. Потрать я на это дело еще немного времени я бы дажа заставил контрол в ячейке ресайзиться не только в ширину но и в высоту при изменении размера ячейки. Но я к счастью вовремя понял что нормального, надежного интерфейса из этого дела получиться не может поскольку 3\4 функциональности объектов недоступна програмеру.


авторДа, не очень
эффективно (из-за отсутствия типизации приходится все и вся хранить как
Variant-ы, что весьма медленно и памяти много кушает), порой не совсем
логично кажется (если иметь опыт программирования в других языках) - но ты
явно не про те проблемы говоришь, которые реально имеются...

Держи пример: FlexGrid и вообще внешние компоненты пользовал?. Без хелпа ведь невозможно ничего с ними сделать потому что не ясен формат методов и свойств. И это на полностью реализованных компонентах с открытой TLB.

авторЧтобы показывали - они должны быть описаны как статические члены класса (ADD
OBJECT ... AS или соответственно в vcx/scx прописаны на этапе разработки), а
для переменных должен быть использован "типизированный" синтаксис с LOCAL
.... AS ... А для "динамических" объектов - конечно не работает - откуда
фоксу знать, какой объект ты добавишь (или НЕ добавишь) в этот класс во
время исполнения!

Кроме того внутренние объекты тебе не показывает IntelliSence в
designtime. Как ты интересно засовываешь своего потомка коллекции в объект в disigntime.

Впрочем я давно не реализовывал классы в prg. Может там сейчас Local As и работает. Завтра проверю.

авторПро какой такой IntelliSense в рантайм идёт речь? Очень любопытно было-бы
услышать способы его реального применения!

Я уже написал. Неизвестный ActiveX.

авторНебогатая библиотека интерфейсных компонент
Можно подумать в NET сверхбогатый набор отличнейших компонент. То-то все
разработчики повально уходят от встроенных контролов в сторону "сторонних"
наборов компонент. Тоже, заметим, как правило небесплатных (если не воровать
конечно, а покупать).

В других средах я имею возможность написать интерфейсный компонент с 0
такой какой мне надо

авторБлин, честное слово достали уже эти заклинания - да НЕ ПИШЕТ практически
никто своих компонентов - такие возможности есть и в Delphi, и в C++ уже
кучу времени, и в NET есть и в фоксе есть! Только почему-то те кто громче
всего кричит о том что "среда супер, можно свои компоненты писать" - даже
банальный текстбокс для своих нужд не пишут - а ищут всякие сторонние,
которые "и то и это и пятое и десятое" делают. Я понимаю, что сама
"возможность" душу греет - но какой от того прок, если не пользоваться?
Мне только это не рассазывай. Я никогда не буду платить за простой компонент 500 баксов, если это не на 100% то что мне нужно и ктому же это коряво работает. Недавно смотрел контролы от ComponentOne и иже с ними.
Нормальное меню офисного Outlook не подскажешь откуда взять? Желательно баксов за 10, больше оно не стоит.

авторили переделать функциональность уже существующих
Ещё менее вероятный сценарий - даже если удалось украсть исходники к
компоненте, или скачать бесплатную - 99.9% программеров не полезут в этот
код - отчасти из-за того что там попробуй ещё разберись :)

Тоже мне шпион. Про перехват событий и подмену оконных процедур ничего не слышал?

авторА если говорить "вообще" - то в фоксе тоже можно писать свои компоненты,
причём "переделать функциональность" во многих случаях можно гораздо проще и
понятнее чем в том-же NET.

Про грид помнишь?


авторВ Фоксе только один выход: Приобретать готовый ActiveX за
деньги.
Просто смешно :) Без комментариев.

Конкретно где смешно?

Достаточно медленное появление в FoxPro новых технологий в
программировании

авторЕщё более смешно. Это про "сферических коней в вакууме", если кто не понял
сразу :) Как в том анекдоте - "а я... а у меня... а я счас как дам по
морде!"
Давай, приведи хоть один пример "новой технологии в программировании" -
ИМЕННО технологии, а не реализации какой-нить фишки, известной ещё 20-30 лет
назад. Желательно именно для NET который такой весь из себя "прогрессивный".

1. Отсоединенные рекордсеты.
2. Интерфейсов в Фоксе есно никогда вообще не будет.

При вашем желании завтра напишу еще.

автор
Никогда не писал серьезных приложений на C++ по причине его ущербности
и МНИМОЙ объекто-ориентированности
Извини, но после ТАКОГО заявления начинаешь с большим сомнением относится ко
ВСЕМ твоим словам.
Это значит язык, который большинство разработчиков считают "эталонной"
реализацией ООП, на котором пишется подавляющее большинство примеров во всех
книжках по ООП - и это он "мнимо ОО"! Мощно сказано :)

А я всегда относился к слову "большинство" с большой настороженностью чего и вам советую. Про ущербность C++ спрашивать у сишников бесполезно. Спроси у дельфистов. Коротко сишники были бедными родственниками в ООП пока меньшинство несколько пятилеток програмило на делфи. Даже TurboVision в борландовсих Turbo C и Turbo Pascal была более объектно ориентированной.


авторУжастно сложные и неудобные MFC,ATL
Можно подумать что тебя заставляют их использовать ;) Вот мне в фоксе не
нравятся "Ужастно сложные и неудобные" классы FFC - я их и не использую.
Только глупо говорить про имеющуюся НО НЕОБЯЗАТЕЛЬНУЮ примочку СРЕДЫ - что
это существенный недостаток ЯЗЫКА.
Кстати ещё можно очень даже поспорить настолько ли они неудобны.

С++ без этих библиотек и было бы большинство не MS C++ а Borland CBuilder :)
Спорить можешь с MS. Они на каждом шагу кричат о том насколько они были неудобны.


"Не удобный" с моей точки зрения интерфейс, куча incude в коде.
Натянутая на уши "визуальность"

авторБа, да уважаемый сэр не может отделить ЯЗЫК C++ от среды программирования MS
VC++ ;)
Честное слово - после этого создаётся впечатление, что вы не далее как вчера
из-за студенческой скамьи встали...
К сведению - существует большое число разнообразных компиляторов и сред
разработки под C++ - в том числе и от так любимого вами Borland-а (хотя BCB
это во многом извращённая реализация, но тем не менее рисовать на ней
формочки методом "тыка" и "писать программы" не введя ни единой строки
кода - это вполне возможно - и некоторые конечно так и делают).

Жаль что вы сразу не поняли что я говорил про C++ от MS. Помоему все в моих словах на это указывало. Или нет. Привидите в пример мои строчки где могло бы показаться что я говорил про что-то иное. Например про CBuilder.
Кстати подобный нравоучительный и унизительный тон выдает в вас подростка, или не доконца повзрослевшего взрослого.


авторСерьезность этой проги заключаеться в технологиях которые
использовались при написании
Вот вот - соль не в том что сама прога хороша, а в том что "серьёзные
технологии использовались" - гигантомания в действии - вместо того чтобы за
5 минут наваять на том-же фоксе примитивнейший но рабочий вариант
"телефонного справочника", мы будем пол-года на NET писать "многопоточный",
"распределённый", "объектный снаружи и изнутри" и т.п. А спрашивается ЗАЧЕМ?
Вы опять извращаете мои слова. Перечитайте мои посты пожалуйста. Там вы увидите что я имел ввиду не блокнот а сложное с богатой функциональностью реально эксплуатирующееся на предприятии приложение.

авторКаждая задача может быть решена неисчислимым множеством способов - среди них
будет очень много ущербных, медленных, неправильных... Будут и хорошие
конечно, но даже среди них будут те которые минимально достаточны, и те
которые невообразимо избыточны - вплоть до промышленных ERP систем,
применяемых для "учёта скрепок"...
Ты наверное тоже ERP систему написал :) Причём в одиночку, за пол-года, не
имеющую никаких проблем, масштабируемую, идеально настраиваемую...
Речь шла просто об удобстве кодирования самых простых вещей. Обратите к примеру свое внимание на то как в VS2003+ используються интерфейсы и честно скажите вам бы не хотелось использовать их в своем коде? Если нет то вам срочно нужно переучиваться.


авторлучше затратить дополнителтное время в самом начале проекта на
реализацию библиотеки классов приложения и базовой функциональности на
должном уровне
Золотые слова! Только отчего такой странный вывод то? Т.е. на фоксе я писать
"правильно" не могу - обязательно налеплю абы как и абы чего - а вот на NET
напротив - я не могу НЕправильно написать, сделав кучу бессмысленных
классов, раскидав логику обработки данных по интерфейсу, использовав десяток
идеологически разных подходов для выполнения по сути сходных задач... В
общем из пальца высосанный и не соответствующий действительности вывод из
общеизвестного факта.
Читайте выше мои посты про объекты. Или пример? Я сюда кидаю исходник моего класса на C# а ты делаешь аналог по удобству и функциональности в Fox'e.

авторОптимизаторы появились
в СУБД дай бог уже сколько десятков лет назад - и до сих пор идёт их
оттачивание и улучшение - а MS значится за пару лет создаст подобную
технологию для объектных коллекций :)
Помните мы говорили про ниши?.
Простой пример использования: Я сделал запрос к БД. После этого на этих данных покрутился сложный алгоритм расчета (не TSQL есно.) На выходе коллекция объектов. Мне надо этими объектами ограничить следующие выборки из БД. Мои действия сейчас? Клею из них XML отправляю на сервер, там парсю и вставляю в запрос. Никаких лишних действий сдесь не замечаете?

авторИзвиняюсь за многословность, но уже достают пустые псевдо-рекламные
сообщения - вместо того чтобы показать реальные плюсы и минусы среды (уж
коли поработал там), или реально рассказать что и как было применено, почему
именно так, что это дало и чем это так замечательно - начинается какая-то
пустая болтовня ни о чём и пальцегнутие...

Я написал словами недостатки VFP и достоинства C# для объемных проектов и нетолько. Вы не поняли. Это ваша боль. В чем претензии ко мне? Мне сюда выкинуть куски кода? нет проблем. Мало конкретики? тогда опять же вам нужен код?

ГДЕ РЕКЛАМА?.

PS. Если Вы не измените тон впредь я вас буду игнорировать.
PPS to All. Я не рекламирую C# и не призываю всех срочно туда переходить. Если вы не забыли я сам пишу на Фоксе. Просто я хотел донести мысль о выгодах которые программер получает при кодинге на Дот Нет, которые выражаються в конце концов в мощном серьезном стабильном быстром и удобном для пользователя конечном продукте.

IMHO Nekrasivo kak-to prikhodit' v gosti k radushnym hoziaevav i vo vremia obeda zayavit' chto mol obed vkusniy no gotoviat oni ego v otstoynyh kastriulyah. A nastoyashiy borshch mojno svarit' tol'ko v takih chornych s blestiashchimi kryshechkami.
Ya vas tut vpervie vstretil, a te ludi, koroyh vi sobralis' ignorirovat' bol'she polutora tisyachi postov imeut i vse v temu. A vi ne s nashego sela i ne znaem my vas.

Ну извините что наступил на больную мозоль.
Что бы общаться нужно как минимум уметь выслушивать собеседника и отвечая не оскорблять его. Я себя не на помойке нашел поэтому не собираюсь вести диалог с теми кто не умеет общаться. Оскорблять и я могу не хуже других, но на форумах я себе этого никогда не позволял. Потому что на оскорбления в онлайн адекватно ответить не возможно (в реале можно в морду дать), а я не хочу что бы кто-то подумал что я прячусь за монитором.

авторNravitsia vam rabotat' s dannymi cherez pen'-kolodu: collection of custom classes, XML, XML parsing, SQL server - good luck. Tol'ko vse eto stoit deneg (legal'no) plus ofigenny overhead (.NET framework - ofigenny COM server, BTW).Vi sortiruete custom collections? I kak, na kakikh objemakh mojno vichodit' pokurit'? To je s poiskom. Pri bol'shyh obemah dannykh custom collections eto "v serjoz i nadolgo".

Большие объемы должны быть на сервере в виде реляционных таблиц, а не на клиенте. Здесь ничего не изменилось.

авторOtsoedinennye nabory dannyh - ne smeshyte. Fox davno ranotaet s cursorami, kotorye i est' otsoedinennymy i vsegda byli. Kidaete v XML - pasuete hot' na kulichki, vozvrashchaete nazad XMLUPDATEGRAM() ...

Пожалуй.

авторDa chtoby novie Foxovskie fichi izuichit' - paru let nado potratit'. Legche napisat' paru bezdelushek i posle kajdogo obloma iskrenne verit' cho eto Fox vinovat :))
Не смешите про пару лет.
Опять вы про безделушки. Надоело это коментировать.

авторInterfaces toje, mojno emulirovat' bilo by jelanie. Popadalis' mne na glaza stat'i s opisaniem.
Нельзя.

авторGlavnoe ruki normal'no zatochennye i golova na plechah. I ne budet Fox po C5 viletat'. :))

Мог бы ответить, унизив тебя, но это не мой метод.

А вообще я думаю что ошибся тредом. Вы не готовы к подобному диалогу. Что бы запросто взять и обсудить недостатки вашего (и моего) любимого Фокса и быть готовым принять тот факт что появляються новые, более удобные и мощные продукты, на которые стоит обратить свое внимание и возможно использовать их, нужно иметь здоровый взгляд на вещи, а не упираться руками и ногами в хороший, но уходящий продукт.

авторИнтересный диалог (если не обращать внимание на "неполиткорректность" некоторых высказываний :( ).
У меня только одно замечание к .NET - ужасная скорость...
Сравниваю на простом примере - работа EM для SQL 2000 и аналогичного инструмента (работающего под .NET 2.0) для SQL 2005. Красиво, слов нет, но какой ценой. Мои заказчики люди практичные и если перед ними стоит выбор "красиво" или не очень, но значительно "быстро", то они ВСЕГДА выбирают "быстро". Вот так. А что выбирают заказчики, то выбираю и я.

Запросы крутяться на серверею поэтому сдесь скорость та же. Готовая программа работает быстро. На счет быстрее фокса или нет я не проверял, поскольку нет еще рабочего проекта. Теоритически должно работать существенно быстрее так как dot.Net это компилятор.
Management Studio и интерфейс VS действительно подтормаживает. Но это design time и это торможение с лихвой окупаеться заложенным функционалом.

авторЭто мой выбор, но мне было интересно послушать и мнение уважаемого Krey.
С уважением, Алексей
Спасибо Алексей.

Извини Crip.
Да все тот же проект. Нет слеты не частые. У некоторых пользователей может несколько раз в день слететь, а может не слететь. Ни к какому месту кода эти слеты не привязаны.