- dealing with multi byte characters - 3 Updates
- A "better" C++ - 4 Updates
- tdm gcc 5.1 slower than 4.7 - 2 Updates
- A small quiz - 1 Update
- static guard locks - 1 Update
- Big problem with templates - 1 Update
| Gerhard Wolf <leawolf@gmx.de>: Aug 28 01:34PM +0200 Hi, im stuck with handling multibyte characters in text-files. For example files with german umlauts. ----- File1 3 Bytes ----- aüb ------------------------- in Hex 0x61 0xFC 0x62 ----- File2 4 Bytes ----- aüb ------------------------- in Hex 0x61 0x3C 0xBC 62 this causes many nasty problems whe using std::*find* std::setfill std::setw ... in my actual case i have c++ code that should convert a csv file into a column fixed format. Therefor i have to determine the max width of earch filed then write the fields using std::setw and std::setfill. The Result of my example code would be 02 003 how can i get solve this problem? Are there any std:: or boost libs. Hopefully the only solution is NOT Search/Replace of all multibyte characters! Also i did not find any useful resources on that topic in the net. Got any? ----------sample code--------------------------------------------------- #include <iostream> #include <fstream> #include <string> #include <iomanip> int _tmain(int argc, _TCHAR* argv[]) { std::ifstream in1,in2; in1.open("file1"); in2.open("file2"); std::string tmp,tmp2; std::getline(in1,tmp); size_t pos = tmp.find("b"); std::cout << std::setw(pos) << std::setfill('0') << pos << std::endl; std::getline(in2,tmp); pos = tmp.find("b"); std::cout << std::setw(pos) << std::setfill('0') << pos << std::endl; return 0; } |
| Ralf Goertz <me@myprovider.invalid>: Aug 28 03:12PM +0200 Am Fri, 28 Aug 2015 13:34:26 +0200 > in Hex 0x61 0x3C 0xBC 62 > this causes many nasty problems whe using std::*find* std::setfill > std::setw ... … > how can i get solve this problem? Are there any std:: or boost libs. > Hopefully the only solution is NOT Search/Replace of all multibyte > characters! Use std::wstring and std::wfstream instead of std::string and std::fstream and imbue your std::wfstream with the encoding used in the input file. Ralf |
| "Lőrinczy Zsigmond" <nospam@for.me>: Aug 28 08:15PM +0200 On 2015.08.28. 13:34, Gerhard Wolf wrote: > aüb > ------------------------- > in Hex 0x61 0x3C 0xBC 62 that is C3 BC most likely -- the utf8 code of 'Ü' I'd suggest iconv -- its purpose is converting between codes |
| Richard Damon <Richard@Damon-Family.org>: Aug 27 10:36PM -0400 On 8/26/15 1:40 PM, Öö Tiib wrote: > Function pointers of usual C++ and extern "C" functions are not > compatible. It is common extension that these are compatible > but C++ does not guarantee it. The issue is that the standard doesn't guarantee it, but neither does it prohibit it. There is nothing inherent about a C interface that says that exceptions can't propagate over the interface. The other big issue would be that extern "C" is just a special case of a whole family of declaration (yes, the only one with a specific definition, but others are allowed as implementation defined behavior), and if you define that extern "C" functions have a different default than normal functions, then by the same manner should that extend to other linkages, after all, if C doesn't understand exceptions, then probably extern "fortran" shouldn't either. Then you run into the problem, what if you have a language that DOES naturally handle exceptions, maybe even an extern "C++". |
| Paavo Helde <myfirstname@osa.pri.ee>: Aug 28 12:02AM -0500 Richard Damon <Richard@Damon-Family.org> wrote in > understand exceptions, then probably extern "fortran" shouldn't > either. Then you run into the problem, what if you have a language > that DOES naturally handle exceptions, maybe even an extern "C++". extern "abi" has been proposed, as a way to define portable C++ ABI (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4028.pdf). This should most definitely support exception pass-through. |
| BGB <cr88192@hotmail.com>: Aug 28 10:49AM -0500 On 8/27/2015 8:38 AM, Wouter van Ooijen wrote: >> and it beats them ALL in terms of performance. > True, but not relevant. By that reasoning plain binary (or better yet: > nand gates and solder!) beats everything. I will partly disagree on the point that logic gate ICs tend to work out as more expensive than using cheap MCUs for non-trivial logic, which may still support higher internal clock speeds. while a few gate chips may be a little cheaper, more are needed, vs the MCU which can typically run pretty much all the logic (then one might hook it up with external analog or power-components). there is a gray area of transistor "logic" where generally a lot of 2N3904's or similar are used, such as to convert a small digital signal into something that can signal some bigger transistors. >> really something that is convincing. You worked *hard* to get results >> that you get for free in C++ and I find the gain (in your examples) a > I think you mean C I mostly still use C, and am using MCUs roughly between the two examples of small MCUs given (epic 2kB of ROM and 256B of RAM). I went the small one-off program route. because, you know, a few hundred lines, who cares. but, for example: can't really copy-paste in the driver program I had used on a bigger controller (which supported more motor types and could use sense feedback to control motor frequency), as there is basically no way it would fit on this MCU. here is a (slightly outdated now): http://pastebin.com/ftg01XWG (I have since made changes, such as adding support for a VF curve rather than using a constant duty-cycle). though, my logic tends to run the things full speed and full-power, as how I am using them I don't generally care if they use a little more power, since the power they use is pretty much tiny vs the electronics they are driving. granted, a way to shave power-use off of some AC 3Ph induction motors would be a little more useful. these things use a bit more power than an MCU (even the transistor driver, where the bridge circuits tend to use a lot more power just in leakage current). like, 0.4mA for the MCU going at full power, is a lot less than 60mA being leaked by the motor driver, is a lot less than 10 or 30 amps to run the motor... (more so when one considers the significant voltage differences between the MCU's 3.3V rail, and a 48VDC - 55VDC rail used to power the motor). a lot of this stuff is at fairly low voltages, vs the 208VAC or 440VAC used by "real" 3-phase induction motors, but this stuff requires high voltage components (600V or 1400V), as well as posing a lot more safety risks. > 'mainstream' use of C++. The advantages of my approach are in composable > library elements, which is very difficult to (effectively) do in C, and > easy but inefficient in 'mainstream' C++. yeah. doing much embedded or real-time programming does somewhat point out how these are not really the same thing as writing code for a PC (or phone). annoying sometimes is needing to explain to people that, no, their smartphone is not representative of a typical embedded microcontroller, and in-fact even an old crappy feature-phone generally may as well be a super-computer in comparison... |
| Wouter van Ooijen <wouter@voti.nl>: Aug 28 07:28PM +0200 > smartphone is not representative of a typical embedded microcontroller, > and in-fact even an old crappy feature-phone generally may as well be a > super-computer in comparison... Agreed. On the school were I teach (lecture?) PC and smart Phone applications belong to the Informatics department, because in most cases you can programn them without paying much attention to their limitations. Small systems, and the realy critical parts of 'big' systems (device drivers, kernels, etc) belong to the Technical Informatics department. But that was last year. Now they have decided that we want to be a broad department, so the distinction will start to blurr :( Wouter |
| Prroffessorr Fir Kenobi <profesor.fir@gmail.com>: Aug 28 12:16AM -0700 W dniu czwartek, 27 sierpnia 2015 23:02:26 UTC+2 użytkownik Prroffessorr Fir Kenobi napisał: > > Andy > c:\mingw\bin\g++ -std=c++98 -O2 -c -w test7.c -fno-rtti -fno-exceptions -fno-threadsafe-statics -march=core2 -mtune=generic -mfpmath=both -msse2 > (-std=c++98 was used to check if it would be maybe speed up but not a difference) ps check up yet a disasembly genereted (probably this is the source of slowdown, though i was not yet read in this as im no to much crafted here) I moved recently from tdm gcc 4.7 onto tdm gcc 5.1 (by renaming compiler folders, not even char of source or build scripts was changed) and it showed my test mandelbrot sse rutine app slowed down from 20 ms per frame till nearli 24 ms per frame why is that? this is asm from disasembly (im presently to tired to read and compare it) 4.7 .p2align 4,,15 .globl __Z16mandelbrot_n_sseU8__vectorfS_i .def __Z16mandelbrot_n_sseU8__vectorfS_i; .scl 2; .type 32; .endef __Z16mandelbrot_n_sseU8__vectorfS_i: pushl %ebp movl %esp, %ebp andl $-16, %esp subl $16, %esp movl 8(%ebp), %ecx movaps %xmm0, (%esp) testl %ecx, %ecx js L12 xorps %xmm0, %xmm0 xorl %eax, %eax movaps %xmm0, %xmm2 movaps %xmm0, %xmm4 jmp L11 .p2align 4,,7 L19: mulps %xmm4, %xmm2 addl $1, %eax subps %xmm5, %xmm6 movaps (%esp), %xmm4 cmpl %eax, %ecx addps %xmm6, %xmm4 addps %xmm2, %xmm2 addps %xmm1, %xmm2 jl L10 L11: movaps %xmm4, %xmm6 movaps %xmm2, %xmm5 movaps LC5, %xmm7 mulps %xmm4, %xmm6 mulps %xmm2, %xmm5 movaps %xmm6, %xmm3 addps %xmm5, %xmm3 cmpltps LC4, %xmm3 andps %xmm3, %xmm7 movmskps %xmm3, %edx testl %edx, %edx addps %xmm7, %xmm0 jne L19 L10: cvtps2dq %xmm0, %xmm0 leave ret L12: xorps %xmm0, %xmm0 jmp L10 .globl __Z16mandelbrot_n_sseDv4_fS_i .def __Z16mandelbrot_n_sseDv4_fS_i; .scl 2; .type 32; .endef .set __Z16mandelbrot_n_sseDv4_fS_i,__Z16mandelbrot_n_sseU8__vectorfS_i 5.1 LHOTB8: .p2align 4,,15 .globl __Z16mandelbrot_n_sseDv4_fS_i .def __Z16mandelbrot_n_sseDv4_fS_i; .scl 2; .type 32; .endef __Z16mandelbrot_n_sseDv4_fS_i: pushl %ebp movl %esp, %ebp andl $-16, %esp subl $16, %esp movl 8(%ebp), %ecx movaps %xmm0, (%esp) testl %ecx, %ecx js L11 pxor %xmm0, %xmm0 xorl %edx, %edx movaps %xmm0, %xmm5 movaps %xmm0, %xmm2 jmp L10 .p2align 4,,10 L18: mulps %xmm2, %xmm5 addl $1, %edx subps %xmm6, %xmm4 cmpl %edx, %ecx addps %xmm5, %xmm5 addps (%esp), %xmm4 addps %xmm1, %xmm5 jl L9 movaps %xmm4, %xmm2 L10: movaps %xmm2, %xmm4 movaps %xmm5, %xmm6 movaps LC7, %xmm7 mulps %xmm2, %xmm4 mulps %xmm5, %xmm6 movaps %xmm4, %xmm3 addps %xmm6, %xmm3 cmpltps LC6, %xmm3 andps %xmm3, %xmm7 movmskps %xmm3, %eax testl %eax, %eax addps %xmm7, %xmm0 jne L18 L9: cvtps2dq %xmm0, %xmm0 leave ret L11: pxor %xmm0, %xmm0 jmp L9 .section .text.unlikely,"x" LCOLDE8: .text LHOTE8: .globl __Z16mandelbrot_n_sseU8__vectorfS_i .def __Z16mandelbrot_n_sseU8__vectorfS_i; .scl 2; .type 32; .endef .set __Z16mandelbrot_n_sseU8__vectorfS_i,__Z16mandelbrot_n_sseDv4_fS_i .section .rdata,"dr" |
| Prroffessorr Fir Kenobi <profesor.fir@gmail.com>: Aug 28 08:19AM -0700 W dniu piątek, 28 sierpnia 2015 09:16:43 UTC+2 użytkownik Prroffessorr Fir Kenobi napisał: > .def __Z16mandelbrot_n_sseU8__vectorfS_i; .scl 2; .type 32; .endef > .set __Z16mandelbrot_n_sseU8__vectorfS_i,__Z16mandelbrot_n_sseDv4_fS_i > .section .rdata,"dr" seems its very nearly the same only some slight changes like order, and different variable is pushed to ram seems like this 5.1 version is unlucky to get worse |
| Luca Risolia <luca.risolia@linux-projects.org>: Aug 28 03:21PM +0200 On 27/08/2015 05:28, Stefan Ram wrote: > definition of f, and it's not about style but just about > straight errors. > decltype(auto)f(){int v=2;return(v);} decltype(v) != decltype ((v)) the former is int (as "v" is a name), while the latter is int& (as "(v)" is an expression where v is an lvalue) |
| Prroffessorr Fir Kenobi <profesor.fir@gmail.com>: Aug 28 12:02AM -0700 W dniu czwartek, 27 sierpnia 2015 23:33:42 UTC+2 użytkownik Paavo Helde napisał: > What is protected is the initialization of the static. I guess depending > on the implementation this may or may not mean a mutex lock on each > entry. i checked some article https://monoinfinito.wordpress.com/2013/12/03/static-initialization-in-c/ and here in the asm example there is showed that some bool check is done if this is already initialized this probably means that it is called only once with entry when static is not yet initialised (probably, as i still dont fully understand it, do some things like struct X {int x; int y; int z; int w;}; foo() { static X x = {1,2,3,4}; } initialized at compile time or on first entry point to function thus guarded too? > program rans faster when compiled with -fno-threadsafe-statics? > About bloat: you must be using lots of statics. Time to start getting rid > of them, statics are evil even if multithreading is not involved. i got many ststics but the simple ones, not sure but they probably do not make guards and probably few that make querds - i think the 100KB bloat comes form another reason than "50 bytes of so" x "number of guards" |
| Paavo Helde <myfirstname@osa.pri.ee>: Aug 28 12:20AM -0500 jacobnavia <jacob@jacob.remcomp.fr> wrote in news:mro1ei$khj$1@dont- email.me: >> conform to the standard. > Of course! > How stupid from me. I just have to fix 344,356 lines of templated code... I was going through the same process at some timepoint in our codebase. This involved deleting some unused templates and adding forward declarations for a bunch of functions. The trickier part was to inject 'typename' and 'template' in the correct places, IIRC. Anyway, this did not take more than half of a day, no big deal. YMMV, of course. Cheers Paavo |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment