Schau dir das an und mach dir deine Implementation,
tools.ietf.org/html/rfc4648

oder nimmst was fertiges.
adp-gmbh.ch/cpp/common/base64.html

@xtamersan

Du meinst schon C++/CLI oder?



Edit: Ich hab jetzt UTF8Encodinggenommen man könnte auch ASCIIEncoding^ ascii = gcnew ASCIIEncoding; nehmen.

Freundliche Grüsse

exc-jdbi

Ups, da hab ich wohl das falsche gepostet. Das CLI nicht gesehen. Damit habe ich mich nie wirklich richtig beschaeftigt, sieht aber ungewohnt komisch aus mit dem ^.

@Eddy

Ich kenn mich auch nicht besonders aus, habs nur von meinem Wissen aus VB.Net abgeleitet.

Freundliche Grüsse

exc-jdbi

So wie es aussieht verwendest du etwas, das den Namen C++ nicht verdient hat.

Ich bin mir zu 99,9% sicher, dass es für dich keinen Sinn ergibt C++/CLI zu verwenden, was du vorhast kann mit ziemlicher Sicherheit in C# einfacher erledigt werden(und mit genau gleicher Performance, evtl. sogar besser, da der C# Compiler vmtl. besser optimiert ist). Und selbst wenn du bei C++/CLI bleiben wolltest, wovon ich dir abraten würde, kannst du da die selben Klassen wie auch in C# verwenden
msdn.microsoft.com/en-us/libra…ang=csharp#code-snippet-3

Wenn du es aber machen willst, weil du gerne C++ lernen würdest, oder allgemein lieber damit programmierst, dann verwende bitte richtiges C++ und nicht diese MS perversion(Das heißt aber auch kein .Net Framework - und nicht diese schönen Vereinfachungen, wie z.B. für die GUI)

@jvbsl

Warum ist denn C++/CLI so pervers. Prinzipiell stell ich mir das ja schon praktisch vor.

Zur Aufklärung: Das ist managed C++ und kein C++/CLI. C++/CLI dient zum wrappen von nativen Bibliotheken für .Net und ist absolut i.O. Managed C++ hingeben ist Quatsch.

C++/CLI ersetzt managed C++ und ist eigt. im Grunde genau dasselbe(mit weniger Bugs natürlich, da neuer).

C++/CLI ist nicht vollkommen in Ordnung, die Leute verwenden es gerne, weil sie denken, toll ich kann C++, können sie aber dann nicht.

Zum wrappen von nativen Dlls ist es schön und gut(finde ich trotzdem nicht die beste Möglichkeit, da nicht Plattformunabhängig), aber die einfachste Möglichkeit.
Für alles andere holst du dir die Schwierigkeiten von C++ mit den Nachteilen von .Net ins Haus.

Deshalb sage ich, 99,9% der Fälle braucht man C++/CLI nicht, kann man direkt in C# machen.

OK danke. Dann habe ich damals wohl doch unwissentlich die richtige Wahl getroffen als ich mit C++ angefangen hab, auch wenn es anfangs ohne Framework echt hart war.

Nein C++/CLI ist ausschliesslich zum Wrappen. Gibt ein gutes Buch über CLI, umsonst. Da wird der Unterschied gut erklärt.

Ich weiß nicht ob das "nein" für mich war, falls ja:

wiki schrieb:

C++/CLI (C++ modified for Common Language Infrastructure) is a language specification created by Microsoft and intended to supersede Managed Extensions for C++

Auf Stackoverflow ähnliche Antworten gefunden und nichts, was irgendetwas anderes sagt.
Falls du dennoch meinst, ich liege falsch könntest du mir das Buch+stelle nennen?

C++/CLI ersetzt Managed C++, dass ist richtig. Es ist aber nicht dafür gedacht um es in dem Sinne wier C# oder VB.Net zu verwenden, sondern als Schnittstelle zwischem nativen C++ und CLI. Man kann also z.B. Bibliotheken wrappen (via C++ interop), dass geht nicht anders. Durch P/Invoke lässt sich keine C++ Bibliothek ansprechen, ist eher für C.

Was da oben gemacht wird ist natürlich Quatsch. Hat mit C++ garnichts zu tun und ist auch nicht nach Standard. Richtiges C++ ist genormt. Da man per C++/CLI auf die CLI zugreift, kann man natürlich auch ganz fein seine Forms basteln, dafür ists aber nicht gedacht und tut in den Augen weh. C++/CLI ist halt Schnittstelle zwischen echtem nativen C++ und .Net (WPF, WCF, Forms, MFC ntl. auch, etc). Wobei man die Architektur leider oft ändern muss, da alle managed Sprachen nicht viele hochsprachen Konzepte unterstützen (Mehrfachvererbung, Templates..).

Ich glaube dann haben wir aneinander vorbei geredet^^
Ich hab ja die ganze zeit gesagt nur zum wrappen verwenden und ansonsten kann alles andere auch C#. War mir nicht klar, dass man mit C++/CLI aufgegeben hattte C++ Entwickler zum Umstieg zu bewegen, mit Managed C++ wars auf jeden Fall so, was natürlich blödsinn ist, weil man Nachteile mit Nachteile kombiniert hat(+es Fehlerhaft war).
mMn verneint der Buchausschnitt auch nichts von dem mir gesagtem.

Damit, dass man C++ nicht mittels P/Invoke ansprechen kann stimmt nicht, es ist nur verdammt umständlich. Mono hat dafür sogar extra eine Vereinfachung gemacht:
github.com/mono/CppSharp
Schließlich geht C++/CLI nur auf Windows.

Dann haben wir aneinander vorbei geredet Joa C++ ansprechen geht teilweise über P/Invoke. Ich behaupte es geht nicht, weil es nicht 100%tig geht. Normale Klassen funktionieren, man gibt halt den Classpointer mit in die Funktion (Dank thiscall). Templates gehen aber nicht und da C++ sozusagen templatebasiert ist, ists blöd Würde man bspw. std::string nach .Net bringen wollen, bliebe einem nur C++/CLI. Templates werden zur Compilezeit generiert, da hat man keine Chance.

Wobei man da auch differenzieren sollte. Entweder C++ oder ich machs in .Net.

Das Buch findet man hier. Die entsprechende Stelle hat ja @Gonger96 schon erwähnt.

Ich selber habe es nie durchgelesen, da für mich schon von anfang an klar war, wenn ich schon C++ lerne dann die altbewährte. Ich bin jedoch auch der Meinung, dass CLI als Wrapper ein ideales Werkzeug ist. In einigen Beiträgen hier wird das ja sogar explizit erwähnt, z.B.für Klassen in nativen Dll's, die man aus .Net ansprechen will.

Der Beitrag oben von mir ist genau ein Beispiel wie man es nicht machen soll, schlecht hin. Und ich finde es gut, dass eine entsprechende Diskussion entstanden ist. Ich denke so muss es auch sein, damit gezielt ersichtlich ist, in welche Richtung es gehen soll. Für Neulinge ist genau das nähmlich nicht immer sofort ersichtlich.

Freundliche Grüsse

exc-jdbi


Wer sich wirklich noch intensiver mit dem CLI befassen möchte
Quick C++/CLI - Learn C++/CLI in less than 10 minutes
.NET-Programmierung mit C++/CLI (Visual C++)
CLI in Action

Ideal muss ich stark widersprechen. Wie gesagt, es macht es einem einfach und damit geht vieles, aber bei den aktuellen Bewegungen von MS Richtung OpenSource und auch Plattformunabhängigkeit ist es eben nicht Ideal. Vorallem da es eher selten passieren dürfte, dass man auf eine reine Cpp Library zurückgreift. Richtige Libraries bieten in der Regel eine C ABI, weil es für Cpp eben keinen Standard gibt und man C Libraries aus allen Sprachen ziemlich einfach Nutzen kann.

Also das mit der C-Brigh wie es in eingen Beiträgen hier im Forum schon erwähnt worden ist, habe ich mir jetzt auf meine Aufgabenliste gesetzt. Ich hab mich noch nie wirklich intensiv damit beschäftigt, finde es aber spannend und möchte mir dazu mal ein paar Beispiele durcharbeiten. Rein aus meiner Neugier raus.