Saturday, August 29, 2015

Digest for comp.lang.c++@googlegroups.com - 25 updates in 7 topics

JiiPee <no@notvalid.com>: Aug 29 10:41AM +0100

In old C++ we used "new" to create memory. But now we have all
containers, vectors and smart pointers. So was just thinking is there
any situation where we would need to use new and we can not use vector
instead? I know saving a bit memory is one reason (because a vector
takes a bit more memory than a raw c pointer). But is there any other
reason. Because on a supermachine, like mine, it does not really matter
if a vector object takes couple of bytes more than a raw pointer as I
have 16 Gig memory....
 
If new only used in a small machines where memory is small?
JiiPee <no@notvalid.com>: Aug 29 12:40PM +0100

On 29/08/2015 12:37, Stefan Ram wrote:
> JiiPee <no@notvalid.com> writes:
>> any situation where we would need to use new and we can not use vector
> Yes. When we are implementing vector.
 
Why would you need to implement a vector? we already have std::vector....
bartekltg <bartekltg@gmail.com>: Aug 29 01:47PM +0200

On 29.08.2015 11:41, JiiPee wrote:
> containers, vectors and smart pointers. So was just thinking is there
> any situation where we would need to use new and we can not use vector
> instead?
 
Some time ago i was writing small matrix library. For fun.
Compiler have hard time with vectorization it, while
vectorization of raw arrays works.
Old openMP does not work with vectors and iterators.
 
Both problems should be solved now. But sometimes is just
more convenient, see below. Sometimes. I too use vector often.
Beside reallocation and freeing memory (whole RAII for free)
it also make a class deep coping.
 
> reason. Because on a supermachine, like mine, it does not really matter
> if a vector object takes couple of bytes more than a raw pointer as I
> have 16 Gig memory....
 
It depends how many small object do you have.
The problem is not that you have two size_t: capacity and size*),
but that vector can hold two times the memory you need.
resevre(n) allocata 'at least n'. shrint_to_fit is only a sugestion.
 
On small machines you also need to keep tract of size and capacity.
The only difference is that you can use a smaller type for it.
 
 
*) if you known exactly how big data is, use array<type, N>
 
BTW, i have 12GB and can't run kerbal without closing a couple
tabs in chrome. Maybe RAM isn't as rich resource as we use to think;-)
 
There isn't such think as too much RAM. I have access to
128GB machine. "Wow, I can run bigger lattice"... and RAM disappear.
 
bartekltg
JiiPee <no@notvalid.com>: Aug 29 01:15PM +0100

On 29/08/2015 12:47, bartekltg wrote:
> The problem is not that you have two size_t: capacity and size*),
> but that vector can hold two times the memory you need.
> 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. Then
we would not have this problem (allocating too much).
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?
JiiPee <no@notvalid.com>: Aug 29 02:24PM +0100

On 29/08/2015 12:47, bartekltg wrote:
> Compiler have hard time with vectorization it, while
> vectorization of raw arrays works.
> Old openMP does not work with vectors and iterators.
 
but can't you use std::valarray for that? it does not have capacity
"Öö Tiib" <ootiib@hot.ee>: Aug 29 07:37AM -0700

On Saturday, 29 August 2015 12:41:41 UTC+3, JiiPee wrote:
> if a vector object takes couple of bytes more than a raw pointer as I
> have 16 Gig memory....
 
> If new only used in a small machines where memory is small?
 
On really small and constrained computing devices we do not use
anything dynamic (neither 'new' nor 'vector'). We have our fixed
objects and fixed arrays that perfectly occupy most of the memory
of such device. So such devices are sort of red herring.
 
There are still cases where 'new' may be best thing to do because of
limitations of C++ language. As an example lets take case when we
need to have covariance of pointers to new objects. Covariance
quite often helps us to get rid of pointless and ugly downcasts so
it is neat feature.
 
Typical case of new object needed is polymorphic 'clone' with
covariant return. It has to return raw pointer (because of covariance)
to new object (because of clone) therefore we have to use manual
resource management here with 'new' (or with 'malloc' or with some
'alloCator.allocate') for to reserve the storage that such new object
occupies.
Bo Persson <bop@gmb.dk>: Aug 29 06:43PM +0200

On 2015-08-29 14:15, JiiPee wrote:
> 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 of the underlying system.
 
It might be impossible (or extremely inefficient) to allow capacity==1
or capacity==127. The current wording *allows* a vector to use 8 or 16
bytes as the minimum allocation.
 
If you do shrink_to_fit when size==127, you might really want the
vector<double> to keep 1024 bytes rather than fragment the heap with a
1016 byte block. That's why shrink_to_fit is a (strong) recommendation,
but not binding.
 
 
Bo Persson
BGB <cr88192@hotmail.com>: Aug 29 12:24AM -0500

On 8/28/2015 12:28 PM, Wouter van Ooijen wrote:
> 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 :(
 
getting into this mostly as a hobbyist, I noticed a few things.
 
moving from generic coding to performance-sensitive PC coding, one
starts to realize just how many clock-cycles are squirreled away in
non-productive "internal busywork".
 
 
in "generic" code, most of the cycles are basically moving from place to
place and convoluted logic trees to eventually get to where the "actual
work" gets done (IOW: actual work being the subset of statements that
are actually relevant to the end result).
 
this is things like invoking 3rd party libraries to do simple
operations, often doing overly low-level operations that each only
really accomplish very little work.
 
a lot of "typical" programmers take this sort of thing for granted, and
then end up thinking data-entry dealing with several hundred clients is
a "heavy workload" because it bogs down their Core i7 or Xeon based
database server...
 
 
meanwhile, someone who actually writes more efficient code, can
essentially do on the order of thousands to millions of times as much
work on the same basic hardware. how? by writing the code that does
whatever more directly, rather than going through mountains of 3rd party
code in the process (as strange of a concept as this is to some people...).
 
like, say, real-time rigid body physics in a game, involves just a
little bit more computational work than doing data-entry.
 
and things like real-time video processing are in-turn more demanding,
and no, it is not about "the GPU being a bazillion times faster than the
CPU".
 
things like video encoding and chroma-key and so on can be done in
real-time on the CPU in HD resolutions with little more than plain C or
C++ code without even necessarily resorting to SIMD intrinsics, much
less needed hand-crafted ASM. maybe one can use integer and fixed point
rather than using floating point for anything which may conceivably have
a decimal point in it...
 
 
moving from performance-oriented code in soft-real-time to firm or hard
real-time similarly mostly involves suddenly needing to deal with the
matter of much smaller timescales, as well as latencies and deadlines.
suddenly code just randomly going off into a rabbit hole for a few
milliseconds every so often is no longer quite so acceptable.
 
and going off to microcontrollers has the matter of needing to deal with
keeping code sizes and memory use small, otherwise it isn't going to fit.
 
 
but, it is worth noting that it isn't *that* drastic.
 
like, it is more about working with the limitations and being
conservative with resources, rather than thinking of everything in terms
of trying to find the biggest possible hammer to hit each nail.
 
 
or such...
Ian Collins <ian-news@hotmail.com>: Aug 29 05:49PM +1200

BGB wrote:
> work on the same basic hardware. how? by writing the code that does
> whatever more directly, rather than going through mountains of 3rd party
> code in the process (as strange of a concept as this is to some people...).
 
It's second nature to Java programmers!
 
--
Ian Collins
"Öö Tiib" <ootiib@hot.ee>: Aug 29 05:46AM -0700

On Friday, 28 August 2015 05:36:36 UTC+3, Richard Damon wrote:
 
> 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.
 
By C standard exception is undefined behavior. All what I ask for is
that C++ takes a clear position that such undefined behavior is not
allowed implicitly (as by default) to be passed to caller of
extern "C" function over supposedly C interface since there is
'noexcept' now in language.
 
> 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.
 
That is simpler since extern "fortran" is implementation-defined. So
implementation has to define what it does. I would only like that it
was *required* from implementations not to "forget" that exceptions
are part of interface.
 
> Then you run into the
> problem, what if you have a language that DOES naturally handle
> exceptions, maybe even an extern "C++".
 
Exceptions are part of interface for me on same level as calling
conventions. Exceptions can differ like calling conventions do
differ. So if C++ implemention declares that it can provide
extern "Ada" interface then I would expect either only Ada
exceptions from it or no exceptions at all.
 
I trust ABI designer can and does create differences there also
maliciously. For example on MSVC we have to '__except' SEH exceptions
and 'catch' C++ exceptions. In C# we can however 'catch' all three
as .net 'Exception'. SEH exception is 'SEHException', C++ exception is
'Win32Exception' and rest are visbasic exceptions.
 
To me such screw-ups leave impression that MS wants C++ developers
to choose other platforms like Linux, OS-X, Android, iOS,
Playstation or Wii for launching their products first and perhaps
when there are enough resources ... then also port it to MS
platforms later. C++ however isn't property of MS so it is not
required to be as screwed up as MS is.
BGB <cr88192@hotmail.com>: Aug 29 09:15AM -0500

On 8/29/2015 12:49 AM, Ian Collins wrote:
>> code in the process (as strange of a concept as this is to some
>> people...).
 
> It's second nature to Java programmers!
 
IME, Java programmers often tend to be more the sort to answer any sort
of coding challenge with "there is a library for that!" and/or proceed
to copy-paste some code fragments off the internet to do it. they tend
to be very adverse to actually writing any code themselves (and then
look down on and belittle anyone who does write their own code).
 
at least the general thinking in most other language communities is that
you use the language to actually write code in it.
Robert Wessel <robertwessel2@yahoo.com>: Aug 29 10:18AM -0500

On Sat, 29 Aug 2015 05:46:31 -0700 (PDT), 嘱 Tiib <ootiib@hot.ee>
wrote:
 
>when there are enough resources ... then also port it to MS
>platforms later. C++ however isn't property of MS so it is not
>required to be as screwed up as MS is.
 
 
I'm not sure I understand - C++ exception handlers are not supposed to
catch OS-type exceptions (such as an access violation). MS provides a
different method for that (SEH), *nix provides signals instead (which
don't quite do what SEH does, of course, but that's the mechanism).
"Öö Tiib" <ootiib@hot.ee>: Aug 29 09:36AM -0700

> catch OS-type exceptions (such as an access violation). MS provides a
> different method for that (SEH), *nix provides signals instead (which
> don't quite do what SEH does, of course, but that's the mechanism).
 
I try to elaborate bit more then. It is true (but is irrelevant and
orthogonal) that operating system raises certain SEH exceptions when it
detects issues like integer divide by zero or access violation.
 
Why it is irrelevant? Because SEH exception is not anyhow bound to
represent only OS level issues and faults. It is just an (alien to
C++ language) exception mechanism. SEH exception can be thrown with
operating system API function 'RaiseException':
https://msdn.microsoft.com/en-us/library/windows/desktop/ms680552%28v=vs.85%29.aspx
 
IMHO such alien exceptions should not fly in C++ by default. C++ exceptions
should not fly in other languages by default. C++ language specification
should be clear about it. Perhaps it can be made part of language how
to adjust translation mechanisms to/from alien exceptions at interface
border but I would hate '__try<"Ada">' garbage keywords all over the code
or the like. It is just pure ugliness for me ... YMMV.
Laszlo Lebrun <lazlo.lebrun@googlemail.com>: Aug 29 03:38PM

Hi experts here,
Sorry for my noob question:
I do need a middleware that reads a serial port (com xx), fetches some
measurement data out of a buffer, averages that data for a minute and
outputs the result to an internal windows virtual serial port using a
given protocol. (So an existing program from which I have no code,
believes to read original serial data from COMxx)
 
How tricky is that?
 
Does a library exist to simulate a serial COM port?
Is that accessible to a technically oriented noob within a few weeks?

 
 
--
Stand up against TTIP and ISDS !
Bo Persson <bop@gmb.dk>: Aug 29 11:05AM +0200

On 2015-08-27 23:31, jacobnavia wrote:
 
> How can I revert to the good old times?
 
> The compiler that compiled this is gcc-4.4.3, and still does.
 
> The new compiler however will not do that even if I specify -std=c++98
 
No, because the standard hasn't changed the rules for name lookup in
templates. It was this way already in C++98.
 
What happens is that newer compilers have improved their standards
compliance. There are generally no switches for putting old bugs back
into the compiler.
 
 
Bo Persson
"Öö Tiib" <ootiib@hot.ee>: Aug 29 06:32AM -0700

On Friday, 28 August 2015 01:04:56 UTC+3, jacobnavia wrote:
> > conform to the standard.
 
> Of course!
 
> How stupid from me. I just have to fix 344,356 lines of templated code...
 
WTF has happened to engineers these days? Don't you feel you lose
face by starting to whine sarcastically in public forum that there
is two days worth of engineering work to do. After you have fixed
the 20-30 conformance issues then it will likely also run on that
old non-conforming compiler. If you lack skill then we can help
just post clear questions.
 
Total rewrite of that amount of code can take 1-3 years of team
of 5 good specialists so it is anyway out of question.
jacobnavia <jacob@jacob.remcomp.fr>: Aug 29 04:42PM +0200

Le 29/08/2015 15:32, Öö Tiib a écrit :
> Don't you feel you lose
> face by starting to whine sarcastically in public forum that there
> is two days worth of engineering work to do
 
No. I just do not feel thatI "lose face" by asking a question, and no,
it is not 2-3 days of work.
 
The problem was already clear in 2010, when I last looked at that code.
 
But it couldn't be done because it involved several MONTHS of work
because of the opaque structure of the include files and also because it
wasn't clear that somebody knew, from the countless variations of
"GetNewPage()" for instance, which one should be used in which
instantiation of the templates.
 
5 years later not a single person of the original team is there.
 
Of course this forum is useless for asking this types of questions. I
know now that better.
 
I should not ask questions here then.
 
Thank you anyway.
Paavo Helde <myfirstname@osa.pri.ee>: Aug 29 10:09AM -0500

jacobnavia <jacob@jacob.remcomp.fr> wrote in news:mrsg8o$mrn$1@dont-
email.me:
 
 
> The problem was already clear in 2010, when I last looked at that code.
 
> But it couldn't be done because it involved several MONTHS of work
> because of the opaque structure of the include files and also because
it
> wasn't clear that somebody knew, from the countless variations of
> "GetNewPage()" for instance, which one should be used in which
> instantiation of the templates.
 
So what? Forward-declare all the overloads.
 
Or do you mean that there are different definitions of GetNewPage() in
different files with the same signature, violating the ODR rule? In this
case it appears that your codebase has much more problems than just
compilation problems, and fixing these issues is a good chance to
actually make the codebase better.
 
BTW, a comprehensive unit test suite is invaluable in such refactorings,
if you don't have one then you should consider creating one before
refactoring.
 
 
> Of course this forum is useless for asking this types of questions. I
> know now that better.
 
> I should not ask questions here then.
 
The only question you asked was "How can I revert to the good old
times?", and the obvious answer to that is: "Invent a time machine, and
when there, try to ignore all the problems in the past which you had
already forgotten meanwhile."
 
Cheers
Paavo
"Öö Tiib" <ootiib@hot.ee>: Aug 29 08:21AM -0700

On Saturday, 29 August 2015 17:42:20 UTC+3, jacobnavia wrote:
> > is two days worth of engineering work to do
 
> No. I just do not feel thatI "lose face" by asking a question, and no,
> it is not 2-3 days of work.
 
You did not ask a question, you did complain that non-conforming to
C++98 code that happened to compile on non-conforming compiler does
not compile on conforming compiler and so you have to do engineering
work. Good for you so far, you have work to do! You told us *nothing*
else. We aren't magicians, we are mere mortals here and we don't know
what your issue with us or your code-base is.
 
> wasn't clear that somebody knew, from the countless variations of
> "GetNewPage()" for instance, which one should be used in which
> instantiation of the templates.
 
Instrument each instantiation with trace that tells it, and process
the trace into csv file with a simple script. Then paste it to your
wiki table and *everybody* can see from your project wiki what
instantiation uses what 'GetNewPage'. Please estimate the effort
needed for described task to be done or list difficulties that make
it take more than 5 years.
 
 
> 5 years later not a single person of the original team is there.
 
No one's nerves can bear with such whiny panic for 5 years.
 
> Of course this forum is useless for asking this types of questions. I
> know now that better.
 
All forums are useless for that. Everywhere you will be said to
stop muttering and whining and ask advice like man.
ram@zedat.fu-berlin.de (Stefan Ram): Aug 29 11:37AM

>any situation where we would need to use new and we can not use vector
 
Yes. When we are implementing vector.
ram@zedat.fu-berlin.de (Stefan Ram): Aug 29 02:39PM

>IME, Java programmers often tend to be more the sort to answer any sort
>of coding challenge with "there is a library for that!" and/or proceed
 
15 years ago we had:
 
»A 100% Pure Java program is one that
depends only on the Java platform«
 
Guidelines for achieving the 100% Pure Java Standard,
Revision 4.0, Sun Microsystems, Inc., 2000
 
But no one talks about this anymore.
Nobody <nobody@nowhere.invalid>: Aug 29 01:22AM +0100

On Thu, 27 Aug 2015 12:24:59 -0700, Prroffessorr Fir Kenobi wrote:
 
> }
> like that
 
> are you sure this situation above do not generate such locks?
 
What code would be guarded by the lock in such a case?
 
Locks are only needed when the compiler has to generate code for the
initialisation (i.e. a constructor).
 
They shouldn't be needed for primitive types initialised from a constant,
or for plain "struct" types where the constructor just stores arguments in
fields (where the arguments are constants). In those cases, the compiler
can just store the variable's initial value in the data segment.
 
But if the compiler has to generate code to initialise the object (e.g.
because the value depends upon program state), it has to ensure that code
is only executed once even if two threads call the function concurrently.
 
> i used this swich and my app binary bloat went down 100KB from 350KB down
> to 250 KB *
 
> what dam could generate whole 100kB of bloat?
 
Linking in a library which wouldn't otherwise be required? Hard to say
without more detail.
Prroffessorr Fir Kenobi <profesor.fir@gmail.com>: Aug 29 01:12AM -0700

W dniu sobota, 29 sierpnia 2015 02:22:06 UTC+2 użytkownik Nobody napisał:
> or for plain "struct" types where the constructor just stores arguments in
> fields (where the arguments are constants). In those cases, the compiler
> can just store the variable's initial value in the data segment.
 
I thought so but asking to be a bit more sure (as sometimes weird things can go in play)
 
This code of my dont slows noticably as i got this guard quite outa loop
(its function is called 100 times per second only)(*) I also think that as its work out by this first initialization some bool or int flag
that is later only for read this flag then not need to be quarded (as all threads only read that), so this lock is only called once..
 
(*) but i also remember that i had such issue already about year ago
(it was putted n my psapi related code for asking system for consumed ram info - and there iirc it was also bloat and there noticable slowdown,
dont remember why as it was also only called 100fps only)
 
 
> > what dam could generate whole 100kB of bloat?
 
> Linking in a library which wouldn't otherwise be required? Hard to say
> without more detail.
 
hard to provide more details here..
what could i do copmare two exe smaller and biger by some binary diff? disasemble and compare for differences?
David Brown <david.brown@hesbynett.no>: Aug 29 12:34PM +0200

On 29/08/15 10:12, Prroffessorr Fir Kenobi wrote:
 
> hard to provide more details here.. what could i do copmare two exe
> smaller and biger by some binary diff? disasemble and compare for
> differences?
 
Generate map files and compare them. You should be able to see a list
of the libraries that are linked in, and the sizes they take in the
executable.
Richard Damon <Richard@Damon-Family.org>: Aug 28 09:48PM -0400

On 8/28/15 7:34 AM, Gerhard Wolf wrote:
> aüb
> -------------------------
> in Hex 0x61 0x3C 0xBC 62
 
Your basic issue is that a text file is not just a text file, but to
process it your program needs to know how the file is encoded.
 
In general, this isn't trivial, as there isn't always a standard that
tells you how a file is encoded.
 
Your first files appears to be encoded using a basic 8 bit character
set, which requires you to know which character set is being used (often
called the 'codepage'). In this case likely some varient of ISO/IEC 8859
 
The second appears to use a multibyte character set (and if the second
character is actually 0xC3, would appear to be UTF-8, i.e. Unicode).
 
The problem is that the second file could also be a valid file if
interpreted in the same codepage as the first! (with different
characters) IF it was 8859-1 for example the file would be aüb (if the
characters pass through usenet properly).
 
Ideally, something will tell you what the encoding of the file will be
(and some document formats will encode this in the file). If not, you
really need to figure it out, which is mostly guessing.
 
One 'trick' that is sometimes used if you really can't know ahead what
the encoding is would be to first see if the file is a valid UTF-8 file,
and if so assume it is. Due to the (intentional) redundancy built into
UTF-8, it is unlikely that a normal non-UTF-8 file will validate as
valid UTF-8, that one major exception being a file with no high bit
sets, but then detecting that as UTF-8 is just the assumption of
standard ASCII (there are some codepages which change the meaning of
some of the first 128 characters, but this is sort of unusual).
 
If it doesn't validate as UTF-8, you mostly will need to guess,
generally you will assume the codepage that is the default for your system.
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.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)