Saturday, February 21, 2015

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

JiiPee <no@notvalid.com>: Feb 21 03:05PM

I am trying to learn how to use unicode string.. its not so easy really.
And difficult to find a guidelines how to do it. So still searching
(some say use UTF-8 , some UTF-16. but using UTF-8 in a code would make
life difficult as many functions like lenght would not work).
 
Everybody say that we should use unicode in our code. If so, then why
all turorials and C++ books use almost always char as a character type
(1 byte)? Why use examples which are not used in real world? This I do
not understand.
 
And even top C++ people like Bjorn does that.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 21 03:17PM

On 21/02/2015 15:05, JiiPee wrote:
> (1 byte)? Why use examples which are not used in real world? This I do
> not understand.
 
> And even top C++ people like Bjorn does that.
 
Do NOT use UTF-16 as it is useless (it is a variable length encoding
like UTF-8 so offers no advantage over UTF-8); instead use UTF-8 (the
best as most common text is Latin) or UTF-32.
 
/Flibble
JiiPee <no@notvalid.com>: Feb 21 04:09PM

On 21/02/2015 15:17, Mr Flibble wrote:
> like UTF-8 so offers no advantage over UTF-8); instead use UTF-8 (the
> best as most common text is Latin) or UTF-32.
 
> /Flibble
 
Yes like this maybe in non-Windows programming. But.... you know Windows
uses UTF-16 and here I am talking about Windows/MFC programming what I
do currently. Visual C++ recommends using UTF-16 for sure and its used
there so I guess its better to use it there. 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)?
JiiPee <no@notvalid.com>: Feb 21 04:10PM

On 21/02/2015 15:17, Mr Flibble wrote:
> like UTF-8 so offers no advantage over UTF-8); instead use UTF-8 (the
> best as most common text is Latin) or UTF-32.
 
> /Flibble
 
And thanks for starding disucussion.. I hope other come and join also as
we try to find the truth.
JiiPee <no@notvalid.com>: Feb 21 04:12PM

On 21/02/2015 15:17, Mr Flibble wrote:
> like UTF-8 so offers no advantage over UTF-8); instead use UTF-8 (the
> best as most common text is Latin) or UTF-32.
 
> /Flibble
 
But does std::string work perfectly with UTF-8? I understood its not
working with std-string functions... for example lenght does not give
correct value.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 21 04:30PM

On 21/02/2015 16:09, JiiPee wrote:
> 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)?
 
Don't use MFC as it is a complete and utter bag of ancient shite; use
something like Qt instead (although Qt also fucktardedly uses UTF-16).
 
/Flibble
JiiPee <no@notvalid.com>: Feb 21 04:35PM

On 21/02/2015 16:30, Mr Flibble wrote:
 
> Don't use MFC as it is a complete and utter bag of ancient shite; use
> something like Qt instead (although Qt also fucktardedly uses UTF-16).
 
> /Flibble
 
Oh, but I already learned MFC and no time really to study others... also
VC++ is now free, so its a good deal and VC++ IDE is really good.... I
am so used to MFC its difficult to change. I guess its a matter of taste
as well? some like mfc some dont. I wish it used std-libraries though
instead of their own.
JiiPee <no@notvalid.com>: Feb 21 04:39PM

On 21/02/2015 16:30, Mr Flibble wrote:
 
> Don't use MFC as it is a complete and utter bag of ancient shite; use
> something like Qt instead (although Qt also fucktardedly uses UTF-16).
 
> /Flibble
 
I was actually using wxWidgets last year, but now turned back to MFC as
they give VC++ now for free.... I cannot resist going back now :) .
 
MFC does the job for sure.. maybe not best but everything is there ,
isnt it?
Marcel Mueller <news.5.maazl@spamgourmet.org>: Feb 21 05:53PM +0100

On 21.02.15 17.12, JiiPee wrote:
> But does std::string work perfectly with UTF-8? I understood its not
> working with std-string functions... for example lenght does not give
> correct value.
 
Well, it depends on what you call the correct value.
Of course, it will not return the number of displayed characters. But
this is true for ASCII as well, if you include the control characters.
 
Unless you have a fixed width font there is no much use for the number
of displayed characters anyway.
On the other hand there are Unicode functions to determine the number of
visible characters. But be aware of pitfalls like invisible white space
(also used as BOM).
 
 
Marcel
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 21 05:33PM

On 21/02/2015 16:39, JiiPee wrote:
 
>> /Flibble
 
> I was actually using wxWidgets last year, but now turned back to MFC as
> they give VC++ now for free.... I cannot resist going back now :) .
 
wxWidgets is also shite as it is similar to MFC; you really should give
Qt a go as it is very good (and works with VC++).
 
/Flibble
Paavo Helde <myfirstname@osa.pri.ee>: Feb 21 11:33AM -0600


> I am trying to learn how to use unicode string.. its not so easy
really.
> And difficult to find a guidelines how to do it. So still searching
> (some say use UTF-8 , some UTF-16. but using UTF-8 in a code would make
> life difficult as many functions like lenght would not work).
 
For many programs, knowing the number of Unicode characters is not
important most of the time, so length() is all they need. Also note that
UTF-16 and UTF-8 are both packed formats, so length() works (or does not
work) exactly in the same way for both (albeit with UTF-16 any bugs will
probably remain hidden longer).
 
> (1 byte)? Why use examples which are not used in real world? This I do
> not understand.
 
> And even top C++ people like Bjorn does that.
 
This is because there is no standard or portable way how to do that.
Choosing the best suited text encoding format depends on the operating
systems, used libraries and frameworks, type of the program (deep text
processing or not?) and the nomenclature of locales/languages which need
to be supported. So there is no single correct answer.
 
For tutorials, the best text format is indeed ASCII, to avoid delving
into unneeded details. For tutorials, also "using namespace std;" is a
good idea. Production code will be different in many ways from tutorial
code.
 
HTH
Paavo
"Öö Tiib" <ootiib@hot.ee>: Feb 21 09:48AM -0800

On Saturday, 21 February 2015 17:05:49 UTC+2, JiiPee wrote:
> And difficult to find a guidelines how to do it. So still searching
> (some say use UTF-8 , some UTF-16. but using UTF-8 in a code would make
> life difficult as many functions like lenght would not work).
 
It is because it depends if your text editor and compiler understand and
support if you write code like:
 
char const banana[] = u8"🍌";
 
Even terrible to read code (that does same) is not supported by Visual
Studio 2013 like:
 
char const banana[] = u8"\U0001F34C";

https://msdn.microsoft.com/en-us/library/69ze775t.aspx
 
> all turorials and C++ books use almost always char as a character type
> (1 byte)? Why use examples which are not used in real world? This I do
> not understand.
 
You still should support Unicode, since it is the only sane way of doing
things. Unfortunately we often still have to rely on third party
libraries in practice (like ICU) for doing it because of the platform
vendors (like Microsoft).

> And even top C++ people like Bjorn does that.
 
Not sure, who is Bjorn?
JiiPee <no@notvalid.com>: Feb 21 06:06PM

On 21/02/2015 17:33, Paavo Helde wrote:
> systems, used libraries and frameworks, type of the program (deep text
> processing or not?) and the nomenclature of locales/languages which need
> to be supported. So there is no single correct answer.
 
ok, I get your point
 
JiiPee <no@notvalid.com>: Feb 21 06:23PM

On 21/02/2015 17:33, Mr Flibble wrote:
 
> wxWidgets is also shite as it is similar to MFC; you really should
> give Qt a go as it is very good (and works with VC++).
 
> /Flibble
 
I read that Qt does not have anymore support properly as the old company
who supported it stopped supporting it....
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 21 06:27PM

On 21/02/2015 18:23, JiiPee wrote:
 
>> /Flibble
 
> I read that Qt does not have anymore support properly as the old company
> who supported it stopped supporting it....
 
Wrong; Qt was sold to Digia which and is alive and well and continually
supported/updated.
 
http://www.qt.io/
 
/Flibble
MikeCopeland <mrc2323@cox.net>: Feb 20 10:13PM -0700

Is there a way to obtain an index value for an STL map? That is, if
I use myMap.find(some_key) and obtain the container object, is there a
way I can obtain a value from that iterator that allows me to (later)
use the myMap.at() function to re-obtain the data object?
Or, is there a way to calculate and store (in the object) the index
value I can use with myMap.at()?
My purpose here is that there are events where, after I've stored a
map object via the key, I want to reacquire the object where I don't
have access to the key: I've written another data object that doesn't
contain the original map key.
Thoughts? TIA
 
 
---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
Barry Schwarz <schwarzb@dqel.com>: Feb 21 12:03AM -0800

On Fri, 20 Feb 2015 22:13:05 -0700, MikeCopeland <mrc2323@cox.net>
wrote:
 
> Is there a way to obtain an index value for an STL map? That is, if
>I use myMap.find(some_key) and obtain the container object, is there a
 
.find() returns an iterator, not the mapped value or the container
object. If you preserve the iterator by either not reusing it or
assigning its value to another iterator, you can access the map
element any time you want.
 
>way I can obtain a value from that iterator that allows me to (later)
>use the myMap.at() function to re-obtain the data object?
 
Once you have the iterator, you can obtain the map key with it->first.
If you save the key, you can use it later in a call to .at(). Unless
you have inserted additional elements into the map, using the iterator
seems to be more efficient.
 
> Or, is there a way to calculate and store (in the object) the index
>value I can use with myMap.at()?
 
What object are you talking about.
 
>map object via the key, I want to reacquire the object where I don't
>have access to the key: I've written another data object that doesn't
>contain the original map key.
 
Keys are unique in a map. If you stored a value in a map using the
key, then save the value of the key for later use in retrieving the
value. Storing another value in the map with a different key will not
change the way you can access the original value. Storing a different
value with the same key destroys the first value. There is no way to
get it back.
 
--
Remove del for email
"Öö Tiib" <ootiib@hot.ee>: Feb 21 09:05AM -0800

On Saturday, 21 February 2015 07:13:28 UTC+2, MikeCopeland wrote:
> I use myMap.find(some_key) and obtain the container object, is there a
> way I can obtain a value from that iterator that allows me to (later)
> use the myMap.at() function to re-obtain the data object?
 
The iterators, pointers or references to elements of 'std::map' are quite
fine for storing for later usage. Neither inserts nor erases will
invalidate any iterators or references to 'std::map' elements unless
that element itself was not erased.
Note that it is not the case with 'boost::flat_map' that usually
outperforms 'std::map' but most inserts and erases invalidate its
iterators and references.
 
> map object via the key, I want to reacquire the object where I don't
> have access to the key: I've written another data object that doesn't
> contain the original map key.
 
Map *is* indexed by keys. If you do not have neither keys nor iterators
then you have insufficient data for to navigate in map.
"Norman J. Goldstein" <normvcr@telus.net>: Feb 21 09:56AM -0800

On 02/21/2015 09:05 AM, Öö Tiib wrote:
>> contain the original map key.
 
> Map *is* indexed by keys. If you do not have neither keys nor iterators
> then you have insufficient data for to navigate in map.
 
I haven't tested this, but the prototype is
 
mapped_type& at (const key_type& k);
 
so I would expect that the address of the return value never changes
(unless the mapped type is deleted and re-inserted). So, rather than
storing an "index", just store the address of the return value of at,
and no need to use "at" again.
"Öö Tiib" <ootiib@hot.ee>: Feb 21 10:16AM -0800

On Saturday, 21 February 2015 19:56:28 UTC+2, Norman J. Goldstein wrote:
> (unless the mapped type is deleted and re-inserted). So, rather than
> storing an "index", just store the address of the return value of at,
> and no need to use "at" again.
 
Yes but in that case storing 'K*' that points at key of element and
using it in 'std::map<K,V>::at' (that is O(log N) method) is clearly
wasteful compared to storing 'std::map<K,V>::iterator' or 'std::map<K,V>::pointer' to that element (that take commonly as
little memory) and to reach value with 'it->second' or 'p->second'.
Trying to access erased and inserted element that way is undefined
behavior in all described cases.
Christopher Pisz <nospam@notanaddress.com>: Feb 20 05:58PM -0600

On 2/20/2015 7:18 AM, Chris Vine wrote:
> pseudo-exception, which is of course what you want. (Boost, which
> implements interruption at the library level, will also unwind the
> stack.)
 
Can you explain what you mean by "blocking interruption/cancellation by
default." I don't understand.
 
I do understand the unwinding of the stack.
 
 
> by themselves, with windows native threads you have to resort to your
> kind of approach if you are not using boost. That may be where your
> background comes from.
 
I also don't understand "deferred cancellation." Can you explain or post
a link?
 
> platforms. This is also why C++11/14 does not provide for thread
> interruption, and probably never will.
 
> Chris
 
I also don't understand "paucity of interruption points."
I might be missing out on some good information here.
 
 
 
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
Robert Wessel <robertwessel2@yahoo.com>: Feb 21 01:30AM -0600

On Fri, 20 Feb 2015 17:58:47 -0600, Christopher Pisz
>> stack.)
 
>Can you explain what you mean by "blocking interruption/cancellation by
>default." I don't understand.
 
 
He just means spending most of the time in the thread with a
boost::this_thread::disable_interruption instance in scope, and only
enabling interuptions at specific points where you're willing to
handle one.
 
 
>> background comes from.
 
>I also don't understand "deferred cancellation." Can you explain or post
>a link?
 
 
Again, just having interruptions disabled most of the time. Then
it'll be held and will fire when the code in the thread enables them.
 
Which is roughly the same as what I said.
 
 
 
>> Chris
 
>I also don't understand "paucity of interruption points."
>I might be missing out on some good information here.
 
 
There are a rather limed number of points where boost::thread will
allow an interruption. For example, if you issue a fread(), that will
not be interrupted, since you're down in the bowels of the OS. The
boost:thread doc lists them:
 
http://www.boost.org/doc/libs/1_54_0/doc/html/thread/thread_management.html
"Öö Tiib" <ootiib@hot.ee>: Feb 21 08:50AM -0800

On Friday, 20 February 2015 23:46:49 UTC+2, Marcel Mueller wrote:
> > code should be exception safe anyway.
 
> Well, pretty much any existing C++ application will never recover from
> an allocation error in a reasonably way.
 
What you are saying is that majority of applications have never been
stress-tested. Pretty much all C++ (and C) applications that have been
stress-tested by semi-proficient quality engineer will recover
reasonably. Difficulties might be only when underlying platform is
configured to behave in brain-damaged way like with that "Linux OOM
Killer".
 
> Simply because almost everything requires some successful memory
> allocations. Even if only for allocation of the std::string with
> the error message.
 
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.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Feb 21 05:24PM

On Fri, 20 Feb 2015 17:58:47 -0600
Christopher Pisz <nospam@notanaddress.com> wrote:
[snip]
> I also don't understand "deferred cancellation." Can you explain or
> post a link?
 
Robert Wessel has answered most of your questions. My reference to
deferred cancellation was in relation to POSIX threads, because boost
thread interruption is always deferred. In addition, both boost and
POSIX threads have the concept of interruption/cancellation being at
any time either enabled or disabled (blocked) for a particular thread.
 
With POSIX threads, cancellation can either be asynchronous or deferred.
With asynchronous cancellation, the thread will be cancelled
approximately immediately (for whatever the implementation defines as
"immediately") and should never be used. It is of historic interest
only. Deferred cancellation only takes effect when the thread of
execution to be cancelled meets a cancellation point (aka in boost an
interruption point), and is the default with pthreads. Either form of
cancellation can be blocked by the thread concerned setting its
cancellation state to disabled, which is equivalent in boost to having a
boost::this_thread::disable_interruption object in scope. A blocked
interruption/cancellation event is not lost, unless one is already
pending. It is stored until the moment (if at all) when cancellation is
enabled and (for deferred cancellation) a cancellation point is
subsequently reached.
 
The combination of deferred cancellation and blocking enables a thread
to control the point in the code at which it is willing to accept a
cancellation event and die, and to do so in a controlled way.
 
Native windows threads do not have deferred cancellation (or at least,
didn't when I last looked at them), so while in windows cancellation is
available it is unusable in reliable code (that is, it can only be
used at program shutdown).
 
> I also don't understand "paucity of interruption points."
> I might be missing out on some good information here.
 
The only boost interruption points are in effect waiting on a
condition variable, waiting on a join, waiting on a sleep or testing
for a pending interruption event with
boost::this_thread::interruption_point(). In particular, a boost
interruption event will not cause blocking system calls to unblock.
This is the more-or-less inevitable result of providing a portable
library solution, as opposed to a system level solution.
 
Chris
Melzzzzz <mel@zzzzz.com>: Feb 21 06:34PM +0100

On Sat, 21 Feb 2015 08:50:29 -0800 (PST)
> reasonably. Difficulties might be only when underlying platform is
> configured to behave in brain-damaged way like with that "Linux OOM
> Killer".
 
Problem is that memory allocators (especially GC) tend to reserve huge
amount of RAM, (not to mention forks) therefore overcommit and OOM
killer....
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)