Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 226
Проверка на попадание во множество — легко реализуется с помощью Linq
Зато как элегантно в Delphi выглядит этот ихний «Begin… end», и оператор присвоения ":=".
Это излишество всегда отталкивало меня от языка. Код просто труднее читать. Визуально обрамление метода в скобки куда приятней.
Это излишество всегда отталкивало меня от языка. Код просто труднее читать. Визуально обрамление метода в скобки куда приятней.
Угу. А самое прикольное — это попрограммировав в delphi или php несколько часов, возвращаться в нормальные среды, и ставить ":=", а также точку вместо плюса для строк. Бууууээээээ…
Согласен, работа с несколькими языками и средами мешает доводить до автоматизма применение некоторых часто используемых операций. Например, использование комбинаций клавиш для компилирования проекта, написание операций присваивания и проверки на равенство.
Это в свою очередь замедляет скорость работы. Но я стал замечать, что со временем переключение между Delphi и Visual Studio у меня стало происходить гораздо быстрее. За все время изучения C# я только один раз умудрился написать в Visual Studio begin..end. Сам посмеялся над собой и продолжил работать.
Человек ко многому может привыкнуть. Иногда нужно приложить для этого некоторое усилие. Думаю еще, что различающийся интерфейс сред разработки помогаем нашему подсознанию делать правильный выбор во время работы.
Это в свою очередь замедляет скорость работы. Но я стал замечать, что со временем переключение между Delphi и Visual Studio у меня стало происходить гораздо быстрее. За все время изучения C# я только один раз умудрился написать в Visual Studio begin..end. Сам посмеялся над собой и продолжил работать.
Человек ко многому может привыкнуть. Иногда нужно приложить для этого некоторое усилие. Думаю еще, что различающийся интерфейс сред разработки помогаем нашему подсознанию делать правильный выбор во время работы.
":=" — оператор смерти.
Вы программируете в Delphi? Если да — вы меня поймёте.
Вы программируете в C#? Если нет — то вы не поймёте меня никогда.
Язык Pascal препятствует написанию сложных программ. Препятствует всем — и реализациями компилятора, и самими языковыми конструкциями.
Язык C# делает это в меньшей степени.
— Паскаль — французский математик, физик, литератор и философ.
Вы программируете в C#? Если нет — то вы не поймёте меня никогда.
Язык Pascal препятствует написанию сложных программ. Препятствует всем — и реализациями компилятора, и самими языковыми конструкциями.
Язык C# делает это в меньшей степени.
— Паскаль — французский математик, физик, литератор и философ.
using System.IO;
static void Main(string[] args)
{
List lines = File.ReadAllLines(«d:\\1.txt»).ToList();
lines.Insert(0, «Доброго времени суток!»);
File.WriteAllLines(«d:\\1.txt», lines);
}
p.s. я тоже поклонник Delphi… в учёбе помогает быстро решать необходимые задачи…
static void Main(string[] args)
{
List lines = File.ReadAllLines(«d:\\1.txt»).ToList();
lines.Insert(0, «Доброго времени суток!»);
File.WriteAllLines(«d:\\1.txt», lines);
}
p.s. я тоже поклонник Delphi… в учёбе помогает быстро решать необходимые задачи…
имелась ввиду переменная: List<string> lines
Спасибо за пример. Красивое и компактное решение.
… Которое скорей всего скажет «ёк» на файле в 1Гб, например, т.к. он весь будет читаться в файл.
Работа с строками как с потоком предназначена как раз для того чтобы не загружать все содержимое в память, а работать как с непрерывным потоком. Немного другая идеология.
Для мелких файлов — решение покатит. А сделав то же самое на StreamReader \StreamWriter — можно получить быстрое и универсальное решение…
Работа с строками как с потоком предназначена как раз для того чтобы не загружать все содержимое в память, а работать как с непрерывным потоком. Немного другая идеология.
Для мелких файлов — решение покатит. А сделав то же самое на StreamReader \StreamWriter — можно получить быстрое и универсальное решение…
TStringList я думаю, так же реализован
так это как? прочтение в память всего файла или работа с строками файла как с входным потоком строк?
Судя по скорости загрузки текстовых файлов, у меня складывается впечатление, что он всю информацию загружает в память. В разделах справки я точного ответа не нашел.
Поэтому, предложенный MarrySun пример, очень даже подойдет в качестве замены на C# примера из статьи. Пусть даже он будет работать немного медленнее.
Поэтому, предложенный MarrySun пример, очень даже подойдет в качестве замены на C# примера из статьи. Пусть даже он будет работать немного медленнее.
using System.IO;
static void Main(string[] args)
{
File.AppendAllText(@"C:\Log.txt", "Program started");
}
Тоже не любил раньше документацию.
Если очень хочется проверки на попадание «как в дельфи», до делаете Enumerable.Range(min, max).Contains(number), но быстродействие немного удручает — лучше две булевых проверки.
Вместо TStringList в C# используется StringBuilder.
Вложенные функции — да, отсутствуют, лучше использовать нормальные функции, а не анонимные делегаты — они дают мусор в стеке.
Приведение типов — кошмар, да, я для этого реализовал функцию As:
public static class ObjectExt { public static T As<T>(this object arg) where T: class{ return arg as T; }
Вызов: employee.As<Manager>().ManagerFunc();
Просто за синтаксисом [classname](arg) уже закреплен конструктор.
Чтения в .NET нет, только отправка, сторонних компонентов море.
Вместо TStringList в C# используется StringBuilder.
Вложенные функции — да, отсутствуют, лучше использовать нормальные функции, а не анонимные делегаты — они дают мусор в стеке.
Приведение типов — кошмар, да, я для этого реализовал функцию As:
public static class ObjectExt { public static T As<T>(this object arg) where T: class{ return arg as T; }
Вызов: employee.As<Manager>().ManagerFunc();
Просто за синтаксисом [classname](arg) уже закреплен конструктор.
Чтения в .NET нет, только отправка, сторонних компонентов море.
и следовали guidelines майкрософта которые предписывают выкидывать null ref если в эктеншен метод передается null? И был не ад?
не проще ли скастовать и проверить на null?
не проще ли скастовать и проверить на null?
И был не ад, потому что проверки на null у меня всегда превентивные.
внутри As? Это по гайдлайну МС запрещено.
В общем я тут согласен с ZlobnyiSerg т.к. данный код доставит больше проблем чем плюшек.
Я понимаю что вы знаете как ее применять, а вот другие члены команды — могут и не знать или забыть или еще что-то…
… И будут у вас вызовы а-ля
var x =null;
x.As<Manager>.ManagerFunc()
И будут они молча проглатываться ( вы же проверяте все =))
А положено им будет выкидывать NullReference Exception
и потомки будут смотреть на эту глупость и распространять ее в массы…
И так родится индусский код
А на седьмой день захавает он мозг неокрепших программистов…
И будет мор, глад и болезни черные…
etc...etc...etc…
В общем я тут согласен с ZlobnyiSerg т.к. данный код доставит больше проблем чем плюшек.
Я понимаю что вы знаете как ее применять, а вот другие члены команды — могут и не знать или забыть или еще что-то…
… И будут у вас вызовы а-ля
var x =null;
x.As<Manager>.ManagerFunc()
И будут они молча проглатываться ( вы же проверяте все =))
А положено им будет выкидывать NullReference Exception
и потомки будут смотреть на эту глупость и распространять ее в массы…
И так родится индусский код
А на седьмой день захавает он мозг неокрепших программистов…
И будет мор, глад и болезни черные…
etc...etc...etc…
Мало ли что там по гайлдайнам МС запрещено — этот код успешно применяется во множестве проектов и с ним никогда проблем не было.
Объясняю подробно. Если у тебя при кастинге вылетает InvalidCastException — ты мудак, ты чего-то не предусмотрел. Если ты используешь приведение as и получаешь NullReferenceException — ты мудак, ты чего-то не предусмотрел. В моих проектах никогда не ловится ни один из этих типов эксепшенов — и, что удивительно, они там не появляются.
Просто нужно мозгом думать, а не писать null.As() — тогда проблем не будет. А если писать как обезьянка, то да — тогда пишите по гайдлайнам микрософта, обмазывайтесь ассертами и все равно все будет крашиться.
Объясняю подробно. Если у тебя при кастинге вылетает InvalidCastException — ты мудак, ты чего-то не предусмотрел. Если ты используешь приведение as и получаешь NullReferenceException — ты мудак, ты чего-то не предусмотрел. В моих проектах никогда не ловится ни один из этих типов эксепшенов — и, что удивительно, они там не появляются.
Просто нужно мозгом думать, а не писать null.As() — тогда проблем не будет. А если писать как обезьянка, то да — тогда пишите по гайдлайнам микрософта, обмазывайтесь ассертами и все равно все будет крашиться.
Объясняйте это не мне, а своей команде (а уж кто и что там вызывает, как мудак или нет — это уже дело ваших собственных сексуальных ориентаций, и постарайтесь поменьше употреблять мат, это больше характеризует Вас, а не тех, кого вы хотите назвать мудаками).
Повторять бессмысленно, у вас свой велосипед, с шахматами и поэтессами. и его вы ни на что, даже более здравое, не променяете (это очевидно по тону).
Просто обращу внимание, что ваш код extension method'а As, если внутри него реализована проверка типа if(thisObj == null) return; отработает успешно, но дальше вы не можете полагаться ни на результаты вызова ManagerFunc ни на то, что объект вообще не нулл. Т.е. вы просто не знаете точное состояние программы, т.к. в зависимости от исходного приводимого объекта (валидный или неприводимый\null) у вас будет 2 состояния. И вам надо помнить о таких вещах. А если бы выкинули исключение на null — то возможное состояние — только одно, а при null — была бы другая ветка программы.
В общем переубеждать даже не собираюсь — каждый дро… т как он хочет. Я предпочитаю так код не писать, по вышеизложенным причинам.
Повторять бессмысленно, у вас свой велосипед, с шахматами и поэтессами. и его вы ни на что, даже более здравое, не променяете (это очевидно по тону).
Просто обращу внимание, что ваш код extension method'а As, если внутри него реализована проверка типа if(thisObj == null) return; отработает успешно, но дальше вы не можете полагаться ни на результаты вызова ManagerFunc ни на то, что объект вообще не нулл. Т.е. вы просто не знаете точное состояние программы, т.к. в зависимости от исходного приводимого объекта (валидный или неприводимый\null) у вас будет 2 состояния. И вам надо помнить о таких вещах. А если бы выкинули исключение на null — то возможное состояние — только одно, а при null — была бы другая ветка программы.
В общем переубеждать даже не собираюсь — каждый дро… т как он хочет. Я предпочитаю так код не писать, по вышеизложенным причинам.
В нашей команде все люди с мозгом, поэтому у нас все хорошо, но спасибо, что поинтересовались.
Мне вспомнился афоризм «Программист на Фортране может написать программу на Фортране, используя любой другой язык». C# — это не как Delphi, только новее. Это другой язык и не все приемы, которые работали в Delphi, работают в C#. Переходя на новый язык нужно менять и свои привычки. Я сейчас довольно часто работаю с кодом на C#, который написали бывшие дельфисты, и у меня иногда просто не хватает слов, чтобы обьяснить им, насколько узко а подчас и неправильно они используют возможности C#.
По поводу проверки попадания в множество, вы же понимаете, что ваш способ проверки ужасно медленный? Куда быстрее будет так:
Если такую проверку надо выполнять часто, то делаете extension метод:
По поводу приведения типов, зато оно понятно и привычно разработчикам, пришедшим из плюсов. Анонимные методы — дело вкуса, обычно если метод довольно большой и содержит некоторое количество внутренних методов, то можно его выделить в отдельный приватный класс.
Соглашусь по поводу получения почты — это и правда один из недостатков дотнета сейчас. Не знаю почему так сложилось.
Что касается Visual Studio — попробуйте поставить и попользоватся Resharper'ом хотя бы на протяжении триального периода (30 дней), вы удивитесь, насколько удобной станет среда разработки с этим плагином.
По поводу проверки попадания в множество, вы же понимаете, что ваш способ проверки ужасно медленный? Куда быстрее будет так:
if(x >= 37 && x <= 75)
Если такую проверку надо выполнять часто, то делаете extension метод:
public static bool In(this int x, int a, int b)
{
return x >= a && x <= b;
}
// и используете его так:
if(x.In(37, 75))
{
// todo
}
По поводу приведения типов, зато оно понятно и привычно разработчикам, пришедшим из плюсов. Анонимные методы — дело вкуса, обычно если метод довольно большой и содержит некоторое количество внутренних методов, то можно его выделить в отдельный приватный класс.
Соглашусь по поводу получения почты — это и правда один из недостатков дотнета сейчас. Не знаю почему так сложилось.
Что касается Visual Studio — попробуйте поставить и попользоватся Resharper'ом хотя бы на протяжении триального периода (30 дней), вы удивитесь, насколько удобной станет среда разработки с этим плагином.
В свое время видел, что могут вытворять программисты perl перешедшие на Delphi, поэтому понимаю вас. Согласен с тем, что C# это новое Delphi. Я как раз приверженец всестороннего изучения языка перед началом его профессионального использования. Другой вопрос, что иногда у людей нет на это времени. Но это как правило попытка оправдаться, не соответствующая действительности.
Не смотря на медленную работу моего примера, у него есть и явные преимущества, поскольку множество можно менять динамически во время выполнения приложения. Кроме того можно задавать диапазоны значений, проверка на попадание в которые будет вызывать загромождение условного оператора.
Ну и еще одна причина, почему я использовал множества, это высокая скорость работы со множеством в Delphi. А в статье как раз идет попытка рассказать о том, чего мне не хватает в C#. И на несколько моих вопросов я уже получил ответы.
Не смотря на медленную работу моего примера, у него есть и явные преимущества, поскольку множество можно менять динамически во время выполнения приложения. Кроме того можно задавать диапазоны значений, проверка на попадание в которые будет вызывать загромождение условного оператора.
Ну и еще одна причина, почему я использовал множества, это высокая скорость работы со множеством в Delphi. А в статье как раз идет попытка рассказать о том, чего мне не хватает в C#. И на несколько моих вопросов я уже получил ответы.
Для меня одним из решающих доводов в пользу временной смены Delphi на C# была WPF и возможность богатой визуализации в последней.
Насчет TStringList можно использовать List и string.Split(' '), на пару строк получится больше.
А вообще проблема насчет отсутствия какого то класса высосана из пальца, т.к. можно сделать свою сборку кода, в который можно реализовать функционал например того же TStringList'а отдельным классом.
>>поскольку создание делегата является частью тела метода:
Не силен в дельфи, но там же функция/процедура тоже тогда будет являться часть метода.
Насчет поиска:
1)Поиск в студии имеет очень широкий ряд возможностей за счет поддержки регулярных выражений.
2)Если вам он не нужен, то воспользуйтесь «коротким» поиском (Ctrl + / или поле ввода в тулбаре). Абсолютно то же самое, что и вышеуказанный поиск.
Насчет закладок:
Функциональность студии всегда можно расширить за счет аддонов, которых есть довольно большое количество на все потребности. Если вы все же не сможете найти его, то можете написать сами (не думаю, что с этим разобраться будет трудно).
Насчет почты:
Не проверял но все же скину stackoverflow.com/questions/44383/reading-email-using-pop3-in-c
Насчет привидения:
В некоторых случаях (как например в примере) вполне можно обойтись без него (указать класс наследник или var), но иногда это действительно раздражает :)
Насчет множеств:
Плохо знаком с множествами, но думаю что можно обойтись без HashSet. Например:
bool[] set = new bool[256];
for (int i = 37; i >Мак-Дональд раскрывает суть нового подхода Microsoft к формированию пользовательского интерфейса посредством языка разметки HAML (исправьте)
Да, помню в книжно пролистал её в надежде узнать что это за зверь, и не заметил как её купил :) Теперь использую только WPF (Silverlight).
А вообще проблема насчет отсутствия какого то класса высосана из пальца, т.к. можно сделать свою сборку кода, в который можно реализовать функционал например того же TStringList'а отдельным классом.
>>поскольку создание делегата является частью тела метода:
Не силен в дельфи, но там же функция/процедура тоже тогда будет являться часть метода.
Насчет поиска:
1)Поиск в студии имеет очень широкий ряд возможностей за счет поддержки регулярных выражений.
2)Если вам он не нужен, то воспользуйтесь «коротким» поиском (Ctrl + / или поле ввода в тулбаре). Абсолютно то же самое, что и вышеуказанный поиск.
Насчет закладок:
Функциональность студии всегда можно расширить за счет аддонов, которых есть довольно большое количество на все потребности. Если вы все же не сможете найти его, то можете написать сами (не думаю, что с этим разобраться будет трудно).
Насчет почты:
Не проверял но все же скину stackoverflow.com/questions/44383/reading-email-using-pop3-in-c
Насчет привидения:
В некоторых случаях (как например в примере) вполне можно обойтись без него (указать класс наследник или var), но иногда это действительно раздражает :)
Насчет множеств:
Плохо знаком с множествами, но думаю что можно обойтись без HashSet. Например:
bool[] set = new bool[256];
for (int i = 37; i >Мак-Дональд раскрывает суть нового подхода Microsoft к формированию пользовательского интерфейса посредством языка разметки HAML (исправьте)
Да, помню в книжно пролистал её в надежде узнать что это за зверь, и не заметил как её купил :) Теперь использую только WPF (Silverlight).
Закладки в студии делаются двойными комбинациями (sic!):
CTRL+K, K — поставить закладку;
CTRL+K, N — перейти к следующей
CTRL+K, P — перейти к предыдущей
Нет нужных книг? Добро пожаловать в интернет — тот же Amazon находит более 200 книг по Delphi (этого мало?!).
Проблемной оказалась только 2005 версия делфи, все остальные планомерно развивались и постоянно добавлялись новые фичи. Да, разница между 7 и 2010 или XE — будет ощутимой, а вот разница между 2006-2007 и 2010 уже не такая уж и большая.
Переход на C# только потому, что «на форумах сторонники шарпа загнобили делфи» — не очень-то дальновидно. Желательно изучать то, что требуется здесь и сейчас, для своей работы и карьеры.
CTRL+K, K — поставить закладку;
CTRL+K, N — перейти к следующей
CTRL+K, P — перейти к предыдущей
Нет нужных книг? Добро пожаловать в интернет — тот же Amazon находит более 200 книг по Delphi (этого мало?!).
Проблемной оказалась только 2005 версия делфи, все остальные планомерно развивались и постоянно добавлялись новые фичи. Да, разница между 7 и 2010 или XE — будет ощутимой, а вот разница между 2006-2007 и 2010 уже не такая уж и большая.
Переход на C# только потому, что «на форумах сторонники шарпа загнобили делфи» — не очень-то дальновидно. Желательно изучать то, что требуется здесь и сейчас, для своей работы и карьеры.
Это как раз таки дальновидно. Переход позволит по крайней мере на ближайшие 5 лет (но я уверен, что и больше) быть в тренде.
Безусловно, все зависит от конкретных обстоятельств, но, тем не менее, тенденция налицо и уже довольно давно.
Безусловно, все зависит от конкретных обстоятельств, но, тем не менее, тенденция налицо и уже довольно давно.
Неужели за 10 лет еще не все поняли, что .Net — это всерьез и надолго?
Посмотрите на дату публикации: 2004 год — самое начало дотнета. Через несколько лет Джоель сам признал, что ошибался (извините, мне лень искать ссылку на статью, где он это сделал). На самом деле, .Net — это самое что ни на есть Fire And Motion.
> Через несколько лет Джоель сам признал, что ошибался (извините, мне лень искать ссылку на статью, где он это сделал).
Не надо искать статью. Через несколько лет Джоэль сделал StackOverflow.com на .NET, nuff said.
Не надо искать статью. Через несколько лет Джоэль сделал StackOverflow.com на .NET, nuff said.
МС, вроде как, глубоко фиолетово на мир Linux.
Вы правда считаете, что ваш комментарий уместен в контексте того, что здесь обсуждают переход с гвоздями прибитого к WinAPI Delphi на хоть немного но кроссплатформенный .Net? При чем тут вообще линукс? Пользователи этой ОС никогда и не были целевой аудиторией Delphi-разработчиков.
Ваш пост — это либо очень толстый троллинг, либо абсолютное непонимание сути технологий .NET и wine.
pasha_golub, кстати, совершенно прав — благодаря стандартному использованию WinAPI, приложения на Delphi практически без проблем можно «завести» под Wine'ом, а вот .NET-приложения ни под Вайном не запустятся, ни в моно не откомпилируются (речь про GUI, а не консольные утилиты).
Wine — это все-таки прокладка-реализация WinAPI, а совсем не нативный механизм, в отличии от Mono.
С совместимостью .NET/Mono не так то все просто. Если посмотреть на страницу совместимости Mono-.NET, то можно увидеть, что платформонезависимые компоненты реализованы очень даже хорошо (http://mono-project.com/Compatibility), к примеру WindowsForms в Mono есть, поэтому Mono очень даже взрослый и допиленный фреймворк.
Проблема с переносимостью состоит в том, что редко найдешь приложение, которое не использует Windows-специфичные технологии, которые просто невозможно реализовать в Linux (технические сложности или патентные), очень часто Managed Code используется вместе с Native-частью, что исключает любой перенос на Mono.
Если сразу писать пиложение, с использованием только кроссплатформенных компонентов, то все будет замечательно.
С совместимостью .NET/Mono не так то все просто. Если посмотреть на страницу совместимости Mono-.NET, то можно увидеть, что платформонезависимые компоненты реализованы очень даже хорошо (http://mono-project.com/Compatibility), к примеру WindowsForms в Mono есть, поэтому Mono очень даже взрослый и допиленный фреймворк.
Проблема с переносимостью состоит в том, что редко найдешь приложение, которое не использует Windows-специфичные технологии, которые просто невозможно реализовать в Linux (технические сложности или патентные), очень часто Managed Code используется вместе с Native-частью, что исключает любой перенос на Mono.
Если сразу писать пиложение, с использованием только кроссплатформенных компонентов, то все будет замечательно.
Кстати, .NET можно установить под Wine и запускать .NET-приложения под Wine, правда работоспособность такой связки очень условна :)
Такое ощущение, что в стане Майкрософт не хватает некоего лидера, кто смог бы направить развитие их технологий в нужном направлении и показать всем, что же должно получится в итоге — уж больно много проблем и переделок им пришлось сделать за последние 8 лет с .NET, не говоря уже о том, сама компания особо и не торопиться использовать свои же собственные разработки.
Сейчас же все это разнообразие технологий, зачастую конкурирующих друг с другом, ставит в ступор и заставляет задуматься, а правильно ли мы выбрали то или иное решение для своих проектов.
Сейчас же все это разнообразие технологий, зачастую конкурирующих друг с другом, ставит в ступор и заставляет задуматься, а правильно ли мы выбрали то или иное решение для своих проектов.
уж больно много проблем и переделок им пришлось сделать за последние 8 лет с .NET
А можно поподробнее? Я разработчик на .Net и как-то не заметил. Вижу активную эволюцию платформы, вижу развитие и добавление новых возможностей и альтернатив, а вот переделок как то не вижу.
Первые версии фреймворка (с 1 по 2) вкупе со встроенными библиотеками, например, Windows Forms, сильно различались и даже в некоторых местах были несовместимы друг с другом.
Идея мультиплатформенности и открытости NET, на которые повелись многие разработчики, также провалилась из-за сложностей в реализации и технологиях. В реальности ее просто нет (ни моно, ни мунлайт так никак и не могут допилить до вменяемого уровня, не говоря уже о реализации стандартных библиотек, например, все тех же Windows Forms).
Все планы Майкрософт по использованию «аналога WPF» и отказ от «WinAPI» в современных Windows провалились. И взамен повсеместного внедрения вместе с Windows Vista технологию кое-как удалось допилить лишь к 2010 году. Ни о каком внедрении в ближайших версиях Windows речи уже давно не ведется.
Вся это беготня из одного угла в другой с Сильверлайтом — отсутсвие четкого позиционирования технологии (веб? ентерпрайз? десктоп? замена флеша? игры? мобильники? да мы сами ничего не знаем — пускай будет все). А последние события и вовсе чуть ли не поставили крест на будущем сильверлайта (да, да — тот самый отказ Майкрософт от сильверлайта в вебе и взятие курса на веб-стандарты).
В ASP и вебе тоже не все гладко — отказ от развития веб-форм и переход на совершенно другую технологию MVC, остановка развитии Entity Framework и т.п.
Фактически, у Майкрософт ОЧЕНЬ много технологий, которые так же стремительно заменяются и закрываются, как и появляются. Нет стабильности.
Идея мультиплатформенности и открытости NET, на которые повелись многие разработчики, также провалилась из-за сложностей в реализации и технологиях. В реальности ее просто нет (ни моно, ни мунлайт так никак и не могут допилить до вменяемого уровня, не говоря уже о реализации стандартных библиотек, например, все тех же Windows Forms).
Все планы Майкрософт по использованию «аналога WPF» и отказ от «WinAPI» в современных Windows провалились. И взамен повсеместного внедрения вместе с Windows Vista технологию кое-как удалось допилить лишь к 2010 году. Ни о каком внедрении в ближайших версиях Windows речи уже давно не ведется.
Вся это беготня из одного угла в другой с Сильверлайтом — отсутсвие четкого позиционирования технологии (веб? ентерпрайз? десктоп? замена флеша? игры? мобильники? да мы сами ничего не знаем — пускай будет все). А последние события и вовсе чуть ли не поставили крест на будущем сильверлайта (да, да — тот самый отказ Майкрософт от сильверлайта в вебе и взятие курса на веб-стандарты).
В ASP и вебе тоже не все гладко — отказ от развития веб-форм и переход на совершенно другую технологию MVC, остановка развитии Entity Framework и т.п.
Фактически, у Майкрософт ОЧЕНЬ много технологий, которые так же стремительно заменяются и закрываются, как и появляются. Нет стабильности.
Первые версии фреймворка (с 1 по 2) вкупе со встроенными библиотеками, например, Windows Forms, сильно различались и даже в некоторых местах были несовместимы друг с другом
Про 1.1 и 2.0 знаю, но это было давно. Начиная с версии 2.0 все гладко.
Идея мультиплатформенности и открытости NET, на которые повелись многие разработчики, также провалилась из-за сложностей в реализации и технологиях.
Это было понятно в общем-то с самого начала. МС просто незачем помогать писать софт под другие платформы. Мультиплатформенность дотнета в понимании МС — это открытый стандарт и отсутствие претензий к альтернативным реализациям.
Все планы Майкрософт по использованию «аналога WPF» и отказ от «WinAPI» в современных Windows провалились. И взамен повсеместного внедрения вместе с Windows Vista технологию кое-как удалось допилить лишь к 2010 году. Ни о каком внедрении в ближайших версиях Windows речи уже давно не ведется.
А какая разница разработчикам прикладного софта, какими фреймворками пользуется сам МС? Вон в 2010 студии GUI на WPF — и ничего так выглядит. А офис переписывать они пока не будут, дорого это.
Вся это беготня из одного угла в другой с Сильверлайтом — отсутсвие четкого позиционирования технологии (веб? ентерпрайз? десктоп? замена флеша? игры? мобильники? да мы сами ничего не знаем — пускай будет все). А последние события и вовсе чуть ли не поставили крест на будущем сильверлайта (да, да — тот самый отказ Майкрософт от сильверлайта в вебе и взятие курса на веб-стандарты).
Черт, не дописал.
Отказ от Сильверлайта — согласен, но это правильное решение.
Вебформс — изначально костыль для разработчиков под винформс, желающих писать под веб. MVC — это тру-веб путь и за ним будущее. У нас в компании писали свои MVC-фреймворки под ASP.Net еще в 2004 году, потому что писать под вебформс — это же мазохизм.
Entity Framework — вы шутите? Его в 4 версии фреймворка серьезно допилили. Это называется остановкой?
Отказ от Сильверлайта — согласен, но это правильное решение.
В ASP и вебе тоже не все гладко — отказ от развития веб-форм и переход на совершенно другую технологию MVC, остановка развитии Entity Framework и т.п.
Вебформс — изначально костыль для разработчиков под винформс, желающих писать под веб. MVC — это тру-веб путь и за ним будущее. У нас в компании писали свои MVC-фреймворки под ASP.Net еще в 2004 году, потому что писать под вебформс — это же мазохизм.
Entity Framework — вы шутите? Его в 4 версии фреймворка серьезно допилили. Это называется остановкой?
«да, да — тот самый отказ Майкрософт от сильверлайта в вебе и взятие курса на веб-стандарты»
Вот с умереностью могу сказать что вы оба нифига не знаете по поводу Silverlight. И даже поражает с какой увереностью «левые» люди что-то смеют заявлять по поводу Silverlight.
Вы видели Silverlight Firestarter? Если нет, то мне понятны причины вашей «безграмотности», но если вы видели что нам принесем Silverlight 5 и еще заевляете о том что «MS отказалась от Silverlight», то вы просто дебилы (уж извините за мой русский)
Вот с умереностью могу сказать что вы оба нифига не знаете по поводу Silverlight. И даже поражает с какой увереностью «левые» люди что-то смеют заявлять по поводу Silverlight.
Вы видели Silverlight Firestarter? Если нет, то мне понятны причины вашей «безграмотности», но если вы видели что нам принесем Silverlight 5 и еще заевляете о том что «MS отказалась от Silverlight», то вы просто дебилы (уж извините за мой русский)
От него отказались как для основного фреймворка для RIA. Собственно интеграция с COM и постоянное сближение с WPF — как раз и признак того, что на него начали забивать как на веб-фреймворк, а стали позиционировать как «легкий дотнет» и основу для WP7-разработки.
Замечательные вы «догадки» делаете. Видимо вы просто мега эксперт по технологиям .NET и Silverlight.
Где MS заявила что «мы отказались от Silverlight как от сновного RIA фреймворка»? Пруфлинк?
У меня такое ощущение что все посмотрели на выступление балмера на PDC, а на остальные выступления забили (там между прочем было пару прелестнейших доклабов по Silverlight). Причем даже Балмер ничего не говорил о том что они отказываються от Silverlight.
Интеграция с COM, и сближение с WPF — это как говориться «по желанию радиослушателей», очень много народу просило и до сих пор просит большего.
Посомтрите Silverlight Firestarter, в Silverlight 5 обещают еще большую интеграцию с системой.
— А теперь чтобы рас и на всегда прекратить все споры открываем Silverlight 4 Documentation и читаем…
«Microsoft Silverlight is a cross-browser, cross-platform implementation of the .NET Framework for building and delivering the next generation of media experiences and rich interactive applications (RIA) for the Web»
— Извините конечно за грубость но когда обсолюдно «левые» люди делают такие серьезные заявления, тяжело быть адекватным.
Где MS заявила что «мы отказались от Silverlight как от сновного RIA фреймворка»? Пруфлинк?
У меня такое ощущение что все посмотрели на выступление балмера на PDC, а на остальные выступления забили (там между прочем было пару прелестнейших доклабов по Silverlight). Причем даже Балмер ничего не говорил о том что они отказываються от Silverlight.
Интеграция с COM, и сближение с WPF — это как говориться «по желанию радиослушателей», очень много народу просило и до сих пор просит большего.
Посомтрите Silverlight Firestarter, в Silverlight 5 обещают еще большую интеграцию с системой.
— А теперь чтобы рас и на всегда прекратить все споры открываем Silverlight 4 Documentation и читаем…
«Microsoft Silverlight is a cross-browser, cross-platform implementation of the .NET Framework for building and delivering the next generation of media experiences and rich interactive applications (RIA) for the Web»
— Извините конечно за грубость но когда обсолюдно «левые» люди делают такие серьезные заявления, тяжело быть адекватным.
Во-первых, переходить на личности — дурной тон.
Во-вторых, если уж вы и правда считаете меня совсем некомпетентным в этом вопросе, то прежде чем наезжать, ради интереса могли бы посмотреть профайл — там есть ссылка на LinkedIn с детальным резюме, можете прокрутить вниз и посмотреть список сертификаций. Вас видимо больше всего заинтересует Microsoft Certified Professional Developer: Web Developer 4.
Так вот, как человек, который постоянно и очень плотно работает со стеком веб-технологий Microsoft, принимает участие в различных конференциях, сертифицируется и читает тонны материалов по этой теме, в конце-концов, как архитектор программного обеспечения, которому платят неплохие деньги за то, что он принимает решения, какие технологии выбирать для новых проектов с очень не маленькими бюджетами, я вам могу с полной ответственностью заявить, что Сильверлайт на данный момент позиционируется корпорацией Microsoft не совсем в той нише, в которой он был два года назад, когда работали над 4 версией а IE9 только-только начинал компилироватся на билд-машинах разработчиков.
Его не выбросили. Его не перестали развивать. Он не перестал быть одним из стратегических продуктов для компании. Просто из фреймворка общего назначения он превратился в более узкоспециализированный фреймворк для WP7 и сетевых бизнесс-приложений. С легкой претензией на кроссплатформенность.
Если два года назад я мог поверить в то, что в скором времени я увижу в сети множество RIA-приложений и веб-сервисов для широкой аудитории, которые будут написанны полностью на Сильверлайте, то сейчас я вам с уверенностью заявляю, что нет, такого не будет. Возможно даже к несчастью, хороший фреймворк ведь. Увы и ах, придется учить JavaScript и разбиратся с унылыми (по сравнению с Сильверлайтом) канвасом, svg и другими плюшками HTML5.
Во-вторых, если уж вы и правда считаете меня совсем некомпетентным в этом вопросе, то прежде чем наезжать, ради интереса могли бы посмотреть профайл — там есть ссылка на LinkedIn с детальным резюме, можете прокрутить вниз и посмотреть список сертификаций. Вас видимо больше всего заинтересует Microsoft Certified Professional Developer: Web Developer 4.
Так вот, как человек, который постоянно и очень плотно работает со стеком веб-технологий Microsoft, принимает участие в различных конференциях, сертифицируется и читает тонны материалов по этой теме, в конце-концов, как архитектор программного обеспечения, которому платят неплохие деньги за то, что он принимает решения, какие технологии выбирать для новых проектов с очень не маленькими бюджетами, я вам могу с полной ответственностью заявить, что Сильверлайт на данный момент позиционируется корпорацией Microsoft не совсем в той нише, в которой он был два года назад, когда работали над 4 версией а IE9 только-только начинал компилироватся на билд-машинах разработчиков.
Его не выбросили. Его не перестали развивать. Он не перестал быть одним из стратегических продуктов для компании. Просто из фреймворка общего назначения он превратился в более узкоспециализированный фреймворк для WP7 и сетевых бизнесс-приложений. С легкой претензией на кроссплатформенность.
Если два года назад я мог поверить в то, что в скором времени я увижу в сети множество RIA-приложений и веб-сервисов для широкой аудитории, которые будут написанны полностью на Сильверлайте, то сейчас я вам с уверенностью заявляю, что нет, такого не будет. Возможно даже к несчастью, хороший фреймворк ведь. Увы и ах, придется учить JavaScript и разбиратся с унылыми (по сравнению с Сильверлайтом) канвасом, svg и другими плюшками HTML5.
А у меня нет сертификатов, нет высшего образования и я вообще безграмотен.
Вы заявляли:
1) "(да, да — тот самый отказ Майкрософт от сильверлайта в вебе и взятие курса на веб-стандарты)."
2) «От него отказались как для основного фреймворка для RIA.»
Но НИ одного пруф линка вы не предоставили. Из чего следует вывод что это ВАШЕ личное мнение, которое вы почемуто выдаете за мнение Microsoft.
То что Silverlight — это RIA написанно не только в документации постовляемой вместе с Silverligth, но и в википедии (почитайте не поленитесь)
en.wikipedia.org/wiki/Rich_Internet_application
Вы заявляли:
1) "(да, да — тот самый отказ Майкрософт от сильверлайта в вебе и взятие курса на веб-стандарты)."
2) «От него отказались как для основного фреймворка для RIA.»
Но НИ одного пруф линка вы не предоставили. Из чего следует вывод что это ВАШЕ личное мнение, которое вы почемуто выдаете за мнение Microsoft.
То что Silverlight — это RIA написанно не только в документации постовляемой вместе с Silverligth, но и в википедии (почитайте не поленитесь)
en.wikipedia.org/wiki/Rich_Internet_application
[blockquote]
Вся это беготня из одного угла в другой с Сильверлайтом — отсутсвие четкого позиционирования технологии (веб? ентерпрайз? десктоп? замена флеша? игры? мобильники? да мы сами ничего не знаем — пускай будет все). А последние события и вовсе чуть ли не поставили крест на будущем сильверлайта (да, да — тот самый отказ Майкрософт от сильверлайта в вебе и взятие курса на веб-стандарты).
[/blockquote]
Нет никакого отказа от SIlverlight. Меньше доверяйте слухам. После той статьи МС провеля не одно меропреятие с демонстрацией ещё ненаписанного SL5. В апреле будет бета, в июле будет релиз.
Нативная поддержка x64 + Full trust. Silverlight, как по мне никогда не позиционировался заменой флешу. Он нужен для доставки медиаконента.
Вся это беготня из одного угла в другой с Сильверлайтом — отсутсвие четкого позиционирования технологии (веб? ентерпрайз? десктоп? замена флеша? игры? мобильники? да мы сами ничего не знаем — пускай будет все). А последние события и вовсе чуть ли не поставили крест на будущем сильверлайта (да, да — тот самый отказ Майкрософт от сильверлайта в вебе и взятие курса на веб-стандарты).
[/blockquote]
Нет никакого отказа от SIlverlight. Меньше доверяйте слухам. После той статьи МС провеля не одно меропреятие с демонстрацией ещё ненаписанного SL5. В апреле будет бета, в июле будет релиз.
Нативная поддержка x64 + Full trust. Silverlight, как по мне никогда не позиционировался заменой флешу. Он нужен для доставки медиаконента.
Вообще, явный тренд в поведении МС за последние пару лет — это открытость и отказ от множества велосипедов в пользу зарекомендовавших себя технологий, разработаных другими компаниями. Опен-сорсный ASP.Net MVC, активное продвижение и внедрение jQuery, WCF REST Services, IE9 с HTML5 — это все кирпичики одного и того же строения, который делает стек технологий МС понятным и привычным для разработчиков, которые никогда не имели с ними дела.
Это в 90-х они могли себе позволить диктовать свои условия и изобретать собственные решения, потому как конкурентов не было. Сейчас все не так. Разработчики хотят MVC и REST и если МС не даст им их — они уйдут на другие платформы.
Это в 90-х они могли себе позволить диктовать свои условия и изобретать собственные решения, потому как конкурентов не было. Сейчас все не так. Разработчики хотят MVC и REST и если МС не даст им их — они уйдут на другие платформы.
Даже Джоуль Спольски об этом неоднократно говорил: огромное количество новых технологий — это способ борьбы Майкрософт со своими конкурентами — пока они подстраиваются под одно направление, МС открывает новое.
Я сам разработчик на .NET, но когда на семинаре по старту Windows 7, сказали «Извините, но пока все плюшечки доступны только для C++, для C# мы сделали Windows API Code Pack. Он неофициальный, но вроде как работает» , мне стало понятно, что MS не собирается полностью переходить на .NET.
.Net — мертворождённая говнотехнология.
Если, хотя бы периодически, не следить за новыми технологиями и не изучать то, что кажется наиболее перспективным, то в итоге легко оказаться не у дел со старыми невостребованными инструментами на руках.
Даже если новая технология мне не сильно пригодится, я все равно рад тому, что смог ей овладеть. По одной простой причине, я не даю моему мозгу закостенеть и стать неспособным воспринимать новую информацию. А это как раз поможет иметь светлую голову.
Даже если новая технология мне не сильно пригодится, я все равно рад тому, что смог ей овладеть. По одной простой причине, я не даю моему мозгу закостенеть и стать неспособным воспринимать новую информацию. А это как раз поможет иметь светлую голову.
К концу поста уже стал бояться, что напишите «не хватает var-секции для объявления переменных» :) Немножко надуманно всё, на мой взгляд.
Я до сих пор использую Delphi, когда хочу написать какое-то мелкое приложение, работающее с COM'ом. Из-за очень удобного для этих целей OleVariant'а.
КодеГир еще не бесплатен… Можно смело смеяться над дельфистами, которые смеялись у Вас за спиной :)
Я до сих пор использую Delphi, когда хочу написать какое-то мелкое приложение, работающее с COM'ом. Из-за очень удобного для этих целей OleVariant'а.
КодеГир еще не бесплатен… Можно смело смеяться над дельфистами, которые смеялись у Вас за спиной :)
В C# раздел var совершенно не нужен. Я очень дорожу возможностью объявлять переменные максимально близко к месту их использования :)
На сколько я знаю, в C# 4.0 уже появилась достойная замена OleVariant: тип dynamic. Он как раз и позиционируется как очень удобный механизм для работы с COM объектами.
На сколько я знаю, в C# 4.0 уже появилась достойная замена OleVariant: тип dynamic. Он как раз и позиционируется как очень удобный механизм для работы с COM объектами.
> Проверка на попадание во множество
Не нужно, если правильно использовать контейнеры и парадигмы, которые предлагает сам язык.
> Вложенные функции
Нет необходимости. Если Вы в них нуждаетесь, значит Вы неправильно спроектировали класс/группу классов.
Не нужно, если правильно использовать контейнеры и парадигмы, которые предлагает сам язык.
> Вложенные функции
Нет необходимости. Если Вы в них нуждаетесь, значит Вы неправильно спроектировали класс/группу классов.
Прошу прощения, недописал:
> Явное приведение типов
Нет необходимости при правильном проектировании, приведенный Вами пример — плохой тон.
> TStringList
Приведенная Вами задача имеет более элегантное решение:
1) Через использование вспомогательного файла;
2) Считывание всего файла в контейнер/поток, вставка строки в начало контейнера/потока, перезапись файла/flush потока.
> Чтение данных с электронной почты
А класс, который напишет за Вас программу, Вы не хотите найти? Я не .Net программист, но уверен, что уже есть достаточное количество библиотек, реализующий данный функционал.
> Закладки в модулях кода
Они есть. Список всех шорткатов можно найти в документации к IDE, более того, можно самому выставить наиболее удобный шорткат.
> Поиск в модуле кода
Эта панель есть, Вы просто её не заметили. Более того, есть решарпер, о возможностях которого нет смысла здесь писать.
> Заключение
Язык программирования программисту следует выбирать исходя из задачи, которая перед ним стоит. Изучение ООП языка сводится к изучению его основной библиотеки/фрейворка, поэтому существенной разницы между ООП языками нет, есть небольшая разница между их фреймворками, те функции, которых нет можно найти в сторонних библиотеках. Хороший программист всегда будет писать хорошие программы, не важно на каком языке.
Спасибо, удачи в изучении языка.
> Явное приведение типов
Нет необходимости при правильном проектировании, приведенный Вами пример — плохой тон.
> TStringList
Приведенная Вами задача имеет более элегантное решение:
1) Через использование вспомогательного файла;
2) Считывание всего файла в контейнер/поток, вставка строки в начало контейнера/потока, перезапись файла/flush потока.
> Чтение данных с электронной почты
А класс, который напишет за Вас программу, Вы не хотите найти? Я не .Net программист, но уверен, что уже есть достаточное количество библиотек, реализующий данный функционал.
> Закладки в модулях кода
Они есть. Список всех шорткатов можно найти в документации к IDE, более того, можно самому выставить наиболее удобный шорткат.
> Поиск в модуле кода
Эта панель есть, Вы просто её не заметили. Более того, есть решарпер, о возможностях которого нет смысла здесь писать.
> Заключение
Язык программирования программисту следует выбирать исходя из задачи, которая перед ним стоит. Изучение ООП языка сводится к изучению его основной библиотеки/фрейворка, поэтому существенной разницы между ООП языками нет, есть небольшая разница между их фреймворками, те функции, которых нет можно найти в сторонних библиотеках. Хороший программист всегда будет писать хорошие программы, не важно на каком языке.
Спасибо, удачи в изучении языка.
Ну шоткаты Ctrl+K+K, как не меняй, удобнее Борландовского Shift+Ctrl+num они не станут :) Здесь я согласен с ТС, то как это сделано в иде от борланда и старше — замечательно и удобно.
Если есть возможность в express версии VS получить подобный функционал — подскажите, буду признателен.
Если есть возможность в express версии VS получить подобный функционал — подскажите, буду признателен.
Есть окно Bookmarks, с помощью которого доступны все выставленные закладки с указанием файла и номера строки, на которой была установлена закладка. Навигация с помощью данного окна удобней и наглядней, нет необходимости запоминать номера закладок, плюс ко всему есть возможность отключения закладки без её удаления.
Есть add-on к студии позволяющий использовать шоткаты как в дельфе www.usysware.com/dpack/
Когда сам переходил с дельфи на .net в студии не хватало только этого.
Когда сам переходил с дельфи на .net в студии не хватало только этого.
Пример, в котором использовалось приведение, конечно надуман, и создан исключительно для демонстрации синтаксиса двух языков при реализации приведения. На счет плохого тона соглашусь, поскольку даже при реализации абстрактной фабрики приведение бы не понадобилось, поскольку метод GetBonus() был бы виртуальным или абстрактным в родительском классе.
Количество библиотек по работе с электронной почтой на самом деле велико. Но 90% найденных мной платные, и более того были трудности с их покупкой нашим предприятием. Для меня было удивлением, что в .NET framework не включены библиотеки для работы с POP и IMAP.
Что касается закладок, то здесь работает принцип: к хорошему быстро привыкаешь. Их реализация в Delphi просто великолепна, и очень трудно после работы с ними согласиться на что-то другое.
Хороший программист будет писать хорошие программы на любом языке. Но при этом важно, насколько быстро он сможет решить задачу и насколько комфортно ему будет их решать на том или ином языке.
Количество библиотек по работе с электронной почтой на самом деле велико. Но 90% найденных мной платные, и более того были трудности с их покупкой нашим предприятием. Для меня было удивлением, что в .NET framework не включены библиотеки для работы с POP и IMAP.
Что касается закладок, то здесь работает принцип: к хорошему быстро привыкаешь. Их реализация в Delphi просто великолепна, и очень трудно после работы с ними согласиться на что-то другое.
Хороший программист будет писать хорошие программы на любом языке. Но при этом важно, насколько быстро он сможет решить задачу и насколько комфортно ему будет их решать на том или ином языке.
Явное приведение типов можно записать так:
Для удобной работы с текстовым файлом как с набором строк можно открыть файл в текстовом режиме (FileInfo.OpenText())
(manager as Manager).GetBonus()Для удобной работы с текстовым файлом как с набором строк можно открыть файл в текстовом режиме (FileInfo.OpenText())
Ну, мне кажется, использование «as» — это немного другая тема. Это уже зависит от того, что и для чего мы собираемся преобразовывать.
Если мы хотим по-своему обработать Exception, который возникает при преобразовании — нужно использовать (Manager)manager.
А после as чаще всего все равно приходится делать «null check».
В случае
(manager as Manager).GetBonus()
мы никогда не получим InvalidCastException, но запросто можем получить NullReferenceException, что не совсем верно, ведь ошибка по факту в преобразовании. Это затруднит дебаггинг.
Если мы хотим по-своему обработать Exception, который возникает при преобразовании — нужно использовать (Manager)manager.
А после as чаще всего все равно приходится делать «null check».
В случае
(manager as Manager).GetBonus()
мы никогда не получим InvalidCastException, но запросто можем получить NullReferenceException, что не совсем верно, ведь ошибка по факту в преобразовании. Это затруднит дебаггинг.
Если вы хотите обрабатывать InvalidCastException — вас нужно убивать.
За любое catch(InvalidCastException) { логика } или catch(NullReferenceException) { логика } нужно погружать в чан с кислотой. За catch(Exception) { логика } — отрывать яйца.
За любое catch(InvalidCastException) { логика } или catch(NullReferenceException) { логика } нужно погружать в чан с кислотой. За catch(Exception) { логика } — отрывать яйца.
Обрабатывать не надо.
Но это не отменяет желания получать правильный exception
Но это не отменяет желания получать правильный exception
Exactly!
Если по ислкючению можно быстро локализовать ошибку — не важно, что это, инвалидкаст, нулреференс или просто аппликейшнэксепшн.
Важно или нет — зависит от конкретного проекта. Кто-то может их даже в логи разные писать. И да — хорошо, если можно быстро локализовать. Тем не менее, выброс неверного Exception это дело немного, да затрудняет. Без какой-либо причины, кстати.
Не пойму, о чем мы спорим, по-моему очевидная вещь.
Не пойму, о чем мы спорим, по-моему очевидная вещь.
Естественно. Но функция As у меня реализована именно так, и с ней никогда не было проблем. Несмотря на то, что по правильному она должна быть реализована так:
T As<T>(this object obj) where T: class
{
if(obj == null)
throw NullReferenceException();
return (T)obj;
}
T As<T>(this object obj) where T: class
{
if(obj == null)
throw NullReferenceException();
return (T)obj;
}
1. Только не NullReferenceException, а ArgumentNullException в данном случае, если уж хотите что-нибудь бросить :) Если все же хотите именно NullReferenceException, тогда проверка необязательна. Вы его получите при попытке каста (потому что хотите привести к другому типу нулевой объект).
2. И да, тут все правильно, вы в случае неверного каста получаете правильный InvalidCastException.
3. Проблем не было, вполне возможно, сам пример достаточно простой, обычно тут просто негде взяться ошибке.
2. И да, тут все правильно, вы в случае неверного каста получаете правильный InvalidCastException.
3. Проблем не было, вполне возможно, сам пример достаточно простой, обычно тут просто негде взяться ошибке.
Именно NullReference, потому что для обычных методов вызов его от нулевого аргумента дает нулреференец. АргументНулл выдается в случае, если в метод передается нулевой аргумент, который запрещен публичным контрактом.
Мы же во имя единообразия это делаем.
Мы же во имя единообразия это делаем.
Ну незнаю. У нас всегда, когда проверяется аргумент, если он не может быть null, всегда выдается именно ArgumentNullException. И это именно то, для чего этот эксепшен нужен. Мы ведь не используем аргумент, а именно проверяем его.
Для проверки аргументов у нас всегда идет проверка «Ensure.IsNotNull(arg, argName)», которая бросает именно ArgumentNullException.
Мы никогда не бросаем NullReferenceException вручную, он сам получается, если использован null вместо ожидаемого объекта (и это, как по мне — правильное поведение).
Для всего остального есть null-check.
Для проверки аргументов у нас всегда идет проверка «Ensure.IsNotNull(arg, argName)», которая бросает именно ArgumentNullException.
Мы никогда не бросаем NullReferenceException вручную, он сам получается, если использован null вместо ожидаемого объекта (и это, как по мне — правильное поведение).
Для всего остального есть null-check.
NullReferenceException в C# имеет единственный смысл — была использована конструкция null.Method()
При этом, не важно, является ли Method методом объекта или Extension-методом.
Я поэтому стал говорить о единообразии. У extensions синтаксис даже другой — там первый аргумент this, а если this == null — то нужно кидать NullReference
При этом, не важно, является ли Method методом объекта или Extension-методом.
Я поэтому стал говорить о единообразии. У extensions синтаксис даже другой — там первый аргумент this, а если this == null — то нужно кидать NullReference
А, да, согласен, один из вариантов, ибо Extension-метод «не падает» сам при нулевом объекте.
Но тут уже дело вкуса. Extension-метод, ведь, по факту, не метод класса. И в его сигнатуре первый аргумент пусть и идет с «this», это все же аргумент. Так что, в общем-то логично и то, и другое (тут и null.Method(), и передача аргумента). Мы просто предпочитаем смотреть на это как на аргумент.
Но тут уже дело вкуса. Extension-метод, ведь, по факту, не метод класса. И в его сигнатуре первый аргумент пусть и идет с «this», это все же аргумент. Так что, в общем-то логично и то, и другое (тут и null.Method(), и передача аргумента). Мы просто предпочитаем смотреть на это как на аргумент.
У вас данных об ошибке — метод и название exception. Номера строки нет. В тестовой среде ошибка не воспроизводится, переодически возникает на боевой системе при пакетной обработке.
Поможет верное название exception воспроизведению ошибки?
Поможет верное название exception воспроизведению ошибки?
Вы преувеличиваете. Разумеется, никто этого делать не собирается. Но пусть у меня будет Runtime Error типа «InvalidCastException», а не какой другой, если ошибка в преобразовании. leotsarev комментом ниже очень точно высказался на этот счет.
Не согласен насчет «catch(Exception) { логика }». Бывают случаи, когда нужно обработать любую ошибку, не вызывая при этом остановку приложения, а, скажем, отобразить пользователю «500 Internal Server Error», независимо от природы ошибки.
Насчет NullReferenceException же — да, нужно заведомо делать null-check, а не обрабатывать исключения.
Не согласен насчет «catch(Exception) { логика }». Бывают случаи, когда нужно обработать любую ошибку, не вызывая при этом остановку приложения, а, скажем, отобразить пользователю «500 Internal Server Error», независимо от природы ошибки.
Насчет NullReferenceException же — да, нужно заведомо делать null-check, а не обрабатывать исключения.
Если у вас вылетел InvalidCastException — это значит, что мысль в вашем мозге сломалась, потому что к вам попали данные, формат которых вы не предусмотрели. Инвалидкаст — всегда ошибка в логике программы, причем ошибка архитектурная — нарушение LSP, отказ от статической типизации во имя «гибкости» и прочие такие же отвратительные вещи.
А единственный код, который может делать catch(Exception ex) — это Log.WriteException(ex). Делать после этого throw или нет — ваше дело. Я предпочитаю делать, тогда любое необработанное исключение роняет программу, что положительно сказывается на процессе тестирования и сохряняет целостность приложения.
А единственный код, который может делать catch(Exception ex) — это Log.WriteException(ex). Делать после этого throw или нет — ваше дело. Я предпочитаю делать, тогда любое необработанное исключение роняет программу, что положительно сказывается на процессе тестирования и сохряняет целостность приложения.
Ну, сразу скажем, у меня никогда не бывает InvalidCastException :) Но я предпочел бы получить именно его, если на каком-то этапе мысль в моем мозге, как вы говорите, сломалась. Это все, о чем я и хотел сказать.
Насчет архитектурной подоплеки этого эксепшена — тут скорее нарушение LSP и ISP вместе взятых — ибо кусок программы пытается знать о каком-то объекте больше, чем нужно, пытаясь привязаться, скажем, к конкретной реализации интерфейса, нежели к самому интерфейсу.
По поводу «rethrow» — делать его или нет — здесь очень сильно зависит от конкретной ситуации.
P.S. А что значит «отказ от статической типизации»? C# — статически-типизированный «by-design», как можно отказаться от принципиальной части технологии?
Насчет архитектурной подоплеки этого эксепшена — тут скорее нарушение LSP и ISP вместе взятых — ибо кусок программы пытается знать о каком-то объекте больше, чем нужно, пытаясь привязаться, скажем, к конкретной реализации интерфейса, нежели к самому интерфейсу.
По поводу «rethrow» — делать его или нет — здесь очень сильно зависит от конкретной ситуации.
P.S. А что значит «отказ от статической типизации»? C# — статически-типизированный «by-design», как можно отказаться от принципиальной части технологии?
«отобразить пользователю «500 Internal Server Error», независимо от природы ошибки» — за это вот в чан с кислотой, как тут предлагалось по другим поводам, надо бы. Выбешивает, когда из текста сообщения об ошибке непонятно, что именно произошло.
Какого черта пользователь сайта должен вникать в ваши ошибки? Какая ему разница?
Разумеется, если это какой-то небольшой сбой, можно попросить пользователя «перезагрузить страницу и попробовать еще раз», но если это «где-то страшный смертельный косяк» — пользователю все равно, что это — NullReferencexception, ApplicationException, StackOverflowException или WtfIsGoingOnException — он увидит только «Сорри, у нас ошибка! Будьте любезны сообщить об этом администратору по адресу такому-то».
Можете считать, что это неправильным, и тогда я с вами в корне несогласен. Что касается обработки ошибок в Debug-time для, собственно, дебаггинга — то это совершенно другая история.
Разумеется, если это какой-то небольшой сбой, можно попросить пользователя «перезагрузить страницу и попробовать еще раз», но если это «где-то страшный смертельный косяк» — пользователю все равно, что это — NullReferencexception, ApplicationException, StackOverflowException или WtfIsGoingOnException — он увидит только «Сорри, у нас ошибка! Будьте любезны сообщить об этом администратору по адресу такому-то».
Можете считать, что это неправильным, и тогда я с вами в корне несогласен. Что касается обработки ошибок в Debug-time для, собственно, дебаггинга — то это совершенно другая история.
И что полезного пользователь сможет сообщить администратору?
Ну это как пример. Но если уж и сообщить, то ровно одно — что произошла ошибка (возможно с указанием того, в какое именно время) и что он пытался при этом сделать. Остальное (колл-стеки, системные сообщения, и так далее) должно быть в логах, Event-логах, созданных через System.Trace, NLog и прочие утилиты. Пользователю уж точно не нужно показывать, например, YSOD.
Особенно, когда ошибка является следствием не только особенностей программы, но и особенностей данных и последовательности действий пользователя, которые пользователь мог бы поменять и сам, имея чуть больше подробностей. И продолжать пользоваться, а не общаться с администратором, саппортом, разработчиком и т.п. инстанциями.
Зачем так делать?
as это сахар:
эквивалентно
Итого ваш вариант будет выглядеть так:
В отличие от прямого каста, это код будет просто медленее, и кинет вместо прямого exception «неправильный тип» ошибку «null указатель», что будет зря путать :)
as это сахар:
manager as Managerэквивалентно
(manager is Manager) ? ((Manager) manager) : nullИтого ваш вариант будет выглядеть так:
((manager is Manager) ? ((Manager) manager) : null).GetBonus()В отличие от прямого каста, это код будет просто медленее, и кинет вместо прямого exception «неправильный тип» ошибку «null указатель», что будет зря путать :)
«Итого ваш вариант будет выглядеть так»
Это не совсем так. См. blogs.msdn.com/b/ericlippert/archive/2010/09/16/is-is-as-or-is-as-is.aspx
Это не совсем так. См. blogs.msdn.com/b/ericlippert/archive/2010/09/16/is-is-as-or-is-as-is.aspx
Еще одно небольшое замечание. Насколько я понимаю, в этом коде:
> Manager(manager).GetBonus;
Приведения типов нет вообще. Вы создали временный объект класса Manager с помощью конструктора копирования, который либо написали сами, либо за Вас его написал компилятор, а затем вызвали метод временного объекта.
> Manager(manager).GetBonus;
Приведения типов нет вообще. Вы создали временный объект класса Manager с помощью конструктора копирования, который либо написали сами, либо за Вас его написал компилятор, а затем вызвали метод временного объекта.
Для добавления строки в начало файла еще можно так поизвращатся
File.WriteAllText("MyString" + Envinronment.NewLine + File.ReadAlltext());
По поводу POP3,SMTP:
1. библиотека Indy имеет много багов, даже в последней версии. Лучше использовать Synapse. Проверено опытом.
2. в .Net действительно нету прямых готовых методов, зато есть OpenSource'ые классы уже написанные. OpenPOP, OpenSMTP — умеют все. Если нужно — могу поделиться.
Про TStringList:
IList<...> + LINQ посмотрите. В делфи такого нет )
Автор хвалит то к чему он привык, и считает недостатком если чего-то не нашел, не знает еще в VS,.Net,C#. Очень надуманно. Сам был таким когда Шарп видел издалека и все время был в Делфи. )
1. библиотека Indy имеет много багов, даже в последней версии. Лучше использовать Synapse. Проверено опытом.
2. в .Net действительно нету прямых готовых методов, зато есть OpenSource'ые классы уже написанные. OpenPOP, OpenSMTP — умеют все. Если нужно — могу поделиться.
Про TStringList:
IList<...> + LINQ посмотрите. В делфи такого нет )
Автор хвалит то к чему он привык, и считает недостатком если чего-то не нашел, не знает еще в VS,.Net,C#. Очень надуманно. Сам был таким когда Шарп видел издалека и все время был в Делфи. )
В Delphi есть возможность реализовать методы, имеющие уровень видимости, не выходящий за пределы метода, в котором они реализованы
void foo()
{
var bar=delegate(uint arg)
{
return «lol»+arg;
};
Console.WriteLine(bar(123));
}
TStringList
System.Collections.Generic.ListSystem.IO.File.WriteAllLines
System.Collections.Generic.ListSystem.IO.File.WriteAllLines
Парсер — лох.
Было. Но я вас понимаю, топик так быстро вызвал у меня изжогу, что желание излить желчь почти пересилило необходимость прочитать все комментарии.
Ужас, если честно, тихий причём. Конечно есть какие-то мелочи, вроде приведённых вами, которые по тем или иным причинам есть в одном языке, но их нет в другом. Хотите гибкость и простоту во всех действиях — пишите на Perl, делфи, как и C# с С++, для этого совершенно не подходят. С другой стороны сейчас совершенно очевидно наблюдается следующая картина: каждый язык нужен для решения своих задач. С++ — для программирования системных приложений, С# и Java — некоторых классов пользовательских, Perl, Python etc — для прикладного десктопного ПО. Хорошие программы пишутся сразу на нескольких языках, благо всякие Perl спокойно интегрируются в C++ и наоборот. Делфи тут просто нету места. Его некорректно сравнивать с C#, это вообще как сравнивать коричневый с тёплым. Бесполезно сравнивать с С++, поскольку у последнего в разы больше возможностей за счёт библиотек. Как вы интегрируете тот же Perl модуль в программу на Delphi? Или напишите GTK или QT приложение на делфях? Или вы хотите потягаться с интерпретируемыми языками? Ну тогда Python vs Delphi это вообще как мерседес vs дутик (велосипед такой трёхколёсный), даже говорить не о чем. Плюс у delphi просто убогий синтаксис, замедляющий процесс разработки. Учу детей Delphi в течение трёх лет и постоянно говорю им: никогда не пишите на Delphi. Есть тонна более стройных, логичных, мощных и пригодных языков программирования. Зачем ворошить труп? Ну да, 2010 — крутая среда разработки. Что дальше-то? Язык не может в современном мире рассматриваться сам по себе. Язык может рассматриваться только в контексте других языков. Делфи из этого контекста выкинут и никогда не вернётся обратно. А язык, который умеет только то, что заложено в него самого, заведомо убог донельзя.
О боже, и вы еще что-то преподаете по Делфи? Прочитали бы что ли, где и как используются эти инструменты. Маленькая подсказка — для бизнес-приложений и корпоративных разработок, для массовых продуктов и инструментов.
>> «Perl, Python etc — для прикладного десктопного ПО»
>> Как вы интегрируете тот же Perl модуль в программу на Delphi? Или напишите GTK или QT приложение на делфях?
Мне страшно за детишек.
>> «Perl, Python etc — для прикладного десктопного ПО»
>> Как вы интегрируете тот же Perl модуль в программу на Delphi? Или напишите GTK или QT приложение на делфях?
Мне страшно за детишек.
Я рассказываю детишкам как пишется if и почему после while'а стоит do. Сам я на делфи никогда толком не писал и писать никогда не буду, мне достаточно C#, Perl, Python и C++. Зачем мне делфи? Я уверен на 100%, что любая программа, которую мне потребуется написать, легче пишется на питоне, чем на делфях. Если потребуется интеграция в .NET технологии — C#, системное администрирование (да-да, и те самые корпоративные приложения) — однозначно Perl или Python в зависимости от класса задачи, на худой конец — С++, хотя мне лично он совершенно не нужен, ибо я не крутой программист всяких вычислительных приложений. Что вам даёт делфи из такого, чего мне не может дать питон? Я могу сказать, что даёт мне питон: красивое стройное ООП и максимальную гибкость на всех уровнях разработки. Выразительный язык с мощнейшими инструментами, который позволяет полностью сосредоточиться на логике работы приложения и реализовать максимально качественное решение. А делфи? Мне надо трахать свой мозг вопросами совместимости и преобразования типов данных, постоянно спускаться на низкий уровень абстрагирования, на кой всё это? Для бизнес-приложений?? Для массовых продуктов?? Уж лучше тогда С++. Архитектурно — та же хрень примерно, только больше возможностей, выразительней синтаксис, удобней инструменты разработки, шире поддержка, больше библиотек. В таких спорах постоянно обсуждают какие-то мелочи, вроде узкоспециальных возможностей того или иного языка. Я вообще не вижу смысла спускаться так низко. Если даже то, что на самом верху, уже не выдерживает никакой критики, зачем копаться в каких-то мелочах?
Ой, на любом языке можно написать почти всё, что угодно. Вопрос в том, на каком это можно сделать наиболее эффективно. Корпоративные приложения обычно связаны с обработкой данных из БД и других источников. Обработка данных и манипулирование ими — это стезя Perl и Python, и не только текстовых данных, а любых. Абстракции от БД — это тоже без проблем, пользовательские интерфейсы — как два пальца, причём взаимозаменяемые, например, WEB и классический GUI. Самый стандартный пример, который приводят все и всегда при начале изучения Питона. Возведите 1234 в 1234 степень на делфи. А на питоне. Есть разница? Вопрос: зачем мне трахать мозг компилируемыми делфями, когда у меня есть высокоуровневый интерпретируемый язык, который с лихвой может решить 100% задач? Уж что-то, а корпоративные приложения, равно как и всякие простенькие UI, обработчики данных и проч, мне и в страшном сне не привидется писать на делфи или даже на С++. К вопросу о: недавно написал Proxy-SMTP сервер на Perl. Получилось около 300 строчек со всей необходимой обработкой проходящих данных. Сколько оно бы заняло на делфях? Плюс вопросы переносимости, ваша программа на делфях скомпилируется под Mac и Linux? Моя на питоне запустится даже без бубна. В общем, в современном мире дефолт-язык для написания пользовательских приложений — это однозначно интерпретируемый переносимый язык, один из. Писать на чём-то компилируемом можно только если есть веские на то причины. И при этом всё равно нормальный программист озаботится максимальной универсальностью и переносимостью, а значит выбор языка фактически сужается до одного пункта — С++ с универсальными библиотеками вроде QT. Я вообще ставлю качество программы во главу угла разработки абсолютно всегда, а самая основная составляющая качества — это максимальная универсальность всего, что вы пишите. Делфи не предоставляет вообще никакой универсальности, С++ требует усилий на её обеспечение, питон, жава, с# универсальны в той или иной степени из коробки. Можно сколько угодно спорить о C# vs Java, но спорить о Delphi vs *** бесполезно, ибо спор первым давным-давно безнадёжно проигран, о чём говорит хотя бы отсутствие вменяемой DE и компилятора для Linux и других никсов.
Дети не засыпают на уроках?
Есть же клавиша Enter.
Есть же клавиша Enter.
Детям сложно расталковать, что такое if и чем оно отличается от while. Они не засыпают, они просто не хотят вникать. Именно поэтому я преподаю делфи, а не питон. Ибо в питон вообще не въехать без подготовки.
Я только о том, что вы текст не форматируете.
Сложно читать ваши комментарии.
Сложно читать ваши комментарии.
Бывает. Много эмоций вызывает пропагандирование ущербных технологий. Было бы поменьше постов, в которых люди рассказывали бы про in, авось не приходилось бы для перевода отдела на Linux переписывать обвязки к БД, написанные на делфях. Я всё понимаю, человек не думал два года назад, что его любимую винду куда-то кто-то когда-то подвинет, поэтому написал приложение на делфях, жёстко завязанное на MS SQL. Человек — идиот, но ещё больший идиот тот, кто ему внушил, что делфи хорош для БД и создания пользовательских UI. Это никак не относится к автору статьи, но в целом ситуация несколько удручающая.
А зачем сравнивать if и while?
Это же разные сущности (условие и цикл), или вы шутите?
Это же разные сущности (условие и цикл), или вы шутите?
Вы — не защищаете)) Просто я к тому, что делфи не является подходящим инструментом ни для чего. Я не призываю писать серверы на питоне (хотя есть такие) или GUI на чистом С (и такие есть). Я полностью с вами согласен по поводу того, что вы написали. Каждой задаче — свой инструмент. Но для делфи задач нет.
Вопрос: зачем мне трахать мозг компилируемыми делфями, когда у меня есть высокоуровневый интерпретируемый язык, который с лихвой может решить 100% задач? Уж что-то, а корпоративные приложения, равно как и всякие простенькие UI, обработчики данных и проч, мне и в страшном сне не привидется писать на делфи или даже на С++
Я тоже достаточно много пишу на питоне. Но, по сравнению с компилируемыми дельфями и C++ у него есть 2 минуса:
1. Дистрибуция программ. Питон как бы намекает, что на компьютере пользователя должна стоять нужная версия интерпретатора. В .exe он пакуется плохо (это я по личному опыту многочисленной паковки говорю). Redistributable для помещения в msi или pkg отсутствует.
2. Проистекает из пункта N1: дефолтный GUI, который Tk, очень слаб. А нормальный (тот же Qt) требует установки дополнительно к интерпретатору на компьютерах пользователей.
Да, это правда. Это конечно проблемы Windows и только Windows, а не питона, ну да ладно. Немного поизвращавшись проблема решается. Оно того стоит, учитывая что программа без изменений запускается на всех платформах, а язык позволяет писать, думая только о логике и не отвлекаясь на технические заморочки, по крайней мере, не на всякую мелочь, как в случае с делфями. По сравнению с С++ у питона много минусов, иначе бы на С++ никто не писал, но в делфи нет ни кроссплатформенности, ни простоты разработки, ни заточенности под какие-то конкретные задачи, вообще ничего. Китайский мультикит, который по частям хуже специализированных инструментов, а в целом создаёт жалкое впечатление подделки на фоне швейцарских ножей, одним из которых является С++.
Такую мою категоричную реакцию, которая прослеживается в обсуждении, вызвал именно это факт. Я учу детей делфям, но я не пытаюсь их приучить к ним, напротив. А посты на тему какой же делфи хороший обязательно найдут последователей, которые в это поверят. Делфи не плохой, ведь китайские мультикиты покупают. Но способствовать его популяризации — это увольте.
Такую мою категоричную реакцию, которая прослеживается в обсуждении, вызвал именно это факт. Я учу детей делфям, но я не пытаюсь их приучить к ним, напротив. А посты на тему какой же делфи хороший обязательно найдут последователей, которые в это поверят. Делфи не плохой, ведь китайские мультикиты покупают. Но способствовать его популяризации — это увольте.
Это конечно проблемы Windows и только Windows, а не питона, ну да ладно.
Тоесть версия 2.3, установленная в MacOS вас устроит? Уверены? Или версия в ubuntu 10.10, без Tkinter?
Немного поизвращавшись проблема решается
Да кто ж спорит. Я всего лишь скромно намекаю, что если стоит задача передачи софта end user'у, а стоит она довольно часто, то python не лучший выбор.
Что до критики дульфи — ну да, есть ряд недостатков. Мне тот же C++Qt больше нравится. Зато в дельфи делегаты и модульность от рождения были, и радостно переползли в C#.
> Бесполезно сравнивать с С++, поскольку у последнего в разы
> больше возможностей за счёт библиотек. Как вы интегрируете тот же
> Perl модуль в программу на Delphi?
Вы так говорите, как будто это дерьмо, perl, можно нормально прикрутить к программе на C/C++. В теории то наверняка всё гладко, да только почти полное отсутствие документации (акромя каких-то обрубков а-ля embedded perl) и дерьмовость самого интерпретатора (чего только стоит вызов exit(code) при невозможности загрузить модуль) делают это практически невозможным. Использование макросов в API shared либы — это вообще гениальное решение, за которое нужно руки вырывать. Короче, проще делать обёртку для нужного модуля и запускать его во внешнем интерпретаторе, чем мучаться со всем этим дерьмом.
> больше возможностей за счёт библиотек. Как вы интегрируете тот же
> Perl модуль в программу на Delphi?
Вы так говорите, как будто это дерьмо, perl, можно нормально прикрутить к программе на C/C++. В теории то наверняка всё гладко, да только почти полное отсутствие документации (акромя каких-то обрубков а-ля embedded perl) и дерьмовость самого интерпретатора (чего только стоит вызов exit(code) при невозможности загрузить модуль) делают это практически невозможным. Использование макросов в API shared либы — это вообще гениальное решение, за которое нужно руки вырывать. Короче, проще делать обёртку для нужного модуля и запускать его во внешнем интерпретаторе, чем мучаться со всем этим дерьмом.
А именно так и есть. Делфисты — это те, кто застрял в прошлом и не смог освоить Python или на худой конец C# али Java, но которым таки надо рисовать формочки и отчёты.
Есть в Делфях и сбалансированные деревья, и правильные списки, а не TList и прочее.
Погуглите jcl (и jvcl — расширение визуальных компонентов).
Была даже попытка написать аналог STL на Делфи, еще не поддерживающий дженерики.
Погуглите jcl (и jvcl — расширение визуальных компонентов).
Была даже попытка написать аналог STL на Делфи, еще не поддерживающий дженерики.
JEDI-это практически стандартное, самое большое сообщество Делфистов, ну навроде буста для плюсов.
И интересного там много, но документации по этому мало.
И интересного там много, но документации по этому мало.
И все-таки Вы раздуваете «HolyWar».
Но отвечу.
JCL/JVCL практически оффициальный проект. К сожалению, не слежу последнее время за Делфи, но в старых версиях (в семерке точно было) в About самой IDE без установленной JCL, было даже пасхальное яйцо, если нажать Alt и набрать jedi — появлялся логотип проекта JEDI. В некоторых версиях Делфи можно было найти jdbg-файлы, это отладочные файлы в формате проекта JEDI.
Более того, часть разработчиков JEDI работали и работают над собственно Делфи.
Но отвечу.
JCL/JVCL практически оффициальный проект. К сожалению, не слежу последнее время за Делфи, но в старых версиях (в семерке точно было) в About самой IDE без установленной JCL, было даже пасхальное яйцо, если нажать Alt и набрать jedi — появлялся логотип проекта JEDI. В некоторых версиях Делфи можно было найти jdbg-файлы, это отладочные файлы в формате проекта JEDI.
Более того, часть разработчиков JEDI работали и работают над собственно Делфи.
гы. В About у шестёрки оно тож есть.
Тока что это воспроизвёл эти понты с летающими буквами и ссылкой на www.delphi-jedi.org, остающейся после :)
Тока что это воспроизвёл эти понты с летающими буквами и ссылкой на www.delphi-jedi.org, остающейся после :)
Есть, даже пользовался, когда писал в 7ке. Если п амять не изменяет — DeCaL. Не жаловался :)
Т.е. сначала библиотек вовсе нет, потом у них качество хромает, а потом и вовсе разработка ведется не фирмой в 10000 сотрудников, да странички в интернете плохо оформлены. Самим-то не смешно? Других аргументов, видимо, уже не осталось.
Качество JCL удовлетворит Вашему «industrial quality».
У одной только библиотеки JCL пол миллиона загрузок и десятки активных разработчиков.
>> Естественно мне неоткуда узнать о существовании всяких jcl и decal
Раз ничего не знаете в этой области, то и писать не стоит на эту тему.
>> Естественно мне неоткуда узнать о существовании всяких jcl и decal
Раз ничего не знаете в этой области, то и писать не стоит на эту тему.
Список разработчиков
sourceforge.net/project/memberlist.php?group_id=47514
О качестве кода говорит хотя бы то, что этот код прекрасно собирается из исходников (а именно так он и распространяется) на всех версиях Делфи начиная с 5 (или 6й), заканчивая самыми последними и на FreePascal. Работает без ошибок и нареканий.
По поводу проектов на JCL… скажите, а где я могу посмотреть список проектов на плюсах использующих STL? Пример кстати сопоставим.
И закончим холиварить на этом.
sourceforge.net/project/memberlist.php?group_id=47514
О качестве кода говорит хотя бы то, что этот код прекрасно собирается из исходников (а именно так он и распространяется) на всех версиях Делфи начиная с 5 (или 6й), заканчивая самыми последними и на FreePascal. Работает без ошибок и нареканий.
По поводу проектов на JCL… скажите, а где я могу посмотреть список проектов на плюсах использующих STL? Пример кстати сопоставим.
И закончим холиварить на этом.
как мне надоело окно Find and Replace в 2010 студии, которое так и тянет к чему-нибудь прицепиться! кто-нибудь придумал как от этого избавиться?
Приемуществом Delphi всегда была генерация стабильного нативного кода и конечно же тонны компонент как «из коробки» так и от сообщества. Люди умудрились убить в один момент оба своего приемущества: подкосили совместимость со старыми VCL компонентами и переориентировались на .Net Framework. Имхо, никакие рюшки в синтаксисе и IDE уже не возродит сообщества в былых масштабах. а жаль…
У Делфи прекрасная совместимость, в т.ч. и по компонентам — можно без проблем вести разработку на совершенно разных версий IDE (7 и 2007, к примеру).
Переориентации никакой нет, а разработка инструментов под .NET после подставы со вторым фреймворком со стороны Майкрософт была убрана в далекий ящик.
Переориентации никакой нет, а разработка инструментов под .NET после подставы со вторым фреймворком со стороны Майкрософт была убрана в далекий ящик.
Не получится.
У Форм добавились разные методы и свойства, в частности выравнивание. Может между 7 и 2007 и нет разницы в .dfm, а вот набросок формы из 2010 перенести в 7 не получилось (у меня) из-за кучи не найденный свойств выравнивания и привязки, при игнорировании последний поехало все расположение компонентов.
У Форм добавились разные методы и свойства, в частности выравнивание. Может между 7 и 2007 и нет разницы в .dfm, а вот набросок формы из 2010 перенести в 7 не получилось (у меня) из-за кучи не найденный свойств выравнивания и привязки, при игнорировании последний поехало все расположение компонентов.
Меня вот Indy не устраивал. Я даже на делфи предпочитал писать свой класс для работы с почтой, ничего особо сложного там нет.
А после си-подобного синтаксиса я на делфи уже не могу смотреть без отвращения. Паскаль и делфи хороши для студентов, они почти идеальны для обучения программированию. Но использоваться их в повседневной работе — это скорее мазохизм.
А после си-подобного синтаксиса я на делфи уже не могу смотреть без отвращения. Паскаль и делфи хороши для студентов, они почти идеальны для обучения программированию. Но использоваться их в повседневной работе — это скорее мазохизм.
Думаю, что у таких студентов просто нет желания.
Я начинал в школе с делфи, потом C++, Perl, C#, как-то не замечал особых трудностей )
Начинал с Делфи, и сейчас мелкие рутинные утилитки пишу на них.
Потом перешел на плюсы, сейчас занимаюсь тем, что пишу системные сервисы и программы опроса внешних устройств работающие по принципу 24х7
Было бы желание.
Кстати ООП в Делфи не самый плохой, я и сейчас крайне редко применяю наследование от нескольких классов, а вот модель private/protected/public у Делфи мне нравится даже больше, чем у С++
Потом перешел на плюсы, сейчас занимаюсь тем, что пишу системные сервисы и программы опроса внешних устройств работающие по принципу 24х7
Было бы желание.
Кстати ООП в Делфи не самый плохой, я и сейчас крайне редко применяю наследование от нескольких классов, а вот модель private/protected/public у Делфи мне нравится даже больше, чем у С++
Боюсь предположить, что эволюция могла бы сделать со мной, если бы Вы были правы :) Ведь я начинал с бейсика на БКшке, причем и кюбейсик на ПК поюзал :)
P.S. с вышеописанными симптомами сталкиваюсь постоянно, приводят на практику. Давайте быть честными, они не просто ООП не знают, а вообще программировать не умеют. На уровне алгоритмов и АТД :) Эдакие «рисовальщики» форм :)
P.S. с вышеописанными симптомами сталкиваюсь постоянно, приводят на практику. Давайте быть честными, они не просто ООП не знают, а вообще программировать не умеют. На уровне алгоритмов и АТД :) Эдакие «рисовальщики» форм :)
А мои наблюдения таковы: те кто начинал с C++, либо остаются в отрасли либо вообще из нее уходят. И С++ больше преподают на профильных специальностях, в том числе яву и кучу других языков. Отсюда специалисты более широкого мировозрения. А pascal — на специальностях зачастую к програмированию не имеющих отношение, отсюда ощущения, что паскальщики тупят, хотя в плане типизации и ооп паскаль ИМХО гораздо лучше дисциплинирует.
Вопрос красоты языка достаточно относительный. Мне, к примеру, нравится синтаксис C# больше, чем Delphi. И написать иногда лишние пару скобочек (а обычно это делает сама программа) совсем для меня не трудно.
злой копирайтер: скачек -> скачок
теоритический -> теорЕтический
куму-то -> кому-то
куму-то -> кому-то
Delphi ругают те, кто толком его не знает.
Он очень прост в освоении на базовом уровне. И вот, посмотрев, на базовый уровень многие делают ошибочные выводы. Ну и да, есть куча говнокода. Ну а где его нет? С подключением С/С++ библиотек, там как раз меньше всего проблем. Основная проблема на данный момент — отсутствие 64bit компилятора, она вроде как решается — на результат посмотрим.
Как многие уже сказали, С# сравнивать с ним нет смысла. Давайте еще с JavaScript сравним.
Для каждой задачи свои инструменты.
Ну хорошо, если уже сравнивать, то я бы разместил Delphi где-то между С++ и С#, по шкале универсальность/простота освоения.
Да и вообще мы изначально сравниваем несравнимые вещи.
По хорошему надо сравнивать так:
Object Pascal — C# — C++
VCL, CLX — .NET — QT, MFC,…
RAD Studio — Visual Studio — Visual Studio,…
C другой стороны одно, от другого вроде бы не оторвать, но есть же еще С++ Builder. Delphi Prism. Ну и чисто теоретически, наверно, можно прикрутить компилятор dcc в Visual Studio.
Он очень прост в освоении на базовом уровне. И вот, посмотрев, на базовый уровень многие делают ошибочные выводы. Ну и да, есть куча говнокода. Ну а где его нет? С подключением С/С++ библиотек, там как раз меньше всего проблем. Основная проблема на данный момент — отсутствие 64bit компилятора, она вроде как решается — на результат посмотрим.
Как многие уже сказали, С# сравнивать с ним нет смысла. Давайте еще с JavaScript сравним.
Для каждой задачи свои инструменты.
Ну хорошо, если уже сравнивать, то я бы разместил Delphi где-то между С++ и С#, по шкале универсальность/простота освоения.
Да и вообще мы изначально сравниваем несравнимые вещи.
По хорошему надо сравнивать так:
Object Pascal — C# — C++
VCL, CLX — .NET — QT, MFC,…
RAD Studio — Visual Studio — Visual Studio,…
C другой стороны одно, от другого вроде бы не оторвать, но есть же еще С++ Builder. Delphi Prism. Ну и чисто теоретически, наверно, можно прикрутить компилятор dcc в Visual Studio.
Зачем Вам C#, если там всё так плохо?
Ну нельзя так писать. Если хотелось про приведение типов — то можно было просто написать «приведение типов в стиле С/C++» и однострочный пример ((Manager)manager).GetBonus());
А видя пример на экран с наследованием и циничным убийством ООП, не верится что автор компетентен… Возможно, дельфисты смеялись не над скобочками а над кодом?
# Employee manager = new Manager();…
# ((Manager)manager).GetBonus());
А видя пример на экран с наследованием и циничным убийством ООП, не верится что автор компетентен… Возможно, дельфисты смеялись не над скобочками а над кодом?
# Employee manager = new Manager();…
# ((Manager)manager).GetBonus());
В примере с TStringList будет утечка памяти, нужно делать
Если не будет исключения, то может и компилятор разрулит, но у делфиста с 7-летним стажем это должно быть на автомате. Ну и еще при работе с списком строк принято объявлять переменную абстрактного класса TStrings и инициализировать ее как TStringList.
stringList := TStringList.Create();
try
...
finally
stringList.Free();
end;
Если не будет исключения, то может и компилятор разрулит, но у делфиста с 7-летним стажем это должно быть на автомате. Ну и еще при работе с списком строк принято объявлять переменную абстрактного класса TStrings и инициализировать ее как TStringList.
> скачек
Ага, а также прЫжек, щЕлчек, крУжек, знАчек…
Ага, а также прЫжек, щЕлчек, крУжек, знАчек…
приём почты через pop3 я делаю так:
TcpClient tcpClient = new TcpClient();
tcpClient.Connect(pop3, port);
NetworkStream netStream = tcpClient.GetStream();
System.IO.StreamReader strReader = new System.IO.StreamReader(netStream);
if (tcpClient.Connected)
{
…
}
TcpClient tcpClient = new TcpClient();
tcpClient.Connect(pop3, port);
NetworkStream netStream = tcpClient.GetStream();
System.IO.StreamReader strReader = new System.IO.StreamReader(netStream);
if (tcpClient.Connected)
{
…
}
Советую вам прочитать книжку CLR via C# 3rd edition. Там очень подробно объясняется, как .NET устроен изнутри.
Спасибо за историю. Сам думаю о таком переходе. С интересом прочитал о вашем опыте.
Ох, это ощущение, когда в 2016 пишешь на Delphi 7 и перехода не предвидится.
Это очень плохое решение, потому что
1) Весь файл будет прочтен и разобран на строки. А нам этого не надо.
2) При выводе строки будут склеиваться в один поток, а с учетом 1 нам этого не надо
3) При вставке в нулевую позицию произойдет смещение на ячейку (4/8 байт) «вниз» всего массива (скажем, было 10к строк — 10к ячеек на одну вниз). Потому что TStringList он никакой не list.
По поводу поиска в среде: сила дельфийской IDE — в плагинах. GExperts и CNPack. Список процедур, поиск по модулям, автодополнение, раскрашивание кода, отделение блоков цветными линиями, подсвечивание скобок и т.д.
Кстати, по поводу преимуществ — как в C# с получение стек-трейсов? У нас используется EurekaLog на Delphi, выдает стек, имя модуля и объекта, номер строки. Присылается по почте, например.
Попробуйте реализовать то же самое на C#. Если у Вас получится сделать это также элегантно, то я буду только рад, поскольку давно уже ищу такой способ.
Это очень плохое решение, потому что
1) Весь файл будет прочтен и разобран на строки. А нам этого не надо.
2) При выводе строки будут склеиваться в один поток, а с учетом 1 нам этого не надо
3) При вставке в нулевую позицию произойдет смещение на ячейку (4/8 байт) «вниз» всего массива (скажем, было 10к строк — 10к ячеек на одну вниз). Потому что TStringList он никакой не list.
По поводу поиска в среде: сила дельфийской IDE — в плагинах. GExperts и CNPack. Список процедур, поиск по модулям, автодополнение, раскрашивание кода, отделение блоков цветными линиями, подсвечивание скобок и т.д.
Кстати, по поводу преимуществ — как в C# с получение стек-трейсов? У нас используется EurekaLog на Delphi, выдает стек, имя модуля и объекта, номер строки. Присылается по почте, например.
Очень странно слышать что после 7-ки до 2009 не было нормальных версий. Я с 7-ки перешел на 2006 (Turbo Delphi Explorer) и пользовался этой версией много лет, сделал немало проектов. Так вот, по-моему очень стабильная и надёжная версия, заметно надёжнее современной 10.3. Ну и в плане языка по сравнению с Delphi-7 в Delphi-2006 есть куча полезных изменений.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Незаконченная история перехода с Delphi на C#