pustekuchen
Members-
Content Count
6 -
Joined
-
Last visited
Community Reputation
0 Neutral-
Thank you for fixing #1. When will the next version be released?
-
Hello we are actually formatting our whole codebase. GExpert seems to be the most viable solution for this task (Standalone Execution via command line is possible, still maintained and most options). After formatting our code, we found some cases, where the formatter fails or i would expect another result. https://sourceforge.net/p/gexperts/bugs/366/ https://sourceforge.net/p/gexperts/bugs/367/ https://sourceforge.net/p/gexperts/bugs/368/ 1. Multiple formatting of the same file leads to different results, if WrapLongLines (100 Lines) is actived Example unit Unit1; interface type TSampleClass = class(TObject) procedure thisisaverylongfunctionnametoshowaproblemwithlinewarpping_12345678910111213(); virtual; end; implementation end. Formatted once: procedure thisisaverylongfunctionnametoshowaproblemwithlinewarpping_12345678910111213(); virtual; Formattet twice procedure thisisaverylongfunctionnametoshowaproblemwithlinewarpping_12345678910111213(); virtual; I would expect the same result, if the file gets formatted multiple times. (Use Case: automatic calling the formatter before commiting files or calling in a pipeline job) 2. Missing indent for multiline comments Option: Indend Comments active TSampleClass = class(TObject) procedure functionx(); { this is multiline comment ---- ----- ---- --------------------------------- -- ------- ---------- ---- } procedure functiony(); //test end; Expected TSampleClass = class(TObject) procedure functionx(); { this is multiline comment ---- ----- ---- --------------------------------- -- ------- ---------- ---- } procedure functiony(); //test end; 3. Unessesarry line wraps are not removed WrapLongLines (100 chars) Input procedure TSampleClass.functionx; var test: string; begin test := 'this is just a very long string 12345678789012345' + 'this is another very long string for ' + 'example'; end; Output procedure TSampleClass.functionx; var test: string; begin test := 'this is just a very long string 12345678789012345' + 'this is another very long string for ' + 'example'; end; Expected (Indend + Remove uncessesary line wrap) procedure TSampleClass.functionx; var test: string; begin test := 'this is just a very long string 12345678789012345' + 'this is another very long string for ' + 'example'; end; For now we would not activate the "Wrap Long lines" option, because of this behavior. It would be nice, if this could be fixed.
-
Exception at win_mutex::lock in WebSocket++
pustekuchen replied to pustekuchen's topic in General Help
this problem was also solved with the fix in -
Problem was solved by simply call InitializePackage(GetModuleHandle('CPPPackage.bpl'));
-
Hello folks, at the moment i'm trying to create an delphi application which uses a C++-Package with some C++ Projects. Boost 1.79 openssl (master) Asio 1.18.2 websocketpp 0.8.2 The Problem is that exception appear while locking a mutex. Most times there is no problem. The destructor is called after running through do_dispatch where the mutex will be locked and unlocked. At some point after calling op->complete the mutex seems to be broken/uninitialized and the next lock will cause the exception. What could cause this behavior? A normal C++-Application with nearly the same code is working fine. I'm compiling with ASIO_STANDALONE, _WEBSOCKETPP_NO_CPP11_FUNCTIONAL_ (this is needed because the bcc32c have a problem with std::bind) with kind regards Marc
-
Hello all, for a project I use WebSocket++. There is a base64 encoding function base64_encode In this function, static std::string const base64_chars is accessed. For some reason base64_chars points to NULL, which should not be the case. The encoding then produces rubbish data, of course. I'm mixing Delphi and CPP here. I've used the example from David Millington and extended it ,to reproduce this case. In CPPClass.cpp is a static const std::string, which will not displayed in the message, after pressing the button. (Example is attached in this thread) Does anyone have an idea what this could be? Is it possibly a bug in bcc32c ? with kind regards Marc [Duplicate in german forum] uninitialized_globale_var_in_cpp_package.zip