Saturday, February 21, 2015

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

Marcel Mueller <news.5.maazl@spamgourmet.org>: Feb 21 08:20PM +0100

On 21.02.15 17.50, Öö Tiib wrote:
> stress-tested. Pretty much all C++ (and C) applications that have been
> stress-tested by semi-proficient quality engineer will recover
> reasonably.
 
I have never seen C++ code that is really safe with respect to memory
exceptions. Sometimes it might work, but as soon as there is even a
single allocation during stack unwinding it is likely to run into the
same problem again. The logging functionality usually already breaks
with this rule.
And as soon as a function with throw() is in the call stack that does
not handle the exception at all places, std::abort will terminate the
application. From the applications point of view this is undefined
behavior. From the language point of view of course not.
 
> Difficulties might be only when underlying platform is
> configured to behave in brain-damaged way like with that "Linux OOM
> Killer".
 
:-)
 
 
> So the application can be on worst case in situation where it can
> do nothing from that "almost everything". That appears to be plenty
> for to behave reasonably.
 
But how to continue in a useful way? When the expected functionality is
unsustainable without some free memory the application likely will no
longer work. Unless the stack unwinding happens to free a reasonable
amount of memory, everything else is just luck.
 
The C++ language is not well designed to provide guaranteed behavior
with respect to memory demand. It is simply not known how much memory is
required to operate properly. Software producers test the application
and add some safety factor for the system requirements.
 
There have been languages that do suffer from this. I remember OCCAM
that computes the required stack usage of any thread at compile time.
But many algorithms cannot be used in such an environment.
 
 
Marcel
"Öö Tiib" <ootiib@hot.ee>: Feb 21 12:16PM -0800

On Saturday, 21 February 2015 21:20:28 UTC+2, Marcel Mueller wrote:
> single allocation during stack unwinding it is likely to run into the
> same problem again. The logging functionality usually already breaks
> with this rule.
 
Perhaps we use different idioms. Most of the code that I have worked
with have majority of destructors empty and anything the non-empty
ones do may throw nothing. Fairly simple loggers can be written
totally bulletproof and throw nothing (even no 'std::bad_alloc's).
 
> not handle the exception at all places, std::abort will terminate the
> application. From the applications point of view this is undefined
> behavior. From the language point of view of course not.
 
There are some static analysis tools that check for possibility of
uncaught exceptions. Whole code base analysis is often slow so it is
better to run such things on separate computers.
 
> unsustainable without some free memory the application likely will no
> longer work. Unless the stack unwinding happens to free a reasonable
> amount of memory, everything else is just luck.
 
It depends if there are anything useful that the application can do
within given limits. For example if there are no enough memory for it to
read its configuration at start-up then it can still tell it as excuse
for not to start.

 
> There have been languages that do suffer from this. I remember OCCAM
> that computes the required stack usage of any thread at compile time.
> But many algorithms cannot be used in such an environment.
 
There can be some experimental narrow-purpose language that can
mathematically prove its maximum resource consumption. General purpose
programming language can not be designed to provide that on all cases.
Finding out limits and how application handles the problems is done by
stress-testing.
Paavo Helde <myfirstname@osa.pri.ee>: Feb 21 03:41PM -0600

Marcel Mueller <news.5.maazl@spamgourmet.org> wrote in news:mcalpi$dud$1
 
> On 21.02.15 17.50, 嘱 Tiib wrote:
>>> Well, pretty much any existing C++ application will never recover
from
> single allocation during stack unwinding it is likely to run into the
> same problem again. The logging functionality usually already breaks
> with this rule.
 
Running out of memory is pretty fatal, but it's more complicated than
that. Some large image/data processing programs may often allocate memory
blocks of hundreds of MB or even gigabytes. Statistically such
allocations have a greater chance to trigger out-of-memory conditions
than small allocations. If such a large allocation fails, then there is
still plenty of room to allocate any error and logger messages, no
problem here.
 
Rather, the problems appear because there is usually some swap/pagefile
configured. The OS typically pushes other programs and parts of the same
program to the swap and the system starts heavily trashing. Typically the
programs are not well tested when running in swap and start failing in a
random fashion. Even if they are not failing, the computer is pretty much
unusable anyway. Depending on the OS and running programs, a computer
restart might be the best option to come out of the trashing mode. I am
starting to think that turning the pagefile off completely might be the
best approach.
 
> not handle the exception at all places, std::abort will terminate the
> application. From the applications point of view this is undefined
> behavior. From the language point of view of course not.
 
That's why throw specifications is a deprecated antifeature. And
functions with an empty throw clause should not call anything non-
trivial, if they do there is a large problem between the keyboard and
chair.

> unsustainable without some free memory the application likely will no
> longer work. Unless the stack unwinding happens to free a reasonable
> amount of memory, everything else is just luck.
 
The memory is a global resource; if it is exhausted because some other
program tried to eat it all, then I think a good approach is to wait
silently in the OOM handler until the situation gets better, then retry
the allocation. Alternatively, if the program itself is the memory hog,
then it can probably release a lot of it by stack unwinding (in the
correct stack!), then report a failure.
 
 
> The C++ language is not well designed to provide guaranteed behavior
> with respect to memory demand. It is simply not known how much memory
is
 
> There have been languages that do suffer from this. I remember OCCAM
> that computes the required stack usage of any thread at compile time.
> But many algorithms cannot be used in such an environment.
 
Dynamic memory allocation can be handled relatively well in C++. Stack
overflow is a different beast altogether, there are no standard
mechanisms for dealing with that and most program(mer)s just ignore the
problem and hope they get lucky.
 
Cheers
Paavo
Ramine <ramine@1.1>: Feb 21 04:04PM -0800

Hello,
 
 
You have to understand me more, as you have noticed i have invented
and implemented many algorithms an libraries, and i have come to a
conclusion that i want to share with you, i have saw many programmers
on the C and C++ and Java newsgroups discussing programming , but i have
saw them also focusing more on how to factor the code using objects,
generics and/or Lambda expressions, and managing the complexity of the
code by using objects and generics and/or Lambda expressions , also i
saw them focusing on how to learn more how to respect the standards to
be able to render your code portable accross different systems, but i
think i have to be frank with you, beacause when i have invented and
implemented my parallel libraries and all my libraries , the most
difficult part that i have found is not learning how to use effectivly
objects , generics and/or lambda expressions and it's not using
effectivly the standards to make your code portable accross different
systems, but the most difficult part, and it's by experience that i am
telling so, is that you have to be "smart" to "invent" or to implement
or to design efficiently your projects, the most difficult part is that
you must be "smart", i mean if you are not smart enough , you will not
be able to invent new and interesting things in programming, and you
will not be able to render your code fast and good at the efficiency
criteria, this is why i must say that if you want to invent interesting
things or to render your code fast and efficient you have to call
"smart" programmers to do it, and i think that it's the most important
thing of programming. But if you are not a "smart" programmer, there is
still hope ! If you are not a "smart" programmer , what you can do is
focus on the criteria of "reusability" to make bigger and faster and
efficient programming constructs, and this my friends, "reusability", is
where programming shines ! so you will notice that if you want to invent
something like my StringTree or Winmenus or my Parallel libraries ,
average programmers will find that many of my projects are difficult, so
the best way to do is use those smart libraries like mine to make bigger
and faster and efficient constructs, and by applying more and more
"reusability" i don't think that you need to be a smart programmer to
succeed, so finally i can say that there is still hope !
 
You can download my projects from here:
 
 
https://sites.google.com/site/aminer68/
 
 
 
Thank you,
Amine Moulay Ramdane.
"Öö Tiib" <ootiib@hot.ee>: Feb 21 10:37AM -0800

On Saturday, 21 February 2015 20:24:03 UTC+2, JiiPee wrote:
 
> > /Flibble
 
> I read that Qt does not have anymore support properly as the old company
> who supported it stopped supporting it....
 
How so? If you buy professional or enterprise license then you get help
desk support from Digia. If you take open source license then you
get the support that random community member might bother to offer.
JiiPee <no@notvalid.com>: Feb 21 06:50PM

On 21/02/2015 18:27, Mr Flibble wrote:
> continually supported/updated.
 
> http://www.qt.io/
 
> /Flibble
 
Also, I understand that making release programs one must buy a licence.
So its not open source
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 21 06:52PM

On 21/02/2015 18:50, JiiPee wrote:
 
>> /Flibble
 
> Also, I understand that making release programs one must buy a licence.
> So its not open source
 
Yes it is open source; there are non-commercial licenses (LGPL, GPL) and
a commercial license.
 
/Flibble
JiiPee <no@notvalid.com>: Feb 21 06:55PM

On 21/02/2015 18:27, Mr Flibble wrote:
> continually supported/updated.
 
> http://www.qt.io/
 
> /Flibble
 
Ok, paying a licence is not a problem as they do work to keep it well.
But, if the licence is too expensive then poor people like me just
cannot afford it, simple as that.. so we are forced to look other
alternativities
JiiPee <no@notvalid.com>: Feb 21 06:58PM

On 21/02/2015 18:55, JiiPee wrote:
> But, if the licence is too expensive then poor people like me just
> cannot afford it, simple as that.. so we are forced to look other
> alternativities
 
to be exact... I can afford to pay about £50 licence fee only. If its
more than that I am not sure...and does not make sense to put more money
on that as there are free alternativities as well
 
But if its a very good program, then can pay, but not too much... people
who are rich can pay more maybe I know
"Öö Tiib" <ootiib@hot.ee>: Feb 21 11:00AM -0800

On Saturday, 21 February 2015 20:50:39 UTC+2, JiiPee wrote:
 
> > /Flibble
 
> Also, I understand that making release programs one must buy a licence.
> So its not open source
 
You are wrong on all three accounts.
1) You do not have to buy commercial license to make commercial software
with Qt.
2) Qt is distributed as open source.
3) There are no relation between usage license and form of distribution.
Melzzzzz <mel@zzzzz.com>: Feb 21 08:02PM +0100

On Sat, 21 Feb 2015 18:58:21 +0000
> money on that as there are free alternativities as well
 
> But if its a very good program, then can pay, but not too much...
> people who are rich can pay more maybe I know
 
You can use Qt for free and sell commercial application, I think.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 21 07:04PM

On 21/02/2015 19:00, Öö Tiib wrote:
> with Qt.
> 2) Qt is distributed as open source.
> 3) There are no relation between usage license and form of distribution.
 
Not quite true; with LGPL license you have to ship with Qt DLLs (you
can't statically link); I find this to be a pain in the arse.
 
/Flibble
Melzzzzz <mel@zzzzz.com>: Feb 21 08:06PM +0100

On Sat, 21 Feb 2015 19:04:43 +0000
> > distribution.
 
> Not quite true; with LGPL license you have to ship with Qt DLLs (you
> can't statically link); I find this to be a pain in the arse.
 
Either that or statically link, but provide object files ;)
 
JiiPee <no@notvalid.com>: Feb 21 07:10PM

On 21/02/2015 19:00, Öö Tiib wrote:
> You are wrong on all three accounts.
> 1) You do not have to buy commercial license to make commercial software
> with Qt.
 
I am not lying.... year ago when I was checking which one to use, I also
seriously checked Qt, and this licence/fees put me off from that
straight away. ok, posssible they have changed rules....
 
There was a reason why I did not even try Qt.. one was its future and
other one the licence.... maybe they changed things.
 
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Feb 21 07:10PM

On Sat, 21 Feb 2015 16:09:41 +0000
> Obviously programs come when I save my string to file using my
> std-based C++ classes I made. Well, need to convert I guess...
 
> But... why do books teach strings using char-type (non-unicode)?
 
The datum type and the encoding are orthogonal, except as part of
the encoding definition. UTF-8 uses 8 bit datum types as part of the
encoding definition, end of story. So you store it in char arrays of 8
bits per char, which may of course be a char array within a std::string
object. An individual unicode code point may occupy from 1 to 5 chars.
 
std::u16string and UTF-16 are similar. UTF-16 uses a 16 bit datum type.
However, the character length of a UTF-16 string is not the number of
16 bit units in the string. A unicode code point may be represented by
1 or 2 16-bit units.
 
Unicode is not reducible in the way you assume. A unicode code point
is not the same as a glyph, which is probably what you are interested
in. This is partly because of combining characters and partly because
some CJK glyphs cannot be resolved except by looking at what other code
points are associated with it.
 
In other words, you have the wrong mental image of how glyphs are
represented.
 
Chris
JiiPee <no@notvalid.com>: Feb 21 07:12PM

On 21/02/2015 19:02, Melzzzzz wrote:
 
>> But if its a very good program, then can pay, but not too much...
>> people who are rich can pay more maybe I know
> You can use Qt for free and sell commercial application, I think.
 
last time I checked online year ago, I understood selling softwares one
needs a licence.. or some kind of yearly fee or something. Reason I did
not even check more....year ago
"Öö Tiib" <ootiib@hot.ee>: Feb 21 11:15AM -0800

On Saturday, 21 February 2015 21:04:49 UTC+2, Mr Flibble wrote:
> > 3) There are no relation between usage license and form of distribution.
 
> Not quite true; with LGPL license you have to ship with Qt DLLs (you
> can't statically link); I find this to be a pain in the arse.
 
You can. Under LGPL you have to distribute your software in state where
the users can relink it with improved/fixed version of the LGPL-ed part
if they so want. You may not make changes in LGPL-ed part without
distributing those changes as open source. It is definitely easier with
dynamic linking but it is not mandatory.
Melzzzzz <mel@zzzzz.com>: Feb 21 08:15PM +0100

On Sat, 21 Feb 2015 19:12:40 +0000
 
> last time I checked online year ago, I understood selling softwares
> one needs a licence.. or some kind of yearly fee or something. Reason
> I did not even check more....year ago
 
Qt is now LGPL which allows selling close source. GPL allows also
selling but source code must be provided.
"Öö Tiib" <ootiib@hot.ee>: Feb 21 11:25AM -0800

On Saturday, 21 February 2015 21:10:27 UTC+2, JiiPee wrote:
 
> I am not lying.... year ago when I was checking which one to use, I also
> seriously checked Qt, and this licence/fees put me off from that
> straight away. ok, posssible they have changed rules....
 
I did not say you are lying. I said you are wrong. The Qt users have option
to choose LGPL license since 14 January 2009, version 4.5. 6 years have
passed meanwhile. It still does not mean you are lying, simply wrong.
 
> There was a reason why I did not even try Qt.. one was its future and
> other one the licence.... maybe they changed things.
 
The likely reason was that you misunderstood something or read some
wrong or outdated paper somewhere.
 
JiiPee <no@notvalid.com>: Feb 21 07:27PM

On 21/02/2015 19:25, Öö Tiib wrote:
>> other one the licence.... maybe they changed things.
> The likely reason was that you misunderstood something or read some
> wrong or outdated paper somewhere.
 
You want me to google again and find those things? :) .... seriously,
there was that kind of information.
Maybe somebody on forum or something said also "Qt s future is not
certain".
 
Ok, let me quickly try to google it again....
 
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 21 07:44PM

On 21/02/2015 19:15, Öö Tiib wrote:
> if they so want. You may not make changes in LGPL-ed part without
> distributing those changes as open source. It is definitely easier with
> dynamic linking but it is not mandatory.
 
With LGPL license if you statically link you are forced to distribute
your source code; I don't think you can get away with shipping .o files.
 
/Flibble
"Öö Tiib" <ootiib@hot.ee>: Feb 21 12:32PM -0800

On Saturday, 21 February 2015 21:44:49 UTC+2, Mr Flibble wrote:
> > dynamic linking but it is not mandatory.
 
> With LGPL license if you statically link you are forced to distribute
> your source code; I don't think you can get away with shipping .o files.
 
Wikipedia for example is thinking differently.
 
http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License
: Essentially, if it is a "work that uses the library", then it must
: be possible for the software to be linked with a newer version of
: the LGPL-covered program. The most commonly used method for doing
: so is to use "a suitable shared library mechanism for linking".
: Alternatively, a statically linked library is allowed if either
: source code or linkable object files are provided.
jt@toerring.de (Jens Thoms Toerring): Feb 21 08:45PM

> You can use Qt for free and sell commercial application, I think.
 
There are two licenses for Qt, one is a commercial license,
and the other is the LGPL. Under the LGPL you must distribute
your program in a way that allows the user (potentially the
buyer) to relink it with other versions of the library under
the LGPL. So, for example, if you use Qt version 4.x for
ypur program the user must hav th possibility to link it in-
stead against Qt version 5.y. The user may have good reasons
for that, e.g. because he wants to use bug fixes, new features
etc. This can be definitely a problem for a commercial program
since too many things may depend on properties of t version
4.x. But if your "crown jewels" aren't in the GUI of the pro-
gram but can be separated from it (as well-written programs
often allow), there's nothing that keeps you from putting
those "crown jewels" e.g. into a shared, closed source li-
brary (which doesn't make any use of Qt) and distribute the
GUI part as open source, allowing all kinds of modifications
to adapt it to use other versions of Qt. What you need is, of
course, a clean interface betwen the library that does the
interesting stuff and the GUI part.
 
Thus, if you distribute a program whose main appeal is
in eye candy then you need to pay for Qt to keep it secret
- which sounds reasonable to me since the Qt guys put lots
of work into making it simple for you to write it in a plat-
form-independent way. If, on the other hand, the important
part of your program isn't in the graphics domain, you're
free to keep that secret and only expose those parts that
are the graphical user interface for using it - and allow
users to fiddle with that part for their own amusement
(but they can't legally distribute the "core" library with
your "intellectual property" without which their modifica-
tions to the GUI are rather useless). On the other hand, if
someone comes up with a much better GUI than yourself and
distributes it, it may make your commercial library even
more interesting for potential customers who know that there
is a nice replacement for your less than stellar attemot at
cobbling together a GUI. Basically a win-win situation;-)
 
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 21 08:45PM

On 21/02/2015 20:32, Öö Tiib wrote:
> : so is to use "a suitable shared library mechanism for linking".
> : Alternatively, a statically linked library is allowed if either
> : source code or linkable object files are provided.
 
I hope that is correct; most of my code is open source and I would just
like to withhold a part of it.
 
/Flibble
Marcel Mueller <news.5.maazl@spamgourmet.org>: Feb 21 08:35PM +0100

On 11.02.15 22.54, DSF wrote:
> and access the return value through retval. I don't see the need to
> create a local retval at start and then copy it to the stack 'pointer
> to ret' before exit.
 
AFAIK the C++ standard required this.
 
 
> referenced by the FBaseString... to be placed in ESI. Other than
> that, the code was repeated at each return followed by a jump to the
> register POPs.
 
:-) So the CSE optimizer didn't catch it.
 
>> many problems.
 
> That's a given. Unlike char[] or char[30], char * is a pointer to a
> static string; no copying involved.
 
And it is error prone when the char* pointer is passed around. That the
reason for my statement.
 
Since I do no longer use non constant raw pointers in my C++ programs
access violation faults were almost finally gone. Only NULL dereference
remained from time to time.
 
 
Marcel
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)