C# vs. VB.NET

[FireFenix]

Код: Выделить всё

Dim form as New Form 'VB.NET
Form form = new Form; //CSharp

Особенно когда:

Код: Выделить всё

MyProject.MyNamespace1.MyNamespace2.MyNamespace3.MyNamespace4.Mynamespace100500.MyClass Variable = New MyProject.MyNamespace1.MyNamespace2.MyNamespace3.MyNamespace4.Mynamespace100500.MyClass;

явно против сишарпа

Единственное важное отличие это то что в VB.NEt незя юзать unsafe для остального языки равны, и каждому какой нравится, тот и юзает язык

[Хакер]

Dim form as New Form 'VB.NET
Form form = new Form; //CSharp

Неужели в дотнете это вещи сделали равносильными? Совсем у них что-ли крыша поехала такие подставы делать?

[FireFenix]

А что в этом не правильно?

[Хакер]

В том что это DAN-ссылка, и она не имеет ничего общего с инициализацией-при-объявлении. По крайней мере кучу лет не имела в VBn и VBA, и сейчас не имеет в VBA, а в VB.NET-е получается это вдруг стало инициализацией при объявлении?

Либо создатели VB.NET кретины, либо вы путаете сами.

[FireFenix]

В том что это DAN-ссылка

Я не очень знаком с терминологией, DAN = Direct Access Name?

Если ты про то что в VB6 инициализация объекта была

Код: Выделить всё

Dim Var as Type
Var = New Object


То в VB.NET сделали в одну строку

Код: Выделить всё

Dim Var as Type = New Object


Но если тип объекта = тип переменной, то можно сократить до

Код: Выделить всё

Dim Var as New Type

По моему - это хорошо

Или я не правильно понял?

[Хакер]

Я не очень знаком с терминологией, DAN = Direct Access Name?

Declared As New.

То в VB.NET сделали в одну строку

Dim foo as XYZ = New XYZ и Dim foo As New XYZ это принципиально разные вещи.

По моему - это хорошо

Или я не правильно понял?

Это суперплохо.
Потому что:
1) В VB6 (VB5 и так далее) и во всех VBA эта конструкция обозначает одно, а в VB.NET вдруг внезапно — совершенно другое.
2) В VB.NET пропала возможность объявлять DAN-ссылки.

Ещё раз контрольный вопрос. Ты точно правильно знаешь, что означает конструкция
Dim refname As New Classname
в во всех классических VB-языках (всех, исключая VB.NET)?

Сразу говорю, что эта конструкция не тождественна конструкции
Dim refname As New Classname: Set refname = New Classname

[FireFenix]

Проверил в VB.NET

Как я и говорил - при As New и As Type = New il-код одинаковый, т.е. напрямую создание объекта

Ещё раз контрольный вопрос. Ты точно правильно знаешь, что означает конструкция
Dim refname As New Classname
в во всех классических VB-языках (всех, исключая VB.NET)?

Конечно нет, и в VB.NET я до конца всего не знаю

Сразу говорю, что эта конструкция не тождественна конструкции
Dim refname As New Classname: Set refname = New Classname

Знаю что там хитрый механизм и в какой-то теме про формы ты рассказывал...
Если мне не изменяет память, то DAN в VB6 позволяет создавать объект не явно, т.е. объект будет создан при первом к нему обращении без всяких Set

Если это так, то я не вижу преимуществ перед созданием объекта сразу, разве что в правильном использовании на основе этих различий

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

[Qwertiy]

; - рудимент, конечно

Неа. Попробуй-ка распарси: int a = 0, b = 0, c = a ++ b > 3 ? f(a) : g(b).

Удобнее когда одна команда на одну строку.

Весьма спорное утверждение

Не спорное. Почти всегда так удобнее. В Си++ ставлю иногда несколько операторов через запятую, но точку с запятой внутри строки - почти никогда.

Особенно когда:

Код: Выделить всё

MyProject.MyNamespace1.MyNamespace2.MyNamespace3.MyNamespace4.Mynamespace100500.MyClass Variable = New MyProject.MyNamespace1.MyNamespace2.MyNamespace3.MyNamespace4.Mynamespace100500.MyClass;

явно против сишарпа

А если так:

Код: Выделить всё

var Variable = New MyProject.MyNamespace1.MyNamespace2.MyNamespace3.MyNamespace4.Mynamespace100500.MyClass;

Хотя, мне так не нравится Кстати, аналог этой конструкции в VB.NET - просто не указывать тип, если в совйствах пректа включить какую-то опцию (никогда так не делал - по-моему, вообще нечитаемо получися).

По моему - это хорошо

Согласен

Ещё раз контрольный вопрос. Ты точно правильно знаешь, что означает конструкция
Dim refname As New Classname
во всех классических VB-языках (всех, исключая VB.NET)?

Я не знаю, расскажи

Кстати, ещё плюс VB.NET по сравнению с Шарпом - возможность применить Imports для класса.

[Хакер]

Знаю что там хитрый механизм и в какой-то теме про формы ты рассказывал...
Если мне не изменяет память, то DAN в VB6 позволяет создавать объект не явно, т.е. объект будет создан при первом к нему обращении без всяких Set

Если это так, то я не вижу преимуществ перед созданием объекта сразу, разве что в правильном использовании на основе этих различий

Ну вот. Сколько можно. Если объектная переменная в классических VB объявлена As New, то каждое обращение к ней предваряется следующей неявной проверкой:
If ref Is Nothing Then Set ref = New SpecifiedClass

Из этого есть как минимум два следствия:

1. Легален, правилен, и будет отлично работать подобный код:
   

   Код: Выделить всё

   Dim foo As New Joker
...
foo.MakeDirtyJob
Set foo = Nothing
...
foo.MakeDirtyJob ' Тут ошибки не будет, несмотря на то, что foo is nothing
Set foo = Nothing
...
foo.MakeDirtyJob ' И тут
Set foo = Nothing
...
foo.MakeDirtyJob
Set foo = Nothing

   
   Очевидно, что по реалиям VB.NET этот код уже не легален. Если As New теперь обозначает не особый тип ссылки, а просто инициализацию ссылки при объявлении, то после первого Set foo = Nothing будет Null reference exception,потому что после затирки ссылки новым значением она автоматически инициализирована уже не будет, а смысл был именно в этом.
   
   Зачем это вообще может быть нужно? Представьте себе любую ситуацию, где есть некий класс, объект которого в ходе работы приложения может понадобиться в особых случаях, а в рядовых случаях может вообще не понадобиться. Поэтому создавать экземпляр такого класса при запуске программы было бы крайне неразумно (объект в памяти висит, кучу ресурсов насоздавал, а использоваться — так и не используется и не будет).
   Мой пример: класс ErrorLogWindow. Суть класса в следующем — при создании экземпляра такого класса создаётся окошечко, внутри которого какой-нибудь контрол для отображения лога ошибок. Создадим два экземпляра — будет висеть два окошечка, но, очевидно, что нам нужно только одно. Хотя, если у нас один процесс умеет олицетворять несколько как бы отдельно работающих приложений, то нам нужно будет по окошечку на каждое такое «отдельное» приложение. И, очевидно, пока первая ошибка не произошла, создавать такое окно-логгер вообще нет причины.
   
   Для этого мы делаем класс ErrorLogWindows, и объявляем в модуле DAN-ссылку Public ErrorLogger As New ErrorLogWindow. Всё! Теперь в коде, во фрагментах, предусмотренных как обработка ошибок, мы можем просто писать
   ErrorLogger.PrintError "Не удалось сделать такую-то фигню, потому что тра-ля-ля".
   Подобная строчка в нашем проекте может встречаться 1000 раз, а может быть 15 000 раз, и нам ни разу не придётся заботиться о том, а первый ли это вывод ошибки в лог-окно, или не первый.
   
   Если первый — лог-окно будет автоматически создано и настроено, и в него будет выведено сообщение.
   Если не первый — сообщение будет выведено в уже существующее лог-окно.
   Если не первый, но окно закрыли, то опять же по первому сценарию — лог-окно будет автоматически создано, сообщение выведено.
   
   А если у нас тот случай, когда один процесс отождествляет насколько приложений, то мы DAN-ссылку объявляем не в модуле, а в нашем классе CApplication (предполагается, что у нас что-то подобное есть). А если у нас ActiveX EXE, то или там, или там, потому что у Appartament-model серверов у каждого апартамента (читай — потока) модульные переменные — свои, локальные, потоко-специфичные.
   
   Без этой фичи (без DAN-ссылок), единственный выход в описанном случае (вывод сообщений об ошибок из тысяч мест в коде) чтобы не предварять в каждом (из тысячи) случае полезное обращение к объекту ещё и проверкой ссылки на IsNothing — это обрамить вывод сообщения об ошибки в обычную модульную функцию примерно такого содержания:
   

   Код: Выделить всё

   Public Sub DumpError(...)
     If ErrorLogger Is Nothing Then Set ErrorLogger = New ErrorLogWindow
     ErrorLogger.PrintError ...

   
   Во-первых, это супер-уродливо в свете ООП-подхода, делать обычную плоскую функцию, которая является переходником к методу класса. Во-вторых, если у класса ErrorLogWindow не один жалкий метод PrintError, а куча методов, и из нашего большого проекта обращения к этим (всем!) методам равномерно распределены по коду, то пришлось бы делать на каждый метод класса по такой функции-обёртке-проверялки. Это дрянь.
   
   В общем, если говорить кратко.
   В классических VB (то есть VB[n] и VBA) такая вещь как As New это инструмент для воплощения паттерном проектирования, таких как паттерн On-Demand, он же Lazy Initialization (Ленивая инициализация — «принцип лени» одобряет) и Singleton (Одиночка). Экземпляр создаётся только при обращении и создаётся только один (если его насильно не прибить, но тогда будет создан новый один).
   As New призван сэкономить в сумме 1000 строк с проверкой перед каждым из 1000 обращений к объекту.
   
   В VB.NET, если верить вашем словам, As New — это дешёвый синтаксический сахар без идеологии. Он призван сэкономить десятку буковок, позволяя вместо Dim ref As interface = New Class написать Dim ref As New Class с примерно тем же смыслом.
   
   
2. В случае классических VB мы могли использовать этот подход не только для следования принципу лени, экономии ресурсов и сокращения объёма кода (за счёт исключения из него тысячи проверок). Мы могли в конструктор класса (вернее, в событие Initialize класса) вписать некоторый код, который бы регистрировал последовательность событий, которая может произойти, а может и не произойти за «сессию» и записывал его куда-нибудь в журнал, а деструктор (вернее, событие Uninitialize) бы финализировал запись в журнале. Например в случае упомянутого ErrorLogWindow можно было бы делать в каком-то журнале запись, что во время N-ного запуска программы вдруг неожиданно стали чередой возникать ошибки. А потом, мол, лог ошибок закрыли. А потом, дескать, опять полезла серия. В нормальных случаях, то есть если за сессию (с момента запуска программы, до момента её завершения) никаких ошибок не было, то и к DAN-ссылке обращений не было, а значит экземпляр класса не создавался, обработчики событий Initialize/Uninitialize не вызывались, никакие записи в журнал не делались.
   
   В случае же вбдотнетского As New, где это не более, чем синтаксических сахар, обозначающий инициализацию при объявлении, ненужный (в оптимистичной перспективе) объект «логгер-окно» будет создан сразу же. Конструктор отработает сразу же. Использовать этот момент для записи в журнал чего-то вроде «начали внезапно чередою сыпатья ошибки» уже нельзя. Минимум — делать в классе флаг bFirstError, а в методе PrintError проверять состояние флага, и только при первом вызове метода PrintError писать что-то в журнал. А если, как я упомянул, у класса не один метод PrintError, а достаточно много? В каждом проверять флаг? Фи.

Фух.

[Qwertiy]

Спасибо за рассказ.

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

Код: Выделить всё

Public Module All
  Sub Main()
    Console.WriteLine("Shared constuctor is not called until class is used")
    Console.WriteLine("Press any key to call the method")
    Console.ReadKey()
    Logger.Instance.DoIt()
    Console.WriteLine("Press any key to exit")
    Console.ReadKey()
  End Sub
End Module

И 3 варианта реализации синглтона:

Код: Выделить всё

Public Class Logger
  Private Shared MyInstance As Logger = Nothing

  Public Shared ReadOnly Property Instance As Logger
    Get
      Return MyInstance
    End Get
  End Property

  Shared Sub New()
    Console.WriteLine("Inside Shared Sub New")
    MyInstance = New Logger()
  End Sub

  Private Sub New()
    Console.WriteLine("Instance created")
  End Sub

  Public Sub DoIt()
    Console.WriteLine("DoIt is called")
  End Sub
End Class

Код: Выделить всё

Public Class Logger
  Private Shared MyInstance As Logger = New Logger

  Public Shared ReadOnly Property Instance As Logger
    Get
      Return MyInstance
    End Get
  End Property

  Private Sub New()
    Console.WriteLine("Instance created")
  End Sub

  Public Sub DoIt()
    Console.WriteLine("DoIt is called")
  End Sub
End Class

Код: Выделить всё

Public Class Logger
  Private Shared MyInstance As Logger

  Public Shared Property Instance As Logger
    Get
      If MyInstance Is Nothing Then MyInstance = New Logger()
      Return MyInstance
    End Get
    Set(ByVal value As Logger)
      MyInstance = value
    End Set
  End Property

  Private Sub New()
    Console.WriteLine("Instance created")
  End Sub

  Public Sub DoIt()
    Console.WriteLine("DoIt is called")
  End Sub
End Class

Output (первого варианта):

Код: Выделить всё

Shared constuctor is not called until class is used
Press any key to call the method
Inside Shared Sub New
Instance created
DoIt is called
Press any key to exit


Чем не годится?

[FireFenix]

В классических VB (то есть VB[n] и VBA) такая вещь как As New это инструмент для воплощения паттерном проектирования, таких как паттерн On-Demand, он же Lazy Initialization (Ленивая инициализация — «принцип лени» одобряет) и Singleton (Одиночка). Экземпляр создаётся только при обращении и создаётся только один (если его насильно не прибить, но тогда будет создан новый один).
As New призван сэкономить в сумме 1000 строк с проверкой перед каждым из 1000 обращений к объекту.

В VB.NET, если верить вашем словам, As New — это дешёвый синтаксический сахар без идеологии. Он призван сэкономить десятку буковок, позволяя вместо Dim ref As interface = New Class написать Dim ref As New Class с примерно тем же смыслом.

Спасибо за детальное пояснение.

Но зачастую используется конструктор с параметрами, а так же никто не запрещает юзать Shared классы, т.е. применение DAN узконаправленное, без которого зачастую можно обойтись благодаря иной архитектуре проекта. И профит от использования узконаправленных фитчей в размере кода очень сомнителен, по моему чаще приходиться создавать одиночные объекты, тем самым DAN из VB.NET даёт большую компенсацию по строкам

[Qwertiy]

Да всё проще можно:

Код: Выделить всё

Public Class Keeper(Of Smth As New)

Private MyInstance As Smth

Public Property Instance As Smth
  Get
    If MyInstance Is Nothing Then MyInstance = New Smth()
    Return MyInstance
  End Get
  Set(ByVal Value As Smth)
    MyInstance = Value
  End Set
End Property

End Class

плюс, можно сюда защиту для многопоточности присобачить.

Теперь объявляем

Код: Выделить всё

Dim Obj As New Keeper(Of Logger)()

и наслаждаемся результатом

Кстати, а как насчёт потокобезопасности DAN-ссылок в VB6?

[Qwertiy]

Хакер, ну ведь интересно же:

Кстати, а как насчёт потокобезопасности DAN-ссылок в VB6?

[Хакер]

Не хотел писать, но напишу: как об стену горох. С дотнетчиками бесполезно говорить. Авторы языка сделали непоправимую глупость. Глупость, которая за гранью допустимого. И когда объясняешь, почему это плохо, дотнетичики с позитивом на лице объяснят тебе в ответ, почему это хорошо и как утраченную фичу реализовать по-другому.

Кстати, а как насчёт потокобезопасности DAN-ссылок в VB6?

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

[Qwertiy]

И когда объясняешь, почему это плохо, дотнетичики с позитивом на лице объяснят тебе в ответ, почему это хорошо и как утраченную фичу реализовать по-другому.

Ну и чем тебе не нравится последний вариант, кроме того, что надо при обращении писать .Instance? Работает ведь абсолютно так же.
И вообще, нет ничего 100%-плохого, как и ничего 100%-хорошего

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

Для того, чтобы обращение к переменной было потокобезопасно, требуется запретить доступ к ней из других потоков на время выполнения операции, что достаточно накладно. С какой целью это реализовано для любых переменных в VB6? Что-то не приходит в голову ни один язык, где это было бы так. Когда я спрашивал, то считал, что DAN-ссылки как раз могут (в отличие от переменных) быть потокобезопасными...

[Хакер]

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

У каждого потока своя копия переменной.

[Хакер]

Ну и чем тебе не нравится последний вариант, кроме того, что надо при обращении писать .Instance?

В первую очередь тем, что одна конструкция 10 лет обозначало одно, и вдруг стало обозначать совершенно другое. Причём было фичей с идеологией, а стало синтаксическим сахаром. Да кого вообще волнует, каким другим кодом реализуется паттерн on-demand-object-creation. Речь совершенно не об этом.

[Qwertiy]

У каждого потока своя копия переменной.

А как же взаимодействие между потоками?

[1Steps]

...Зачем это вообще может быть нужно? Представьте себе любую ситуацию, где есть некий класс, объект которого в ходе работы приложения может понадобиться в особых случаях, а в рядовых случаях может вообще не понадобиться. Поэтому создавать экземпляр такого класса при запуске программы было бы крайне неразумно (объект в памяти висит, кучу ресурсов насоздавал, а использоваться — так и не используется и не будет). ...

Shared тебе не о чем не говорит? Ты поймешь на сколько это удобно, когда начнешь писать на .Net.
Да и вообще, почему бы тебе не написать мелкомягким о всем о том, что они не правильно делают?

[Хакер]

Shared тебе не о чем не говорит?

В контексте данной беседы — вообще ни о чём.

Ещё раз повторяю: это как об стену горох.

Вот в автомобилях с РКПП есть три педали, и они всегда идут в одноу последовательности: Слева — сцепление, в середине — тормоз, справа — газ. Даже в праворульных машинах, где весь салон отзеркален, положение педалей остаётся прежним: газ в праворульных машинах по прежнему остаётся справа.

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

Так вот, в таком случае, меня даже близко не волнует, что кто-то мне будет говорить «Ты поймешь на сколько это удобно, когда начнешь ездить на этой модели». Хотя я лично считаю это неудобным, я могу на время заставить себя принять идею, что это офигенно удобно.

Каким бы ни был ответ на вопрос «удобно ли это», это меня вообще ни на секунду не волнует. Потому что самая первичная идея — да ни в коем случае нельзя делать такие вещи (переставлять педали местами и менять их роль кардинально).

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

Вот если мы имеем программу, запускаемую из командной строки, у которой есть определённые ключи, то самое худшее, что могут сделать разработчики, это в какой-нибудь версии 6.33.9578 поменять роль нескольких ключей. Например есть программа rm, и у неё есть в частности знаменитая пара ключей -r и -f. По-моему совершенно очевидно, что ни при каких соблазнах нельзя взять, и поменять смысл этих ключей. Хоть миллион вам предлагают, хоть что. Просто недопустимо сделать так, чтобы с определённой версии команда rm -rf вдруг стала делать совершенно другое. И нет никаких компромиссных решений: хоть завалите листовками весь мир с информацией о том, что смысл ключей изменён. Хоть хелп этим забейте. Есть тысячи людей, которые машинально и не задумываясь вбивают rm -rf, и есть тысячи скриптов, в которых забито использование команды именно в таком виде.

Можно создать совершенно другую утилиту с другим именем и там, пожалуйста, менять смысл ключей. Но эксплуатировать имя оригинальной утилиты и одновременно с этим делать всем пользователем мегадосадную ловушку — нет уж, извините.

Аналогично с языками программирования:

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

Мне даже не ловко это писать, по-моему это в сто крат очевидней, чем 2 + 2 = 4. Не может быть никаких оправданий ловушкам, создаваемым разработчиками продукта для пользователей продукта.

Да и вообще, почему бы тебе не написать мелкомягким о всем о том, что они не правильно делают?

Во-первых, какой смысл? С каких это пор мнение неизвестно-кого стало иметь для MS значение, отличное от нуля.
Во-вторых, кому писать? На деревню дедушке?
В третьих, я находил баги в XP и Win 7 и вот о них следовало бы действительно написать багрепорты в MS. Я собирался это сделать, но всё никак нет времени даже на это.

[Mikle]

Аналогия работы "As New" в Visual Basic (и только) с порядком педалей на автомобилях вообще понятна, но сильно преувеличена. И есть, кстати, автобус, выпускавшийся примерно в 60-х годах в одной из стран советской прибалтики, где педали таки были перепутаны.

[Хакер]

Аналогия работы "As New" в Visual Basic (и только) с порядком педалей на автомобилях вообще понятна, но сильно преувеличена.

Я бы сказал, преуменьшена. Если с педалями подвох понятен сразу, то в случае с «As New» некоторые могут даже не заметить подвоха.

[Maitris]

C# построже и лучше оплачивается, плюс большинство open-source, да и просто профессиональных проектов идет на нем:) А VB.NET - отличный переходной этап.

[Qwertiy]

http://msdn.microsoft.com/en-us/library/vstudio/ms771662(v=vs.90).aspx
Радует строчка

Код: Выделить всё

using Microsoft.VisualBasic.ApplicationServices;

в app.cs
ну и последующий комментарий

Код: Выделить всё

    // Using VB bits to detect single instances and process accordingly:
    //  * OnStartup is fired when the first instance loads
    //  * OnStartupNextInstance is fired when the application is re-run again
    //    NOTE: it is redirected to this instance thanks to IsSingleInstance
    public class SingleInstanceManager : WindowsFormsApplicationBase