class FirstLevelException : Exception
{
}
class SecondLefelException : FirstLevelException
{
}
...
try
{
DoSomething();
}
catch (SecondLevelException)
{
}
catch (FirstLevelException)
{
}
catch (Exception)
{
}
самосовершенствование
Отучился в институте 3 курса. Изучали С++. Прошли базу которая описана во всех учебниках по этому языку. Естественно специалистом в С++ я от этого не стал. Решать простейшие задачки решать уже надоело, руку набил. В связи со всем этим возник вопрос: какие технологии, приемы в программировании сейчас наиболее распространены и востребованы? Что изучить? И наскока сейчас востребован C#?
сильно востребован! :)
работая в ИТ компании у меня сложилось впечатление, что на С++"ный проект мне не попасть - зачем я, 20-летний пацан, если есть взрослые дядьки, у которых опыта работы на С++ столько, сколько мне лет всего! :(
а вот на С#\Java\PHP\Python\Perl мы, молодёж, с ними тягаться можем! :-P а сам шарп востребованый довольно
работая в ИТ компании у меня сложилось впечатление, что на С++"ный проект мне не попасть - зачем я, 20-летний пацан, если есть взрослые дядьки, у которых опыта работы на С++ столько, сколько мне лет всего! :(
а вот на С#\Java\PHP\Python\Perl мы, молодёж, с ними тягаться можем! :-P а сам шарп востребованый довольно
не правда. и С++ сейчас очень даже востребован. причем именно Junior'a сейчас найти - днем с огнем. "взрослые дядьки" - они рядовыми девелоперами быть не хотят ;) им team-leader'ство подавай
А если говорить о Win32: насколько сейчас востребована разработка с использованием чистого API? Или это теперь чуть ли не официально "discouraged", и всех склоняют использовать .NET Framework?
Цитата: Tirpitz
А если говорить о Win32: насколько сейчас востребована разработка с использованием чистого API?
Всегда все зависит от задачи. Никто не станет реализовывать софт уровня офисного пакета с регистрации класса главного окна. Разработка сложного интерфейса немыслима на Win API или MFC (да покарает меня Аллах :D ). А вот какие-то тонкие вещи, нереализованные в .NET Framework, типа различного рода общения с shell32 вполне тянут на создание нормальной управляемой (managed) обертки вокруг API.
з.ы. для меня С++ слишком тошен, чего бы не говорили его защитники. Java? она мне как язык не нравится (да я в плане языков эстет). Потому для себя решил - .NET
Цитата: hardcase
Потому для себя решил - .NET
Только вот .NET - не язык... :)
N-John, не имеет значения какой язык учить. Все равно придется переучиваться.
Если ты считаешь, что тебе сейчас нужно поднапрячься и выучить, к примеру, C#, а потом все оставшуюся жизнь почить на его лаврах, то ты очень ошибаешься. Учиться придется постоянно.
Начни учить C++ и C# одновременно. Делов то... По четным дням недели пишешь на C++, по нечетным - на C#.
Цитата: Green
Только вот .NET - не язык... :)
.NET Больше чем язык. :)
Цитата: hardcase
.NET Больше чем язык. :)
И даже больше, чем платформа.
О!! назревает холивар. Не хватает тока самоубийц-моджохедов, волающих: "пиши на асме, все остальное - фигня". :D
Цитата: hardcase
Java? она мне как язык не нравится (да я в плане языков эстет). Потому для себя решил - .NET
Я конечно извиняюсь... :)
А что в языке не так? Именно с точки зрения осмысленности, ясности, лаконичности и достаточности самого языка?
Друзья, работающие на C# наоборот, плюются по поводу языка
(по поводу громоздкости и излишеств синтаксических конструкций).
[quote=Green]
Только вот .NET - не язык...
[/quote]
Ну если "на вопросы смотреть ширше", так и Java тоже не язык ;) Верней, далеко не только язык.
Цитата: Zorkus
Ну если "на вопросы смотреть ширше", так и Java тоже не язык ;) Верней, далеко не только язык.
Ну так .NET - совсем не язык. :)
[QUOTE=N-John]...И наскока сейчас востребован C#?[/QUOTE]Майкрософт заявила о C# как о новом основном средстве разработки приложений для Windows.[QUOTE=Green]Ну так .NET - совсем не язык. [/QUOTE]В рамках .NET языки отличаются лишь правилами написания управляющих конструкций, то есть синтаксисом. Парадигма языков, нацеленных на исполнение под CLR, одна и та же, по большому счёту (впрочем, остаётся Cobol, в котором я, признаться, ничего не смыслю, да и не интересен он мне вовсе. Мож там всё и по-другому, но мне в это не верится).
Цитата: N-John
...возник вопрос: какие технологии, приемы в программировании сейчас наиболее распространены и востребованы? Что изучить? И наскока сейчас востребован C#?
Я тут прочитал следующее: "какой язык мне нужно изучить, чтоб было легче устроиться на работу и чтоб больше получать". Подход понятен и для меня несколько печален.
Но ладно, пусть будет такой подход. В этом случае лучше уже сейчас идти в какую-нибудь уважаемую фирму и устраиваться туда на четверть ставки (пол-ставки или еще как) за небольшую плату. Там вам скажут что востребовано и что учить, а вы полезным делом займетесь. А когда окончите институт, то легко устроитесь на эту работу и будете получать хорошую зарплату.
Может мои высказывания спорны, но кагда я после окончания института пытался устраиваться на работу, мне большинство работодателей говорили, что я опоздал, что должен был приходить к ним еще студентом...
Вообще все споры о том, какой язык лучше, по моему бесмыслены. Какой язык использовать - это во первых, дело личных предпочтений, во вторых, в значительной степени определяется тем, какую задачу предстоит решать.
А вообще я согласен с уже озвученным мнением, какой язык не учи, все равно придется доучиваться. Да и вообще, при нашей профессии, учиться приходится всю жизнь.
А вообще я согласен с уже озвученным мнением, какой язык не учи, все равно придется доучиваться. Да и вообще, при нашей профессии, учиться приходится всю жизнь.
Цитата: Kogrom
]
Но ладно, пусть будет такой подход. В этом случае лучше уже сейчас идти в какую-нибудь уважаемую фирму и устраиваться туда на четверть ставки (пол-ставки или еще как) за небольшую плату. Там вам скажут что востребовано и что учить, а вы полезным делом займетесь. А когда окончите институт, то легко устроитесь на эту работу и будете получать хорошую зарплату.
Может мои высказывания спорны, но кагда я после окончания института пытался устраиваться на работу, мне большинство работодателей говорили, что я опоздал, что должен был приходить к ним еще студентом...
Но ладно, пусть будет такой подход. В этом случае лучше уже сейчас идти в какую-нибудь уважаемую фирму и устраиваться туда на четверть ставки (пол-ставки или еще как) за небольшую плату. Там вам скажут что востребовано и что учить, а вы полезным делом займетесь. А когда окончите институт, то легко устроитесь на эту работу и будете получать хорошую зарплату.
Может мои высказывания спорны, но кагда я после окончания института пытался устраиваться на работу, мне большинство работодателей говорили, что я опоздал, что должен был приходить к ним еще студентом...
Правильно говорили.
Насчет 1/4 ставки -- о таких вакансиях я вообще не слышал, если честно. Если вы хотите развиваться, найдите немного больше времени для этого, чем 2 часа в день.
У нас, например, на 0.5 ставки берут в основном, студентов, на draft-QA. И то, эти вакансии далеко не всегда есть.
Девелопером же на полставки если и берут, то в довольно редких случаях, + работу там дают типа написания unit-тестов, саппорта, мелких багфиксов и т.п. Совершенно не творческая, мало развивает, исключительно для получения небольших денег. А гнаться в начале карьеры за деньгами более чем за мастерством - губительно :).
Сколько нибудь интересные вакансии есть только на полные ставки :)
(это я говорю про Самарский рынок, и вообще IMHO).
Это я понял, когда устраивался на работу (на 3 курсе), и сразу пошел на полную ставку :). Эксперимент показал, что учиться на дневном отделении + работать на полную ставку вполне реально.
И немного времени даже остается свободного.
Цитата: Zorkus
Эксперимент показал, что учиться на дневном отделении + работать на полную ставку вполне реально.
Ну, я только один такой случай припоминаю, чтоб кто-то мог совмещать и не вылететь из технического ВУЗа. Это смог человек, про которого вся кафедра говорила, что он непостижимо удивительный гений, и что выгнать его нельзя по этой причине, не смотря на то, что в институте он появляется раз в месяц.
То есть главное - убедить преподавателей в том, что вы гений и в будущем прославите родной институт :)
Цитата: Kogrom
Ну, я только один такой случай припоминаю, чтоб кто-то мог совмещать и не вылететь из технического ВУЗа. Это смог человек, про которого вся кафедра говорила, что он непостижимо удивительный гений, и что выгнать его нельзя по этой причине, не смотря на то, что в институте он появляется раз в месяц.
То есть главное - убедить преподавателей в том, что вы гений и в будущем прославите родной институт :)
То есть главное - убедить преподавателей в том, что вы гений и в будущем прославите родной институт :)
:D
Во! Зришь в корень ;)
Работать первые два года на имя среди преподов кафедры, чтобы потом оно работало на тебя.
Ну раз в месяц -- это наверное чересчур. Если не на 5 курсе.
Но раз-два в неделю заходить - нормально. Если не ставить целью учиться на 5-ки, конечно.
Я знаю еще пару ребят, устроившихся так.
Тут еще главное, взвесить сможешь ли ты. По времени и силам, и не слушать безоглядно друзей/подруг/одногруппников/преподавателей/..., которые станут крутить пальцем у виска и говорить, что ты самоуверенный псих, и зачем тебе это надо, и не надо гнаться за стаей зайцев, etc.
Развели, тля, старую универскую бодягую. Альма-матер, понимаешь...
С++ - отстой!!! Вот самое оно - по настоящему современные языки - С#, .NET и CLR!. А я настолько затормозил с этим C++, что уже 15 лет не могу с него слезть. Не могу "быть на уровне" нормального "менеджера по созданию программного обеспечения". Да и платят мало, нафик... Вот кому это, скажите, надо: всякие там ботаники, типа Кнута и иже с ним.
Столица! C#! Хата "в пределах Садового", и выплаты по кредиту за иномарку под полтора лимона... Вот она, жизнь!!! В вы тут: "структуры данных", "лаконичность"... Главное: Перспективность! Удачливость! Денег - как грязи... Годик - другой поработаем, хрен с ним, программистом, потом магазинчик откроем... Тоже фирма, ёханый бабай...
Так что: Налетай! Подешевело!
С++ - отстой!!! Вот самое оно - по настоящему современные языки - С#, .NET и CLR!. А я настолько затормозил с этим C++, что уже 15 лет не могу с него слезть. Не могу "быть на уровне" нормального "менеджера по созданию программного обеспечения". Да и платят мало, нафик... Вот кому это, скажите, надо: всякие там ботаники, типа Кнута и иже с ним.
Столица! C#! Хата "в пределах Садового", и выплаты по кредиту за иномарку под полтора лимона... Вот она, жизнь!!! В вы тут: "структуры данных", "лаконичность"... Главное: Перспективность! Удачливость! Денег - как грязи... Годик - другой поработаем, хрен с ним, программистом, потом магазинчик откроем... Тоже фирма, ёханый бабай...
Так что: Налетай! Подешевело!
Цитата: Lerkin
Главное: Перспективность! Удачливость! Денег - как грязи... Годик - другой поработаем, хрен с ним, программистом, потом магазинчик откроем... Тоже фирма, ёханый бабай...
Ишь, как человек переживает :)
Мне тоже такая позиция не очень нравится, но я, образно выражаясь, "живу в стране эльфов", меня вообще деньги мало интересуют. Нельзя этого требовать от других.
С другой стороны, мой подход дает свободу от того, какой язык программирования востребован кем-то. Главное - какой язык программирования востребован мной, для воплощения моих идей, моих проектов.
Ок, малясь похоливарим :rolleyes:
Цитата: Zorkus
Я конечно извиняюсь... :)
А что в языке не так? Именно с точки зрения осмысленности, ясности, лаконичности и достаточности самого языка?
А что в языке не так? Именно с точки зрения осмысленности, ясности, лаконичности и достаточности самого языка?
Отсутствие свойств. Привычка у меня есть такая с Делфей оставшаяся. Люблю свойства и терпеть немогу get_теры и set_теры.
Кривоватые парамтерические типы (генерики).
Виртуальность функций по-умолчанию но это фигня по сути.
Отсутствие структур (копозитных типов-значений) - кругом классы. Я вот частенько использую структуры.
Но скорее самый главный минус - нету атрибутов. Без атрибутов вообще не представляю разрботки чего-либо более сложного чем HelloWorld.
Цитата: Zorkus
Друзья, работающие на C# наоборот, плюются по поводу языка(по поводу громоздкости и излишеств синтаксических конструкций).
Для меня по крайней мере существует один недостаток в C#2.0 - это неудобство объявления свойств. В этом плане в C#3.0 удобнее - есть автосвойства.
Цитата: Kogrom
Ну, я только один такой случай припоминаю, чтоб кто-то мог совмещать и не вылететь из технического ВУЗа.
да ладно... я пол-четвертого и пятый курс проработал на госпредприятие. и ничего. до гения мне, как на четвереньках до пекина :)
Lerkin - колись - пил? :)
Цитата: squirL
да ладно... я пол-четвертого и пятый курс проработал на госпредприятие. и ничего. до гения мне, как на четвереньках до пекина :)
Скромничаете :) Да и потом, я не утверждал, что тот человек был гением. Главное - так думали преподаватели :)
Ну и еще от ВУЗа зависит, от кафедры, от специальности. В моем случае довольно строго было с посещениями занятий, особенно практических и лабораторных.
Цитата: squirL
Lerkin - колись - пил? :)
:rolleyes: ну, есть чуток... а что, неправду глаголю?
это я под воздействием ощущений от "Гордон Кихот", сорри...
пойду и я тогда, за компанию... ты кстати в IRC заходь :) там для задушевных разговоров самое место. под пивко ;)
Цитата: Der Meister
Парадигма языков, нацеленных на исполнение под CLR, одна и та же, по большому счёту (впрочем, остаётся Cobol, в котором я, признаться, ничего не смыслю, да и не интересен он мне вовсе. Мож там всё и по-другому, но мне в это не верится).
Как раз парадигмы языков могут быть совершенно разными, главное, чтобы после компиляции получался код понятный CLR.
Цитата: hardcase
Ок, малясь похоливарим :rolleyes:
Отсутствие свойств. Привычка у меня есть такая с Делфей оставшаяся. Люблю свойства и терпеть немогу get_теры и set_теры.
Кривоватые парамтерические типы (генерики).
Виртуальность функций по-умолчанию но это фигня по сути.
Отсутствие структур (копозитных типов-значений) - кругом классы. Я вот частенько использую структуры.
Но скорее самый главный минус - нету атрибутов. Без атрибутов вообще не представляю разрботки чего-либо более сложного чем HelloWorld.
Для меня по крайней мере существует один недостаток в C#2.0 - это неудобство объявления свойств. В этом плане в C#3.0 удобнее - есть автосвойства.
Отсутствие свойств. Привычка у меня есть такая с Делфей оставшаяся. Люблю свойства и терпеть немогу get_теры и set_теры.
Кривоватые парамтерические типы (генерики).
Виртуальность функций по-умолчанию но это фигня по сути.
Отсутствие структур (копозитных типов-значений) - кругом классы. Я вот частенько использую структуры.
Но скорее самый главный минус - нету атрибутов. Без атрибутов вообще не представляю разрботки чего-либо более сложного чем HelloWorld.
Для меня по крайней мере существует один недостаток в C#2.0 - это неудобство объявления свойств. В этом плане в C#3.0 удобнее - есть автосвойства.
По поводу свойств в C# - спорно. Простое действие - чтение/запись значения, но при этом может происходить что угодно. Причем неприятность в том, что далеко не всегда можно быть уверенным, что присвоение произошло.
Хотя, конечно, очень удобно:)
Что-то мне подсказывает, что раньше такие темы носили название "С чего начать?", подразумевая "как зашибить бабла, без особого напряга".
Извините, если обидел. Намерения такого не было...
Извините, если обидел. Намерения такого не было...
Цитата: lifs
По поводу свойств в C# - спорно. Простое действие - чтение/запись значения, но при этом может происходить что угодно. Причем неприятность в том, что далеко не всегда можно быть уверенным, что присвоение произошло.
Аналогично. При вызове get_тера или set_тера может происходить что угодно, и далеко не всегда можно быть уверенным, что присвоение произошло.
Но если быть честным, свойства нужны не для того чтобы усложнять программу. Они нужны чтобы упрощать - это часть понятия инкапсуляции. И еще, свойство - единая сущность, а если мы используем идеологию геттеров/сеттеров - у нас получается две сущности для одного понятия, Оккам был бы недоволен.
PS Компилер всеравно для поддержки свойств формирует специальные методы get_XXX и set_XXX а для событий add_XXX и remove_XXX.
Цитата: hardcase
Но если быть честным, свойства нужны не для того чтобы усложнять программу. Они нужны чтобы упрощать - это часть понятия инкапсуляции. И еще, свойство - единая сущность, а если мы используем идеологию геттеров/сеттеров - у нас получается две сущности для одного понятия, Оккам был бы недоволен.
По поводу инкапсуляции - бесспорно.
Но, во-первых, проблемы с совместимостью с другими .NET языками при использовании индексаторов - не все поддерживают в полном объеме (например, тот же C#), а также ограничения накладываемые на использование в качестве out и ref параметра.
Во-вторых, свойства могут каждый раз возвращать разные значения (например, тот же DateTime.Now), что не есть хорошо.
Цитата: hardcase
Ок, малясь похоливарим :rolleyes:
Отсутствие свойств. Привычка у меня есть такая с Делфей оставшаяся. Люблю свойства и терпеть немогу get_теры и set_теры.
Кривоватые парамтерические типы (генерики).
Виртуальность функций по-умолчанию но это фигня по сути.
Отсутствие структур (копозитных типов-значений) - кругом классы. Я вот частенько использую структуры.
Но скорее самый главный минус - нету атрибутов. Без атрибутов вообще не представляю разрботки чего-либо более сложного чем HelloWorld.
Для меня по крайней мере существует один недостаток в C#2.0 - это неудобство объявления свойств. В этом плане в C#3.0 удобнее - есть автосвойства.
Отсутствие свойств. Привычка у меня есть такая с Делфей оставшаяся. Люблю свойства и терпеть немогу get_теры и set_теры.
Кривоватые парамтерические типы (генерики).
Виртуальность функций по-умолчанию но это фигня по сути.
Отсутствие структур (копозитных типов-значений) - кругом классы. Я вот частенько использую структуры.
Но скорее самый главный минус - нету атрибутов. Без атрибутов вообще не представляю разрботки чего-либо более сложного чем HelloWorld.
Для меня по крайней мере существует один недостаток в C#2.0 - это неудобство объявления свойств. В этом плане в C#3.0 удобнее - есть автосвойства.
Про события не забудь, братан, про события! :) И про отражение. И про безопасность вкупе с контролем версий.
Взамен аттрибутов C++ предлагает макросы (да и препроцессор вообще) + шаблоны. Просто для того, чтобы выполнить немного кода во время компиляции, геморра побольше придётся насидеть (впрочем, при умелых-то руках... По-моему, это дело опыта).
Цитата:
По поводу свойств в C# - спорно. Простое действие - чтение/запись значения, но при этом может происходить что угодно. Причем неприятность в том, что далеко не всегда можно быть уверенным, что присвоение произошло.
Хотя, конечно, очень удобно
Хотя, конечно, очень удобно
Так ведь исключения в руки, и вперёд. Зато, например, я без труда могу отследить, изменилось ли значение того или иного поля, или нет. Да и вообще, введение контроля над значением поля требует минимума усилий. Помимо всего прочего, с помощью свойств можно легко реализовать отложенное создание экземпляров объектов (правда, в C++ для этого хорошо подходят шаблоны, но с их применением в данной области связано немало досадных нюансов)
Цитата:
Но, во-первых, проблемы с совместимостью с другими .NET языками при использовании индексаторов - не все поддерживают в полном объеме (например, тот же C#)...
Индекаторы канают по CTS, и то, что какая-то из реализаций какого-либо языка не поддерживает CTS в полном объёме, не есть проблема .NET. Кстати, а в каком месте применение индексаторов в C# ограничено? Чё от них ещё требуется-то?
Цитата:
...а также ограничения накладываемые на использование в качестве out и ref параметра.
Потому, что out и ref вообще плохая практика, на мой взгляд. Данные ограничения заставляют обращать внимание на ошибки, которые происходят при возврате значения функции через параметры, которые совершаются изо дня в день уже более пятнадцати лет. По-моему так.
Цитата:
Во-вторых, свойства могут каждый раз возвращать разные значения (например, тот же DateTime.Now), что не есть хорошо.
Чего плохого в том, что мой возраст увеличивается с каждой секундой? Я же от этого не становлюсь неуправляемым и неоднозначным... Мой возраст является моим неотъемлемым свойством, и для того, чтобы его знать, необязательно, в принципе, явно меня о нём спрашивать: я не должен выполнять никакой работы для изменения его величины. Логично?
Цитата: hardcase
Кривоватые парамтерические типы (генерики).
И чем они кривоваты? :)
Да, на уровне байткода их нету, никакой информации о предпочтительном типе не сохраняется, и внутри там сплошь Object-ы и тайпкастинг. Но это не проблема языка, это проблема Javac/JVM.
Цитата:
Виртуальность функций по-умолчанию но это фигня по сути.
Почему фигня? Это тебя особенно напрягает? :)
Цитата:
Отсутствие структур (копозитных типов-значений) - кругом классы. Я вот частенько использую структуры.
Опять таки, я лично не могу сказать каково это, но не вижу в чем преимущество использования структур. Просто не вижу, зачем нужно иметь структуры в языке.
Знакомые опять же, в этом аспекте языка плюются и говорят, что реализованы они криво, при маршаллинге с ними проблемы и т.п.
Цитата:
Но скорее самый главный минус - нету атрибутов. Без атрибутов вообще не представляю разрботки чего-либо более сложного чем HelloWorld.
Я бы сказал несколько по другому. "Не представляю возможности разработки более сложного в .NET". То, что .NET везде требуются аттрибуты, не значит, что они безусловно необходимы другим языкам.
Я же могу указать следующие минус .NET :) :
1) Отсутствие проверяемых исключений!!!
2) Вообще концепция обработки исключений в .NET мне не нравится.
Как-то с одним другом решали задачу, работали параллельно на Java и .NET, задача из области криптографии. Так вот, он мне показывал метод один, у которого известно, что он может выбросить кучу узкоспец. исключений исключений (пример сейчас с ходу не приведу, извини. Возможно, через неделю смогу, если хочешь). Я бы сделал более иерархию исключений, и выбрасывал бы проверяемое исключение более высокого уровня, с указанной в качестве причины более узкоспециальным исключением (например - checked Exception - FileReadException, root cause - FilePermissionException+ сообщение об ошибке).
Насколько я знаю, в C# нету возможности написать несколько отдельных выражений catch{}. В итоге часто встречается код в виде
catch(Exception ex). Перехват всего вообще наугад :).
2) Много лишних элементов типа in/out, которые не прям сверхюзабельны и в загромождают язык.
[QUOTE=Zorkus]Насколько я знаю, в C# нету возможности написать несколько отдельных выражений catch{}[/QUOTE]Отчего же? Нормально
Код:
Цитата: Der Meister
Так ведь исключения в руки, и вперёд. Зато, например, я без труда могу отследить, изменилось ли значение того или иного поля, или нет. Да и вообще, введение контроля над значением поля требует минимума усилий. Помимо всего прочего, с помощью свойств можно легко реализовать отложенное создание экземпляров объектов (правда, в C++ для этого хорошо подходят шаблоны, но с их применением в данной области связано немало досадных нюансов)
Индекаторы канают по CTS, и то, что какая-то из реализаций какого-либо языка не поддерживает CTS в полном объёме, не есть проблема .NET. Кстати, а в каком месте применение индексаторов в C# ограничено? Чё от них ещё требуется-то?
Индекаторы канают по CTS, и то, что какая-то из реализаций какого-либо языка не поддерживает CTS в полном объёме, не есть проблема .NET. Кстати, а в каком месте применение индексаторов в C# ограничено? Чё от них ещё требуется-то?
Причем тут CTS? CLR поддерживает индексация любых свойств, а не только 1 как c# или Visual Basic. Не всегда сторонние компоненты генерят исключения, а тупо молчат.
Цитата: Der Meister
Взамен аттрибутов C++ предлагает макросы (да и препроцессор вообще) + шаблоны. Просто для того, чтобы выполнить немного кода во время компиляции, геморра побольше придётся насидеть (впрочем, при умелых-то руках... По-моему, это дело опыта).
Аттрибуты и макросы - разные вещи. Аттрибты в большинстве своем добавляются в метаданные и позволяют описывать дополнительные свойства объекта, динамически получаемые во время выполнения. Макросы же выполняются на стадии компиляции и все.
Цитата: Der Meister
Чего плохого в том, что мой возраст увеличивается с каждой секундой? Я же от этого не становлюсь неуправляемым и неоднозначным... Мой возраст является моим неотъемлемым свойством, и для того, чтобы его знать, необязательно, в принципе, явно меня о нём спрашивать: я не должен выполнять никакой работы для изменения его величины. Логично?
Ничего плохо в этом нет. Но не логично, что свойство, доступное только на get, постоянно изменяется. Имхо гораздо правльнее и логичнее GetTimeNow().
Цитата:
Просто не вижу, зачем нужно иметь структуры в языке.
Типы данных, доступные по значению.
Цитата:
Причем тут CTS? CLR поддерживает индексация любых свойств, а не только 1 как c# или Visual Basic. Не всегда сторонние компоненты генерят исключения, а тупо молчат.
CTS - соглашение, гарантирующее совместимость .NET сборок, созданных с применением различных средств разработки. CLR вообще много чего поддерживает, но на экспорт всё должно идти в соответствие с CTS - гарант совместимости, по идее. Так вот, причём тут поддержка индексации CLR? Можа и тупо свести индексатор к методу GetValue(Type index){} и всё. А вот вид функции типа this[Type index] регламентируется как раз-таки CTS.
Цитата:
Аттрибуты и макросы - разные вещи. Аттрибты в большинстве своем добавляются в метаданные и позволяют описывать дополнительные свойства объекта, динамически получаемые во время выполнения. Макросы же выполняются на стадии компиляции и все.
Ну почему же? С помощью одних только макросов можа наворотить класс до неузнаваемости (например, ввести самопальную поддержку RTTI), а уж если шаблонами уметь вертеть... Просто аттрибуты удобнее, на мой взгляд.
Цитата:
Ничего плохо в этом нет. Но не логично, что свойство, доступное только на get, постоянно изменяется. Имхо гораздо правльнее и логичнее GetTimeNow().
Ага. А ещё все данные логично хранить в структурах и обращаться к ним посредством вызова методов типа DateTime_GetDate(DATETIME dt).
Нелогичным было бы, если постоянно изменялось бы свойство, доступное для чтения и записи. Такое, конечно, возможно, но так и operator[] в C++ можно заставить отформатировать жёсткий диск. Здравый смысл вообще рулит.
Цитата: Der Meister
CTS - соглашение, гарантирующее совместимость .NET сборок, созданных с применением различных средств разработки. CLR вообще много чего поддерживает, но на экспорт всё должно идти в соответствие с CTS - гарант совместимости, по идее. Так вот, причём тут поддержка индексации CLR? Можа и тупо свести индексатор к методу GetValue(Type index){} и всё. А вот вид функции типа this[Type index] регламентируется как раз-таки CTS.
CTS дает полное описание типов данных и их взаимодействие, поодерживаемое виртуальной машиной. А CLS - описывает тот минимум, который должны поодерживать все языке для совместимости. Так вот индексирование различных свойств туда не входит. Кстати, this[..] превращается в get_Item.
Цитата: Der Meister
Ну почему же? С помощью одних только макросов можа наворотить класс до неузнаваемости (например, ввести самопальную поддержку RTTI), а уж если шаблонами уметь вертеть... Просто аттрибуты удобнее, на мой взгляд.Ага.
Опять. Аттрибуты и макросы - разные вещи и служат для разных целей. И используются по-разному.
Цитата:
Нелогичным было бы, если постоянно изменялось бы свойство, доступное для чтения и записи.
Но такие свойства можно написать.
Цитата:
Такое, конечно, возможно, но так и operator[] в C++ можно заставить отформатировать жёсткий диск.
Зачем?
Цитата: Zorkus
И чем они кривоваты?
Да, на уровне байткода их нету, никакой информации о предпочтительном типе не сохраняется, и внутри там сплошь Object-ы и тайпкастинг. Но это не проблема языка, это проблема Javac/JVM.
Да, на уровне байткода их нету, никакой информации о предпочтительном типе не сохраняется, и внутри там сплошь Object-ы и тайпкастинг. Но это не проблема языка, это проблема Javac/JVM.
Вот именно в этом и кривоваты. Последнее время приходится писать кодогенераторы, работающие в рантайме (генерирую шаблонный код используя атрибуты и отражение - таким макаром тягаю хранимые процедуры или выпонляю запросы в БД, могу показать при случае). А типы попадаются параметризированные, в связи с этим нужно иметь нормальный доступ к генерик-параметрам через отражение. Не представляю, как бы это выглядело, если везде были object-ы.
Цитата: Zorkus
Почему фигня? Это тебя особенно напрягает?
Да не слишком, просто в классике виртуальные методы требуют вызова через таблицу (но это уже головная больь оптимизатора кода).
Цитата: Zorkus
Опять таки, я лично не могу сказать каково это, но не вижу в чем преимущество использования структур. Просто не вижу, зачем нужно иметь структуры в языке.
Ну хм... для маршаллинга :) А еще бывает использую их в качестве легковесных объектов (когда нужно 2-3 поля хранить) для хранения в словарях.
Цитата: Zorkus
Знакомые опять же, в этом аспекте языка плюются и говорят, что реализованы они криво, при маршаллинге с ними проблемы и т.п..
Маршаллигн структур в неуправляемый код описывается посредством атрибутов. Да это тонкий момент и нужно быть просто внимательным при объявлении.
Цитата: Zorkus
Я бы сказал несколько по другому. "Не представляю возможности разработки более сложного в .NET". То, что .NET везде требуются аттрибуты, не значит, что они безусловно необходимы другим языкам.
Атрибуты - это дополнительная метаинформация. А когда информация была лишней? С помощью них можно более полно определить модель предметной области.
Цитата: Zorkus
Я же могу указать следующие минус .NET :) :
1) Отсутствие проверяемых исключений!!!
1) Отсутствие проверяемых исключений!!!
Всегда считал это плюсом. Этож ужс какой писать у метода throws и список эксепшонов. Потому частенько этот механизм нивилируется программистом: throws Exception успокаивает компилер.
Кстати этот механизм можно внедрить и в .NET: через атрибут, например вида [Throws(typeof(MyProject.SomeException))], а какаянить утиллита статической верификации кода потом прошерстила бы сборку на наличие кетч секций на эти исключения. Кстати клевая идея :)
Цитата: hardcase
Вот именно в этом и кривоваты. Последнее время приходится писать кодогенераторы, работающие в рантайме (генерирую шаблонный код используя атрибуты и отражение - таким макаром тягаю хранимые процедуры или выпонляю запросы в БД, могу показать при случае). А типы попадаются параметризированные, в связи с этим нужно иметь нормальный доступ к генерик-параметрам через отражение. Не представляю, как бы это выглядело, если везде были object-ы.
В Java 1.7 они будут уже на уровне байткода существовать. Возрадуйся ;)
Вообще активное использование рефлексии при работе с БД...Покажи, зачем тебе это надо, чтобы вытянуть хранимую процедуру?
[quote=hardcase]Ну хм... для маршаллинга :) А еще бывает использую их в качестве легковесных объектов (когда нужно 2-3 поля хранить) для хранения в словарях.
[/quote]
Я понял задачу. А зачем нужны структуры-то? :) Оставим пока нативный код. Сериализацию класса прекрасно можно делать. Хоть в бинарный формат, хоть в XML.
В чем преимущество использования структуры вместо класса в качестве Entry-row для коллекции? Существенно производительнее?
[quote=hardcase]
Атрибуты - это дополнительная метаинформация. А когда информация была лишней? С помощью них можно более полно определить модель предметной области.
[/quote]
В Java есть аннотации. Которые могут быть трех уровней доступности, как известно - Source, используемая компилером и затем отбрасываемая, Class, сохраняемая в байткоде и не загружаемая виртуальной машиной, и Runtime, доступные понятно когда.
Предположу, что это похоже на аттрибуты .NET.
Если так, то беру свои слова обратно:) Без аннотаций плохо.
[quote=hardcase]
Всегда считал это плюсом. Этож ужс какой писать у метода throws и список эксепшонов. Потому частенько этот механизм нивилируется программистом: throws Exception успокаивает компилер.
[/QUOTE]
Тут вопрос философии языка. Конечно, если программист пишет везде throws Exception, и catch(Exception), пользы от проверяемых ислючений никакой. Ну такому надо просто обрывать культяпки, чтоб не писал больше...
Каждое проверямое исключение показывает вполне реальную/вероятную сбойную ситуацию, которая может произойти. И которые программист должен отлавливать (каждую, естественно, отдельно), и обрабатывать адекватно. Как минимум -- логировать. А обычно еще изменять аккуратно логику, транслировать на другие уровни абстракции и прочее.
Так что тут я не согласен.
Джошуа Блох, "Java. Эффективное программирование." как раз пишет про то, как надо правильно их использовать (среди всего остального).
Цитата: Zorkus
В Java 1.7 они будут уже на уровне байткода существовать. Возрадуйся ;)
Клева :)
Цитата: Zorkus
Вообще активное использование рефлексии при работе с БД...Покажи, зачем тебе это надо, чтобы вытянуть хранимую процедуру?
Простой пример на вызов хранимки и возврат единственной строки:
Код:
[StoredProcedure("sdo_membership_CreateGroup")]
public abstract GroupEntry CreateGroup(Guid parent_id, string group_name);
public abstract GroupEntry CreateGroup(Guid parent_id, string group_name);
Код:
[StoredProcedure("sdo_membership_GetRootGroups")]
public abstract ICollection<GroupEntry> GetRootGroups();
public abstract ICollection<GroupEntry> GetRootGroups();
Код:
public class GroupEntry : PrincipalEntry {
private Guid _parentId;
[DataColumn("parent_id")]
public Guid ParentId {
get { return _parentId; }
set { _parentId = value; }
}
public bool IsRoot {
get { return ParentId == Guid.Empty; }
}
}
private Guid _parentId;
[DataColumn("parent_id")]
public Guid ParentId {
get { return _parentId; }
set { _parentId = value; }
}
public bool IsRoot {
get { return ParentId == Guid.Empty; }
}
}
Также есть атрибут SqlCommandAttribute, в котором можно прописать SQL-предложение, параметры метода в этом случае будут параметрами этой команды.
Атрибут DataColumnAttribute маркирует свойство Entry-класса для привязки к столбцу данных, вертаемых СУБД.
Спец. компилятор через отражение анализирует класс и выполняет реализацию абстрактных методов.
Цитата: Zorkus
В чем преимущество использования структуры вместо класса в качестве Entry-row для коллекции? Существенно производительнее?
Существенного повышения производительности в рутинных задачах получить видимо не удасться. Ну в крайне редких случаях при работе с unsafe кодом и указателями развечто. Плюс тут один - не используем кучу для создания объектов, это кстати касается массивов структур, которые создаются сразу, без дополнительной последовательной инициализации каждого элемента.
У меня же позиция скорее концептуальная. Если при объявлении класса я постулирую существование некой значимой сущности, тогда как объявление структуры я интерпретирую как некоторую комбинацию значений.
Цитата: Zorkus
В Java есть аннотации. Которые могут быть трех уровней доступности, как известно - Source, используемая компилером и затем отбрасываемая, Class, сохраняемая в байткоде и не загружаемая виртуальной машиной, и Runtime, доступные понятно когда.
Признаю, в Java я совсем не силен, и видимо заблуждаюсь в некоторых (многих) вещах. Повод купить книженцию толковую и изучить предмет глубже и ширше. :)
Цитата: Zorkus
Каждое проверямое исключение показывает вполне реальную/вероятную сбойную ситуацию, которая может произойти. И которые программист должен отлавливать (каждую, естественно, отдельно), и обрабатывать адекватно. Как минимум -- логировать.
В принципе, золотые слова. Обычно программист держит в голове, на чем может засыпаться программа, throws помогает статически контролировать повдение программы при возникновении сбоев, тут я согласен, просто он бывает слишком назойливым (а идею с атрибутом Throws я всеже на досуге обдумаю).
Цитата: Zorkus
1) Отсутствие проверяемых исключений!!!
а в google code style ексепшены вообще запрещены... :rolleyes:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions
Цитата: squirL
а в google code style ексепшены вообще запрещены... :rolleyes:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions
Вот и я их не люблю, впрочем, как и RTTI. :)
Зачем показывать C++ Code Style? :)
Подход к работе с исключениями очень разный в этих языках.
Начать хоть с того, что запретить использование их в Java нельзя :)
Компилятору плевать на Google Style :rolleyes:
Подход к работе с исключениями очень разный в этих языках.
Начать хоть с того, что запретить использование их в Java нельзя :)
Компилятору плевать на Google Style :rolleyes:
Цитата: Zorkus
Зачем показывать C++ Code Style? :)
Подход к работе с исключениями очень разный в этих языках.
Начать хоть с того, что запретить использование их в Java нельзя :)
Подход к работе с исключениями очень разный в этих языках.
Начать хоть с того, что запретить использование их в Java нельзя :)
А вот МакКоннел настаивает на их использовании. Кому верить? Собственному опыту :D