[and or xor] vs. [&& || ?]
-
volkard schrieb:
Konrad Rudolph schrieb:
Wieso? 'Not 0 = -1'; 'Not 1 = 0'.
das wundert mich jetzt.
not 1 hätte ich glatt für -2 gehalten.*g* damit habe ich ziemlich gut bewiesen, dass an Deiner Aussage doch etwas dran ist, was?
Nun ja, wie gesagt, man muss darauf achten, dass man solche Sachen nach Boolean konvertiert, wie es sich gehört. Dann kann nichts passieren.
-
Konrad Rudolph schrieb:
Diese Aussage disqualifiziert Dich einfach
Toll, jetzt bin ich schon disqualifiziert. Dachte eigentlich, dass sich dazu noch am ehesten ein Mod genötigt sieht. Darf ich trotzdem weiter diskutieren? Bitte, bitte, bitte, bitte, bitte, bitte...
Konrad Rudolph schrieb:
da sie unbegründet und falsch ist.
Unbegründet vielleicht, falsch aber noch lange nicht. Und ich will jetzt auch keinen Flamewar herbeirufen, dafür ist es einfach zu sehr OT. Letztendlich kann ich nur aus persönlichen Erfahrungen sprechen (was VB.NET nicht einschliesst). Und da zieht VB als Sprache gegenüber C/C++ einfach den Kürzeren. Was mich zudem mal interessieren würde, ist, wieviel Marktanteil professionelle VB Anwendungen haben. Vielleicht kannst du mir das ja verraten?
volkard schrieb:
not 1 hätte ich glatt für -2 gehalten
ich übrigens auch
-
groovemaster schrieb:
Nur hab ich in diesem Zusammenhang noch nie über die alternativen Formen von Operatoren nachgedacht...Und da ich jetzt sehe, dass es tatsächlich Leute gibt die sowas machen, kann ich immer noch keinen Gewinn diesbezüglich feststellen....würde ich mir übrigens keine Gedanken machen...
ich erkenne ein muster.
ich mach mir sogar gedanken, warum uhren für linkshänder (also solche, die am rechten handgelenk getragen werden und damit man beim aufziehen keinen knoten in den fingern kriegt, die krone links haben) nicht andersrum laufen.
-
groovemaster schrieb:
Konrad Rudolph schrieb:
da sie unbegründet und falsch ist.
Unbegründet vielleicht, falsch aber noch lange nicht. Und ich will jetzt auch keinen Flamewar herbeirufen, dafür ist es einfach zu sehr OT.
Einen Flamewar möchte ich auch nicht, aber ich hatte ja bereits vorgeschlagen, das Thread zu teilen (das geht doch in diesem Forum, oder?), denn ich finde die Diskussion wichtig.
Was mich zudem mal interessieren würde, ist, wieviel Marktanteil professionelle VB Anwendungen haben. Vielleicht kannst du mir das ja verraten?
Nein, kann ich nicht, denn es gibt keine zwei Statistiken, die sich darüber einig sind. Ich weiß nur, dass wohl über sechs Millionen Menschen VB (Classic) kommerziell einsetzen. Es gibt Statistiken, die besagen, dass VB die meistgenutzte Sprache ist. Das muss allerdings nicht viel heißen, da es Statistiken gibt, die behaupten, C/C++ sei es, dann wieder ist es Java und manchmal etwas ganz anderes, z.B. Cobol.
-
Konrad Rudolph schrieb:
Einen Flamewar möchte ich auch nicht, aber ich hatte ja bereits vorgeschlagen, das Thread zu teilen (das geht doch in diesem Forum, oder?), denn ich finde die Diskussion wichtig.
mein fanclub liest mit, solange ich dabei bin. keine bange.
-
Konrad Rudolph schrieb:
Was mich zudem mal interessieren würde, ist, wieviel Marktanteil professionelle VB Anwendungen haben. Vielleicht kannst du mir das ja verraten?
Nein, kann ich nicht
VB wurde dafür entwickelt, es dem Programmierer zu gestatten schnell kleine Clients (am besten mit Access als DB Backend) zu erstellen.
MS hat erkannt, dass diese Sprache überholt ist und sie durch VB.NET ersetzt um eben das Niveau der Sprache zu heben.
Muss man mehr sagen? Der Entwickler der Sprache hat die Mängel eingesehen und die Konsequenzen gezogen... Mehr muss man wirklich nicht sagen
-
VB wurde dafür entwickelt, es dem Programmierer zu gestatten schnell kleine Clients (am besten mit Access als DB Backend) zu erstellen.
Das wage ich zu bezweifeln. Ich habe nie etwas dementsprechendes von Microsoft gelesen. Sicherlich ist VB mit Hinsicht auf DB-Frontend-Programmierung entwickelt worden. Aber das ist sicherlich nicht der einzige Zweck. Übrigens verwendet Microsoft Visual Basic oft selbst für kommerzielle Anwendungen. Die Software "Windows AntiSpyware" (aktuell noch in der Betaphase) von Microsoft ist in VB6 geschrieben -- und das, obwohl VBC doch eigentlich "obsolet" ist ...
Shade Of Mine schrieb:
Muss man mehr sagen? Der Entwickler der Sprache hat die Mängel eingesehen und die Konsequenzen gezogen... Mehr muss man wirklich nicht sagen
Sag bloß, es wird kein Sprachupdate von C++ mehr geben. Uh, warte, es *gab* eines, als .NET herauskam. Von Microsoft, sicher. Nicht-Standard, sicher. Aber es gab ein Update. Und ich dachte eigentlich, dass auch am C++-Standard nach wie vor herumgewerkelt wird.
Du könntest ja mal deutlicher formulieren, *was* genau Du sagen wolltest. Dass VB Mängel hat? Na ja, old news.
-
Konrad Rudolph schrieb:
Das wage ich zu bezweifeln. Ich habe nie etwas dementsprechendes von Microsoft gelesen. Sicherlich ist VB mit Hinsicht auf DB-Frontend-Programmierung entwickelt worden. Aber das ist sicherlich nicht der einzige Zweck. Übrigens verwendet Microsoft Visual Basic oft selbst für kommerzielle Anwendungen. Die Software "Windows AntiSpyware" (aktuell noch in der Betaphase) von Microsoft ist in VB6 geschrieben -- und das, obwohl VBC doch eigentlich "obsolet" ist ...
Und? VB6 wird vermutlich nicht weiter entwickelt, und wenn doch, dann nur dank der Community die das ja von MS fordert.
Schau dir mal ein großes VB6 Projekt an - die Wartbarkeit geht gegen 0. Keine Trennung von Code und GUI - alles direkt in die Formulare.
Die Funktionen könnten in Modulen liegen, tun sie aber selten, was zu lustigen Code verdoppelungen führt.
Ich kann nur sagen, lustig ist das nicht. Klar, mag sein dass ich nur mit schlechten VB Projekten konfrontiert wurde, aber in der Tat habe ich nie ein schönes VB Projekt gesehen. Das lässt mich vermuten, dass VB ungeeignet für große, komplexe Programme ist.
Sag bloß, es wird kein Sprachupdate von C++ mehr geben.
Irrelevant. Du verwechselst nämlich etwas: offene Standards mit proprietären Sprachen.
Wenn irgendwann mal sich niemand für einen neuen C++ Standard interessieren würde, gäbe es immer noch Compiler die weiter entwickelt würden und somit wäre die Sprache C++ immer noch in modernen Umgebungen verwendbar. Ich bezweifle zB dass VB6 je die Avalon Features nutzen können wird. Was effektiv heisst: neue Software in VB ist nicht sinnvoll möglich.
Uh, warte, es *gab* eines, als .NET herauskam.
Nein.
Von Microsoft, sicher. Nicht-Standard, sicher.
Managed C++ / C++/CLI != C++
Und ich dachte eigentlich, dass auch am C++-Standard nach wie vor herumgewerkelt wird.
Klar.
Aber was hat das mit dem Thema zu tun?Du könntest ja mal deutlicher formulieren, *was* genau Du sagen wolltest. Dass VB Mängel hat? Na ja, old news.
VB6 wird wahrscheinlich eingestellt.
Aber wesentlicher: MS hat erkannt, dass VB so wie es war, nicht mehr tragbar war (es wurde zB eigens für VB WinCGI entwickelt, weil VB nicht einmal die CGI Anforderungen erfüllen konnte). Große Projekte in VB sind nur mir großer Disziplin möglich, weil der Code sonst unwartbar wird.VB hat die stärken bei kleinen Anwendungen, zB mit einer Access DB im Hintergrund, ein kleines Tool, ein frontend für ein bestehendes Programm, Rapid Prototyping, etc. aber sicher keine komplexen Anwendungen
Schau dir zB mal das Deployment von großen VB Anwendungen an. Die Hölle. Es gibt sehr oft probleme wegen fehlender DLLs, etc. Das macht echt keinen Spass...
Keine Ahnung wie komplex dieses AntiSpy ist - ich tippe aber darauf, dass VB nur als frontend verwendet wird...
-
volkard schrieb:
mein fanclub liest mit, solange ich dabei bin. keine bange.
[quote="volkard"]
Stimmt...Microsoft war noch nie gut bei Standarts. VB hat genau gleich viele Fehler
und Loecher wie Windows. Und bitte, ich habe nicht lust mein VB-Compiler
alles 3 Tage zu Updaten wegen Sicherheits Maengeln und Fehlern.Mit VB wollten sie wieder eine neuen Standart machen, und alles von
neu an geschrieben.Unterschied zwischen VB und C++ ist <= 99 %
das eine 1% die sie gleich haben, ist, das es auf Windows lauft.Wenn ihr mich fragt (das macht auch keiner) Fuck Microsoft.
Die sollen mal lernen das man das rechnen nicht neu erfinden muss,
bevor sie etwas Progen, und das nicht mal richtig.MFG Ghost
-
Shade Of Mine schrieb:
Und? VB6 wird vermutlich nicht weiter entwickelt, und wenn doch, dann nur dank der Community die das ja von MS fordert.
VB.NET *ist* eine Weiterentwicklung von VB6.
Schau dir mal ein großes VB6 Projekt an - die Wartbarkeit geht gegen 0. Keine Trennung von Code und GUI - alles direkt in die Formulare.
Falsch, alles falsch. Wenn Du nur solche Projekte gesehen hast, dann sind die eben alle schlecht gewesen. Ich habe schon große Projekte in VB6 geschrieben und habe damit absolut keine Probleme.
Klar, wenn aller Code in einem Modul (bzw. einem Formular) rumhängt, dann ist das ganze sehr schnell unübersichtlich. Aber in großen Projekten macht man sowas auch nicht. In VB6 kann man genauso wie in C++ GUI vom Rest trennen.Klar, mag sein dass ich nur mit schlechten VB Projekten konfrontiert wurde, aber in der Tat habe ich nie ein schönes VB Projekt gesehen. Das lässt mich vermuten, dass VB ungeeignet für große, komplexe Programme ist.
Nun, so ein Pars pro toto ist einfach nicht gültig. Nur weil Du schlechte Erfahrungen gemacht hast kannst Du nicht expandieren und sagen, "VB ist immer schlecht".
Wenn irgendwann mal sich niemand für einen neuen C++ Standard interessieren würde, gäbe es immer noch Compiler die weiter entwickelt würden und somit wäre die Sprache C++ immer noch in modernen Umgebungen verwendbar. Ich bezweifle zB dass VB6 je die Avalon Features nutzen können wird. Was effektiv heisst: neue Software in VB ist nicht sinnvoll möglich.
ACK. Genau dagegen richtet sich ja die Petition einiger MS-MVPs. Hier hat Microsoft leider echt Mist gebaut.
VB6 wird wahrscheinlich eingestellt.
Höchstwahrscheinlich wird es das.
Aber wesentlicher: MS hat erkannt, dass VB so wie es war, nicht mehr tragbar war (es wurde zB eigens für VB WinCGI entwickelt, weil VB nicht einmal die CGI Anforderungen erfüllen konnte).
Das ist falsch. Ich /habe/ schon CGI-Anwendungen in VB entwickelt -- ohne MS' komische CGI-Bibliothek. Es herrscht anscheinend der weiterbreitete Irrglaube, dass man in VB keine Konsolenanwendungen schreiben könnte und dass diverse andere Dinge nicht gingen, die in Wahrheit problemlos machbar sind. Das einzige Problem ist hierbei, dass das alles "undokumentierte" Sachen sind, die in der VB-IDE nicht direkt unterstützt werden und nur in der MS-KB oder auf Fachseiten zu finden sind.
Große Projekte in VB sind nur mir großer Disziplin möglich, weil der Code sonst unwartbar wird.
Ich finde, dass große Disziplin für große Projekte generell nötig ist. Ich finde VB für große Projekte durchaus geeignet aber ich denke ebenfalls, dass VB für kleine Projekte optimal ist. Und ich sehe nicht, wieso das ein Nachteil sein sollte. Bei einem Großteil aller programmierten Anwendungen handelt es sich wahrscheinlich um kleine bis mittelgroße Anwendungen und hierfür eignet sich VB einfach sehr gut.
Schau dir zB mal das Deployment von großen VB Anwendungen an. Die Hölle. Es gibt sehr oft probleme wegen fehlender DLLs, etc. Das macht echt keinen Spass...
Fehlende DLLs? Das ist ein durchschnittlich 60cm vom Bildschirm entferntes Problem, kein Problem von VB. Vom beigelegten Weitergabeassistent von VB sollte man freilich nicht allzu viel erwarten aber es gibt ja professionelle kostenlose Abhilfe, z.B. das Visual Studio Setup Tool von Microsoft.
Keine Ahnung wie komplex dieses AntiSpy ist - ich tippe aber darauf, dass VB nur als frontend verwendet wird...
Natürlich. Wenn ich Dir bei einer Sache zustimme, dann der, dass VB für Frontends, weniger aber für Backends geeignet ist. Diese schreibe ich dann ja auch für große Projekte meist in C++.
-
Green_Ghost schrieb:
Microsoft war noch nie gut bei Standarts. VB hat genau gleich viele Fehler
und Loecher wie Windows. Und bitte, ich habe nicht lust mein VB-Compiler
alles 3 Tage zu Updaten wegen Sicherheits Maengeln und Fehlern.Ich habe meinen VB-Compiler noch nie updaten müssen. Die Runtime hat ein einziges Update rübergebügelt bekommen, das Service Pack 5.
Wenn ihr mich fragt (das macht auch keiner) Fuck Microsoft.
Die sollen mal lernen das man das rechnen nicht neu erfinden muss,
bevor sie etwas Progen, und das nicht mal richtig.Mannomann, das Niveau des Threads steigt ja ins Unermessliche ...
-
Konrad Rudolph schrieb:
Mannomann, das Niveau des Threads steigt ja ins Unermessliche ...
Nein. Das passiert wenn Unix auf Windows Trift.
Jedes SP von Microsoft Updatet die DLLs und Sourcen.
Darum muss man ja uch unter Winprogs schauen, welche SP man hat,
und welche updates da noch draus sind.Aber Microsoft muss sich wircklich noch etwas ins zeugs legen.
Wuerde ich etwas auf Windows progen, haette ich ein Herzanschlag,
von den ewigen Loechern, Bugs und ausnahme fehlern.
Welche gruende gibt es auf Windows zu arbeiten. Was kann es besser?
Nichts nichts nichts nichtsMFG Ghost
-
Konrad Rudolph schrieb:
VB.NET *ist* eine Weiterentwicklung von VB6.
Marketingtechnisch: Ja
Praktisch: Neindu kannst VB6 code aber nicht vernünftig nach .NET übernehmen. Es gibt zwar Tools, die klappen aber nicht immer.
Eine Weiterentwicklung die 90% inkompatibel ist, praktisch keine Weiterentwicklung sondern etwas neues.
Warum schreit die Community denn sonst?
Falsch, alles falsch. Wenn Du nur solche Projekte gesehen hast, dann sind die eben alle schlecht gewesen. Ich habe schon große Projekte in VB6 geschrieben und habe damit absolut keine Probleme.
Oh, deshalb ist alles falsch. Verstehe.
Es ist immer möglich gute Programme zu schreiben, aber VB macht es einem recht schwer. Und in der Praxis sind die meisten Programme deshalb mies.
Klar, wenn aller Code in einem Modul (bzw. einem Formular) rumhängt, dann ist das ganze sehr schnell unübersichtlich. Aber in großen Projekten macht man sowas auch nicht. In VB6 kann man genauso wie in C++ GUI vom Rest trennen.
Nein. Nicht genauso. Weil dir zb die Komponenten der OOP fehlen.
Klar geht es dennoch, aber es ist aufwand, den man zB in Java nicht hat.Nun, so ein Pars pro toto ist einfach nicht gültig. Nur weil Du schlechte Erfahrungen gemacht hast kannst Du nicht expandieren und sagen, "VB ist immer schlecht".
Das habe ich auch nicht gesagt.
VB6 wird wahrscheinlich eingestellt.
Höchstwahrscheinlich wird es das.
Somit sind VB6 Programme leider zum wegwerfen, denn ob man das nach .NET portiert oder neuschreibt ist auch schon egal
Das ist falsch. Ich /habe/ schon CGI-Anwendungen in VB entwickelt -- ohne MS' komische CGI-Bibliothek. Es herrscht anscheinend der weiterbreitete Irrglaube, dass man in VB keine Konsolenanwendungen schreiben könnte und dass diverse andere Dinge nicht gingen, die in Wahrheit problemlos machbar sind. Das einzige Problem ist hierbei, dass das alles "undokumentierte" Sachen sind, die in der VB-IDE nicht direkt unterstützt werden und nur in der MS-KB oder auf Fachseiten zu finden sind.
Wozu wurde dann WinCGI entwickelt?
Aber ok: die undokumentierten Features von VB kenne ich natürlich nicht. Aber wenn sie undokumentiert sind, würde ich mich sowieso hüten sie in einem wichtigen programm zu verwenden, weil man sonst vielleicht inkompatibel zur nächsten VB version ist (was bei VB sowieso ein Problem ist -> VB4, VB5, VB6 -> jedesmal musst man die anwendung anpassen. Das ist eigentlich auf dauer nicht tragbar).
Ich finde, dass große Disziplin für große Projekte generell nötig ist.
Gut, aber nicht nötig.
Bei GUI Libraries mit einem Slot/Listener Prinzip ist es einfacher den Code von dem GUI Code zu trennen. Wenn MVC und Doc/View schön unterstützt wird, ist es ziemlich simpel. In VB ist das alles nicht der Fall. Das erschwert die Arbeit.Fehlende DLLs? Das ist ein durchschnittlich 60cm vom Bildschirm entferntes Problem, kein Problem von VB. Vom beigelegten Weitergabeassistent von VB sollte man freilich nicht allzu viel erwarten aber es gibt ja professionelle kostenlose Abhilfe, z.B. das Visual Studio Setup Tool von Microsoft.
Ich hatte damit öfters Probleme.
Natürlich. Wenn ich Dir bei einer Sache zustimme, dann der, dass VB für Frontends, weniger aber für Backends geeignet ist. Diese schreibe ich dann ja auch für große Projekte meist in C++.
Genau. Das meine ich. VB ist hierfür nicht geeignet, da nimmt man lieber ein C++ backend.
Ich würde zB nie ein komplexes VB backend schreiben - als frontend finde ich VB mittlerweile veraltet, aber vor ein paar Jahren hätte ich durchaus VB als frontend für so ziemlich jedes C++ Programm in erwägung gezogen.
Nur würde ich nie VB als backend in erwägung ziehen, mittlerweile würde ich es sogar _nie_ in erwägung ziehen, weil man dank Java und .NET bessere alternativen hat.
-
Konrad Rudolph schrieb:
Falsch, alles falsch. Wenn Du nur solche Projekte gesehen hast, dann sind die eben alle schlecht gewesen. Ich habe schon große Projekte in VB6 geschrieben und habe damit absolut keine Probleme.
ich war bei einem maßgeblich dabei, das so um 500 funktionen hatte. und es hätten ruhig endlos viel mehr werden können. das projekt war einfach. ne datenbank dahinter, dialoge davor und dazwischen basic, was die datenverarbeitung machte, daten konvertierte auch zu dateien raus und wiede rein, femdsoftware dazu auch benutzt hat, komplexester algo war wohl, eine transitive hülle zu berechnen. manchmal ist vb total klasse. es soll auch keiner auf die idee kommen, das abzuschaffen oder unmöglich komplex zu machen.
dann hab ich aber auch meinen homepageersteller in vb versucht. war schlicht unmöglich. jetzt lebt die aktuele version in 300 zeilen c++ (mit basic-frontend, sozusagen).
den multithreaded ftp-uploader mit lokalem mirror, der nur geänderte dateien hochschickt und natürlich die abhängigkeiten der jobs berücksichtigt, also nicht foo/bar uploaden, bevor /foo erstellt wurde (gemeinerweise in nem anderen thread), habe ich gar nicht in vb versucht.
warum?
-
Wenn ich die frage schnell hier stellen darf:
priority_queue sortier Ortnung:
wenn int a=10;
und int b=5;
und der wert im priority_queue ist, ist a oder b oben/top?
also wie sind die prioritaeten des priority_queue?
(e>w) == ist true und oben. ist true gleich unten.muss das wissen, weil ich meine classe danach schreiben muss.
THX Ghost
PS: Ich habe nichts gegen windowsklicker, habe nur was gegen den Bill von Microsoft. Also nicht falsch verstehen.
-
Shade Of Mine schrieb:
Es ist immer möglich gute Programme zu schreiben, aber VB macht es einem recht schwer.
Da würde ich sagen, das ist eindeutig eine Frage der Gewöhnung. In C++ (und den diversen Tools bzw. Bibliotheken) muss man sich auch erst einarbeiten. Gleiches gilt natürlich für VB nur ist hier die Einarbeitungszeit wegen der geringeren Komplexität wesentlich kürzer, wenn man eine grundsätzliche Ahnung hat.
Klar, wenn aller Code in einem Modul (bzw. einem Formular) rumhängt, dann ist das ganze sehr schnell unübersichtlich. Aber in großen Projekten macht man sowas auch nicht. In VB6 kann man genauso wie in C++ GUI vom Rest trennen.
Nein. Nicht genauso. Weil dir zb die Komponenten der OOP fehlen.
Das stimmt so nicht. OOP ist in VB durchaus möglich (alle meine Programme sind fast 100% OOP) und VB unterstützt OOP auch in großen Stücken. Mangelnde OOP-Unterstützung ist natürlich aber eine der Tatsachen, die mich zum Umstieg auf VB.NET gebracht haben.
Das ist falsch. Ich /habe/ schon CGI-Anwendungen in VB entwickelt -- ohne MS' komische CGI-Bibliothek. Es herrscht anscheinend der weiterbreitete Irrglaube, dass man in VB keine Konsolenanwendungen schreiben könnte und dass diverse andere Dinge nicht gingen, die in Wahrheit problemlos machbar sind. Das einzige Problem ist hierbei, dass das alles "undokumentierte" Sachen sind, die in der VB-IDE nicht direkt unterstützt werden und nur in der MS-KB oder auf Fachseiten zu finden sind.
Wozu wurde dann WinCGI entwickelt?
Aber ok: die undokumentierten Features von VB kenne ich natürlich nicht. Aber wenn sie undokumentiert sind, würde ich mich sowieso hüten sie in einem wichtigen programm zu verwenden, weil man sonst vielleicht inkompatibel zur nächsten VB version ist (was bei VB sowieso ein Problem ist -> VB4, VB5, VB6 -> jedesmal musst man die anwendung anpassen. Das ist eigentlich auf dauer nicht tragbar).
Also, gerade im Fall Kommandozeilenanwendung/CGI handelt es sich nicht um etwas, das mangelnde Inkompatibilität riskiert. Man bedient sich ja hier der WinAPI für den Konsolenzugriff, somit ist gesichert, dass das Programm läuft, solange MS die WinAPI nicht ändert. Und um das ganze als Konsolenanwendung zu linken, bedarf es eines Linkerparameters, der sogar dokumentiert /ist/, nur nicht in der VB-Doku. MS hat nämlich einfach für VB den VC-Linker verwendet ...
Ich finde, dass große Disziplin für große Projekte generell nötig ist.
Gut, aber nicht nötig.
Bei GUI Libraries mit einem Slot/Listener Prinzip ist es einfacher den Code von dem GUI Code zu trennen. Wenn MVC und Doc/View schön unterstützt wird, ist es ziemlich simpel. In VB ist das alles nicht der Fall. Das erschwert die Arbeit.Ich behaupte, dass das eine reine Frage der Gewohnheit ist.
Fehlende DLLs? Das ist ein durchschnittlich 60cm vom Bildschirm entferntes Problem, kein Problem von VB. Vom beigelegten Weitergabeassistent von VB sollte man freilich nicht allzu viel erwarten aber es gibt ja professionelle kostenlose Abhilfe, z.B. das Visual Studio Setup Tool von Microsoft.
Ich hatte damit öfters Probleme.
Ich auch. Aber dabei handelte es sich stets um Fehler meinerseits, die ich aus Unwissenheit gemacht hatte. Das "Problem" mit der Auslieferung der nötigen Komponenten hat man aber ja mit jeder Anwendung (in jeder Sprache), die auf externe Komponenten zugreift oder ein Framework verwendet. Das Problem ist nicht VB-eigen.
Ich würde zB nie ein komplexes VB backend schreiben - als frontend finde ich VB mittlerweile veraltet, aber vor ein paar Jahren hätte ich durchaus VB als frontend für so ziemlich jedes C++ Programm in erwägung gezogen.
Nur würde ich nie VB als backend in erwägung ziehen, mittlerweile würde ich es sogar _nie_ in erwägung ziehen, weil man dank Java und .NET bessere alternativen hat.
Nun ja, Java ... aber das ist ein anderes Thema. Ich bin inzwischen ja auch größtenteils auf VB.NET umgestiegen und pflege nur noch zwei Projekte in VBC weiter.
-
volkard schrieb:
den multithreaded ftp-uploader mit lokalem mirror, der nur geänderte dateien hochschickt und natürlich die abhängigkeiten der jobs berücksichtigt, also nicht foo/bar uploaden, bevor /foo erstellt wurde (gemeinerweise in nem anderen thread), habe ich gar nicht in vb versucht.
warum?
Weil Multithreading in VB6 ein #*%& (= pain in the ass) ist.
-
in c++ sortiert man immer das kleinste element an den anfang.
also wird eine priority_queue in c++ auch das kleinste element auswerfen.aber du kannst ja nen umgedrehten anderen vergleicher mitgeben, dann wird die ganze queue andersrum sein und du wirst das größte bekommen. also kein bedarf, dein programm danach auszurichten. wenn es gute gründe für die eine oder anderew richtung gibt, dann beachte sie. gibt es keine gründe oder nur so schwache, wie wir hier für üder wider and finden, dann nimm die version, die das kleinste element ausgibt, denn die ist normal und jeder fremde programmierer erwartet die.
-
Ach du Schreck,
nur einen Tag lang mal hier nicht reingeschaut und dann das! Respekt für die ausführliche Thematisierung von C++ vs. VB, Windows gegen Unix, && gegen and, || gegen or etc. in einem Thread!1. ist das alles größtenteils Geschmacksfrage, so halte ich z.B. von Windows mehr als von Linux, von C++Builder mehr als von MSVC, von Firefox mehr als von Internet Explorer, von C++ mehr als von VB, doch das eigentlich nur, weil ich mit meinen Favoriten mehr Erfahrung habe und daher mit ihnen besser zurechtkomme.
2. glaube ich, daß and/or etc. für Leute eingeführt wurden, die auf ihren Tastaturen nicht so problemlos wie wir an | und & herankommen (siehe Trigraph-Sequenzen), und nicht, weil sie ästhetischer sind.
3. macht Microsoft zwar Fehler, muß deswegen aber nicht gleich verteufelt werden, denn auch Bill ist nur ein Mensch. Stur gegen MS zu stänkern finde ich naiv, denn wer von euch benutzt denn kein Windows? Nur weil es den Markt dominiert? Ich kenne genug Leute, die Windows häßlich, langsam, störend, unsicher und vieles mehr finden, ohne z.B. zu wissen, daß man das alles ändern kann. Ein Linux-Programmierer aus meinem Bekanntenkreis verteufelt Windows gegenüber anderen Menschen aufs Bitterste (ohne dabei Argumente zu nennen), dabei weiß ich mit Sicherheit, daß er auf seinem heimischen PC Windows installiert hat und benutzt. Kurz: Leute, es ist lächerlich. Ich schließe mich daher der letzen c't an und bin für die "Win-Win-Situation" ;)!
Moritz
-
Nachdem Du Dich von Deinem Schreck erholt hast
audacia schrieb:
2. glaube ich, daß and/or etc. für Leute eingeführt wurden, die auf ihren Tastaturen nicht so problemlos wie wir an | und & herankommen (siehe Trigraph-Sequenzen), und nicht, weil sie ästhetischer sind.
Das gilt soweit ich weiß vornehmlich für C. Ich will nicht ausschließen, dass die Motivation bei C++ eine ähnliche war aber ich kann mir durchaus vorstellen, dass da noch andere Motivationen eine Rolle gespielt haben *könnten*.
Zum Rest Deines Postings: 100% ACK.