Sunday, January 29, 2017

Digest for comp.lang.c++@googlegroups.com - 22 updates in 9 topics

"Öö Tiib" <ootiib@hot.ee>: Jan 29 11:32AM -0800

> > A lot of the original crew hasn't shown up as often or at all anymore
> > though.
 
> I miss James Kanze.
 
Times are changing. Good is suppressed and disappearing but weird is
winning and dominating. There are less people like James Kanze but lot of
jeff-relfs, ramines and rick-c-hodgins everywhere.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 29 10:43PM

> On Friday, January 27, 2017 at 2:43:48 PM UTC-6, Christopher J. Pisz wrote:
>> On 1/27/2017 5:14 AM, JiiPee wrote:
>> > This is one of the best newsgroup I have been. Also been learning many
...
>> A lot of the original crew hasn't shown up as often or at all anymore
>> though.
 
> I miss James Kanze.
 
Me too.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 29 10:48PM

On 29/01/2017 22:43, Jorgen Grahn wrote:
>>> though.
 
>> I miss James Kanze.
 
> Me too.
 
I also miss James Kanze even if he was an annoying cunt.
 
/Flibble
woodbrian77@gmail.com: Jan 29 01:38PM -0800


> But there should be support for appending a string_view to
> std::string. That seems to still be missing from gcc 7.0
> and clang 3.9.1. That's kind of frustrating.
 
I found support for this with gcc7 now. I had to use
-std=c++17 rather than the -std=c++1z that clang likes.
 
And I found a bug with my usage of string_view. I was passing
the results from it's "data" member function to a constructor
that takes a char const*. I knew that that function doesn't
guarantee to return a null terminated string, but forgot about
that.
 
This page says:
http://en.cppreference.com/w/cpp/experimental/basic_string_view/data
 
"Returns a pointer to the underlying character array. The pointer is such that the range [data(); data() + size()) is valid and the values in it correspond to the values of the view. (n.b. Unlike basic_string::data() and string literals, data() may return a pointer to a buffer that is not null-terminated. Therefore it is typically a mistake to pass data() to a routine that takes just a const CharT* and expects a null-terminated string.) "
 
One thing I would add to that is that is if you encounter this problem,
you might want to add a function that takes a string_view. If you
already have a string_view, then it's good to use that. That's what I did
in fixing the problem and it will help me avoid a few calls to strlen.
 
 
I've been looking at Clang and GCC's implementations of string_view.
 
This is from Clang 3.9.1:
 
private:
const value_type* __data;
size_type __size;
 
---------------------------
 
And this is from GCC 7.0
 
private:
// blah blah
size_t _M_len;
const _CharT* _M_str;
 
---------------------------
 
I think GCC's version is better in terms of the name _M_len
rather than __size.
 
It seems though that putting the pointer first might help
in terms of preventing some padding in the type if the pointer
is 8 bytes and the length member is 4. So maybe Clang's way
is better... I just wrote a little test program and the
size of string_view is 16 on both clang and gcc. But who
needs support for such long strings? Does the standard
require that? I could live with 4 billion as a limit for the
length of strings.



Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
David Brown <david.brown@hesbynett.no>: Jan 29 10:27PM +0100

On 28/01/17 00:22, Alf P. Steinbach wrote:
> Sausage here. Of course in a matter of life and death we'll help you,
> but not for something less. I guess four months or so of normal behavior
> would suffice to forgive (but not forget) your behavior.
 
I don't approve of Rick's religious posts any more than anyone else
here. And it is a perfectly reasonable attitude to withhold help to
people who don't follow the rules of a newsgroup, at least roughly.
 
But Rick did start this thread with a reasonable C++ question. His
religious posting was a follow up to Mr. Flibble's post - which was a
clear and deliberate troll post knowing /exactly/ the reaction he was
going to provoke.
 
I have no idea what it would take to stop Rick bursting into religious
posts. But I /do/ know that posts like Mr. Flibble's certainly do not help.
Jeff-Relf.Me <@.>: Jan 29 04:34AM -0800

deplorable owl <owl@rooftop.invalid>: Jan 29 07:38PM

> Why would I manually run _your "blah" and "offon"
> when _my "X.EXE" does it all, automatically ? to wit:
 
It's not about what program you run to process the data. It's about
keeping the data in a flexible and compact form. The form you use for
input data requires at least five times as much space as would simply
keeping a record of timestamps, and also requires that any other program
that might want to make use of your data has to go through unnecessary
contortions.

 
> as it _only shows "When I slept" and "%OffLine"; to wit:
 
> http://Jeff-Relf.Me/SleepPat.PNG
> http://Jeff-Relf.Me/SleepPat.HTM
 
 
It's cleaner, but you lose information for days when you
might have slept fewer than 7 hours.
Snit <usenet@gallopinginsanity.com>: Jan 29 01:38PM -0700

On 1/29/17, 12:38 PM, in article hgvnbmfk98g.k@rooftop.invalid, "deplorable
> keeping a record of timestamps, and also requires that any other program
> that might want to make use of your data has to go through unnecessary
> contortions.
 
But you can script it and take more steps... which is what I noted was bad
and then you twisted to say I do not think scripting things to avoid work
makes sense.
 
Now you are in the position I was... no reason for him to not do things in a
more direct and logical way, eh?
 
 
--
Personal attacks from those who troll show their own insecurity. They cannot
use reason to show the message to be wrong so they try to feel somehow
superior by attacking the messenger.
 
They cling to their attacks and ignore the message time and time again.
Jeff-Relf.Me <@.>: Jan 29 12:44PM -0800

"Öö Tiib" <ootiib@hot.ee>: Jan 29 11:52AM -0800

On Friday, 27 January 2017 23:37:50 UTC+2, Ian Collins wrote:
> > need it, and who cares about the copy? It's an exception, which should
> > occur exceptionally.
 
> Indeed. The cost of throwing far outweighs the cost of generating a string.
 
The difference of 'const char* what() const' of 'std::exception'
from 'string_view' is basically that it is required to end with character
zero.
 
It likely feels major difference only because of Parkinson's law of
triviality. ;)
Paul <pepstein5@gmail.com>: Jan 29 06:31AM -0800

The code below is intended to return the value of the first-occurring
unique character in a string, and to return the null character if no
characters are unique. This can be done quite simply with a vector of
length 256 because the number of chars is small. Imagine that the char type
is huge. Is the below code correct and efficient or is there something
a bit unpleasant about it?
 
Many thanks,
Paul
 
#include <iostream>
#include <list>
#include <string>
#include <unordered_map>
 
char findFirstUnique(const std::string& str)
{
std::unordered_map<char, std::list<char>::iterator> Map;
std::list<char> letters;
for(char letter : str)
if(Map.find(letter) == Map.end())
{
letters.push_back(letter);
Map[letter] = --letters.end();
}
else if(Map[letter] != letters.end())
{
letters.erase(Map[letter]);
Map[letter] = letters.end();
}

if(letters.empty())
{
std::cout << "All letters duplicated";
return 0;
}

return letters.front();

}
Daniel <danielaparker@gmail.com>: Jan 29 10:18AM -0800

On Sunday, January 29, 2017 at 9:31:35 AM UTC-5, Paul wrote:
> characters are unique. This can be done quite simply with a vector of
> length 256 because the number of chars is small. Imagine that the char type
> is huge. Is the below code correct and efficient
 
Using maps or sets for this is going to be less efficient than sequence
containers. Also, I think you should be more explicit about the empty string or
all duplicates case. An alternative might be
 
std::pair<char,bool> findFirstUnique(const std::string& str)
{
std::string s(str);
std::sort(s.begin(), s.end());
 
bool unique = true;
 
auto prev = s.begin();
auto it = s.begin();
 
if (s.begin() != s.end())
{
++it;
bool done = false;
while (!done && it != s.end())
{
if (*it == *prev)
{
++it;
}
else if ((it - prev) == 1)
{
done = true;
}
else
{
prev = it;
++it;
}
}
}
return ((it - prev) == 1) ? std::make_pair(*prev,true) : std::make_pair(0,false);
}
 
Note, however, that a function like this would be mostly useless today because
an std::string would be expected to contain UTF-8 sequences, so you should
probably modify it to return the first unique UTF-8 sequence.
 
Daniel
Paul <pepstein5@gmail.com>: Jan 29 10:40AM -0800

On Sunday, January 29, 2017 at 6:18:41 PM UTC, Daniel wrote:
> an std::string would be expected to contain UTF-8 sequences, so you should
> probably modify it to return the first unique UTF-8 sequence.
 
> Daniel
 
Thanks for your thoughts, Daniel.
I should have said this before, but the context for the
question is my attempt to learn about Data Structures and Algorithms
for the purpose of performing well in job interviews.
 
Rightly or wrongly, solutions are always frowned upon which have
suboptimal worst-case time complexity. Sorting the string would be
heavily criticised for providing an O(N * log N) algorithm instead of an
O(N) algorithm where N is the string length.
 
 
Paul
Paul <pepstein5@gmail.com>: Jan 29 10:52AM -0800

On Sunday, January 29, 2017 at 6:18:41 PM UTC, Daniel wrote:
> an std::string would be expected to contain UTF-8 sequences, so you should
> probably modify it to return the first unique UTF-8 sequence.
 
> Daniel
 
I don't think this solves the same problem that I solved.
I meant that the task is to find the unique character that occurs
earliest. For example f("character") == 'h' because the non-repeaters
are 'h', 'e' and 't', and 'h' occurs at an earlier point in the string
than the other non-repeaters.
 
Paul
Paavo Helde <myfirstname@osa.pri.ee>: Jan 29 09:04PM +0200

On 29.01.2017 20:18, Daniel wrote:
> }
> return ((it - prev) == 1) ? std::make_pair(*prev,true) : std::make_pair(0,false);
> }
 
This is finding the smallest unique character, not the first occurring
one as specified in the task description.
 
std::sort() is also O(N*log N) which is worse than the OP's O(N) using
hash map operations which have average constant complexity.
 
Cheers
Paavo
Daniel <danielaparker@gmail.com>: Jan 29 11:06AM -0800

On Sunday, January 29, 2017 at 1:52:29 PM UTC-5, Paul wrote:
 
> I don't think this solves the same problem that I solved.
 
You're right. I replied too quickly.
 
Daniel
Paavo Helde <myfirstname@osa.pri.ee>: Jan 29 09:15PM +0200

On 29.01.2017 16:31, Paul wrote:
> letters.erase(Map[letter]);
> Map[letter] = letters.end();
> }
 
These multiple map find and lookup operations could be replaced by a
single insert(). Not sure the optimizer is able to do this by itself.
 
> }
 
> return letters.front();
 
> }
 
The algorithm itself seems OK, as std::list iterators are not
invalidated when deleting or adding other elements to the list. This
might actually be one of the very few valid usage cases for std::list I
have ever seen.
 
About performance: the requirement 'char type is huge' basically says
that a solution with a lookup array is infeasible, so something like a
hash map seems to be needed indeed.
 
I have some suspicions about the std::list still. It is a very expensive
data structure, each node requires separate dynamic allocation which is
slow, plus the nodes are not guaranteed to be compact in the memory
which makes accessing it yet slower. I would get rid of the list and
just use a hash map which counts the occurrences of characters. This
would mean two passes: first count the occurrences, then in the second
pass find the first character with count 1. My gut feeling tells me this
would be faster than messing with a std::list, but YMMV.
 
Cheers
Paavo
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 29 03:47PM

abuse@glorb.com
 
/Flibble
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 29 05:29PM +0100

On 29.01.2017 16:47, Mr Flibble wrote:
> abuse@glorb.com
 
> /Flibble
 
I don't see his postings but I believe he's an old-time troll (if memory
serves). Whatever address he's posting from is one that let's him keep
on doing it. The best strategy may be to just silently killfile him.
 
Cheers!,
 
- Alf
alexo <alessandro.volturno@libero.it>: Jan 29 01:02PM +0100

Il 28/01/2017 21:40, Christiano ha scritto:
 
> }
 
> Reference:
> http://www.tldp.org/HOWTO/Bash-Prompt-HOWTO/c327.html
 
Too many "magic" numbers.
Thank you anyway,
 
this is the output compiled with Code::Block 16.01 - MingW compiler
under MS-Windows:
 
[2J
[0;0f
[0;31mH [0;32me [0;33ml [0;34ml [0;35mo [0;36m, [0;37m
[0;31mw [0;32mo [0;33mr [0;34ml [0;35md [0;36m. [0;37m. [0;31m. [0;32m
[10;30f:)...
 
Microsoft Visual Studio 17 RC doesn't evn compile it.
Paul <pepstein5@gmail.com>: Jan 28 05:08PM -0800

The code below is copied from a blog. Should the author have said
Guard(const Guard& other)=delete;
 
Does the const omission matter? I would have thought that the author's
code doesn't prevent copying. The version without the const is a different
function.
 
Paul
 
 
 
#include <iostream>
#include <thread>
 
class Guard
{
public:
Guard(std::thread& t)
: thread(t)
{ }

~Guard()
{
if (thread.joinable())
{
thread.join();
}
}

Guard(Guard& other)=delete;
Guard& operator=(const Guard& rhs)=delete;
 
private:
std::thread& thread;
};
 
void function()
{
std::cout << "I'm inside function." << std::endl;
}
 
int main()
{
std::thread t(function);
Guard guard(t);
 
return 0;
}
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 29 03:11AM +0100

On 29.01.2017 02:08, Paul wrote:
> Guard guard(t);
 
> return 0;
> }
 
In the formal there are four possible "copy" constructors: T(T&), T(T
const&), T(T volatile& ) and T(T const volatile&). Declaring any of them
prevents the automatic generation of a "copy constructor".
 
 
Cheers!,
 
- Alf
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)