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.
|
