Monday, August 31, 2015

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

woodbrian77@gmail.com: Aug 31 12:03PM -0700

On Monday, August 31, 2015 at 3:34:03 AM UTC-5, Öö Tiib wrote:
> > because it's small and doesn't require a C++2014 compiler.
 
> You write that binary generated from stutter is longer with
> std=c++1y compiler ... yet you choose stutter? Odd choice.
 
I choose it in part to avoid requiring a C++ 2014 compiler.
 
> Maybe I misunderstand something but it seems like you are
> making it both less readable and less efficient?
 
I admit the make_unique form is easier to read. I would
like to see support for make_unique added to C++ 2011
compilers.
 
Brian
Ebenezer Enterprises - G-d is love.
http://webEbenezer.net
jt@toerring.de (Jens Thoms Toerring): Aug 31 07:46PM

> kosher now. In practice, &vec[0] and &str[0] have always been kosher
> (albeit a bit ugly and non-intuitive - I guess that's why non-const
> vector::data() was added).
 
Yup, I think I had been looking at the option of using a vector
while still using C++98 and decided that it wouldn't be viable
(I tend to be a bit paranoid and avoid anything not guaranteed
by the standard - I don't want someone ending up with wrong
data because I used some fishy shortcuts). And then I didn't
check again if anything had changed about that with C++11, just
remembering that there was some kind of a snag.
 
Of course, there's the point that Chris Vines brings up, i.e.,
that resize() on the vector will initialize all of that data
without that being necessary. On the other had when you have
to get several MBs from a device that's typically the real
bottleneck (at least if it arrives via USB or LAN or some-
thing even slower) compared the initialization of the memory
with 0.
 
Nice to know that I've now got one more option;-)
 
Thanks and best regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
legalize+jeeves@mail.xmission.com (Richard): Aug 31 07:51PM

[Please do not mail me a copy of your followup]
 
Paavo Helde <myfirstname@osa.pri.ee> spake the secret code
 
>Since C++11 std::vector has non-const data() overload and std::string has
>the contiguous buffer guarantee.
 
Be aware that writing through the pointer returned by data() is
undefined behavior.
<http://en.cppreference.com/w/cpp/string/basic_string/data>
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Paavo Helde <myfirstname@osa.pri.ee>: Aug 31 03:29PM -0500

legalize+jeeves@mail.xmission.com (Richard) wrote in
 
> Be aware that writing through the pointer returned by data() is
> undefined behavior.
> <http://en.cppreference.com/w/cpp/string/basic_string/data>
 
I think nobody here has proposed to use basic_string::data() (and casting
away const) for obtaining a pointer to a mutable buffer, we were talking
about vector::data().
 
But otherwise, yes it would be nice to have also a non-const version of
basic_string::data() for write access. Meanwhile I recalled another issue
with &string[0] apart of ugliness, namely it is UB when the length of the
string is zero (whereas vector::data() on a zero size vector is OK).
 
Cheers
Paavo
"Chris M. Thomasson" <nospam@nospam.nospam>: Aug 31 01:32PM -0700

> "Paavo Helde" wrote in message
> news:XnsA507EF07353Cmyfirstnameosapriee@216.166.105.131...
[...]
 
> I think nobody here has proposed to use basic_string::data() (and casting
> away const) for obtaining a pointer to a mutable buffer, we were talking
> about vector::data().
 
Is casting the const away Kosher?
Paavo Helde <myfirstname@osa.pri.ee>: Aug 31 03:34PM -0500

"Chris M. Thomasson" <nospam@nospam.nospam> wrote in
>> casting away const) for obtaining a pointer to a mutable buffer, we
>> were talking about vector::data().
 
> Is casting the const away Kosher?
 
No, it is not. Why do you ask?
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 31 09:41PM +0100

On Mon, 31 Aug 2015 13:32:32 -0700
> > casting away const) for obtaining a pointer to a mutable buffer, we
> > were talking about vector::data().
 
> Is casting the const away Kosher?
 
std::vector::data() is not const for a non-const vector.
jt@toerring.de (Jens Thoms Toerring): Aug 31 08:58PM


> Be aware that writing through the pointer returned by data() is
> undefined behavior.
> <http://en.cppreference.com/w/cpp/string/basic_string/data>
 
There-in lies a certain problem: it's not uncommon that the
devices I have to interface return ASCII data for certain re-
quests (e.g., with an ascilloscope, the current timebase or
sensitivity of a channel) and binary for requests that return
lots of data (e.g. a measured waveform). And what I really got
to like about C++'s strings is that they, in contrast to C
strings, can perfectly handle binary data. So, in the best of
all worlds, I would prefer to simply use a string for every-
thing (and leave the interpretation of what they contain to
some later stage) - but, unfortunately, because of the UB you
mention, they can't be used as buffers the same way as vectors.
Of course, I could use a vector<char>, it's just that that then
has to be converted to a string in all the cases where the de-
vice did send an ASCII string. Well, life's never perfect;-)
 
Best regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
Paavo Helde <myfirstname@osa.pri.ee>: Aug 31 04:08PM -0500

jt@toerring.de (Jens Thoms Toerring) wrote in
> thing (and leave the interpretation of what they contain to
> some later stage) - but, unfortunately, because of the UB you
> mention, they can't be used as buffers the same way as vectors.
 
Yes they can - by using slightly uglier syntax &string[0] (or (string.empty
()? NULL: &string[0]) instead of string.data().
ram@zedat.fu-berlin.de (Stefan Ram): Aug 31 07:38PM

>I admit the make_unique form is easier to read. I would
>like to see support for make_unique added to C++ 2011
>compilers.
 
When passing the constructor arguments of unknown number to
make_unique, variadic templates help to implement make_unique
as a function template.
 
In C++ 2011, possibly it can be done for some numbers of
arguments with several different templates. For example, for
a single argument »x«:
 
template< class T, typename S >::std::unique_ptr< T >make_unique( S x )
{ return( ::std::unique_ptr< T >(new T( my_forward< S >( x )))); }
 
template< typename T >T && my_forward( T && x )
{ return static_cast< T&& >( x ); }.
 
(not tested).
"Öö Tiib" <ootiib@hot.ee>: Aug 31 02:24AM -0700

On Monday, 31 August 2015 11:59:22 UTC+3, Öö Tiib wrote:
> Wikipedia contains article about it:
> https://en.wikipedia.org/wiki/Bush_hid_the_facts
> Those heuristics are not a part of C++ for obvious reasons.
 
I forgot to mention that the heuristics are in 'IsTextUnicode' function
of Windows API:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd318672(v=vs.85).aspx
So use it at your own risk and pay close attention to usage of 'lpiResult'
parameter of it.
legalize+jeeves@mail.xmission.com (Richard): Aug 31 07:14PM

[Please do not mail me a copy of your followup]
 
Gerhard Wolf <leawolf@gmx.de> spake the secret code
 
>std::string line = std::string(wline.begin(), wline.end());
>does not work.
 
std::string and std::wstring are just typedefs for flavors of
std::basic_string:
 
<http://en.cppreference.com/w/cpp/string>
 
All the members functions you're using are really defined on
std::basic_string.
 
There is a facility in the locale library for "narrowing" wide strings
(std::basic_string<wchar_t>) and "widening" narrow strings
(std::basic_string<char>). However, I find the API cumbersome to use
and people aren't very familiar with the details of the locale support
in the standard library so it's hard to find people who can answer
your questions.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
David Brown <david.brown@hesbynett.no>: Aug 31 02:55PM +0200

On 31/08/15 13:49, jacobnavia wrote:
 
> The C containers library is written in C and features nice stuff. Fully
> open source (no license) available at:
 
> https://code.google.com/p/ccl/
 
Regardless of any pros or cons of the CCL and C versus the STL and C++,
would you please sort out your licensing issues. The link about claims
it is a BSD 3-clause license, but that requires copyright information
and licence information in the software. As far as I can see, there is
no such information in either the documentation or any of the files.
 
This means that the code /cannot/ be used for any purpose, except
perhaps personal evaluation - whether it be open source, closed source,
commercial or free. You need to make the licensing and copyrights clear
(or alternatively, make it entirely clear that you are donating
everything to public domain).
 
As far as I can tell, you want people to be able to freely use your code
in open and closed software - so a 3-clause BSD license is a good
choice. But it must be explicit in the code and documentation, along
with copyright notices (without which the license makes no sense) - it
is not enough to have a note on the code.google.com project page.
 
 
One day I hope to get the time to look at CCL properly - but
unfortunately, that will not be today.
Ian Collins <ian-news@hotmail.com>: Sep 01 07:14AM +1200

jacobnavia wrote:
>> have been significanly easier in C++ (mainly, although not solely,
>> because in C++ you can skip all those annoying mallocs and frees.)
 
> In C you can do it too if you use the GC.
 
Heap memory isn't the only resource that needs to be managed....
 
--
Ian Collins
legalize+jeeves@mail.xmission.com (Richard): Aug 31 07:03PM

[Please do not mail me a copy of your followup]
 
Laszlo Lebrun <lazlo.lebrun@googlemail.com> spake the secret code
>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)
 
You can use boost.asio to read/write data from/to serial ports:
<http://www.boost.org/doc/libs/1_59_0/doc/html/boost_asio/overview/serial_ports.html>
 
>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?
 
So if I understand you correctly, you want to read data from a
physical serial port, intercept and/or manipulate it in some way, and
make that modified data stream available through a virtual serial port
to some other application. The other application is connected to the
virtual serial port as if it were connected to the original hardware
serial port.
 
How you provide a serial port to an operating system is beyond the
scope of this newsgroup, but this stack overflow thread might help for
Windows:
<http://stackoverflow.com/questions/1605721/faking-an-rs232-serial-port>
 
Another option is to simply stick a small hardware device in the
cabling. An arduino could easily process the serial port data on one
port and write the data out on another port. Again, this is beyond
the scope of this newsgroup.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Ed Anson <EdAnson@comcast.net>: Aug 30 07:58PM -0400

On 8/29/15 4:18 PM, Ian Collins wrote:
> 1) Stick with the old compiler. Sometimes the effort required to work
> with new tools is too great.
 
I'll second that. I have been working with a legacy code base that was
developed around 2000. The compiler is similarly non-compliant. My
organization's solution was to VERY carefully preserve the compiler that
was originally used and to continue using it.
 
Although this approach has the down side of preventing use of modern
tools, it also prevents the massive expense of refactoring -- and
re-testing -- the entire code base. For a legacy product that is no
longer being developed (bug fixes only), that is the most practical
decision.
 
OTOH if the product is still being actively developed, that is another
matter entirely. In that case, it may be well worth the expense to adapt
the code to work with current tools. You might even be surprised at how
many latent bugs are exposed in the process. IME the best practice is to
incrementally refactor code every time it is changed. That helps keep
the code base in good shape.
Juha Nieminen <nospam@thanks.invalid>: Aug 31 07:37AM

> Of course this forum is useless for asking this types of questions. I
> know now that better.
 
You have to maintain incorrectly-made code that just happened to compile on a
non-standard compiler, then you ask here what to do with a very vague question
without actual concrete examples, and then you get all butthurt when you get
a generic answer, and get a temper tantrum worthy of a 5-year-old.
 
Yes, that's the correct way of getting answers and solving your problems.
Stomp the floor and whine until somebody does what you want.
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 31 01:59PM +0100

On Mon, 31 Aug 2015 07:37:39 +0000 (UTC)
> tantrum worthy of a 5-year-old.
 
> Yes, that's the correct way of getting answers and solving your
> problems. Stomp the floor and whine until somebody does what you want.
 
Bearing in mind the fact that the original question was so general as to
be meaningless and unanswerable, and given the OP's past contributions
to this newsgroup, I think it improbable that he is "trying to maintain
a huge C++ database application with templates all around" as stated.
That task would surely be given to someone who is actually a C++
programmer of reasonable experience.
 
It seems much more probable that the OP is pursuing his ludicrous "C
macros are as good as or better than C++ templates" meme with a bit of
troll fodder.
 
Chris
jacobnavia <jacob@jacob.remcomp.fr>: Aug 31 05:34PM +0200

Le 31/08/2015 14:59, Chris Vine a écrit :
> It seems much more probable that the OP is pursuing his ludicrous "C
> macros are as good as or better than C++ templates" meme with a bit of
> troll fodder.
 
Yes, of course.
 
Look, as many others I am forced to work through this monster
applications where C++ heads leave for the maintenance team or somebody
else to clean up after them.
 
I am just trying to make it compile clean. I started to do what was
proposed here: to add in each file the declarations where needed.
 
But then, the next problem started:
 
friend declarations can't have default arguments. Decision of the C++
standards committee of 1999.
 
In 2010 that code still compiled OK.
 
IN 2015 it doesn't. That was fixed in gcc-something.
 
In principle the solution is simple: Eliminate the default arguments and
make the all explicit.
 
I am almost through that. Then I will go on with the next mess.
 
jacob
 
P.S. Yes, I do not like C++. For obvious reasons. That makes me a troll?
 
Should I abstain from asking questions here?
Melzzzzz <mel@zzzzz.com>: Aug 31 06:14PM +0200

On Mon, 31 Aug 2015 17:34:43 +0200
 
> IN 2015 it doesn't. That was fixed in gcc-something.
 
> In principle the solution is simple: Eliminate the default arguments
> and make the all explicit.
 
What's wrong with adding declaration?
 
#include <iostream>
 
void f(int = 6);
struct A{
friend void f(int);
};
 
int main()
{
f();
}
 
void f(int a)
{
std::cout<<a<<'\n';
}
 
> I am almost through that. Then I will go on with the next mess.
 
Heh.
 
 
> jacob
 
> P.S. Yes, I do not like C++. For obvious reasons. That makes me a
> troll?
 
You do not like C++ simply because you like C too much ;p
 
 
> Should I abstain from asking questions here?
 
No.
Melzzzzz <mel@zzzzz.com>: Aug 31 06:28PM +0200

On Mon, 31 Aug 2015 18:14:35 +0200
 
> > IN 2015 it doesn't. That was fixed in gcc-something.
 
> > In principle the solution is simple: Eliminate the default arguments
> > and make the all explicit.
 
Also have you tried -fpermissive?
jacobnavia <jacob@jacob.remcomp.fr>: Aug 31 06:54PM +0200

Le 31/08/2015 18:28, Melzzzzz a écrit :
> Also have you tried -fpermissive?
 
Yes, of course that works. But doing that kind of stuff exposes me to
the QA manager that surely will look at that with a bad eye
 
:-(
bartekltg@gmail.com: Aug 31 11:12AM -0700

W dniu poniedziałek, 31 sierpnia 2015 18:54:58 UTC+2 użytkownik jacobnavia napisał:
 
> Yes, of course that works. But doing that kind of stuff exposes me to
> the QA manager that surely will look at that with a bad eye
 
> :-(
 
"Dear mr manager, we fucked up 5 years ago and wrote a code that is
incompatible with the standard, but it works on our compiler.
Now these saboteur from gnu fix... I mean change it and we either
spend two day by typing "typename" in our code or we can compile
it with -fpermissive. I want to emphasize that our code will
be not less standard compatible than for the last 5 years."
 
;-)
 
This is a businesses decision. Put some effort to clean it
or go around the problem.
 
bartekltg
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 31 07:32PM +0100

On Mon, 31 Aug 2015 18:54:38 +0200
 
> Yes, of course that works. But doing that kind of stuff exposes me to
> the QA manager that surely will look at that with a bad eye
 
> :-(
 
Your original complaint was about an issue with templates, not with
friend functions. If -fpermissive solves the template issue as well
then I would guess it was a simple dependent name look-up issue in a
base class method called from a derived class method. gcc got more
strict about that a few years ago when moving to support two phase
look-up in conformity with the standard, but retained the old behaviour
for defective code with the -fpermissive flag.
 
If you had originally posted a more informative post with some code and
sample error messages instead of complaining about "getting hundreds of
undefined references in those templates" with the question "How can I
revert to the good old times?", and it was a name look-up issue, people
would have been able to help you and you would have been told to use
the -fpermissive flag to revert to the good old times.
 
The fact that you knew about this all along ("of course that works")
seems to prove the point that in your original posting you were not
asking a genuine question but just having a good rant.
 
But if I am wrong about that and you still want an answer about your
template problems (and being told "how can I revert to the good old
times" is not after all enough), you can solve the issue
without -fpermissive by disambiguating the dependent name look-up,
either with a type qualifier - so if B is the template base class and
f() is the method name, by calling B::f() explicitly in your derived
class method - or by using the this keyword by calling this->f(). If
the problem is with type names not identifier names, you might need more
liberal use of the 'typename' keyword.
 
If that doesn't work, the template problems stem from something else and
you are seeking genuine help, post something more informative.
 
Chris
jacobnavia <jacob@jacob.remcomp.fr>: Aug 31 08:49PM +0200

Le 31/08/2015 20:32, Chris Vine a écrit :
> The fact that you knew about this all along ("of course that works")
> seems to prove the point that in your original posting you were not
> asking a genuine question but just having a good rant.
 
No!
 
It works for the friend declaration in a class issue.
 
It DOES NOT WORK for the templates issue!
 
Please do not try to paint me in that "troll" corner.
 
I just have to do this idiotic job and that is punishment enough!
 
Thanks
 
jacob
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)