Hi,
ich möchte ein Programm schreiben, dass beliebige Zahlen von 0-99 einliest. Soweit sogut. Nun soll das Programm Kombinationen zweier Zahlen finden, sodass deren Summe im Bereich von 30-45 liegt. Zahlen, die schon bei einem Paar verwendet wurden, stehen natürlich nicht mehr zur Verfügung. Das kniffelige ist jedoch, dass das Programm in der Lage sein sollte die Kombinationen von Zahlen zufinden, die die meisten Zahlenpaare im Bereich von 30-45 liegen.
Leider stehe ich grade ziemlich auf dem Schlauch und habe kein Ansatzidee. Kann mir vielleicht einer von euch helfen? Würde das Programm dann auch gerne auf mehrere Threads verteilen, aber das schaff ich dann schon selbst, brauch halt irgendwie nur nen Denkanstoß, wie so ein Algorithmus für die Zahlenpaare aussehen kann.
Vielen vielen Dank schonmal!
LordJaxom schrieb:
Ich finde dieser Beitrag ist für die FAQ interessant. Besonders, da @ ein äußerst schlechter Suchbegriff für Suchmaschinen ist
*Pusch und der Bitte für die FAQ anschliesse*
foreach(DataColumn c in DataTableWith6Cols.Columns)
{
otherDataTable.Columns.Add(c.ColumnName);
}
for(int i = 0; i < DataTableWith6Cols.Rows.Count; i++)
{
foreach(DataColumn c in DataTableWith6Cols.Columns)
{
otherDataTable.Rows[i][c.ColumnName] = DataTableWith6Cols.Rows[i][c.ColumnName];
}
}
So oder so ähnlich.
Hier nun die Lösung:
Es gibt keinen direkten Weg, um die Aufrufkonventionen unter C# für diesen Fall zu ändern. Aber es existieren trotzdem noch 2 Wege, die möglich sind.
Der 1. Weg ist eine nachträgliche Manipulation des IL-Codes der C#-Applikation, die die DLL verwenden will, und wird hier beschrieben:
http://www.codeproject.com/csharp/cdeclcallback.asp?df=100&forumid=248333&exp=0&select=1317814
Allerdings ist das eine äußerst fragwürdige Methode, da sie während der Entwicklung einen erheblichen Mehraufwand bedeutet.
Die Alternative ist folgende:
Die Callback-Funktion wird in der C++-DLL als __stdcall deklariert.
Dll-Header-Datei
#pragma once
#ifdef DLLCSTEST_EXPORTS
#define DLLCSTEST_API extern "C" __declspec(dllexport)
#else
#define DLLCSTEST_API __declspec(dllimport)
#endif
// Callback-Funktionstyp deklarieren
typedef void __stdcall tCallback (int Wert1); // als StandardCall festlegen
typedef tCallback* tpCallback;
namespace MyNamespace
{
// exportierte Funktionen
DLLCSTEST_API int fnDllCsTest(int a);
DLLCSTEST_API void SetCallback(tpCallback Callback);
}
Diese Deklaration bewirkt, dass die Übergabeparameter IMMER von der aufgerufenen Funktion selbst entfernt werden. C++-Aufrufe können das so berücksichtigen.
Zu beachten ist dann lediglich (für C++-Applikationen, die diese DLL verwenden wollen), dass auch Callback-Funktionen, die unter C++ angelegt und eingebnden werden, ebenfalls so zu deklarieren sind. Aber das ist kaum eine Mühe und bringt auch keine Nachteile.
So kann die Callback-Möglichkeit sowohl von C++- als auch von C#-Anwendungen ohne Änderung in der DLL genutzt werden.
Gruß,
Wes
Danke das ist genau das was ich gesucht habe.
Brauch das für Private Felder, mussm al schauen was ich bei den BindingFlags angeben muss, falls du es schon weißt würdest du mir nochmals sehr weiterhelfen. also nochmal vielen dank!
sorry, hab eben über das thema noch nicht so viel gelesen!
vielleicht hat jemand eine gute einstiegslektüre oder tutorial für mich was dieses thema behandelt?
TH3LL schrieb:
http://diditwith.net/2006/10/05/PerformanceOfForeachVsListForEach.aspx
Hm. Diese Resultate überraschen mich ganz extrem und ich hoffe, das das nur ein Spezialfall und nicht allgemeingültig ist, denn:
Der Testfall „for-loop with pre-determined count“ darf *nicht* schneller sein als der Testfall „for-loop“! Und zwar ganz einfach aus dem Grund, dass Hejlsberg persönlich behauptet hat, dass der .Count-Aufruf durch den JITter herausoptimiert wird, d.h. zwischen den beiden Versionen dürfte es *keinen* Unterschied geben.
Noch schlimmer wird es bei den anderen beiden Testfällen. Russel meinte, zwei calls müssten langsamer sein als ein callvirt und die Testergebnisse scheinen ihm recht zu geben. Das kann aber eigentlich nicht sein, denn in einer normalen foreach-Schleife dürfte eigentlich *kein einziger* call stattfinden: der JITter sollte diese Aufrufe nämlich ebenfalls inlinen. Und zwar *immer*. Der callvirt-Aufruf bei der Verwendung von ForEach + Delegate kann hingegen nicht ge-inlined werden, müsste demnach langsamer sein.
Ich vermute, dass die Ursache für die komische Performance woanders zu suchen ist: und zwar empfiehlt Microsoft, bei IEnumerator.Current jedes Mal einen Gültigkeitstest auszuführen, der im Kontext einer foreach-Schleife natürlich total überflüssig ist. Eventuell wird dieser Test nicht herausoptimiert, und im Fall der ForEach-Methode findet er nicht statt. Dieser extreme Unterschied verwundert mich aber trotzdem.
Zusammenfassung: Unter der Annahme, dass Optimierungen aktiviert sind, und der JITter wie erwartet seinen Job macht, würde ich mir folgende Reihenfolge bei der Laufzeit erwarten:
„for-loop“ = „for-loop with pre-determined count“ = „foreach-loop“ < „List<int>.ForEach call“
Hallo,
ich habe mir grad eine kleine MDI Anwendung gebastelt!
In der Parentform ein leeres MenuStrip Objekt platziert, und beim laden der Form per programmcode initialisiert und "bestückt"
DAs selbe bei der ChildForm.
In der ChildFom habe ich MergeAction auf MatchOnly gestellt!
Im Parent gibt es den Punkt Datei mit Neu und Beenden!
Im Child auch Datei mit Speichern und Speichern unter!
Nun möchte ich das beim öffnen des Childs das Speichern und Speichern unter zwischen neu und Beenden eingefügt wird!
Geht das irgendwie?Er setzt sie beiden immer ans Ende!
Hab ich mich nicht verständlich ausgedrückt?
Also zur Sicherheit noch einmal:
Wenn ich mittels Drag'n'Drop ein Image von einer PictureBox in eine andere "dragge" ,wie kann ich während des Vorganges das Image an der Mausposition anzeigen? (da wo jetzt das Symbol angezeigt wird; Wenn man das Image hier "droppen" kann -> Bild transparent anzeigen, wenn nicht -> Bild nicht anzeigen)
Ist ungefähr klar was ich meine?
Ich bitte um Tipps und Tricks!
Lg DragMe
Gut ok ich schau mir das an, aber es geht auch nicht wenn ich es auf Sizeable lasse. :(. Wenn ich es dann maximize rückt es sich trotzdem nich selbständig zurecht
Edit: Wenn ich ein ganz neues Projekt mache und State Maximized mache klappts mit der Sidebar wunderbar. Ich denke beim anderen gehts nicht weil das Form wiegesagt gaaaaaaaanz hinten liegt. Soll quasie ein Desktop ersatz werden
Ist schon wahr, MSDN ist eine hervorragende Informationsquelle -- wenn man weiss, welche Fragen man stellen soll.
Als Umsteiger von VB6 und C++ nach C# habe ich das Buch "Visual C# 2005 Schritt für Schritt" von Microsoft Press mit gutem Erfolg nutzen können; meine "Transfer-"Zeit hat sich dadurch auf ca. sechs Wochen reduziert.
Hallo Community,
meine Applikation hat ein (einziges) Window ohne Rahmen. Ich habe es auch geschafft, dass es zu diesem Window auch einen Taskbar button gibt, der den Namen des Window anzeigt. Das Kontextmenü dieses Taskbar-Button erschein jedoch nicht -- kein Wunder, denn das Window hat ja auch kein Menü und damit auch kein System-Menü.
Hier meine Frage:
Wie kann ich dem Taskbar-Button ein ein Kontextmenü zuordnen und die entsprechenden Ereignisse im Window auswerten? Kann mir jemand mit einem Hinweis bzw. Link auf eine Beschreibung helfen?
(Zu diesem Thema gibt es bestimmt jede Menge Dokumentation, aber ich habe sie wohl deshalb nicht gefunden, weill ich möglicherweise nicht die richtigen Suchanfragen formuliert habe)