# Beratung Programmiersprachen/Design Mix



## Crymes (27. April 2012)

Hallo,
Ich wollrte mir demnächst eine Anwendung erstellebn, die vielleicht OpenCL beinhaltet.
Sie soll aber möglichst auch Drag and Drop für Input Dateien unterstützen, das Design sollte auch passen.

Was schlagt ihr vor? 

Den Kern mit C++ programmieren und per DLL in C# einbinden?
Alles in C# programmieren?
Andere Möglichkeiten?

Ich denke, dass C++ schneller ist, bin mir aber nicht sicher.


----------



## Crysis nerd (27. April 2012)

Du könntest es theoretisch auch komplett in C++ programmieren, nur ist da das Fenster Handling und so alles doof. Also entweder mit externer Bibiliothek wie QT oder sogar mit .Net (was sich ja praktisch garnicht gehört das mit C++ zu mixen ).
Daher find ich die Idee mit der DLL eigentlich ganz gut. Also Performance kritisches zeug in C++ und Gerüst drum rum in C#, das würde perfekt die (meiner Meinung nach) dicken Vorteile der Sprachen herausheben 

Sind dir denn beide Sprachen geläufig?

Und mit C++ schneller.. ich würde sagen ja, aber das kann man halt irgendwie nicht uneingeschränkt sagen, deswegen schmeiß ich meine Meinung hier nich in den Raum, führt wohl eh nur zu Diskussionen...

mfg
Lukas


----------



## joffal (27. April 2012)

Per se würde ich mit allem eigentlich zu C# raten. C++ ist oft nur im Embedded-Sektor sinnvoll!

Außerdem wollt ich mal fragen, ob ich deinen Thread für folgende Frage "ausnutzen" darf? 

Weiß schon jemand, ob .NET mit Windows 8 für Programmierer nun wirklich stark an Bedeutung verlieren soll? Weil ich habe so EINIGE (Echtzeit-)Anwendungen in C# mit .NET und der 3D-Teil wird mit SlimDX realisiert. Nur hab ich bisher noch kaum Angaben dazu gefunden ...
Deswegen weiß ich nicht, ob ich dir (Crymes) nicht vllt doch eher C++ anraten sollte, denn die Win32-API wird auch in Win8 im Vordergrund stehen


----------



## Crysis nerd (27. April 2012)

Okay... deine Information joffal, wundert mich schon. Ich hätte nie gedacht, dass MS so handeln würde...
Okay, da Windows 8 jetzt für viele Geräte und Architekturen rauskommen soll, liegt das etwas näher.. Aber trotzdem. Alles geht in Richtung Java oder C#... Jedenfalls was mein Kindskopf so in der Programmierwelt überblicken kann..

Aber ich wollte auch nich zu sehr ablenken.. ich bleib jedenfalls bei meiner Meinung, C++ als Core zu nehmen, auch wenn du zb bei Win 7 bleiben willst...


mfg
Lukas


----------



## Crymes (27. April 2012)

@joffal:
Frag ruhig, deine Frage kommt eigentlich sehr gelegen, da ich das Programm in den W8 AppStore stellen wollte 

Wie ist es mit der OpenCL Syntax in C#?
Ist das dann immer noch C?


----------



## Skysnake (27. April 2012)

Nein, du kannst die meisten Sachen aus C++ verwenden. Nicht alles aber das meiste.


----------



## Crymes (27. April 2012)

So, ich sag jetzt einfach mal was ich machen will: Es soll ein rogramm werden, was beliebige Dateien/Ordner erst komprimiert und danach verschlüsselt (vielleicht danach nochmal komprimieren oder andersherum?).
Ich habe ein Bisschen nach AES recherschiert und festgestellt, das das für mich zu Komplex ist bzw. ich nichts versteh.
Nun werde ich mir einen eigenen Verschlüsselungsalgorythmus einfallen lassen müssen, habt ihr Ideen, welche variablen Quellen ich nehmen könnte, die auf dem Zielrechner aber trotzdem gleich sind?


----------



## Skysnake (27. April 2012)

Acker dich einfach für AES durch 

Das Verfahren taugt was, und du kannst dir sicher sein, das es funktioniert. Sehs als Übung für später an, da kannste ja auch nicht sagen "ich verstehs nicht" 

Auch wenn ich da voll und ganz mitfühlen kann, mir gehts mit manchen Sachen ja auch so, und ich versuch dann drum rum zu kommen, aber manchmal gehts halt nicht, und dann muss man durch.


----------



## Crymes (27. April 2012)

Vielleicht werde ich das mit dem AES mal näher betrachten, so ne Anwendung wäre extrem nützlich, wenn oich jemanden schnell Dateien übers Internet geben will.....

Das mit der Komprim ierung ist aber glaub viel zu kompliziert.


----------



## Skysnake (27. April 2012)

Naja, kommt drauf an, wie effizient es sein soll 

Wenns auch ok ist, wenn die Datei später größer ist, dann gehts relativ einfach


----------



## Crymes (27. April 2012)

Wieso soll die größer werden


----------



## Skysnake (27. April 2012)

Weil ein Komprimierungsverfahren nicht zwigend kleinere Dateien verursacht 

Ist wirklich so. Je nach Verfahren kanns dir passieren, dass die komprimierte Datei größer ist als das Orginal in gewissen Situationen


----------



## Crymes (27. April 2012)

OK, aber ein Komprimierungsverfahren zu imolementieren.... Dem bin ich nicht gewachsen.


----------



## Crysis nerd (27. April 2012)

Ach was.. einfach Datei Binär öffnen, alles als char interpretieren und falls mehrere gleiche chars hintereinander sind, einfach zusammenfassen  und in eine Tabelle eintragen ;D 
Ne.. wie schon gesagt, Komprimierung effizient zu machen ist sehr komplex... bei verlustfreier wie auch verlustbehafteter. 
Verschlüsselung: Wühl dich durch AES durch.. Dahinter stehen Mathematiker die... ziemlich ziemlich helle in der Birne sind  
Is komplex, ich blick noch nichmal RSA so richtig, aber man schafft alles.

Zur Kompremierung fällt mir noch ein, dass du sicher irgendwie von 7zip (is doch Open Source oder?) irgendwie etwas für Entwickler bekommst. Damit kannste schon gut Komprimieren... Aber bin mir nich sicher.


Jedenfalls viel Spaß bei diesen beiden total trivialen Themen der Programmierung 

Um zu deiner eigentlichen Frage zu kommen: Komprimierung und Verschlüsselung wird bei eigentlich allen halbwegs guten Programmen in einer Mischung aus C und ASM geschrieben, das is klar. Is halt zu Performance kritisch um da mit irgendwas anderem ran zu gehen...

mfg


----------



## pyro539 (27. April 2012)

Mach dir doch keine Gedanken wie AES oder Packalgorithmen intern funktionieren. Du musst sie auch gar nicht implementieren, denn es gibt mit 100%-iger Sicherheit schon Implementierungen für C#.

Ich würde dir auch davon abraten einen eigenen Algorithmus zu entwerfen, wenn das wirklich sicher sein soll. AES ist nicht ohne Grund von Mathematikern in jahrelanger Arbeit entworfen worden 

Und ein letztes: Ich würde zuerst packen, danach verschlüsseln. Ich denke nicht, dass man verschlüsselte Daten noch komprimieren kann, da das ja alles nur noch Binärdaten sind.


----------



## Crysis nerd (28. April 2012)

pyro539 schrieb:


> Und ein letztes: Ich würde zuerst packen, danach verschlüsseln. Ich denke nicht, dass man verschlüsselte Daten noch komprimieren kann, da das ja alles nur noch Binärdaten sind.


 Würd ich fast auch sagen.. aber es könnte ja auch umgekehrt sein, in manchen Fällen zumindest. Würd michmal echt interessieren, ob das immer so ist, dass vorher komprimieren besser ist...


----------



## Crymes (28. April 2012)

Meine ursprüngliche Idee war, dass ich OpenCL lernen wollte.
Nun hab ich mir überlegt, dass die ganzen Techdemos aus Grafikdarstellugn bestehen und ich sowas nicht kann.

Nach bein paar Wochen bin ich dann darauf gekommen, dass komprimierung und Verschlüsselung keine Grafik beinhalten und sich gut parallelisieren lassen müssten.
Deshalb wollte ich eigentlich einfache Algorythmen, sodass man da ein bisschen mit der OpenCL optimkierung spielen kann.

Aber gibt es denn überhaupt Programme, die eine Datei verschlüsseln?

Truecrypt macht ja so komische Partitionen.
Dann wäre das schon eine gute Aufgabe für mich, mit sowas einfachem anzufangen.


----------



## Skysnake (28. April 2012)

ICh glaub du hast die open*G*l angeschaut, nicht open*C*l


----------



## Crymes (28. April 2012)

Nein, ich meine, dass nur Partikel oder Physik berechnet werden/wird, die dann auf dem Bildschirm angezeigt werden.
Sowas wie Folding at Home, wo es wirklich nur um Berechnungen geht, finde ich in OpenCL selten.


----------



## Skysnake (29. April 2012)

Das sind eigentlich die meisten Samples. Okok, man hat noch irgendwelche Konvolation-Filter usw, aber man hat auch mehr als genug ohne Graphikausgabe, zumal die Visualisierung eben nur dazu dient die Sachen bildlich dar zu stellen. Man muss sich damit aber nicht wirklich auseinander setzen.


----------



## Crymes (29. April 2012)

Kennt ihr ein gutes Buch, in dem OpenCL erklärt wird? Es kann notfalls auch in Englisch sein.


----------



## Skysnake (29. April 2012)

Also es gibt ein OpenCL Buch, welches in Zusammenarbeit mit AMD erstellt wurde.

Ansonsten gibts noch "Programming Massively Parallel Processors", welches von nVidia erstellt wurde und sich zu 98% um CUDA dreht. CUDA und OpenCL sind aber zu 99% identisch. Nur einige Schlüsselwörter und so weiter sind anders. Der Umstieg ist also SEHR einfach. 

Ansonsten halt die Software-Developer-Guides von AMD und nVidia lesen. Die sind kostenlos und da steht mehr oder weniger das gleiche drin, nur eben nicht so gut aufbereitet. Ansonsten gibts glaub ich bei khronos.org noch Tutorials. Du musst einfach dich einarbeiten und Beispiele machen. OpenCL ist teilweise schon etwas tricky, da sehr schlecht zu debuggen. Ich saß auch schon Stunden vor nem winzig kleinen Problem, welches ich aber durch das schlechte Debugging nicht gesehen habe -.-

Was ganz hilfreich ist ist unter VS2010 zu entwickeln, wenn du ne AMD nimmst, da es dort einen Debugger/Profiler gibt, der recht gut ist. Ansonsten kannste dir auch mal gDebugger anschauen, welches AMD und nVidia unterstützt. Als ich vor einigen Monate aber mal mir das Ding angeschaut habe, bin ich damit nicht zurecht gekommen, war da aber auch ganz frisch drausen und wohl noch verbuggt. Keine Ahnung wies da im Moment aussieht.


----------

