Saturday, January 16, 2016

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

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 16 10:38PM +0100

On 1/16/2016 9:46 PM, Stefan Ram wrote:
 
> Does this mean that »the address of 'int f()' will always
> evaluate as 'true'« is false?
 
No. It means that the interpretion where this says that `&f` is the
value `true`, is meaningless.
 
 
> If it is false, what had the author in mind?
 
That the address of a function converts implicitly to `true`, and never
to `false`, since it's always non-zero.
 
This is also the case with the address of a variable, but iostreams have
an overload of `<<` that takes a pointer to void, which will be used
unless it's address of a `char`, which will be interpreted as a C
string. So, for data pointers the `bool` overload isn't considered.
 
These overloads are not considered for address of function, because
there's no implicit conversion between data pointers and function
pointers (apparently in support of Harvard architectures), and until
C++11 an implementation was not even formally allowed to support
`reinterpret_cast` between them, which was and is required by Posix, and
by the Windows API, and other in-practice programming.
 
 
Cheers & hth.,
 
- Alf
Paavo Helde <myfirstname@osa.pri.ee>: Jan 16 11:51PM +0200

On 16.01.2016 22:46, Stefan Ram wrote:
 
> int f(){ return 7; }
> int main() { ::std::cout << f << "\n"s; }
> 9 29 [Warning] the address of 'int f()' will always evaluate as 'true' [-Waddress]
... in this context.
 
All statements always need to be interpreted in a context. Like, that
the statement is written in English, it is about C++, and it talks
about the usage of f in the indicated source code line.
woodbrian77@gmail.com: Jan 16 05:42AM -0800

A friend has given me hundreds of his technical books.
I've just started going through them. I've recycled
the books on Java, Python, Perl, Ruby, CSS and HTML. I'm not
looking at the books at them moment, but I would guess
there are at least 30 books about UML. The C++ books
are from Scott Meyers, Stroustrup, Koenig and others.
There are lots of books also on writing compilers.
I'm leaning toward recycling most of the UML books.
 
G-d willing, I'll post more about these books in the
future with more details. I'd like help in deciding
which books to recycle/give away and which to keep.
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 16 04:48PM +0100


> G-d willing, I'll post more about these books in the
> future with more details. I'd like help in deciding
> which books to recycle/give away and which to keep.
 
I'd select one reference book on UML and ditch the rest of the UML books.
 
The aspects of notation that needs a deep long study simply aren't
useful, and engaging in such study is counter-productive.
 
Well unless you've paid some extortion-like licenses for some UML-based
"process" tool?
 
 
Cheers,
 
- Alf
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 16 06:15PM

On Sat, 2016-01-16, Alf P. Steinbach wrote:
 
> I'd select one reference book on UML and ditch the rest of the UML books.
 
> The aspects of notation that needs a deep long study simply aren't
> useful,
 
Not unless everyone else knows the notation too, and IME people don't,
not in detail. I find class diagrams and state diagrams useful.
Others like the sequence diagrams, but it ends there. I haven't seen
the stick figures in a decade ...
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
woodbrian77@gmail.com: Jan 16 01:25PM -0800

On Saturday, January 16, 2016 at 9:48:44 AM UTC-6, Alf P. Steinbach wrote:
> > future with more details. I'd like help in deciding
> > which books to recycle/give away and which to keep.
 
> I'd select one reference book on UML and ditch the rest of the UML books.
 
There aren't as many as I thought.
 
1. Elements of UML style by Ambler
2. UML 2.0 in a Nutshell
3. Advanced Object Oriented Analysis and Design using UML
4. Project Quality Assurance for UML-based Projects
5. UML Toolkit
6. Database Design for Smarties using UML
7. UML and C++: A Practical Guide to Object Oriented Development
8. UML 2.0 in Action
9. The UML Profile for Framework Architectures
10. Developing Software with UML
11. Real-time UML Second Edition by Douglass
12. UML Distilled Third Edition by Fowler
13. Applying UML and Patterns
 
There may be one or two more that I'm missing.
 
It looks like the 5th one, UML Toolkit, there's
been a "UML 2 Toolkit" published subsequently.
The book I have is probably kind of old. I agree
about keeping one or two at the most. Thanks.
JiiPee <no@notvalid.com>: Jan 16 12:50AM

On 14/01/2016 18:00, Richard wrote:
> [Please do not mail me a copy of your followup]
 
> People may be "Windows only programmers" and never touch MFC. (I hope to
> not have to touch MFC code ever again.)
 
I started MFC back in 1997. I found it easy/quick to learn. Also it has
a great support in Visual Studio community 2015 (free). VS is way better
than codeblocks or similar. I switched to codeblocks and wxWidgets for
1-2 years (because MFC was not free). But I found wxWidgets difficult to
learn and there is not much support for it.. .not many books about
wxWidgets neither. I did research those...i really wanted to learn it,
but it was difficult. So.... when VS was free , I was happy to go back
to MFC.
 
The thing to understand also is that if somebody has learned well MFC,
it does not make sense necessary to learn a new GUI, but rather keep
mastering what you already know well. Especially if you dont use GUI so
often. So that is another reason to stay with MFC.
 
I do not see wxWidgets or others much better than MFC. They might be
bettter, but I do not see essential difference in a basic use.
 
What is essentially better in wxWidgets compared to MFC? Also lets
remember MFC is done by Microsoff (who knows windows), but wxWidgets is
not. there might be some benefit there...
 
> Many "Windows only" programmers
> use wxWidgets or Qt because they are comprehensive UI frameworks that are
> freely available.
 
but Qt is not free, is it? there are a lot of people who would not pay .
 
> In desktop GUI application developers that I talk to,
> even "Windows only" developers, MFC has been losing mindshare steadily for
> years and years.
 
but I think its a matter of taste partly. You can very well create a
dialog box with MFC....and it looks and works the same as done with
wxWidgets. Most of the stuff done in GUI are very similar when done with
wxWidgets or MFC... the code even looks similar.
 
> are those that deal with legacy code bases that were written in MFC
> in the first place. Everyone else I talk to is using Qt or wxWidgets.
> YMMV, of course.
 
obviously if you need multiplatform stuff, then right tool needs to be
there. but like me am doing only windows programming currently.
JiiPee <no@notvalid.com>: Jan 16 12:58AM

On 16/01/2016 00:50, JiiPee wrote:
>> not have to touch MFC code ever again.)
 
> I started MFC back in 1997. I found it easy/quick to learn. Also it
> has a great support in Visual Studio community 2015 (free).
 
also there are tons of books written about VS and MFC but you dont find
that for wxWidgets. I think I found couple of wxWidgets books when i was
googling it....I really think this is a major problem with wxWidget:
books and support. one of the reasons I left it year ago.
"Öö Tiib" <ootiib@hot.ee>: Jan 16 01:11PM -0800

On Saturday, 16 January 2016 02:51:15 UTC+2, JiiPee wrote:
> > use wxWidgets or Qt because they are comprehensive UI frameworks that are
> > freely available.
 
> but Qt is not free, is it? there are a lot of people who would not pay .
 
Most of Qt framework is available under free open source licenses.
http://doc.qt.io/qt-5/licensing.html For most needs LGPL is fine.
If you want to have Qt under commercial license then these are available
as well but such cost few thousands of euros.
ram@zedat.fu-berlin.de (Stefan Ram): Jan 16 08:46PM

This is supposed to be a C++ program:
 
#include <iostream> /* ::std::cout */
#include <ostream> /* << */
#include <string> /* ::std::string */
 
using namespace ::std::literals;
 
int f(){ return 7; }
 
int main() { ::std::cout << f << "\n"s; }
 
The output of the program is:
 
1
 
GCC prints:
 
In function 'int main()':
9 29 [Warning] the address of 'int f()' will always evaluate as 'true' [-Waddress]
 
Let me test this!
 
This program prints »7«:
 
#include <iostream> /* ::std::cout */
#include <ostream> /* << */
#include <string> /* ::std::string */
 
using namespace ::std::literals;
 
int f(){ return 7; }
 
int main() { ::std::cout <<( &f )() << "\n"s; }
 
If it was true that »the address of 'int f()' will always
evaluate as 'true'«, then it should be possible to replace
»&f« by »true« and get the same behavior:
 
#include <iostream> /* ::std::cout */
#include <ostream> /* << */
#include <string> /* ::std::string */
 
using namespace ::std::literals;
 
int f(){ return 7; }
 
int main() { ::std::cout <<( true )() << "\n"s; }
 
This now prints:
 
In function 'int main()':
9 37 expression cannot be used as a function
 
Does this mean that »the address of 'int f()' will always
evaluate as 'true'« is false?
 
If it is false, what had the author in mind?
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 16 06:25AM +0100


>> Religion is the root of all evil.
 
> According to the Bible, the love of money is the
> root of all kinds of evil.
 
Of course, but still worth mentioning, according to Donald Knuth it's
premature optimization that's the root of all evil.
 
Cheers & hth.,
 
- Alf
Gareth Owen <gwowen@gmail.com>: Jan 16 07:11AM


> I don't expect everyone to care, but those who are
> seeking to follow G-d will be glad to find a safe
> place to learn about C++ programming.
 
Don't let the door hit you in the ass on the way out. I think we'll
manage without your pimping of Middleware writer.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 16 07:12AM

On Sat, 2016-01-16, Alf P. Steinbach wrote:
>> root of all kinds of evil.
 
> Of course, but still worth mentioning, according to Donald Knuth it's
> premature optimization that's the root of all evil.
 
Evil is negative. Shouldn't its root be imaginary?
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
woodbrian77@gmail.com: Jan 16 05:27AM -0800

On Saturday, January 16, 2016 at 1:11:22 AM UTC-6, gwowen wrote:
> > place to learn about C++ programming.
 
> Don't let the door hit you in the ass on the way out. I think we'll
> manage without your pimping of Middleware writer.
 
 
For years now the C++ Middleware Writer has been the
elephant in the room. There are scores of topics that
I've raised that should be revisited.
 
 
Brian
Ebenezer Enterprises - "He came to His own, and His own
received Him not. But as many as received Him, to them
gave He power to become the sons of G-d." John 1:11,12
 
http://webEbenezer.net
Daniel <danielaparker@gmail.com>: Jan 16 08:25AM -0800

On Saturday, January 16, 2016 at 12:26:06 AM UTC-5, Alf P. Steinbach wrote:
> On 1/15/2016 10:33 PM, woodbrian77@gmail.com wrote:
 
> Of course, but still worth mentioning, according to Donald Knuth it's
> premature optimization that's the root of all evil.
 
On the other hand, it's regrettable that the authors of iostreams didn't apply a little premature optimization.
 
Daniel
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 16 06:04PM


> For years now the C++ Middleware Writer has been the
> elephant in the room. There are scores of topics that
> I've raised that should be revisited.
 
Only in your own mind Brian: everybody else, thanks mostly to your
incoherent spam, couldn't give the slightest fuck about it sausages.
 
/Flibble
 
P.S. Please confirm you are a cunt by yet again replying with your
favourite sentence "Please don't swear here".
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 16 06:20PM

On Sat, 2016-01-16, Daniel wrote:
>> premature optimization that's the root of all evil.
 
> On the other hand, it's regrettable that the authors of iostreams
> didn't apply a little premature optimization.
 
Wouldn't that have been a textbook example of optimization that isn't
premature?
 
(Assuming the rather bad performance of iostreams in popular
implementations /is/ due to the interface design.)
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Daniel <danielaparker@gmail.com>: Jan 16 11:03AM -0800

On Saturday, January 16, 2016 at 1:20:38 PM UTC-5, Jorgen Grahn wrote:
> > didn't apply a little premature optimization.
 
> Wouldn't that have been a textbook example of optimization that isn't
> premature?
 
Indeed, but how to tell the difference? :-)
 
> (Assuming the rather bad performance of iostreams in popular
> implementations /is/ due to the interface design.)
 
Would it have stayed this bad, this long, if it were not so?
 
Daniel
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)