Thursday, November 29, 2018

Digest for comp.lang.c++@googlegroups.com - 8 updates in 3 topics

woodbrian77@gmail.com: Nov 29 11:39AM -0800

Shalom
 
One of the comments in this thread:
https://www.reddit.com/r/cpp/comments/a14o5q/real_world_problems_with_pragma_once/
 
said that Cray doesn't support pragma once. I know gcc,
Clang and MSVC do support it. I was wondering if Intel,
IBM or Oracle compilers support it.
 
In my software:
https://github.com/Ebenezer-group/onwards
 
I've been using pragma once for a number of years, but
maybe I should switch to using include guards. In the
past I had more include files, but now just have a few,
so switching to include guards would be easy.
Thank you in advance.
 
 
Brian
Ebenezer Enterprises - Enjoying programming again.
http://webEbenezer.net
David Brown <david.brown@hesbynett.no>: Nov 29 09:47PM +0100

> past I had more include files, but now just have a few,
> so switching to include guards would be easy.
> Thank you in advance.
 
I think "#pragma once" is supported by most compilers, but include
guards are supported by /all/ compilers. I would expect performance of
them to be very similar - I know gcc has short-circuit paths in the
pre-processor to make handling of include guards as efficient as possible.
 
Include guards are standard, "#pragma once" is not, but it is so common
that it is unlikely ever to be an issue. I'd not bother changing,
unless someone complains about it not working with their compiler.
 
 
> Brian
> Ebenezer Enterprises - Enjoying programming again.
 
I am glad to hear you are enjoying your programming again. I expect
most of us have been enjoying it since we started. Did you go through a
bad period where programming was an unpleasant chore for you?
Vir Campestris <vir.campestris@invalid.invalid>: Nov 29 09:56PM

On 29/11/2018 20:47, David Brown wrote:
 
> Include guards are standard, "#pragma once" is not, but it is so common
> that it is unlikely ever to be an issue.  I'd not bother changing,
> unless someone complains about it not working with their compiler.
 
To be fast, and standard compliant, I use both.
 
Andy
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Nov 29 12:55PM -0800

On 11/25/2018 10:19 PM, Chris M. Thomasson wrote:
> pointers into a table of locks. A thread can create a little array of
> hashed pointers, sort them, remove duplicates, then take all of the
> locks in the table. The sorting and uniqueness factor prevents deadlock.
[...]
> Will post more info sometime tomorrow.
 
This allows one to lock addresses without having to create a mutex for
each one. Just pass the address of a variable to a thread local lock
set, lock it, and the variable is now locked wrt mutual exclusion.
 
Now, to make this more fine grain, what about a multex that used
read-write locks? A thread can have two classes of lock sets, reads and
writes.
wyniijj@gmail.com: Nov 28 04:26PM -0800

Öö Tiib於 2018年11月28日星期三 UTC+8下午9時13分36秒寫道：
 
> > It works, but hardly to say better than pre-C++11 style,
> > after having read https://en.cppreference.com/w/cpp/language/constant_expression
 
> I do not understand what is your point and what is "better".
 
I was trying to use constexpr and to know that the code has to be
written like pre-c++11 style (a bit frustrated, c++17 way is 'better')
 
> Yes, to learn C++ one has to read quite a lot of manuals and
> books.
 
That sayed a lot.
Is it good or bad one has to read A LOT c++ manuals and books?
 
> > usage experiences.
 
> So ... C++11 added sub-bar constexpr and therefore C++11 is enough
> for you?
 
I can read just common, less cultural English, can't figure out 'sub-bar'.
And yes, c++11 should be enough for me, I hope.
 
> Python is scripting language that entirely ignores those
> concerns. Where efficiency is needed there it calls
> C or C++ programs or modules.
 
If some new keyword(or ...) is invented to improve convenience and
optimiztion, I am sure it wil do, but also sure other 'untouched'
part will suffer the opposite effect to the extent proportional to
that the new thing convers, not yet mentioning the complexity and
user/developer burdon grows by multipication when they are mixed in
use/consideration.
I rember Bjarne Stroustrup used to be very careful abour the core
part of the language. But stuffs after c++11 are more and more
'for fun' looked to me (much less insightful).
 
I am seeing programming languages from the perspective of the user,
not developer. So whatever the underlying language should not be
relevant to the user language in this concern. I don't like Python
but it is favored more than c++ by many is fact.
"Öö Tiib" <ootiib@hot.ee>: Nov 29 05:24AM -0800

> > books.
 
> That sayed a lot.
> Is it good or bad one has to read A LOT c++ manuals and books?
 
It is difficulty. Lot of somewhat overlapping features, more
variance in ways to reach same result. Often the differences
in fitness for particular purpose are small and so the
differences of readability, safety, reliability and/or performance
of result will be also small. It is complicated to learn to realize
when these differences might be significant. Hard to master,
hard to beat when mastered.
 
> > for you?
 
> I can read just common, less cultural English, can't figure out 'sub-bar'.
> And yes, c++11 should be enough for me, I hope.
 
My English is anyway bad. I meant that features added by C++11
were really major but somewhat inconveniently or weakly thought
thru. C++14 and C++17 have attempted to fix it, not to add much
new.
 
> I rember Bjarne Stroustrup used to be very careful abour the core
> part of the language. But stuffs after c++11 are more and more
> 'for fun' looked to me (much less insightful).
 
The constexpr function of C++11 can contain only one, return,
statement. That is clearly too limiting.
 
> not developer. So whatever the underlying language should not be
> relevant to the user language in this concern. I don't like Python
> but it is favored more than c++ by many is fact.
 
User Is using software. User does not care with what tools it
is made. Programming language is tool of developer.
So it is developer who should choose what tool to use
for what task. Python is better tool for some situations,
C++ for other situations.
jameskuyper@alumni.caltech.edu: Nov 29 05:44AM -0800

On Thursday, November 29, 2018 at 8:25:08 AM UTC-5, Öö Tiib wrote:
> On Thursday, 29 November 2018 02:26:25 UTC+2, wyn...@gmail.com wrote:
> > Öö Tiib於 2018年11月28日星期三 UTC+8下午9時13分36秒寫道：
...
> were really major but somewhat inconveniently or weakly thought
> thru. C++14 and C++17 have attempted to fix it, not to add much
> new.
 
I suspect you meant "sub-par" <https://en.wiktionary.org/wiki/sub-par>.
scott@slp53.sl.home (Scott Lurndal): Nov 29 01:47PM

>>=20
 
>I can read just common, less cultural English, can't figure out 'sub-bar'.
>And yes, c++11 should be enough for me, I hope.
 
The expression 'sub-par' generally means at a quality less than
average. Yet in the game of golf, sub-par is actually excellent :-)
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)