Sonstige Programmiersprachen

• B

  Welche Sprache
  • Benk  

  19
  0
  Stimmen
  19
  Beiträge
  2125
  Aufrufe

  M

  Linux von A-Z schrieb: Mechanics schrieb: Und wenn man mit Linux arbeitet, muss man sich mit sehr vielen Sachen im Detail auskennen, die einen unter Windows nicht interessieren, weil sie einfach funktionieren (oder auch nicht). Das ist doch schon wieder die Konsumentensicht. Befassen wir uns hier nicht eher mit dem Entwicklerstandpunkt? Hier ist die System-API auf Linuxseite IMHO viel einfacher und strukturierter als das Wirrwarr bei Windows mit zigtausend Systemcalls samt -W und -Ex-Varianten und anderen Sauereien. Die Unix-API ist da bedeutend simpler und IMHO schöner, wobei es auch da ein paar sehr, sehr dunkle Ecken gibt (Terminalhandling...brrr). Vielleicht. Aber darauf wollte ich ja auch hinaus, man kann sich mit Linux nicht gut auskennen, wenn man das nicht benutzt. Was bringt es dir, irgendwelche APIs zu kennen, wenn du mit dem System als Anwender nicht zurechtkommst? Vor allem, wenn man sicherheitsrelevante Software schreiben will. Da würde ich eher von der Adminsicht und nicht von der Konsumentensicht reden. Und da muss man bereit sein, sich in sehr viele Details reinzudenken, die ein Windows Anwender noch nie gesehen hat. Ich sehe das nicht als Nachteil von Linux, das ist nur etwas, was einem klar sein muss, bevor man sich darauf einlässt. Was die API angeht... Ich weiß ehrlich gesagt nicht mal genau, was du meinst. Meinst du die System Calls? Die interessieren doch keinen, die paar Low Level Funktionen sind schon durch jede Standardlibrary gewrappt. Und die Kernel API ist auch recht umfangreich. Ich finde es tatsächlich erstmal einfacher, unter Linux Treiber zu schreiben als unter Windows, aber wenn es in die Tiefe geht, bin ich mir gar nicht sicher, ob es dann immer noch so einfach und übersichtlich ist.
• ?

  clang: error
  • Gast  

  7
  0
  Stimmen
  7
  Beiträge
  1973
  Aufrufe

  ?

  hab nun das makefile selbst per hand geschrieben aber bekomme nun: make /usr/local/cuda/bin/nvcc -O3 -c -g -arch=compute_30 -code=sm_30 CUDA_ConvNN.cu -I/Developer/NVIDIA/CUDA-6.0/include/ g++ -std=c++11 -I/usr/local/cuda/include main.cpp Undefined symbols for architecture x86_64: "CentreData(Dataset&, std::__1::vector<float, std::__1::allocator<float> >&, std::__1::vector<float, std::__1::allocator<float> >&, std::__1::vector<float, std::__1::allocator<float> >&)", referenced from: RunCUDA_CNN_2(int, float, int) in main-c54edb.o RunCUDA_CNN_1(int, float, int) in main-c54edb.o "CalcMean(Dataset&, std::__1::vector<float, std::__1::allocator<float> >&, std::__1::vector<float, std::__1::allocator<float> >&, std::__1::vector<float, std::__1::allocator<float> >&)", referenced from: RunCUDA_CNN_2(int, float, int) in main-c54edb.o RunCUDA_CNN_1(int, float, int) in main-c54edb.o "LoadData(char const*, Dataset&)", referenced from: RunCUDA_CNN_2(int, float, int) in main-c54edb.o RunCUDA_CNN_1(int, float, int) in main-c54edb.o "cv::_InputArray::_InputArray(cv::Mat const&)", referenced from: SaveWeights(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, float const*, int, int, int) in main-c54edb.o OutputResultsForSite(CNN::CudaConvNN&, Dataset const&, std::__1::vector<float, std::__1::allocator<float> >&, std::__1::vector<float, std::__1::allocator<float> >&, std::__1::vector<float, std::__1::allocator<float> >&) in main-c54edb.o "cv::_OutputArray::_OutputArray(cv::Mat const&)", referenced from: OutputResultsForSite(CNN::CudaConvNN&, Dataset const&, std::__1::vector<float, std::__1::allocator<float> >&, std::__1::vector<float, std::__1::allocator<float> >&, std::__1::vector<float, std::__1::allocator<float> >&) in main-c54edb.o "cv::_OutputArray::_OutputArray(cv::Mat&)", referenced from: SaveWeights(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, float const*, int, int, int) in main-c54edb.o OutputResultsForSite(CNN::CudaConvNN&, Dataset const&, std::__1::vector<float, std::__1::allocator<float> >&, std::__1::vector<float, std::__1::allocator<float> >&, std::__1::vector<float, std::__1::allocator<float> >&) in main-c54edb.o "cv::Mat::deallocate()", referenced from: cv::Mat::release() in main-c54edb.o "cv::Mat::zeros(int, int, int)", referenced from: SaveWeights(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, float const*, int, int, int) in main-c54edb.o OutputResultsForSite(CNN::CudaConvNN&, Dataset const&, std::__1::vector<float, std::__1::allocator<float> >&, std::__1::vector<float, std::__1::allocator<float> >&, std::__1::vector<float, std::__1::allocator<float> >&) in main-c54edb.o "cv::Mat::create(int, int const*, int)", referenced from: cv::Mat::create(int, int, int) in main-c54edb.o "cv::Mat::Mat(cv::Mat const&, cv::Rect_<int> const&)", referenced from: cv::Mat::operator()(cv::Rect_<int> const&) const in main-c54edb.o "cv::resize(cv::_InputArray const&, cv::_OutputArray const&, cv::Size_<int>, double, double, int)", referenced from: SaveWeights(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, float const*, int, int, int) in main-c54edb.o OutputResultsForSite(CNN::CudaConvNN&, Dataset const&, std::__1::vector<float, std::__1::allocator<float> >&, std::__1::vector<float, std::__1::allocator<float> >&, std::__1::vector<float, std::__1::allocator<float> >&) in main-c54edb.o "cv::imwrite(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, cv::_InputArray const&, std::__1::vector<int, std::__1::allocator<int> > const&)", referenced from: SaveWeights(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, float const*, int, int, int) in main-c54edb.o OutputResultsForSite(CNN::CudaConvNN&, Dataset const&, std::__1::vector<float, std::__1::allocator<float> >&, std::__1::vector<float, std::__1::allocator<float> >&, std::__1::vector<float, std::__1::allocator<float> >&) in main-c54edb.o "cv::putText(cv::Mat&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, cv::Point_<int>, int, double, cv::Scalar_<double>, int, int, bool)", referenced from: OutputResultsForSite(CNN::CudaConvNN&, Dataset const&, std::__1::vector<float, std::__1::allocator<float> >&, std::__1::vector<float, std::__1::allocator<float> >&, std::__1::vector<float, std::__1::allocator<float> >&) in main-c54edb.o "cv::fastFree(void*)", referenced from: cv::Mat::~Mat() in main-c54edb.o "CNN::CudaConvNN::FeedForward()", referenced from: RunCUDA_CNN_2(int, float, int) in main-c54edb.o RunCUDA_CNN_1(int, float, int) in main-c54edb.o RunValidation(CNN::CudaConvNN&, Dataset const&) in main-c54edb.o RunValidation2(CNN::CudaConvNN&, Dataset const&) in main-c54edb.o GradientChecker(CNN::CudaConvNN&, Dataset&) in main-c54edb.o OutputResultsForSite(CNN::CudaConvNN&, Dataset const&, std::__1::vector<float, std::__1::allocator<float> >&, std::__1::vector<float, std::__1::allocator<float> >&, std::__1::vector<float, std::__1::allocator<float> >&) in main-c54edb.o "CNN::CudaConvNN::LoadWeights()", referenced from: RunCUDA_CNN_2(int, float, int) in main-c54edb.o RunCUDA_CNN_1(int, float, int) in main-c54edb.o "CNN::CudaConvNN::SaveWeights()", referenced from: RunCUDA_CNN_2(int, float, int) in main-c54edb.o RunCUDA_CNN_1(int, float, int) in main-c54edb.o "CNN::CudaConvNN::TotalMemUsed()", referenced from: RunCUDA_CNN_2(int, float, int) in main-c54edb.o RunCUDA_CNN_1(int, float, int) in main-c54edb.o "CNN::CudaConvNN::Init(int, int, int, int)", referenced from: RunCUDA_CNN_2(int, float, int) in main-c54edb.o RunCUDA_CNN_1(int, float, int) in main-c54edb.o "CNN::CudaConvNN::AddLayer(CNN::LayerType)", referenced from: RunCUDA_CNN_2(int, float, int) in main-c54edb.o RunCUDA_CNN_1(int, float, int) in main-c54edb.o "CNN::CudaConvNN::AddLayer(CNN::LayerType, int)", referenced from: RunCUDA_CNN_2(int, float, int) in main-c54edb.o RunCUDA_CNN_1(int, float, int) in main-c54edb.o "CNN::CudaConvNN::AddLayer(CNN::LayerType, int, int)", referenced from: RunCUDA_CNN_2(int, float, int) in main-c54edb.o RunCUDA_CNN_1(int, float, int) in main-c54edb.o "CNN::CudaConvNN::BackProp(float, float)", referenced from: RunCUDA_CNN_2(int, float, int) in main-c54edb.o RunCUDA_CNN_1(int, float, int) in main-c54edb.o GradientChecker(CNN::CudaConvNN&, Dataset&) in main-c54edb.o "CNN::CudaConvNN::SetImages(float const*, unsigned long)", referenced from: RunCUDA_CNN_2(int, float, int) in main-c54edb.o RunCUDA_CNN_1(int, float, int) in main-c54edb.o RunValidation(CNN::CudaConvNN&, Dataset const&) in main-c54edb.o RunValidation2(CNN::CudaConvNN&, Dataset const&) in main-c54edb.o GradientChecker(CNN::CudaConvNN&, Dataset&) in main-c54edb.o OutputResultsForSite(CNN::CudaConvNN&, Dataset const&, std::__1::vector<float, std::__1::allocator<float> >&, std::__1::vector<float, std::__1::allocator<float> >&, std::__1::vector<float, std::__1::allocator<float> >&) in main-c54edb.o "CNN::CudaConvNN::SetLabels(float const*, unsigned long)", referenced from: RunCUDA_CNN_2(int, float, int) in main-c54edb.o RunCUDA_CNN_1(int, float, int) in main-c54edb.o RunValidation(CNN::CudaConvNN&, Dataset const&) in main-c54edb.o RunValidation2(CNN::CudaConvNN&, Dataset const&) in main-c54edb.o GradientChecker(CNN::CudaConvNN&, Dataset&) in main-c54edb.o OutputResultsForSite(CNN::CudaConvNN&, Dataset const&, std::__1::vector<float, std::__1::allocator<float> >&, std::__1::vector<float, std::__1::allocator<float> >&, std::__1::vector<float, std::__1::allocator<float> >&) in main-c54edb.o "CNN::CudaConvNN::CudaConvNN()", referenced from: RunCUDA_CNN_2(int, float, int) in main-c54edb.o RunCUDA_CNN_1(int, float, int) in main-c54edb.o "CNN::CudaConvNN::~CudaConvNN()", referenced from: RunCUDA_CNN_2(int, float, int) in main-c54edb.o RunCUDA_CNN_1(int, float, int) in main-c54edb.o "CNN::Layer::GetWeights(std::__1::vector<float, std::__1::allocator<float> >&)", referenced from: RunCUDA_CNN_2(int, float, int) in main-c54edb.o RunCUDA_CNN_1(int, float, int) in main-c54edb.o "CNN::Layer::SetWeights(float const*)", referenced from: RunCUDA_CNN_2(int, float, int) in main-c54edb.o RunCUDA_CNN_1(int, float, int) in main-c54edb.o "CNN::Layer::GetWeightValue(int)", referenced from: GradientChecker(CNN::CudaConvNN&, Dataset&) in main-c54edb.o "CNN::Layer::SetWeightValue(int, float)", referenced from: GradientChecker(CNN::CudaConvNN&, Dataset&) in main-c54edb.o "CNN::Layer::GetSumWeightGrad(std::__1::vector<float, std::__1::allocator<float> >&)", referenced from: GradientChecker(CNN::CudaConvNN&, Dataset&) in main-c54edb.o "CNN::Layer::GetOutput(std::__1::vector<float, std::__1::allocator<float> >&)", referenced from: RunValidation(CNN::CudaConvNN&, Dataset const&) in main-c54edb.o RunValidation2(CNN::CudaConvNN&, Dataset const&) in main-c54edb.o GradientChecker(CNN::CudaConvNN&, Dataset&) in main-c54edb.o OutputResultsForSite(CNN::CudaConvNN&, Dataset const&, std::__1::vector<float, std::__1::allocator<float> >&, std::__1::vector<float, std::__1::allocator<float> >&, std::__1::vector<float, std::__1::allocator<float> >&) in main-c54edb.o "cv::Mat::copyTo(cv::_OutputArray const&) const", referenced from: OutputResultsForSite(CNN::CudaConvNN&, Dataset const&, std::__1::vector<float, std::__1::allocator<float> >&, std::__1::vector<float, std::__1::allocator<float> >&, std::__1::vector<float, std::__1::allocator<float> >&) in main-c54edb.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [main.o] Error 1
• ?

  OOP-Denkweise &quot;vergessen&quot;
  • Gast  

  5
  0
  Stimmen
  5
  Beiträge
  878
  Aufrufe

  ?

  gfgdfgfdgdfgdg schrieb: C bietet doch alles was du brauchst. Klassen: struct CTOR, DTOR: Create und Destroy Funktion, erstellt bzw. löscht Instanz der struct Methoden: Funktionen, die als ersten Parameter einen struct Pointer annehmen Polymorphismus: Funktionszeiger, der je nach tatsächlichem Typ vom CTOR befüllt wird statt Ableitungen kannst du z.B. Aggregation verwenden usw... Die Frage war, wie man das *sinnvoll* umsetzt, d.h. auf wieviel OOP convenience verzichte ich, um noch einigermaßen lesbare C Programme zu erhalten (würde mich auch interessieren). Dass man sich die meisten C++ Features in C hässlich nachbauen kann, ist mir z.B. auch bekannt.
• ?

  Header Files im Makefile verlinken
  • Ein ehemaliger Benutzer  

  6
  0
  Stimmen
  6
  Beiträge
  1085
  Aufrufe

  ?

  Vielen danke schon einmal an alle. Das "Ultimative Makefile" hat mir schon einmal sehr weitergeholfen.
• ?

  funktionale programmiersprachen
  • Gast  

  8
  0
  Stimmen
  8
  Beiträge
  930
  Aufrufe

  ?

  ramsey schrieb: wie werden in rein funktionalen programmiersprachen input / outputs gelöst? oder funktionen mit zuständen wie prngs? die funktion soll ja den gesamtzustand nicht ändern können soviel ich verstanden habe U.a. durch "Composition", "Schnittstellen", "Definition" oder "Ausnahmen" - oder gar Verzicht. Zufallsgeneratoren, die immer nur die gleiche "Zufallszahl" produzieren, das muß man erstmal hinbekommen Composition meint dann eben, man arbeitet mit diesen Typ "Zufallszahl" weiter..., konstruiert windige Funktionsabfolgen... Am einfachsten läßt sich ein Vorverständnis des Sachverhalts (bei Haskell) so aufbauen: Datentypen lernen und lernen, neue Datentypen zu erstellen. Die Datentypen können selbst ganz einfach sein, oder sehr komplex werden, etwa wenn sie selbst aus verschachtelten, interaktiven Algorithmen bestehen. Und wenn es gar nicht anders geht, dann werden eben "ökonomisch kontrollierte" "Seiteneffekte" zugelassen
• ?

  unicode normalization
  • Gast  

  3
  0
  Stimmen
  3
  Beiträge
  424
  Aufrufe

  

  Oder auch http://en.wikipedia.org/wiki/Unicode_equivalence#Normal_forms
• ?

  C++ für Android und Co.
  • Gast  

  16
  0
  Stimmen
  16
  Beiträge
  1094
  Aufrufe

  A

  Seit WP 8 kann man offiziell C++ programmieren.
• ?

  Mingw build GLEW statically
  • Gast  

  3
  0
  Stimmen
  3
  Beiträge
  555
  Aufrufe

  R

  make glew.lib
• ?

  Batch (Anfänger)
  • Gast  

  5
  0
  Stimmen
  5
  Beiträge
  399
  Aufrufe

  ?

  Grazie mille!
• ?

  calloc vs malloc+memset: Warum ist calloc langsamer?
  • Gast  

  9
  0
  Stimmen
  9
  Beiträge
  989
  Aufrufe

  G

  Das könnte auch der Overflow-check von calloc beim multiplizeren sein.
• ?

  Frage zur Internen verarbeitung des Computers von Werten
  • Gast  

  11
  0
  Stimmen
  11
  Beiträge
  2246
  Aufrufe

  

  Hallo DerPCInteressierte, als Beispiel: int x = 65; printf("%d, %c", x, x); oder aber int x = 65; cout << x << ", " << char(x); Wenn du wissen willst, wie man selber die Ausgabe einer Dezimalzahl programmiert (bzw. wie obige Funktionen intern implementiert sind), dann schau z.B. mal in Converting numbers to strings and strings to numbers.
• ?

  Android-App auf Moto G testen
  • Gast  

  3
  0
  Stimmen
  3
  Beiträge
  464
  Aufrufe

  ?

  Yupp, gelöst: Ins Manifest einfügen: <activity android:name="AndroudActivity" android:label="@string/app_name" > <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> und es läuft
• A

  &quot;COM Lite&quot;, Mono und GCC
  • audacia  

  6
  0
  Stimmen
  6
  Beiträge
  1707
  Aufrufe

  A

  Artchi schrieb: Wieviel spielt denn Performance eine Rolle? Ich möchte schon gerne das UI auf der einen und das Model auf der anderen Seite haben können, oder die Implementierung einer Skriptfunktion auf der einen und das Skript auf der anderen. Einen Webservice oder Marshaling über Pipes kommt mir da suboptimal vor. Außerdem besteht mein Problem, wie hustbaer richtig erkannt hat, hauptsächlich in der möglichst automatischen Generierung der Interface-Definitionen in mehreren Sprachen. Das wird auch nicht leichter, wenn ich jetzt einen lokalen Webservice statt COM verwende. Über CORBA weiß ich leider nichts; wenn das mein Problem löst, könntest du mir mehr darüber sagen wie? hustbaer schrieb: Es läuft also darauf hinaus dass du die Interface-Definitionen 1x schreiben willst, und daraus dann die anderen nötigen Files generieren. Genau. Ich habe mit der oben beschriebenen Technik jetzt ein Projekt umgesetzt, das mittlerweile gut läuft, aber die parallele Wartung der Interfaces war a) nervig und b) eine lästige Fehlerquelle, die schon zahlreiche Stunden gekostet hat, z.B., weil das Marshaling manchmal unerwartetes Standardverhalten hat, oder weil ich eine Methode vergessen habe einzufügen. Unter Mono/Linux gab es noch lustigere Artefakte. (Mono/Windows habe ich aufgegeben, nachdem ich gemerkt hatte, daß Mono das Exception-Handling in C++ kaputtmacht, indem es einen kaputten SEH-Filter registriert.) Das würde ich mir in Zukunft gerne ersparen, und noch wichtiger: wenn jemand anderes an einem solchen Projekt arbeitet, der diese Fehler noch nicht gemacht hat, braucht er nicht auch nochmal auf die Nase fallen. hustbaer schrieb: Die Frage ist nur noch: in welchem Format schreibst du die Interface-Definitionen? Die "Pseudo-C# als Interfacedefinition" Variante würde mir nicht so gefallen, weil verwirrend. Die Pseudo-C# Klassen sehen dabei dann ja so aus als wären sie der verwendete Source-Code, sind es aber nicht. Hmmm... Ja, das stimmt. Der Vorteil wäre, daß ich sie in Visual Studio schreiben könnte, was sehr bequem ist, aber der Nachteil, wie du sagst, daß ich dann eine Pseudoassembly habe, die gar nicht zur Laufzeit benötigt wird. hustbaer schrieb: Ich würde mal gucken ob es fertige MIDL Parser (idealerweise in C#) gibt die du als Basis verwenden kannst. Hmjagut, nur ist IDL praktisch genau so verbose wie C++, vielleicht noch ein bißchen schlimmer hustbaer schrieb: Oder, andere Idee: Guck dir mal die von der MS Toolchain erzeugten COM-Interop-Assemblies an. Habe ich mal gemacht. Ich könnte ja, wie im Eingangspost skizziert, MIDL nehmen, um einen C++-Header und via TLBIMP eine Typbibliothek für .NET zu bekommen. Der Reflector sagt mir, daß solche Interop-Assemblies abhängigkeitsfrei ist; ich darf nur nicht die Compiler-Magic zum Erzeugen eines COM-Objekts verwenden, denn der Compiler generiert dafür einen Aufruf von Activator.CreateInstance() , und das wird von Mono nicht implementiert. Möglicherweise kann ich die also in Mono direkt verwenden. Die von MIDL erzeugten Header sind halt nicht so hübsch, u.a., weil ich auf die helper methods verzichten muß und die auch nicht mit einem einfachen Postprocessing-Schritt hinzufügen kann hustbaer schrieb: und weil C# keine Interface-Vererbung unterstützt, so daß man die Methoden des Basisinterfaces neudefinieren muß. Huch? Siehe z.B. hier und hier. In C# besagt "interface inheritance" lediglich, daß du von Interface IDerived zu Interface IBase casten kannst. In COM sagt "interface inheritance" darüber hinaus, daß die VMT von IDerived zuerst die Einträge von IBase , dann seine eigenen Einträge enthält, d.h. jede IDerived -Referenz ist auch ohne Typecast eine IBase -Referenz. Und zumindest in meinem Ansatz führte das dazu, daß ich in C# die Funktionen von IBase in IDerived wiederholen mußte, wenn ich ein kompatibles VMT-Layout bekommen wollte. Wenn das nicht so wäre, könnte ich ja auch den umgekehrten Weg gehen, also: eine Assembly voller Interfaces in C# als ComVisible definieren, irgendwie eine IDL rausziehen, mit MIDL einen C++-Header erstellen. Das wäre dann etwas bequemer, als selbst IDL zu schreiben. Aber so muß ich selbst Duplikate der geerbten Funktionen schreiben, um "interface inheritance" à la COM zu simulieren. Wenn ich aber eine C++-Typbibliothek nach .NET importiere, generiert TLBIMP diese Duplikate automatisch für mich. Danke jedenfalls für eure Beschäftigung mit dem Thema, das hat mir schon viel geholfen.
• ?

  Kennt hier noch einer die class CFrau?
  • Gast  

  3
  0
  Stimmen
  3
  Beiträge
  497
  Aufrufe

  ?

  class Brot : public virtual Supermarkt {
• ?

  Python: Frage zu &quot;float &gt; 0&quot; vs &quot;float &gt; 0.0&quot;
  • Gast  

  5
  0
  Stimmen
  5
  Beiträge
  1180
  Aufrufe

  ?

  Ok, also kein Feinheit die mir unbekannt ist. Mehr brauche ich nicht zu wissen, werde demnächst mal wieder "> 0" notieren und schauen ob sich der Fehler erneut einschleicht, dann melde ich zurück. Ansonsten verbuche ich das unter "hast vermutlich doch irgendwo seltsam geklammert o.ä" und nicht unter "Unbekannte Feinheiten". Danke!
• 

  Fehlerbehandlung bei Systemen mit asynchronen Benachrichtigungen
  • hustbaer  

  2
  0
  Stimmen
  2
  Beiträge
  373
  Aufrufe

  R

  wie waere es eine error handling funktion/callback einzubaeuen. dann kann die applikation selbst mit dem fehler umgehen. ansonsten bleibt dir nicht mehr als die applikation zu beenden, verschlucken sollte die lib die fehler nicht, da selbst wenn die app nicht haengt/abstuerzt, eventuell folgefehler entstehen die viele daten korrumpieren ohne dass der user es weiss. und auch beim entwickeln wuerde man nicht merken dass ein fehler stattfand.
• ?

  Web-App oder Native-App?
  • Gast  

  8
  0
  Stimmen
  8
  Beiträge
  997
  Aufrufe

  O

  Ansonsten: Client-Zertifikat
• N

  Wörter in einer MP3 Datei suchen
  • numbo  

  20
  0
  Stimmen
  20
  Beiträge
  2111
  Aufrufe

  ?

  Die Trollz im c++forum sind einfach die besten!
• ?

  regex um funktionsname + argumente zu bekommen
  • Gast  

  8
  0
  Stimmen
  8
  Beiträge
  988
  Aufrufe

  ?

  ^\s*\w+\((\s*(\w)\s*,?)\)\s$ Nur mal so hergemacht..:)
• L

  Library, Unity Builds oder Object files kombinieren
  • lyinch  

  5
  0
  Stimmen
  5
  Beiträge
  751
  Aufrufe

  C

  Dieser Thread wurde von Moderator/in SeppJ aus dem Forum C++ (auch C++0x und C++11) in das Forum Rund um die Programmierung verschoben. Im Zweifelsfall bitte auch folgende Hinweise beachten: C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage? Dieses Posting wurde automatisch erzeugt.