защо MS Visual Basic е по-добър от MS Visual C++

примерно средствата за трасиране на кода в VB са по-начетени от тези в VC++. естествено едни по-развити средства са голям плюс за всяка развой на среда , а те са:

1. във VB е напълно възможно код който работи по принцип да отказва да работи когато го дебъгваш.
2. във VB т. 1 я има и във обратния вариант
3. нормално е когато следиш някоя променлива тя да си променя стойноста по закона на случайноста. естествено това поведение е много ценно...
4. възможно да задкулисно да се изпълнява код който няма как да знаеш , че се изпълнява и там да стават бози/лимонади...които да се изразяват в ненадейна промяна на стойноста на дадена следена променлива.
5. най-добре изобщо да не се следи за стойности на променливи понеже , нали така може да се променят.
6. всички тези преимущества правят VB отлична среда за разработка:)) така , че VC вече губи почва под краката си:))

Като завършиш 3-ти клас, пак ше си говорим.

mnogo si zle, ama iavno ne go znaesh, po-dobre si mulchi!

Абе и аз бих пуснал ленгуидж флейм тема (не за ВБ де), ама имаше предложение преди време за 5 лева глоба и бой със стар вестник и ме е шубе :))

бавци

понеже ми е писнало от умници които надраскват по едно-две изречения и хвърлят обиди...

кода на класа Error

Option Explicit
Private m_isError As Boolean
Private m_isZero As Boolean
Private m_objVector As Object

Public Property Get isError() As Boolean
isError = m_isError
End Property

Public Property Get isZero() As Boolean
On Error GoTo lerror
Call m_objVector.GetX
isZero = m_isZero
Exit Property
lerror:
m_isError = True
End Property
Private Sub Class_Initialize()
m_isError = False
m_isZero = False
End Sub

кода зад формата

Option Explicit
Private Sub Form_Load()
Dim e As Error

Set e = New Error

If e.isError Then
MsgBox "Error"
Else
MsgBox "!Error"
End If

Set e = Nothing
End Sub

ако се сложи точка на прекъсване на реда Set e = New Error и се наблюдават свойствата e.isError и e.isZero се вижда , че те излизат със стойности True/False съответно. защо това е така? така е понеже VB извиква тези свойства за да може да покаже съответните стойности. естествено това няма как да се засече с точка на прекъсване(всеки може да сложи и да провери(просто изпълнението няма да спре там!)) , вероятно ако се сложи брояч ще се засече точно колко пъти се викат тези свойства. isZero е нарочно разписано по такъв начин , че да рефлектира върху m_isError. сега понеже m_isError е истина проверката във формата сработва и се показва диалогова кутия със съобщение за грешка.

ако престанем да наблюдаваме тези свойства странно защо се изпълнява другия клон в кода и излиза съобщение за липса на грешка!

напълно е възможно тази особенност да се проявява и в случая когато просто се задържи курсора върху ... понеже VB ще действа по същия начин.

този именно проблем се опитах да опиша и се радвам , че ми отворихте очите за това колко са добри програмистите в българия :)

a be ne mu obrushtaite vnimanie , toia e zavurshil PU-to ...

Първо - България се пише с голяма буква, на останалите ти правописни грешки няма да се спирам.
Второ - Вижуал Бъзик код не ми се чете, но си избии от главата че другите, включително и разработчиците на самия VB, както и програмистите на VB, са глупаци като теб. За домашно можеш да помислиш според теб дали изобщо е възможно VB да е толкова бъгав, колкото го описваш, или може би... само може би... проблема е в главата ти???

Айдее.. почнаха да се засягат програмистите на бейсик.
Относно правописните грешки - преди "че" се слага запетайка. Както виждаш и ти ги допускаш (сигурен съм и аз) и е глупаво да правиш забележки за това тук (може би във форум "Правопис"..).

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

в парвиа момент като видях че пише "Тема: Re: по принцип отговора е и за останалите двама ху" веднага се интерпретирах сричката ху като думичката дето почва сас ху и заваршва на й(хуй), обач не , вобще не става дума за тва, пишело хубавци.

ебаси кво се притеснявате толко, тва е една от малкото красоти на езика ни пред англиискиа, там все още се псуват на shit и madafakar, да покажем че и ние сме дали нещо на света

защо не се гордееме сас богатството на езика ни

Ми да ти кажа нещо: понеже си ме знаеш, че съм малко ман и як няма да се шашнеш, ма аз думата 'хуй' не я ползвам. Ето причината:
Ми тва си е руска дума. Ясно е, че като ще се говори за кур хората са склонни да кажат 'пенис', 'член', 'хуй' и секви думи дето не са базовата. Разбирам притеснението им, ма аз на кура си не мога да му кажа хуй. Некак си по малко му звучи :-) Ми то що мислиш има толко много рускини в България :-) Бах, дай да различаваме българската пишка от руската все пак :-) Малииии, по-малко требе да пиеме с тебе :-))))


System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_

В отговор на:

---

примерно средствата за трасиране на кода в VB са по-начетени от тези в VC++. естествено едни по-развити средства са голям плюс за всяка развой на среда , а те са:

1. във VB е напълно възможно код който работи по принцип да отказва да работи когато го дебъгваш.
2. във VB т. 1 я има и във обратния вариант
3. нормално е когато следиш някоя променлива тя да си променя стойноста по закона на случайноста. естествено това поведение е много ценно...
4. възможно да задкулисно да се изпълнява код който няма как да знаеш , че се изпълнява и там да стават бози/лимонади...които да се изразяват в ненадейна промяна на стойноста на дадена следена променлива.
5. най-добре изобщо да не се следи за стойности на променливи понеже , нали така може да се променят.
6. всички тези преимущества правят VB отлична среда за разработка:)) така , че VC вече губи почва под краката си:))

---

Ако това ще те успокои - дебъгерът на Visual C# също не прекъсва в точки на прекъсване в get методи на property-та, когато обновява прозорците със стойностите им.

По принцип писането на get методи на properties, които имат странични ефекти, какъвото е твоят isZero, е изключително лоша програмистка практика. Очевидно дебъгера трябва да извика get метода на дадено property преди да покаже стойността му в прозореца с локалните променливи или watch-а. Ти ако пишеш дебъгер и някой иска да наблюдава стойността на някакво property, но е сложил точка на прекъсване някъде в get метода му, как би процедирал? Ще възобновиш изпълнението на програмата и ще преместиш дебъгването в контекста на get-а? И всеки път, когато програмистът има нещастието да посочи с мишката някъде в кода върху e.isZero докато трасира кода, и ти ще напускаш текущо трасирания код за да прекъснеш в get метода? Мен лично това би ме издразнило.

Така че за т.3-5 ти сам си си виновен, че така си написал метода. А за т.6 - проблемът в C++ (преди да се появи managed C++) е решен елементарно - в C++ просто няма property-та.

"Всички науки са или физика, или колекциониране на пощенски марки." (Е. Ръдърфорд)

Току що проверих: ако сложиш точка на прекъсване в get метод на property и трасираш код от типа object.Property дебъгера на C# скача към точката прекъсване в get метода. Точно както бих очаквал да работи един дебъгер.

"Всички науки са или физика, или колекциониране на пощенски марки." (Е. Ръдърфорд)

Ето го поредния тъпак.

А бе пич ако поразгледаш малко по-подробно из клубовете ще видиш, че има клуб Visual Basic. Там когато някой има проблеми пита как да ги разреши. Но трябва да има поне малко акъл в главата. Тия които страдат от липса на такъв плюят VB без изобщо да са в час.

Кодът, който си постнал тук говори за твоето невежество и липса на елементарен опит в програмирането с VB. Пример. Кръстил си си класа ERROR, при положение, че това е запазена дума във VB. Втори пример - пропъртито isZero. Когато едно пропърти е декларирано с Property Get, то трябва да връща някаква стойност. Твоето (isZero) каква стойност връща когато възникне грешка - False, и то защото от Майкрософт са се сетили, че има тъпаци като тебе, които ще забравят да го сетнат. А бе кво да ти разправям повече. Немам думи. И тоя тръгнал акъл да дава кое става и кое не. Аз ще ти кажа - и VB и VC++ са много добри, обаче попаднали в твоите ръце нищо няма да се получи, освен да излезе лошо има на българските програмисти.

Аз го изпълних твоят код във VB и се оказа, че само съм си загубил времето, защото ти изобщо не си в час. И това което си обяснил не е вярно. Колегата правилно ти каза, не е лошо първо да завършиш 3 клас. При този код който си дал никога, ама никога не се извиква пропъртито isZero. Именно и затова дебъгера не ти спира там. То е логично, ебати. Пропъртито isError се извиква и при този код винаги ама винаги връща False поради простата причина, че isZero никога не се изпълнява. Аз добавих умишлено ред в кода, който да извика isZero и понеже ми липсва m_objVector.GetX възникна грешка и след това isError стана True. Абсолютно адекватно действие от страна на VB.
За твоя информация само ще ти кажа, че тестовете съм ги правил на официално закупен VB с инсталиран SP5

Един съвет от мене:
Следващият път когато имаш някакъв проблем първо иди се прегледай, и когато и това не помогне, питай за помощ в клуб VB, вместо да плюеш по форумите и с неадекватните си обяснения и действия да създаваш лошо име на българските програмисти. Ще съм ти благодарен ако го спазваш, заради колегите около мен, които със своите изключителни възможности и адекватни действия се борят за място под слънцето. Благодаря!

Бии, за да те уважават!

Очевидно не си разбрал, какъв му е "проблема" на bugicha, а той е, че когато си в дебъг режим и искаш от студиото да ти покаже стойността на дадено property, дали като задържиш показалеца на мишката над него, или в watch прозорците, дебъгера все пак трябва да извика get метода зада получи стойността. Неговият get метод обаче има страничен ефект, като модифицира стойността, която връща isError, така че изпълнението на кода му зависи от контекста, в който се изпълнява. И той се шашка, тъй като студиото не прекъсва в точките на прекъсване в get метода му, когато вика неявно въпросния get метод. И бърза да обяви, че това е проблем на Visual Basic, без да се замисли дали пък това не е По-Добрият Вариант (TM) за работа на дебъгера.

"Всички науки са или физика, или колекциониране на пощенски марки." (Е. Ръдърфорд)

Може и да не съм разбрал, но това не му дава право да плюва по езика.
А и освен това, когато едно приложение отиде при клиента, то в повечето случаи отива компилирано и ефекта които той е описал не се наблюдава поради простата причина, че клиентите (с някои изключения) не ползват дебъгери.
Аз знам и други недостатъци на VB-то, например, че може да декларираш масив с начална стойност каквато си поискаш, въпреки че в документацията е написано че масивите започват от 0 или 1. Но не съм тръгнал да се оплаквам и да плюя по форумите, колко бил тъп езика и т.н. Като не му харесва да не го полва.

Бии, за да те уважават!

Можеш ли да обясниш следното. Нека имаме следния модел, написан във VB.NET, при който символи се изпращат един след друг посредством примка (примка наричам, да речем, For-Next loop), като целта е символите да се конкатенират накрая в един общ стринг, в случая GlobalString, и да се представят на екрана чрез ListBox1.Items.Add(GlobalString):

Private newstring As String
Dim GlobalString As String

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
Dim chrs() As String = {"0", "1", "2", "3", "4", "5"}
For ii As Integer = 0 To chrs.Length - 1
Call addchar(Convert.ToByte(Asc(chrs(ii))))
System.Threading.Thread.Sleep(500)
Next
End Sub

Private Sub addchar(ByVal e As Byte)
newstring = Chr(CType(e, Integer))
GlobalString &= newstring
ListBox1.Items.Add(GlobalString)
Me.Refresh()
End Sub


Въпросният модел работи добре и, както се очаква, дава в ListBox1.Items.Add(GlobalString) следното:

0
01
012
0123
01234
012345

Kогато обаче програма написана на VB.NET се обръща към външно устройство, изпращащо същите символи, чрез код в който няма и помен от примка, да речем:

Public Sub OpenPort()
RS232Comms1.CloseComms()
RS232Comms1.OpenComms()
RS232Comms1.WriteBlock(&H12)
End Sub



Public Sub rS232Comms1_DataRxEvent(ByVal sender As System.Object, ByVal e As RS232.RxEventArgs) Handles RS232Comms1.DataRxEvent

Dim buffer() As Byte = e.data
Dim newString As String = System.Text.Encoding.ASCII.GetString(buffer)

RS232Comms1.SetDTR()

GlobalString &= newString
TextBox1.Text = GlobalString

End Sub

символите се получават един след друг, като че ли пращани от примка, а конкатенация не се извършва, въпреки наличието на оператора &=. Ето какво излиза вследствие на ListBox1.Items.Add(GlobalString):

0
1
2
3
4
5

Пич, защо му обръщаш внимание на тоз, той не търси помощ, а се чуди каква глупост да постне във форума, и си мисли, че е много велик. като му видиш сорса ти става ясно колко е в час.

Пробленът е друг. Той плюе езика. Във VB има много бъгове, не го отричам, Обаче тоя ли е правилният начин за да се изтъкнеш. Можеше да го сподели без излишни фоейрверки. Защото това не е кой знае какъв проблем и ако човек си напише добре кода, може да го избегне без проблеми. Но проблемът е, че тук четът всякакви хора от цял свят и после като искаш да вземеш проект извън България, който да правиш на VB и оня (обикновено българин) ти казва: "Е, да де, ама ти знаеш ли в клубовете на дира какво пише за тоя твоя език" И си до тука. Губиш, заради такива саморекламиращи се "специалисти". И не ме е яд, че аз губя, ами ме е яд че от цялата работа печелят индийци, египтяни и т.н. Защото ако тръгна да го правя проекта на VC++ цената рязко се качва, поради това, че повечето неща на VB ги имам готови и ще ги сглобя за кратки срокове. На VC++ всичко трябва да се пише отначало. А така се качва цената, а като се качи цената ставаш неконкурентноспособен.

Аз не му обръщам внимание, тоя изобщо не ме интересува. Просто си защитавам както моя, така и хляба на няколко мои колеги.

Бии, за да те уважават!

В отговор на:

---

Просто си защитавам както моя, така и хляба на няколко мои колеги.

---

Защитаваш си хляба по форумите? Айде де.

--
Екстремно програмиране на български.
[линк]

немога да повярвам , че изобщо се намери:) аз ли грешно обяснявам или що?