Friday, April 20, 2018

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

Jeff-Relf.Me @.: Apr 20 12:57PM -0700

Sergio <invalid@invalid.com>: Apr 20 03:30PM -0500

> wrote a little (JavaScript) browser extension called "Discord";
> it's IRC on steroids; popular on Reddit; gamers love it too;
> and, get this, it's only worth 1.65$ billion... losers ! !
 
js on a pdp-11 boat anchor
Lofty Goat <rlwatkins@gmail.com>: Apr 20 04:45PM -0500

On Fri, 20 Apr 2018 12:57:49 -0700 (Seattle), Jeff-Relf.Me wrote:
 
> wrote a little (JavaScript) browser extension called "Discord"; it's
> IRC on steroids; popular on Reddit; gamers love it too; and, get this,
> it's only worth 1.65$ billion... losers ! !
 
Jeff, do you post to science groups because you want people to pity you?
 
--
Goat
benj <benj@nobody.net>: Apr 20 06:33PM -0400

On 4/20/2018 5:45 PM, Lofty Goat wrote:
>> IRC on steroids; popular on Reddit; gamers love it too; and, get this,
>> it's only worth 1.65$ billion... losers ! !
 
> Jeff, do you post to science groups because you want people to pity you?
 
I'm pretty sure it's working!
"Jouko Koski" <joukokoskispam101@netti.fi>: Apr 20 07:43PM +0300

What is your preferred method for tackling the lavishly long identifiers
that seem to dominate C++ code?
 
C++ does not have packages or modules. Identifiers are visible in the
header files so that one has to be very careful with namespace aliases
and using directives.
 
After spending a while with old cut and dry C code some C++ code like
 
std::function<void(boost::asio::ip::tcp::socket&&)> server;
 
or
 
socket.async_write_some(boost::asio::buffer(output.buf + output.len, n),
[ptr](boost::system::error_code const& ec, std::size_t n) {
 
feels rather hard to read.
 
--
Jouko
Marcel Mueller <news.5.maazl@spamgourmet.org>: Apr 20 06:54PM +0200

On 20.04.18 18.43, Jouko Koski wrote:
> What is your preferred method for tackling the lavishly long identifiers
> that seem to dominate C++ code?
 
using namespace ...
 
> C++ does not have packages or modules. Identifiers are visible in the
> header files so that one has to be very careful with namespace aliases
> and using directives.
 
At the top level scope: yes.
In nested scopes this is no real problem.
 
 
> socket.async_write_some(boost::asio::buffer(output.buf + output.len, n),
> [ptr](boost::system::error_code const& ec, std::size_t n) {
 
> feels rather hard to read.
 
Feel free to write smarter code. ;-)
 
 
Marcel
"Jouko Koski" <joukokoskispam101@netti.fi>: Apr 20 10:41PM +0300

"Marcel Mueller" wrote:
 
>> What is your preferred method for tackling the lavishly long identifiers
>> that seem to dominate C++ code?
 
> using namespace ...
 
Can you give some example, because:
 
>> and using directives.
 
> At the top level scope: yes.
> In nested scopes this is no real problem.
 
So, everything I write shall go to some dedicated namespace where I do
"using" for all the things I need? Then all the users of my code will
get them too. Ok, but then I apparently can to do yet another nesting
level and do "using" only for my own identifiers to pull them to the
outer level for everyone else. Is that the solution?
 
>> [ptr](boost::system::error_code const& ec, std::size_t n) {
 
>> feels rather hard to read.
 
> Feel free to write smarter code. ;-)
 
I would be glad to. Can you recommend any specific language?
 
--
Jouko
Ian Collins <ian-news@hotmail.com>: Apr 21 07:47AM +1200

On 04/21/2018 07:41 AM, Jouko Koski wrote:
>>> that seem to dominate C++ code?
 
>> using namespace ...
 
> Can you give some example, because:
 
For you later example,
 
namespace tcp = boost::asio::ip::tcp;
 
std::function<void(tcp::socket&&)> server;
 
Would help.
 
boost::asio is a pathological case for nested namespaces!
 
--
Ian.
drew@furrfu.invalid (Drew Lawson): Apr 20 08:53PM

In article <%MoCC.1004$9K9.630@uutiset.elisa.fi>
 
>socket.async_write_some(boost::asio::buffer(output.buf + output.len, n),
>[ptr](boost::system::error_code const& ec, std::size_t n) {
 
>feels rather hard to read.
 
While I tend to agree, using boost examples is pretty unfair. The
boost camp has an insane love of deeply nested namespaces. Not
much of the code I deal with goes deeper than:
 
namespace::class::routine_or_type
 
I find the syntax unpleasant to read, but the benefits outweigh that.
 
--
Drew Lawson | I told them we had learned to change
| our swordblades into plows.
| I told them they should learn from us
| what should I tell them now?
janis.taranda@gmail.com: Apr 20 12:14PM -0700

First
 
```
odb -I /usr/include/x86_64-linux-gnu/qt5 -x -fPIE -d sqlite -p qt --trace --generate-query models/storeoauth2client.hstarting plugin odb
In file included from /usr/lib/odb/i686-linux-gnu/include/c++/4.9.3/type_traits:35:0,
from /usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:45,
from /usr/include/x86_64-linux-gnu/qt5/QtCore/qchar.h:43,
from /usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:48,
from /usr/include/x86_64-linux-gnu/qt5/QtCore/QString:1,
from /usr/local/include/odb/qt/basic/sqlite/default-mapping.hxx:8,
from <odb-prologue-2>:1:
/usr/lib/odb/i686-linux-gnu/include/c++/4.9.3/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support for the \
```
 
And when I add --std c++11 flag it's millions of errors, staring:
 
```
odb --std c++11 -I /usr/include/x86_64-linux-gnu/qt5 -x -fPIE -d sqlite -p qt --trace --generate-query models/storeoauth2client.hstarting plugin odb
In file included from /usr/lib/odb/i686-linux-gnu/include/c++/4.9.3/cwchar:44:0,
from /usr/lib/odb/i686-linux-gnu/include/c++/4.9.3/bits/postypes.h:40,
from /usr/lib/odb/i686-linux-gnu/include/c++/4.9.3/bits/char_traits.h:40,
from /usr/lib/odb/i686-linux-gnu/include/c++/4.9.3/string:40,
from /usr/lib/odb/i686-linux-gnu/include/c++/4.9.3/random:40,
from /usr/lib/odb/i686-linux-gnu/include/c++/4.9.3/bits/stl_algo.h:66,
from /usr/lib/odb/i686-linux-gnu/include/c++/4.9.3/algorithm:62,
from /usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:109,
from /usr/include/x86_64-linux-gnu/qt5/QtCore/qchar.h:43,
from /usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:48,
from /usr/include/x86_64-linux-gnu/qt5/QtCore/QString:1,
from /usr/local/include/odb/qt/basic/sqlite/default-mapping.hxx:8,
from <odb-prologue-2>:1:
/usr/lib/odb/i686-linux-gnu/lib/gcc/i686-linux-gnu/4.9.3/include-fixed/wchar.h:93:3: error: conflicting declaration 'typedef struct __mbstate_t __mbstate_t'
} __mbstate_t;
^
In file included from /usr/include/_G_config.h:17:0,
from /usr/include/libio.h:31,
from /usr/include/stdio.h:41,
from /usr/lib/odb/i686-linux-gnu/lib/gcc/i686-linux-gnu/4.9.3/include-fixed/wchar.h:46,
from /usr/lib/odb/i686-linux-gnu/include/c++/4.9.3/cwchar:44,
from /usr/lib/odb/i686-linux-gnu/include/c++/4.9.3/bits/postypes.h:40,
from /usr/lib/odb/i686-linux-gnu/include/c++/4.9.3/bits/char_traits.h:40,
from /usr/lib/odb/i686-linux-gnu/include/c++/4.9.3/string:40,
from /usr/lib/odb/i686-linux-gnu/include/c++/4.9.3/random:40,
from /usr/lib/odb/i686-linux-gnu/include/c++/4.9.3/bits/stl_algo.h:66,
from /usr/lib/odb/i686-linux-gnu/include/c++/4.9.3/algorithm:62,
from /usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:109,
from /usr/include/x86_64-linux-gnu/qt5/QtCore/qchar.h:43,
from /usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:48,
from /usr/include/x86_64-linux-gnu/qt5/QtCore/QString:1,
from /usr/local/include/odb/qt/basic/sqlite/default-mapping.hxx:8,
from <odb-prologue-2>:1:
/usr/include/bits/types/__mbstate_t.h:21:3: note: previous declaration as 'typedef struct __mbstate_t __mbstate_t'
} __mbstate_t;
^
In file included from /usr/lib/odb/i686-linux-gnu/include/c++/4.9.3/cwchar:44:0,
from /usr/lib/odb/i686-linux-gnu/include/c++/4.9.3/bits/postypes.h:40,
from /usr/lib/odb/i686-linux-gnu/include/c++/4.9.3/bits/char_traits.h:40,
from /usr/lib/odb/i686-linux-gnu/include/c++/4.9.3/string:40,
from /usr/lib/odb/i686-linux-gnu/include/c++/4.9.3/random:40,
from /usr/lib/odb/i686-linux-gnu/include/c++/4.9.3/bits/stl_algo.h:66,
from /usr/lib/odb/i686-linux-gnu/include/c++/4.9.3/algorithm:62,
from /usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:109,
from /usr/include/x86_64-linux-gnu/qt5/QtCore/qchar.h:43,
from /usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:48,
from /usr/include/x86_64-linux-gnu/qt5/QtCore/QString:1,
from /usr/local/include/odb/qt/basic/sqlite/default-mapping.hxx:8,
from <odb-prologue-2>:1:
/usr/lib/odb/i686-linux-gnu/lib/gcc/i686-linux-gnu/4.9.3/include-fixed/wchar.h:102:1: error: '__BEGIN_NAMESPACE_C99' does not name a type
__BEGIN_NAMESPACE_C99
^
/usr/lib/odb/i686-linux-gnu/lib/gcc/i686-linux-gnu/4.9.3/include-fixed/wchar.h:105:1: error: '__END_NAMESPACE_C99' does not name a type
__END_NAMESPACE_C99
^
```
Maybe you see the problem right away?
Ian Collins <ian-news@hotmail.com>: Apr 21 07:35AM +1200

> /usr/lib/odb/i686-linux-gnu/include/c++/4.9.3/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
> #error This file requires compiler and library support for the \
> ```
 
Why are you using an old compiler?
 
--
Ian
janis.taranda@gmail.com: Apr 20 12:41PM -0700

piektdiena, 2018. gada 20. aprīlis 22:35:18 UTC+3, Ian Collins rakstīja:
 
> Why are you using an old compiler?
 
> --
> Ian
 
Please tell me more about it. Why old? What's new? Im not advanced c++ dev.
Ian Collins <ian-news@hotmail.com>: Apr 21 07:55AM +1200

>>> ```
 
>> Why are you using an old compiler?
 
> Please tell me more about it. Why old? What's new? Im not advanced c++ dev.
 
It looks like odb bundles gcc 4.9.3, so my comment wasn't helpful...
 
The errors you posted could be down to a conflict of system and gcc
headers, which system are you using?
 
--
Ian.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 20 12:47PM

On Thu, 2018-04-19, Tim Rentsch wrote:
>> about it.
 
> What about the phrase "crossing too many levels of detail" leads
> you to think it might be bad grammar?
 
*shrug* It felt like mixing metaphors, but I'm not sure. Sorry for
bringing it up -- my point was really that I found it very
illuminating.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
woodbrian77@gmail.com: Apr 20 10:42AM -0700

On Friday, April 20, 2018 at 7:47:16 AM UTC-5, Jorgen Grahn wrote:
 
> *shrug* It felt like mixing metaphors, but I'm not sure. Sorry for
> bringing it up -- my point was really that I found it very
> illuminating.
 
"Covering too many levels of detail" might be simpler.
 
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
Ian Collins <ian-news@hotmail.com>: Apr 21 07:30AM +1200

>> bringing it up -- my point was really that I found it very
>> illuminating.
 
> "Covering too many levels of detail" might be simpler.
 
But it doesn't convey the same message. It is the swapping back and
forth between levels of detail that is the heart of the problem.
 
Tim's phrase hits the nail squarely on the head.
 
--
Ian.
boltar@cylonHQ.com: Apr 20 09:04AM

On Wed, 18 Apr 2018 17:50:30 +0200
 
>As work around you can go the other way around and use std::string as
>allocator, i.e. malloc replacement, and modify the storage afterwards.
>AFAIK there is no undefined behavior in this pattern.
 
You mean directly modify the memory pointed to by std::string::c_str()?
No no, thats a very bad idea as I found out myself a few years back. Most of
the time it worked, but occasionally it didn't and created obscure bugs.
Sometimes you learn the hard way :)
 
>If you intend to deal with string /constants/ then C++17's string_view
>come into play (as already mentioned).
 
I've only just got up to speed with c++11, I don't have the time or the will to
keep playing catch-up with whatever the standards committee are throwing into
the kitchen sink this year, especially given that in the large companies I work
in the C++ compilers are only rarely updated anyway.
"Öö Tiib" <ootiib@hot.ee>: Apr 20 03:27AM -0700

> No no, thats a very bad idea as I found out myself a few years back. Most of
> the time it worked, but occasionally it didn't and created obscure bugs.
> Sometimes you learn the hard way :)
 
It is getting old how the "Snowflakes" generation always misinterprets
whatever others say in worst possible way, then build ugly straw man
arguments out of that misinterpretation and then argue against the
utter nonsense that they themselves just manufactured.
 
If you need to convert std::basic_string<CharT> to mutable CharT pointer
then use &str[0]. It returns pointer to mutable data unless str was
const (then you should not edit it anyway) and unless str.size() was
0 (then editing that null character pointed at there is obviously undefined
behavior). That idiom is apparently older than members of your generation
and so there is no wonder that you don't know about it. :D
boltar@cylonHQ.com: Apr 20 11:00AM

On Fri, 20 Apr 2018 03:27:34 -0700 (PDT)
>utter nonsense that they themselves just manufactured.
 
>If you need to convert std::basic_string<CharT> to mutable CharT pointer
>then use &str[0]. It returns pointer to mutable data unless str was
 
And this ugly hack is guaranteed to work for every implemetation of std::string
is it?
 
>0 (then editing that null character pointed at there is obviously undefined
>behavior). That idiom is apparently older than members of your generation
>and so there is no wonder that you don't know about it. :D
 
If you had stopped to engage your brain for a minute before writing your
patronising bullshit you might have wondered how many millenials actually post
to usenet or have even heard of it. FWIW I was born way before 1980 and if I
need unwarranted smartass reponses I can just talk to my kid for 5 minutes.
"Öö Tiib" <ootiib@hot.ee>: Apr 20 04:51AM -0700

> >then use &str[0]. It returns pointer to mutable data unless str was
 
> And this ugly hack is guaranteed to work for every implemetation(sic) of
> std::string is it?
 
You call that "ugly hack" after accusing others of suggesting to casting
away const from what c_str() returns and admitting that you did it yourself?
Read the fine manual. Yes, it should work for every conforming
implementation of std::basic_string. The std::string is required to be
std::basic_string<char, std::char_traits<char>, std::allocator<char>>
 
> post to usenet or have even heard of it. FWIW I was born way before 1980
> and if I need unwarranted smartass reponses I can just talk to my kid for 5
> minutes.
 
You did start posting here unwarranted smartass responses. Those
automatically make all smartass responses to you warranted and also
disqualify you from complaining about allegedly unwarranted smartass
responses to you. So complain about something else if you need to.
boltar@cylonHQ.com: Apr 20 01:44PM

On Fri, 20 Apr 2018 04:51:46 -0700 (PDT)
>> And this ugly hack is guaranteed to work for every implemetation(sic) of
>> std::string is it?
 
>You call that "ugly hack" after accusing others of suggesting to casting
 
It is an ugly hack.
 
>away const from what c_str() returns and admitting that you did it yourself?
 
Yes I did it myself and found out it was a bad idea as I said. But I guess
you think you're perfect and never make mistakes. I've met people like you in
in plenty of companies, usually while having to bug fix their code.
 
>implementation of std::basic_string. The std::string is required to be
>std::basic_string<char, std::char_traits<char>, std::allocator<char>>
 
And that explains why it will always work does it? Right.
 
>> If you had stopped to engage your brain for a minute before writing your
>> patronising bullshit you might have wondered how many millenials(sic)
 
You always know when someone's run out of argument when they point out typos :)
 
>You did start posting here unwarranted smartass responses. Those
 
No I didn't actually - I asked a perfectly reasonable question and got some
smartass responses as a result. I guess like you those authors thought I'd run
off chastened. Well I've been on usenet in various guises since 1991 so thats
not going to happen my friend.
 
Perhaps you should concentrate on your English comprehension and the ability to
follow threads instead of getting your spellchecker out.
Christiano <christiano@engineer.com>: Apr 20 11:35AM -0700

> not going to happen my friend.
 
> Perhaps you should concentrate on your English comprehension and the ability to
> follow threads instead of getting your spellchecker out.
 
I did a post at std-discussion:
 
Constructor std::string(char * &&). Why not?
https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/8_xudInYUkk
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)