Tuesday, June 23, 2015

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

Paul N <gw7rib@aol.com>: Jun 23 04:11PM -0700


> Notes about the notation above:
 
> * Instead of a "swap_with" method, it's my impression that most people prefer a non-member "swap" function, perhaps expressed as an inline "friend" function. However, a non-member "swap" function can easily be expressed in terms of a "swap_with" method. The opposite, expressing a member function in terms of non-member function, is a bit unnatural to me.
 
> * Instead of the C++11 "auto" syntax for functions (a.k.a. trailing return type), most people still prefer the old C++03 function declaration syntax. I see no reason to use the old syntax except inertia, since the new syntax covers it all. The new syntax e.g. allows using class-local types in the return type without qualification, and it makes it easier for me to spot the function name.
 
You say that "the copy constructor has to initialize various members. This is work that the copy assignment operator doesn't have to do." but your code means that the copy assignment operator goes through all that the copy constructor does and all that the destructor does. Is it assumed that the neatness of the code and the ease of making it exception-safe outweighs any possible run-time inefficiency?
alf.p.steinbach@gmail.com: Jun 22 05:02PM -0700

Instead of (as an example) this:
 
class Foo
{
private:
int golgoroth_;
float fiskepudding_;
double color_;
public:
Foo( char const* ): golgoroth_( 1 ), color_( 2.718128 ) {}
Foo( float ): golgoroth_( 1 ), fiskepudding_( 0 ) {}
};
 
auto main() -> int {}
 
you can do this, which automates & guarantees the zeroing:
 
template< class Base >
struct Initialized_POD
: Base
{
Initialized_POD(): Base() {} // Value-init -> zero-init
};
 
struct Foo_state
{
int golgoroth_;
float fiskepudding_;
double color_;
};
 
class Foo
: private Initialized_POD< Foo_state >
{
public:
Foo( char const* ) { golgoroth_ = 1; color_ = 2.718128; }
Foo( float ) { golgoroth_ = 1; }
};
 
auto main() -> int {}
 
It's not universally applicable, rather the opposite, but I suspect it might be Just The Thing(tm) for your concrete problem.
 
It's more safe than the memset approach -- maintainers can't forget to zero things, and there's no problem with later introduction of virtual functions -- and it's also less code in general, even though it might look somewhat verbose in the short example above. Compiled with optimization it should be just as efficient as memset. I.e., no known big problems, some nice advantages. :)
 
Cheers & hth.,
 
- Alf
alf.p.steinbach@gmail.com: Jun 22 05:47PM -0700

> {
> Initialized_POD(): Base() {} // Value-init -> zero-init
> };
 
Looking at it again, a better name might be just `Zeroed`.
legalize+jeeves@mail.xmission.com (Richard): Jun 23 01:24AM

[Please do not mail me a copy of your followup]
 
alf.p.steinbach@gmail.com spake the secret code
>> Initialized_POD(): Base() {} // Value-init -> zero-init
>> };
 
>Looking at it again, a better name might be just `Zeroed`.
 
That's a nice little snippet, a great contribution to this thread.
--
"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>: Jun 23 08:17AM +0200

On 22/06/15 22:34, JiiPee wrote:
> int* p;
> ? I think it would be safer to put nullptr so that other code knows its
> not pointing to anywhere.
 
No, it is (normally) better not to put a fake value in initialisation.
Putting a fake value might mislead people into thinking it is a real
value, and it stops the compiler being able to warn you if you use it
before putting in the real value (compilers can warn about the use of
uninitialised variables in most cases).
 
So if you don't have anything sensible to put in your variable, don't
put anything in it (or don't declare it at all until you need it).
 
Noob <root@127.0.0.1>: Jun 23 09:12PM +0200

On 22/06/2015 19:33, Richard wrote:
 
> [Please do not mail me a copy of your followup]
 
(I find this foreword annoying.)
 
> C++11 support in VS is quite good from my perspective.
> <https://utahcpp.wordpress.com/2015/06/22/c111417-features-in-visual-studio-2015/>
 
VS2015 is unreleased software. It doesn't support anything (yet).
 
> Microsoft has been improving their compiler rapidly in recent years.
> If you haven't looked at it in a while, you're missing a lot.
 
Well, I have gcc and clang, I don't need VS.
 
Regards.
Vir Campestris <vir.campestris@invalid.invalid>: Jun 23 09:27PM +0100

On 23/06/2015 20:12, Noob wrote:
> Well, I have gcc and clang, I don't need VS.
 
You haven't tried VS have you?
 
gcc and clang are compilers. They may even be better compilers than the
one in VS as they fight each other for the same market.
 
VS is an IDE. I can't find anything nearly as good on Linux. I'm using
Eclipse, but it's clunky and unreliable in comparison.
 
Andy
legalize+jeeves@mail.xmission.com (Richard): Jun 23 08:29PM

[Please do not mail me a copy of your followup]
 
Noob <root@127.0.0.1> spake the secret code
 
>On 22/06/2015 19:33, Richard wrote:
 
>(I find this foreword annoying.)
 
Well, at least you're consistent in being a complainer.
 
>> C++11 support in VS is quite good from my perspective.
 
><https://utahcpp.wordpress.com/2015/06/22/c111417-features-in-visual-studio-2015/>
 
>VS2015 is unreleased software. It doesn't support anything (yet).
 
VS2015 community edition release candidate is available now.
<https://www.visualstudio.com/>
 
The community technology preview releases have been available for many
months. While those releases were not advertised as being "ready for
prime time", it would allow you to evaluate C++11/14/17 conformance on
your code base.
 
When people talk about VS not "fully supporting C++xx", this is a
statement that is simultaneously true and not very useful. The reason
it isn't very useful is because the parts that VS doesn't yet support
may not be present in your code base and therefore, the lack of support
may be completely irrelevant. Lots of commercial code bases aren't
even modernized to use C++11 features yet, so harping on the lack of
something like C++14 support for say SFINAE-friendly result_of from
proposal N3462 is probably not that useful.
 
Unless, of course, you really depend on that feature and then it's
important. The authors of that proposal are Eric Niebler, Daniel
Walker and Joel de Guzman. I've met Eric in person and have had many
email discussions with Joel. I am not familiar with Daniel Walker,
but judging by his company on this proposal, I'm sure I'd respect his
thoughts on these matters as I do Eric and Joel. Eric and Joel are heavy
contributors to libraries in Boost. The life of a library writer is much,
much different form the life of a library consumer -- in other words
an application developer. The point is that N3462 may or may not be
important to your code base. It certainly is irrelevant if you, and
none of the header-only libraries you use, depend on std::result_of.
 
The lack of support in VS2013 for constexpr could be considerably more
annoying, but we've been doing many of these sorts of things in
clumsier ways all along. Many of the features in C++11 are focused on
making things easier in the language, as opposed to making impossible
things possible. However, even in the case of constexpr things aren't
as bleak as they might appear at first if your investigation is simply
"bah! It doesn't support constexpr, they suck!" Let's look at the
timeline:
 
2013-06 Visual Studio 2013 released, no constexpr support
2013-11 VS Nov 2013 CTP0, partial constexpr support
2014-06 VS14 CTP1, partial constexpr support
2014-08 VS14 CTP3, partial constexpr support
2014-11 VS 2015 preview, partial constexpr support
2015-04 VS 2015 RC, constexpr almost complete modulo compiler bugs
2015-06-02 constexpr complete for VS 2015 RTM[*]
[*] <http://bit.ly/1LzK1it>
2015-06-23 VS 2015 RC available for free
 
For the size of the team at Microsoft -- I've met a few of them over
the years as an MVP -- I'd say they're doing a really good job of
getting the standard into the hands of Windows developers while
maintaining the quality of implementation.
 
>> Microsoft has been improving their compiler rapidly in recent years.
>> If you haven't looked at it in a while, you're missing a lot.
 
>Well, I have gcc and clang, I don't need VS.
 
Elsewhere in this thread you wrote:
 
> But the problem is that this project's Windows binaries are supposed
> to be generated with VS, which is lagging in C++11 support.
 
...which implies that you *do* need it.
 
> (Perhaps Microsoft is too busy pushing C#)
 
...and this implies that you don't know what you're talking about, but
are mostly interested in complaining about Microsoft.
--
"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>
Ian Collins <ian-news@hotmail.com>: Jun 24 08:30AM +1200

Vir Campestris wrote:
> one in VS as they fight each other for the same market.
 
> VS is an IDE. I can't find anything nearly as good on Linux. I'm using
> Eclipse, but it's clunky and unreliable in comparison.
 
If you like VS, try NetBeans. The two are uncannily similar in many ways.
 
--
Ian Collins
scott@slp53.sl.home (Scott Lurndal): Jun 23 08:49PM


>VS is an IDE. I can't find anything nearly as good on Linux. I'm using
>Eclipse, but it's clunky and unreliable in comparison.
 
>Andy
 
Who needs an IDE? I cannot stand to use any of them.
legalize+jeeves@mail.xmission.com (Richard): Jun 23 09:26PM

[Please do not mail me a copy of your followup]
 
Vir Campestris <vir.campestris@invalid.invalid> spake the secret code
 
>VS is an IDE. I can't find anything nearly as good on Linux.
 
Try CLion. It's the first viable competitor I've seen to VS so far.
--
"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>
legalize+jeeves@mail.xmission.com (Richard): Jun 23 09:28PM

[Please do not mail me a copy of your followup]
 
slp53@pacbell.net spake the secret code
 
>Who needs an IDE? I cannot stand to use any of them.
 
I used to have that attitude in the mid/late 90s when I switched from
working at a unix shop to working at a Windows shop. Initially I kept
my emacs on Windows and worked primarily in emacs for editing and only
used VS for compiling. Over time, I learned to use the VS IDE and
found myself being more productive at navigating through and
manipulating my code. The only thing that's come close to being that
productive is CLion and it barely just came out.
--
"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>
Noob <root@127.0.0.1>: Jun 24 12:02AM +0200

On 23/06/2015 22:29, Richard wrote:
 
> [Please do not mail me a copy of your followup]
 
Well, I may just have to start mailing you a copy of all my
Usenet followups.
 
> months. While those releases were not advertised as being "ready for
> prime time", it would allow you to evaluate C++11/14/17 conformance on
> your code base.
 
AFAICT, VS2013 was supposed to support C++11 NSDMI (a feature which
YOU suggested I use). And that feature had to be removed because the
implementation didn't get it right. Are you sure VS2015 gets it right?
 
> the years as an MVP -- I'd say they're doing a really good job of
> getting the standard into the hands of Windows developers while
> maintaining the quality of implementation.
 
suum cuique.
 
 
>> But the problem is that this project's Windows binaries are supposed
>> to be generated with VS, which is lagging in C++11 support.
 
> ...which implies that you *do* need it.
 
To be precise: I'm building the Linux version, and another fellow
builds the Windows version (using VS2012 IIUC). I just have to avoid
using syntax VS2012 doesn't approve.
 
>> (Perhaps Microsoft is too busy pushing C#)
 
> ...and this implies that you don't know what you're talking about, but
> are mostly interested in complaining about Microsoft.
 
One shouldn't let facts get in the way of a proper trolling opportunity.
How's C11 support in VS coming along, by the way? :-p
 
Regards.
corvusoft.solutions@gmail.com: Jun 23 02:46AM -0700

Hello All,
 
Having just released an open source (GPL) project to bring asynchronous RESTful services to C++11. I thought I'd try and elicit some feedback from the C++ community at large. I'd appreciate any feedback on coding styles, architecture, bugs, potential tech-debt, feature requests, or general discussion.
 
Restbed: https://github.com/corvusoft/restbed.
legalize+jeeves@mail.xmission.com (Richard): Jun 23 04:34PM

[Please do not mail me a copy of your followup]
 
corvusoft.solutions@gmail.com spake the secret code
 
>Having just released an open source (GPL) project to bring asynchronous
>RESTful services to C++11. I thought I'd try and elicit some feedback
>from the C++ community at large.
 
A Boost/MIT/BSD license is preferable. C++ is heavily used in industry
and if you want real-world adoption of your library, a GPL license is a
hindrance and will cause many people to skip over your library. These
are exactly the sort of people you want commenting on your library,
hwoever.
--
"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>
alf.p.steinbach@gmail.com: Jun 22 07:08PM -0700

On Tuesday, June 16, 2015 at 9:12:30 PM UTC+2, Paul wrote:
 
> /*Problem 5
> Write a program that outputs all possibilities to put + or - or nothing between the numbers 1, 2, ..., 9 (in this order)
> such that the result is always 100. For example: 1 + 2 + 34 - 5 + 67 - 8 + 9 = 100.*/
 
Well, I see that K. Frank already suggested the to me most natural solution, and Victor Bazarov already presented complete code for that solution.
 
But since different people's notion of beauty and ugliness differs, here's my take on it:
 
------------------------------------------------------------------------------
 
// Problem 5
// Write a program that outputs all possibilities to put + or - or nothing between
// the numbers 1, 2, ..., 9 (in this order) such that the result is always 100. For
// example: 1 + 2 + 34 - 5 + 67 - 8 + 9 = 100.
 
#include <assert.h>
 
static_assert( int(987654321) == 987654321LL, "`int` isn't enough for 987654321" );
 
enum class Op { none = 0, plus, minus };
 
auto eval( int expr_id )
-> int
{
int operand = 0;
int result = 0;
Op previous_op = Op::plus;
 
for( int i = 1; i <= 10; ++i )
{
if( i != 10 ) { operand = 10*operand + i; }
Op const current_op = Op( expr_id % 3 );
if( i == 10 || current_op != Op::none )
{
switch( previous_op )
{
case Op::none: assert( false ); break;
case Op::plus: result += operand; break;
case Op::minus: result -= operand; break;
}
previous_op = current_op; operand = 0;
}
expr_id /= 3;
}
return result;
}
 
#include <iostream>
using namespace std;
 
auto main() -> int
{
for( int expr_id = 0; expr_id < 3*3*3*3*3*3*3*3; ++expr_id )
{
if( eval( expr_id ) == 100 )
{
cout << "100 = ";
int id = expr_id;
for( int i = 1; i <= 9; ++i )
{
static char const* const operators[] = {"", " + ", " - "};
cout << i << operators[id % 3];
id /= 3;
}
cout << endl;
}
}
}
 
Cheers & hth.,
 
- Alf
Paul <pepstein5@gmail.com>: Jun 23 01:27AM -0700

> }
> }
> }
 
I like this solution very much. Regarding the static assert, if I were concerned about this, I would simply use long longs in the first place, but that's probably just me.
 
Paul
ram@zedat.fu-berlin.de (Stefan Ram): Jun 23 04:03AM

>auto eval( int expr_id )
> -> int
...
> int result = 0;
...
> return result;

Since C++14 »-> int« is not necessary anymore:
 
auto f() { auto result = 5481; return result; }
 
, and »decltype( auto )« will retain the »const«:
 
decltype( auto )f()
{ static auto i = 0; auto const & j = i; return j; }
 
.
ram@zedat.fu-berlin.de (Stefan Ram): Jun 23 06:35AM

>int* p;
>? I think it would be safer to put nullptr so that other code knows its
>not pointing to anywhere.
 
Show the full function and then we will see that there will
be a natural way to rewrite the function into a form where
every variable is initialized with a natural value if it is
known what that function is supposed to do.
Lynn McGuire <lmc@winsim.com>: Jun 22 06:54PM -0500

On 6/22/2015 5:19 PM, Ian Collins wrote:
>> methods and have ::std as the global namespace?
 
>> i.e., "using namespace std;".
 
> Valuable lesson learned!
 
Which is? We wrote a lot of our C++ code before std:: was used in MS VC++.
 
Lynn
legalize+jeeves@mail.xmission.com (Richard): Jun 23 01:29AM

[Please do not mail me a copy of your followup]
 
Lynn McGuire <lmc@winsim.com> spake the secret code
 
>>> i.e., "using namespace std;".
 
>> Valuable lesson learned!
 
>Which is? We wrote a lot of our C++ code before std:: was used in MS VC++.
 
For some, the lesson is that 'using namespace std;' at file scope is a
bad idea. I could go either way depending on the coding standards of
whatever group I'm working in at the time.
 
I've done:
- 'using namespace fmeh;' at file scope
- 'using namespace fmeh;' at function scope
- 'using namespace bar = the::really::deeply::nested::fmeh;' at file scope
 
Of course, I also keep my functions and files small. The larger the
unit (function, file, etc.), the harder it is to see these global
settings.
 
In a header, I always refactor away when I see it:
- 'using namespace fmeh;' at global scope in a header file
- 'using namespace bar = the::really::deeply::nested::fmeh;' at global scope
 
These end up having non-local interactions that are best avoided.
 
For others, the lesson is to make sure that your own types are always
inside some namespace that you control. Then your own fmeh::shared_ptr<>
won't clash with std::shared_ptr<>. Namespaces have been around for a
really long time, yet I'm still surprised how few C++ developers use
them effectively, even when examples of good namespace usage abound in
the standard library and places like boost, cinder, etc.
--
"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>
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)