- Is new-allocation needed anymore? - 11 Updates
- A "better" C++ - 9 Updates
- dealing with multi byte characters - 5 Updates
| JiiPee <no@notvalid.com>: Aug 31 12:59AM +0100 On 31/08/2015 00:25, Jens Thoms Toerring wrote: > vector). I'll have to see how I can use this newly acquired piece > of knowledge;-) > Regards, Jens " It would be different if one would be able to write directly to the vectors memory area and change it's size afterwards, but that's not allowed. " But dont you still have the problem that the vector will allocate possible two times more memory than you need because of the capacity? yes you can write to its memory I think, but you cannot really manage yourself the amount of memory the vector allocates, can you? |
| bartekltg <bartek@gmail.com>: Aug 31 02:21AM +0200 On 31.08.2015 01:59, JiiPee wrote: > " > But dont you still have the problem that the vector will allocate > possible two times more memory than you need because of the capacity? I have checked it and it is not that bad. If you insert data by series of 'push_back()' it may be two times too much. But if you resize to necessary size, or reserve enough space, vector use only so much memory (plus allocator data + alignment Bo Persson was talking, about). At least in a simple test in gcc 4.9.2. bartekltg |
| JiiPee <no@notvalid.com>: Aug 31 02:04AM +0100 On 31/08/2015 01:21, bartekltg wrote: > or reserve enough space, vector use only so much memory > (plus allocator data + alignment Bo Persson was talking, > about). At least in a simple test in gcc 4.9.2. oh, did not consider that. So without pushbacks it should allocate about the requested memory. But obviously one would like be sure that this is how the vector always works. The resize documentation does not mention anything about it really. |
| Paavo Helde <myfirstname@osa.pri.ee>: Aug 30 11:25PM -0500 > the requested memory. But obviously one would like be sure that this is > how the vector always works. The resize documentation does not mention > anything about it really. Oh come on guys, the compiler/STL writers are worried about the performance at least as much as you are (plus they actually know what they are doing). They will not go and preallocate reams of extra memory just because of fun or something. Cheers Paavo |
| Paavo Helde <myfirstname@osa.pri.ee>: Aug 30 11:55PM -0500 jt@toerring.de (Jens Thoms Toerring) wrote in > pointer only? Could be that I'm too squeamish and it's above > the board to do it that way. If it is it would make some > things quite a bit simpler;-) Since C++11 std::vector has non-const data() overload and std::string has the contiguous buffer guarantee. So both vector::data() and &str[0] are kosher now. In practice, &vec[0] and &str[0] have always been kosher (albeit a bit ugly and non-intuitive - I guess that's why non-const vector::data() was added). Cheers Paavo |
| woodbrian77@gmail.com: Aug 30 10:38PM -0700 On Sunday, August 30, 2015 at 5:58:51 PM UTC-5, Öö Tiib wrote: > I 'reset' smart pointer for same reasons why I 'clear' a container. > It has to be empty by program logic and so I 'reset' or 'clear' it. > I may need 'new' for some rare reasons like for covariance. This line auto request=::std::make_unique<cmw_request>(localbuf); results in a text segment that's 71 bytes bigger than this line auto request=::std::unique_ptr<cmw_request>(new cmw_request(localbuf)); using gcc 5.1.1 on Linux. I've taken that line from this program - http://webEbenezer.net/misc/cmwAmbassador.cc I compile the code with std=c++1y for the version with make_unique. For the other version I compile it with std=c++11. If I compile the version with new using std=c++1y, it's 88 bytes bigger than the version with make_unique. The version that uses new is attractive because it's small and doesn't require a C++2014 compiler. Brian Ebenezer Enterprises - In G-d we trust. http://breitbart.com |
| "Öö Tiib" <ootiib@hot.ee>: Aug 31 01:33AM -0700 > std=c++1y, it's 88 bytes bigger than the version with > make_unique. The version that uses new is attractive > because it's small and doesn't require a C++2014 compiler. You write that binary generated from stutter is longer with std=c++1y compiler ... yet you choose stutter? Odd choice. Maybe I misunderstand something but it seems like you are making it both less readable and less efficient? As for std=c++11 how you know that the difference with std=c++1y is anyhow related to that 'request' variable? In general if there is actually some quality of implementation issue and it matters and fix reduces readability (like stutter in your example) then I expect a comment in code that documents the reason, (but I can't see one in your example). My strong push towards readability is because I work with teams on code that has to stay maintainable years later. Other people may of course do whatever they want with their code. |
| bartekltg <bartekltg@gmail.com>: Aug 29 06:10PM +0200 On 29.08.2015 14:15, JiiPee wrote: >> resevre(n) allocata 'at least n'. shrint_to_fit is only a sugestion. > Ok so if we need a vector which behaves differently than std::vector. > I think std::vector should have an option to set capacity = size. And we have since c++11. It is shrink_to_fit I was talking about. but i may not work: " void shrink_to_fit(); 14 Remarks: shrink_to_fit is a non-binding request to reduce capacity() to size(). [ Note: The request is non-binding to allow latitude for implementation-specific optimizations. — end note ] " > A bit strange to create my own vector class just because the std version > allocates too much memory. the capacity functionality > should be maybe optional? why is it not? Because vectro should be ready for multiple 'push_back'. If you always keep only enough memory, vector <double> tab; for (int i=0;i<N;++) tab.pushback(sin(0.1*i)); will be quadratic. A standard solution for that is to allocate "too much" memory. Then it is linear. vector is a very good universal container. But sometimes a feature, needed 99% of times, is not optimal for you. > but can't you use std::valarray for that? it does not have capacity I can. It even may be better for compiler to optimize the code. bartekltg |
| bartekltg <bartekltg@gmail.com>: Aug 29 05:44PM +0200 On 29.08.2015 14:15, JiiPee wrote: >> resevre(n) allocata 'at least n'. shrint_to_fit is only a sugestion. > Ok so if we need a vector which behaves differently than std::vector. > I think std::vector should have an option to set capacity = size. And we have since c++11. It is shrink_to_fit I was talking about. but i may not work: " void shrink_to_fit(); 14 Remarks: shrink_to_fit is a non-binding request to reduce capacity() to size(). [ Note: The request is non-binding to allow latitude for implementation-specific optimizations. — end note ] " > A bit strange to create my own vector class just because the std version > allocates too much memory. the capacity functionality > should be maybe optional? why is it not? Because vectro should be ready for multiple 'push_back'. If you always keep only enough memory, vector <double> tab; for (int i=0;i<N;++) tab.pushback(sin(0.1*i)); will be quadratic. A standard solution for that is to allocate "too much" memory. Then it is linear. vector is a very good universal container. But sometimes a feature, needed 99% of times, is not optimal for you. > but can't you use std::valarray for that? it does not have capacity I can. It even may be better for compiler to optimize the code. bartekltg |
| bartekltg <bartekltg@gmail.com>: Aug 29 07:46PM +0200 Somebody see this post? This is a third try. On 29.08.2015 14:15, JiiPee wrote: >> resevre(n) allocata 'at least n'. shrint_to_fit is only a sugestion. > Ok so if we need a vector which behaves differently than std::vector. > I think std::vector should have an option to set capacity = size. And we have since c++11. It is shrink_to_fit I was talking about. but i may not work: " void shrink_to_fit(); 14 Remarks: shrink_to_fit is a non-binding request to reduce capacity() to size(). [ Note: The request is non-binding to allow latitude for implementation-specific optimizations. — end note ] " > A bit strange to create my own vector class just because the std version > allocates too much memory. the capacity functionality > should be maybe optional? why is it not? Because vector should be ready for multiple 'push_back'. If you always keep only enough memory, vector <double> tab; for (int i=0;i<N;++) tab.pushback(sin(0.1*i)); will be quadratic. A standard solution for that is to allocate "too much" memory. Then it is linear. vector is a very good universal container. But sometimes a feature, needed 99% of times, is not optimal for you. > but can't you use std::valarray for that? it does not have capacity I can. It even may be better for compiler to optimize the code. bartekltg |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 31 01:13PM +0100 On Mon, 31 Aug 2015 02:04:05 +0100 JiiPee <no@notvalid.com> wrote: [snip] > about the requested memory. But obviously one would like be sure that > this is how the vector always works. The resize documentation does > not mention anything about it really. std::vector::reserve() must allocate as much as requested (or throw) and can allocate more, but in practice it will do what you ask it subject to the requirements of alignment. A reasonable implementation is not going to do something stupid gratuitously. Of course, in the case that your most recent posts have been concerned with - using std::vector as a buffer for some other function such as read() to read into - you should really use std::vector::resize() rather than std::vector::reserve() so that the vector is correctly sized (std::vector::data() returns "a pointer such that [data(), data() + size()) is a valid range"), but that has the disadvantage that it acts like calloc(), namely that for built-in types it default-inserts elements into its memory with value initialization to 0. If avoiding any unnecessary zeroing operations on built-in types when constructing the buffer is wanted, then if all you want is a buffer where the size is not known at compile time but is known at run time (or you want the buffer to have a longer lifetime than block scope) it is perfectly fine to use std::unique_ptr with the new[] expression; and if you know the size of the buffer at compile time, you should use a C-style array or std::array where all you want is a plain buffer with block scope. On your more general question "is new-allocation needed anymore", it is also needed for placement new. Chris |
| Juha Nieminen <nospam@thanks.invalid>: Aug 31 07:14AM > I think a better way of approaching C++ is to use some > of the standard library facilities. For example, use a > vector rather than an array. Was he talking about static arrays or dynamic arrays (ie. those you create with new or malloc)? I wouldn't be surprised if the context was the question of whether it's better to use "raw" arrays (ie. allocated with new and through raw pointers) or a standard data container. --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Juha Nieminen <nospam@thanks.invalid>: Aug 31 07:18AM > You can't have it both ways. Of course you can. Why is it so hard to accept that one language may be faster in some things and another language in another thing? C++ is faster in generic code (qsort() vs. std::sort() being the quintessential example). And we don't even need some highly-twinkered artificial constructed example for this. The code for std::sort() doesn't need to resort to low-level trickery to achieve this speed. Those benchmarks where C is like 2% faster than C++ are almost invariably really artificial and, essentially, horrible low-level code that no sane person would use in an actual program. --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Juha Nieminen <nospam@thanks.invalid>: Aug 31 07:28AM > No. My C compiler system features garbage collection. Using Boehm's > software, you do not need to do anything "manually". How fitting, considering the title of the thread... Well, you can use your GC'd C variant if you want. I'll keep using C++, which is much simpler, cleaner and easier to use (and in many cases more efficient.) --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| jacobnavia <jacob@jacob.remcomp.fr>: Aug 31 11:17AM +0200 Le 31/08/2015 09:18, Juha Nieminen a écrit : >> You can't have it both ways. > Of course you can. Why is it so hard to accept that one language may be > faster in some things and another language in another thing? Then why is it so difficult for you to accept that C is faster? > C++ is faster in generic code (qsort() vs. std::sort() being the > quintessential example). This is because the C compilers haven't been taught to do the same that they do for C++. In principle a C compiler could also look into the called function of qsort and inline it if needed! Or you could modify the sognature of qsort so that you could pass it an inline function and expect it to expand the qsort algorithm specialized for this data type! Why this isn't done? And we don't even need some highly-twinkered > artificial constructed example for this. The code for std::sort() doesn't > need to resort to low-level trickery to achieve this speed. ??? You leave the trickery to the compiler. > Those benchmarks where C is like 2% faster than C++ are almost invariably > really artificial and, essentially, horrible low-level code that no sane > person would use in an actual program. No. They are written by people who care about performance. |
| jacobnavia <jacob@jacob.remcomp.fr>: Aug 31 11:19AM +0200 Le 31/08/2015 09:28, Juha Nieminen a écrit : > How fitting, considering the title of the thread... > Well, you can use your GC'd C variant if you want. I'll keep using C++, > which is much simpler, C++simpler than C. Of course! How did I miss that? :-) > cleaner Wow, C is "dirty" did you get that? and easier to use Sure (and in many cases more efficient.) Yes. You win. C++ is SIMPLER than C. OK |
| Ian Collins <ian-news@hotmail.com>: Aug 31 09:44PM +1200 jacobnavia wrote: > they do for C++. > In principle a C compiler could also look into the called function of > qsort and inline it if needed! How do you propose doing that for every C function where C++ would use a function template that has a void* or a function pointer as its parameter(s)? -- Ian Collins |
| jacobnavia <jacob@jacob.remcomp.fr>: Aug 31 11:53AM +0200 Le 31/08/2015 11:44, Ian Collins a écrit : > How do you propose doing that for every C function where C++ would use a > function template that has a void* or a function pointer as its > parameter(s)? If you have a function that accepts a function parameter and that parameter is an inline function, it is possible for the compiler, if the definition of the inline function is available (as it has to be) to expand the calls into that fnction and merge the resulting code into the bigger function code. This is just making the "inline" keyword more sophisticated, that is all. But the C committee is not going to go into that direction. So, C remains "slower". Many function templates can also be done with C macros, but surely not all of them. |
| Juha Nieminen <nospam@thanks.invalid>: Aug 31 11:40AM > C++ is SIMPLER than C. OK It indeed is. int main(int argc, char* argv[]) { std::vector<std::string> params(argv, argv + argc); std::sort(params.begin(), params.end()); std::string str; for(auto& p: params) str += p; std::cout << str << "\n"; } That's significantly simpler than what you have to do with C. (And no, I'm not talking about the *output* of the program. You can certainly make the program print the same thing with simpler code than the above. That's not the point. The point is that those operations are much more complicated to do in C than in C++. This example is just a demonstration of their use; the actual printed output is not the important point.) C is actually a very frustrating language. An acquaintance of mine went through a C course recently, and constantly asked for my help. It was really frustrating to have to deal with all those mallocs and frees (especially when reading strings of indeterminate length from a file into a complex data structure). Every single task he had to do would have been significanly easier in C++ (mainly, although not solely, because in C++ you can skip all those annoying mallocs and frees.) --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| jacobnavia <jacob@jacob.remcomp.fr>: Aug 31 01:49PM +0200 Le 31/08/2015 13:40, Juha Nieminen a écrit : > std::cout << str << "\n"; > } > That's significantly simpler than what you have to do with C. I posted this last week: Using the CCL (C containers library) we have: (from memory) #include <containers.h> int main(void) { strCollection *myData = strCollection.CreateFromFile("mydata.txt"); strCollection.Sort(myData); strCollection.WriteToFile(myData,"mySortedData.txt"); return 0; } The C containers library is written in C and features nice stuff. Fully open source (no license) available at: https://code.google.com/p/ccl/ In C you czan do exactly the same. > That's not the point. The point is that those operations are much more > complicated to do in C than in C++. This example is just a demonstration > of their use; the actual printed output is not the important point.) If you use containers in C you have the same abstraction level. > into a complex data structure). Every single task he had to do would > have been significanly easier in C++ (mainly, although not solely, > because in C++ you can skip all those annoying mallocs and frees.) In C you can do it too if you use the GC. |
| Gerhard Wolf <leawolf@gmx.de>: Aug 31 08:34AM +0200 > Use std::wstring and std::wfstream instead of std::string and > std::fstream and imbue your std::wfstream with the encoding used in the Thanks. Using std::w* was half the battle because it seems all the std::string functions (find, subst...), std::setw, ..setfill have no std::w* counterpart or im a wrong? So i have to convert to std::string? but how? std::string line = std::string(wline.begin(), wline.end()); does not work. |
| Gerhard Wolf <leawolf@gmx.de>: Aug 31 08:35AM +0200 > 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. Thanks. Using std::w* was half the battle because it seems all the std::string functions (find, subst...), std::setw, ..setfill have no std::w* counterpart!? So i have to convert to std::string? but how? std::string line = std::string(wline.begin(), wline.end()); does not work. |
| Gerhard Wolf <leawolf@gmx.de>: Aug 31 08:47AM +0200 Ok i created a 3rd and a 4th File. It contains both 'ü' variants in HEX: 61 FC 62 3C BC 62 and a File4 (FC-3CBC) flipped: 61 3C BC 62 FC 62 Windows Notepad (Sublime Text) opens: File1 displaying aüb (61 FC 62) File2 " aüb (61 C3 BC 62) File3 " aüb<¼b (61 FC 62 3C BC 62) File4 " a<¼büb (61 3C BC 62 FC 62) it seems these or all Win Applications (or MS libs) seems handle both variants correct if not mixed otherwise basic 8 bit character set is used. But that doesn't help solving my problem. |
| Ralf Goertz <me@myprovider.invalid>: Aug 31 09:59AM +0200 Am Mon, 31 Aug 2015 08:34:19 +0200 > it seems all the std::string functions (find, subst...), > std::setw, ..setfill have no std::w* counterpart or im a wrong? > So i have to convert to std::string? but how? No, you don't have to convert to std::string (and it wouldn't generally solve your problem as you can't fit *each* utf-8 encoded character into 8bit simultaneously). And yes, you can use find(), subst() etc. on wstring since it is merely a „typedef basic_string<wchar_t> wstring;" and these functions are defined with basic_string, eg.: http://www.cplusplus.com/reference/string/basic_string/find/ What you have to keep in mind is that you have to use the „L" specifier when using literals: std::wstring ws=L"Hello World"; Ralf |
| "Öö Tiib" <ootiib@hot.ee>: Aug 31 01:59AM -0700 On Monday, 31 August 2015 09:47:47 UTC+3, Gerhard Wolf wrote: > both variants correct if not mixed otherwise basic 8 bit character set > is used. > But that doesn't help solving my problem. MS Notepad is using pile of heuristics to detect the encoding of text in *.txt file. Sometimes the heuristics fail in notable way so even Wikipedia contains article about it: https://en.wikipedia.org/wiki/Bush_hid_the_facts Those heuristics are not a part of C++ for obvious reasons. |
| 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