hier steht einiges dazu - vor allem die sachen die man bei var beachten muss - was geht und was nicht:
http://msdn.microsoft.com/de-de/library/bb384061.aspx
MSDN schrieb:
Die folgenden Beschränkungen gelten für implizit typisierte Variablendeklarationen:
- var kann nur verwendet werden, wenn eine lokale Variable in der gleichen Anweisung deklariert und initialisiert wird. Die Variable kann nicht mit NULL oder einer Methodengruppe bzw. einer anonymen Funktion initialisiert werden.
- var kann nicht für Felder im Klassengültigkeitsbereich verwendet werden.
- Variablen, die mit var deklariert werden, können nicht im Initialisierungsausdruck verwendet werden. Anders ausgedrückt, ist der Ausdruck int i = (i = 20); gültig, während der Ausdruck var i = (i = 20); einen Kompilierungsfehler verursacht.
- Mehrere implizit typisierte Variablen können nicht in der gleichen Anweisung initialisiert werden.
- Wenn sich ein Typ mit der Bezeichnung var im Bereich befindet, wird das var-Schlüsselwort zu diesem Typnamen aufgelöst und nicht als Teil einer implizit typisierten lokalen Variablendeklaration aufgefasst.
generll heisst es:
Der Einsatz von var kompliziert jedoch potenziell Ihren Code, sodass andere Entwickler ihn nur schwer nachvollziehen können. Aus diesem Grund wird in der C#-Dokumentation var im Allgemeinen nur verwendet, wenn es erforderlich ist.
ich schreibe mein code immer das auch andere es super verstehen - und mit einer richtigen IDE braucht man nie wirklich viel tippen
wenn wenn du
var bla = new MeineKlasse();
schreibst, musst du "MeineKlasse()" explizit tippen
wenn du aber
MeineKlasse bla = new MeineKlasse();
machen moechtest brauchst du es auch nur einmal eingeben am anfang, direkt nach dem new kann man es mit enter automatisch einsetzen lassen
die redudanz des tippens ist also kein argument
ich selber finde "var" eher stoerend als sinnvoll - daher verwend ich das auch nie (hab derzeit auch keine linq anweisung am laufen wo ich var verwenden musste)
einige sagen ja auch das es dann einfacher wenn man typen aendert, zb den rueckgabewert von:
var data = GetData("bla");
..
da halte ich aber gegen und sage - wenn man ein typen aendert - sollte man beim refactor vorgang auch diese methode ueberpruefen ob da noch etwas zu tun ist
wenn da zb nur data.Name verwendet wird - und das neue objekt hat zufaellig auch ein Name property - schluckts der compiler, aber zur laufzeit hat man eventuell dann ein problem, da die funktion haette geaendert werden muessen
ich find also das var eher schneller fehler verursachen kann - sei es durch die handhabe oder wie im beispiel
wenn man ein var hat - muss man immer erst irgendwie nachsehen was das fuer ein objekt ist - je nachdem wo es her kommt - var verkompliziert das ganze nur
btw - wird etwas offtopic denk ich #gg
//dazuedit - die ms empfehlung find ich grad nicht - ich habs hier aus nem buch
Hallo
Ich hab im google ähnliche Probleme gefunden - aber keien Lösung. Es befindet sich die PDB File im Debug Ordner. Doch wenn ich meine WPF App aus dem Explorer starte und eine Exception werf, werden mir keine Zeilennummern angezeigt - bzw. im Stack Trace steht auch nicht meine Funktion von der ich geworfen hab. Gefangen wird die Exception mit DispatcherUnhandledException
Muss ich die Exe irgendwie speziell starten?
Danke im Voraus
mfg
Hi,
tawa schrieb:
[...]
Es wäre übel, wenn zwischen Delete und Insert ein Benutzerwechsel stattfinden würde.
Ich gehe stark davon aus, dass es NICHT der Fall ist. Das wäre ein Armutszeugnis für .NET-Webservices. Hätte nur gern Sicherheit
Welcher Webservice weiß denn wie der Zugriff auf Deine Resourcen gesteuert werden soll? Das ist immer ganz Dir überlassen.
C#? Ich kenne die genauen Excel Eigenheiten nicht, aber bist du sicher, dass "hh\:mm\:ss" richtig ist? C# macht daraus "hh:mm:ss" , warum also diese "\"s?
witte schrieb:
Dann zerteile halt Deine Logok in mehrere Assemblys, ist ja nicht so dass Du für jedes extra Assembly 10 Euro zahlen mußt oder so.
LoL, so dass am Ende für jede Assembly zwei Klassen existieren? Für die DLL, wo ich internal benutze, existiert ja sowieso erst ein einziger Namespace. Viel mehr als 10 - 15 Klassen wird es wohl nicht geben und die grössere Menge werden wohl EventArgs Klassen sein, wobei das noch nicht alles in Stein gemeisselt ist
Allerdings merke ich mehr und mehr die Vorteile von C#. Wie gesagt, es ist halt ein Angewöhnungsprozess.
Gerade in dieser DLL werden ständig Dinge mit einem Server abgeglichen. Die meistens Änderungen kann der User nur verzögert machen, also erst die Bestätigung des Server verändert die Daten. So kann ich die entsprechenden Setter Funktionen internal machen, die Getter public und die Events auf die Wesentlichen beschränken. Eigentlich ganz praktisch
Grüssli
Ja klar wäre es gleich besser da hast du Recht. Mein Gedanke war nur, eine Frage, eine Antwort Das er später eventuell eh nochmal auf diese Frage des Parsens zurückkommt war ja logisch.Aber du hast Recht, direkt durchparsen macht gleich alles zusammen.
Andorxor schrieb:
Sehr freundlich einfach auf die Seite zu verlinken und noch nicht mal sagen was genau dein Problem mit meinen Post ist.
Wenn Du liest was im verlinkten Post steht und dann vllt. noch dem Link in diesem Thread folgst solltest Du von selbst erkennen was fehlen könnte.
So, ich habe das Rätsel inzwischen einigermaßen gelöst. Ich benötige für meine Zwecke folgende Konfiguration:
- Iso Level READ COMMITTED
- NO WAIT (nicht auf Änderungen fremder Transaktionen warten)
- Rec Version (Letzte committete Version des Records lesen)
Diese Parameter lassen sich unter ADO.NET jedoch nur beim Starten einer Transaktion setzen. Das heisst, ich bin gezwungen jedes SELECT Statement in einer Transaktion zu kapseln. Das finde ich ziemlich unschön, da diese Transaktion mindestens bestehenbleiben muss, bis ich alle Ergebnis-Records ausgelesen habe. Wenn ich jetzt zwischendurch Änderungen mache, werden diese erst wirksam wenn die Übergeordnete "SELECT-Transaktion" abgeschlossen wurde, oder? Irgendwie ist das doch alles Quark
Hallo..
ja, genau das hab ich gemacht.
dennoch flackert es meist kurz.
Ne Idee woran das liegen könnte?
Ansonsten werde ich heut abends/morgen früh mal ein Beispielprojekt hier reinstellen...
Gruß und Danke
solche "typen" wie int, double usw haben alle die funktion Parse() sowie TryParse() - mit try kannst du erst testen lassen ob es nach dem typen convertiert werden kann
Eigentlich ganz einfach. Solltest du WPF, WF, WCF oder eins der C# 3.0 Features wie automatische Properties, Linq, Lambda Ausdrücke etc. benutzen brauchst du 3.5. Ansonsten tuts auch 2.0.
1. Ja, du bist im falschen Unterforum. Was du als Quellcode präsentierst ist C. C hat nichts zu tun mit C# oder C++ oder C++/CLI (alles eigenständige Sprachen). Hier ist das C Forum:
http://www.c-plusplus.net/forum/viewforum-var-f-is-10.html
2. Solltest du vielleicht anstatt eines Makros nicht eher eine Funktion machen?
#include <stdio.h>
float sgn(float val)
{
// Hier dein Code rein
// und mit return das Resultat zurückgeben.
}
int main(void)
{
float zahl1 , zahl2, zahl3;
zahl1 = -123;
zahl2 = 123;
zahl3 = 0;
printf("%f\n", sgn(zahl1));
printf("%f\n", sgn(zahl2));
printf("%f\n", sgn(zahl3));
return (0);
}
Grüssli
Danke für die Aufklärung. Das habe ich in meinem Buch ganz eindeutig missverstanden. Hatte mich darüber schon ein wenig gewundert gehabt, da man nämlich sonst ein wenig den GC aushebeln würde. Aber jetzt ist alles klar und der GC ist auch nicht ausgehebelt und man hat nur eine sichere zusätzliche Möglichkeit.
Nochmals danke.
Grüssli
