Wednesday, September 9, 2020

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

Marcel Mueller <news.5.maazl@spamgourmet.org>: Sep 09 07:35AM +0200

Am 25.08.20 um 18:38 schrieb Christian Hanné:
> package in Java)?
> I think that would be very cool since you could establish security
> -mechanisms on top of that.
 
Basically you need to protect memory, either from reading or writing or
execution.
 
The first limiting factor is the granularity. Common architectures use
4k block size for this purpose. To protect every variable you need to
reduce this in fact significantly. Otherwise excessive padding would be
required to separate each block with different access rights.
 
The second point is volatility. The protection level changes with every
method call. So to CPU protection information has to be updated (to some
degree) on every method invocation. In case of inlining of trivial
methods like getters these updates would remain and make the entire
solution extremely inefficient.
 
It is by far more efficient, to check this constraints *at compile time*
once than doing the same over an over at run time.
 
In fact almost any movement of execution to the compile process reduces
resources taken at execution time. constexpr is a good example to allow
such optimizations.
 
So I would call this a bad idea.
 
 
Marcel
"Christian Hanné" <the.hanne@gmail.com>: Sep 09 03:51PM +0200

> 4k block size for this purpose. To protect every variable you need to
> reduce this in fact significantly. Otherwise excessive padding would be
> required to separate each block with different access rights.
 
Ok, then the different fields have to be assigned to different pages.
This would be most useful by having multiple this-pointers.
 
> degree) on every method invocation. In case of inlining of trivial
> methods like getters these updates would remain and make the entire
> solution extremely inefficient.
 
That's not an issue. The kernel can do this.
Richard Damon <Richard@Damon-Family.org>: Sep 09 10:35AM -0400

On 9/9/20 9:51 AM, Christian Hanné wrote:
>> trivial methods like getters these updates would remain and make the
>> entire solution extremely inefficient.
 
> That's not an issue. The kernel can do this.
 
The issue isn't that it can't be done, but that it will reduce your
performance incredibly. Basically you are adding the overhead of a
system call into the kernel and much of the overhead of a task switch to
EVERY method call, and return.
"Christian Hanné" <the.hanne@gmail.com>: Sep 09 04:37PM +0200

> performance incredibly. Basically you are adding the overhead of a
> system call into the kernel and much of the overhead of a task switch to
> EVERY method call, and return.
 
Security always rules over performance.
James Kuyper <jameskuyper@alumni.caltech.edu>: Sep 09 11:19AM -0400

On 9/9/20 10:37 AM, Christian Hanné wrote:
>> system call into the kernel and much of the overhead of a task switch to
>> EVERY method call, and return.
 
> Security always rules over performance.
 
Absolutes are generally false. This is a prime example.
 
There's no upper limit on how far you can compromise performance in the
name of increased security - the only completely secure computer system
is one that has been turned off, which corresponds to infinitely poor
performance. At some point you have to decide that the value of a small
amount of extra security does not justify a large cost in decreased
performance.
 
The performance hit of this suggestion would be very large, and since
it's turning issues that are suppose be dealt with at compile time into
issues that need to be dealt with at run-time, the security benefit is
very close to 0 (possibly negative).
"Christian Hanné" <the.hanne@gmail.com>: Sep 09 05:21PM +0200

> Absolutes are generally false. ...
 
Not in this case.
But as I see you're a person that easily offers security for nothing.
boltar@nuttyella.co.uk: Sep 09 03:38PM

On Wed, 9 Sep 2020 11:19:47 -0400
 
>There's no upper limit on how far you can compromise performance in the
>name of increased security - the only completely secure computer system
>is one that has been turned off,
 
And not even then if someone has physical access to the machine.
James Kuyper <jameskuyper@alumni.caltech.edu>: Sep 09 11:45AM -0400

On 9/9/20 11:21 AM, Christian Hanné wrote:
>> Absolutes are generally false. ...
 
> Not in this case.
> But as I see you're a person that easily offers security for nothing.
 
Those comments display as little knowledge about me as they do about
security.
"Christian Hanné" <the.hanne@gmail.com>: Sep 09 06:01PM +0200

>> But as I see you're a person that easily offers security for nothing.
 
> Those comments display as little knowledge about me as they do about
> security.
 
I'm an expert in this.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 09 04:31PM +0100

Shader based blurred outline (black) applied to colorized "material design" icons so they look legible on both dark and light backgrounds:
 
https://neogfx.org/images/materialdesign.png
 
/Flibble
 
--
¬
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 08 09:45PM -0400

On 9/8/20 3:59 PM, olcott wrote:
>> have preferred C code 10:1 over C++ code for general coding styles.
 
> I focused on learning the subset of c++ the most directly enabled me to
> write much better code.
 
Same with me. C++ is an absolutely brilliant extension of C in the
number and types of abilities it opens up to coding, but it goes way
too far with its number of library functions it tries to bring forward
IMO.
 
I think those features should be shared public open source libraries
that people can choose to add to their product, and not something the
language itself requires to be compliant.
 
--
Rick C. Hodgin
olcott <NoOne@NoWhere.com>: Sep 08 08:56PM -0500

On 9/8/2020 8:45 PM, Rick C. Hodgin wrote:
 
> I think those features should be shared public open source libraries
> that people can choose to add to their product, and not something the
> language itself requires to be compliant.
 
I only use its OOP classes and std::vector, std::string and sometimes
std::map. Inheritance might be good for class libraries but I have never
written one of those. I still (after decades of C++) mostly use
<stdio.h> for IO. The C++ formatted output is simply too tedious.
 
--
Copyright 2020 Pete Olcott
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 08 07:49PM -0700

On 9/8/2020 6:56 PM, olcott wrote:
> written one of those.
 
 
> I still (after decades of C++) mostly use
> <stdio.h> for IO. The C++ formatted output is simply too tedious.
 
Agreed.
Juha Nieminen <nospam@thanks.invalid>: Sep 09 06:27AM

> I still (after decades of C++) mostly use
> <stdio.h> for IO. The C++ formatted output is simply too tedious.
 
One advantage of the C++ style streams is that they are easily extensible
to support custom types while retaining the same usage syntax. I find this
very handy especially for things like debug output and such.
 
In other words, if I have something like:
 
class MyClass { ... };
 
I can then implement an std::ostream operator<< overload that allows me to
write things like:
 
MyClass obj = whatever;
std::cout << "a=" << a << ", b=" << b << ", obj=" << obj << "\n";
 
Sometimes I prefer implementing a separate debug printing function as a
variadic template, which I can call like:
 
dPrint("a=", a, ", b=", b, ", obj=", obj, "\n");
 
but even then the extensibility of std::ostream becomes handy because it
simplifies the implementation of that dPrint() function (because its
implementation can simply pass the parameters to std::ostream::operator<<).
 
Doing either one of those two things using <cstdio> only, instead of using
<iostream>, would be a lot more difficult. That's because of the lack of
overloads (and type safety) in <cstdio>.
 
That being said, there are other situations where std::printf() is a lot
handier than std::cout. For example, compare:
 
std::printf("%08X", value);
 
to the equivalent:
 
// Need this because some flag changes are persistent:
std::ios_base::fmtflags f = std::cout.flags();
std::cout << std::hex << std::uppercase << std::setw(8)
<< std::setfill('0') << value;
std::cout.flags(f);
 
which is, admittedly, a bit ridiculous.
Melzzzzz <Melzzzzz@zzzzz.com>: Sep 09 06:38AM

> << std::setfill('0') << value;
> std::cout.flags(f);
 
> which is, admittedly, a bit ridiculous.
 
You can't have everything, that is why use printf when more convenient
:P
 
 
--
current job title: senior software engineer
skills: c++,c,rust,go,nim,haskell...
 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
David Brown <david.brown@hesbynett.no>: Sep 09 11:54AM +0200

On 09/09/2020 08:38, Melzzzzz wrote:
>> << std::setfill('0') << value;
>> std::cout.flags(f);
 
>> which is, admittedly, a bit ridiculous.
 
It is also, IMO, unpleasant that the streams are stateful (with these
flags), and even more unpleasant that you don't at least have a push/pop
interface to those flags.
 
It would be a lot nicer, simple to implement, and safer and easier to
use, to have some functions (perhaps in their own namespace) for
formatting outputs. So "std::formating::hex(x)" would be a (template)
function that took an integer type and returned a dedicated type that
has an << operator for printing out its value in hex. (And there would
be a Hex version for capitals, functions for floating point data, etc.)
 
> You can't have everything, that is why use printf when more convenient
> :P
 
In C++, you /can/ have everything. You just have to wait for a new
standard. The disadvantage, of course, is that you get /everything/,
including old stuff that with hindsight was not a good idea in the first
place.
olcott <NoOne@NoWhere.com>: Sep 09 09:21AM -0500

On 9/9/2020 1:27 AM, Juha Nieminen wrote:
> << std::setfill('0') << value;
> std::cout.flags(f);
 
> which is, admittedly, a bit ridiculous.
 
Exactly!
 
 
--
Copyright 2020 Pete Olcott
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 08 07:42PM -0700

On 9/8/2020 4:00 PM, Mr Flibble wrote:
> Hi!
 
> Work has begun in earnest on neoGFX Design Studio:
 
> https://neogfx.org/images/designstudio.png
 
Looks pretty slick. :^)
Bonita Montero <Bonita.Montero@gmail.com>: Sep 09 06:10AM +0200

Am 09.09.2020 um 01:00 schrieb Mr Flibble:
> Hi!
> Work has begun in earnest on neoGFX Design Studio:
> https://neogfx.org/images/designstudio.png
 
So much work - and almost no one will use it.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Sep 09 06:25AM +0200

On 09.09.2020 06:10, Bonita Montero wrote:
>> Work has begun in earnest on neoGFX Design Studio:
>> https://neogfx.org/images/designstudio.png
 
> So much work - and almost no one will use it.
 
That's a very mean comment.
 
I sincerely hope that neoGFX gets a large user base.
 
However, there is an example, the Ultimate C++ IDE & framework, where
despite obviously a large investment of work and time, and despite being
open source with a team behind it, it remains a fringe thing. I never
even tried it. <url: https://www.ultimatepp.org/>.
 
So how can Leigh avoid that fate?
 
He's tried creating a video about it, and so on, but I think he needs to
get an established user base. Maybe starting with students and their
teachers. Make available complete examples to try out, make it easy to
install and use the the library (if possible, easier than CMake).
 
- Alf
rick.c.hodgin@gmail.com: Sep 08 09:58PM -0700

On 9/9/20 12:25 AM, Alf P. Steinbach wrote:
>>> https://neogfx.org/images/designstudio.png
 
>> So much work - and almost no one will use it.
 
> That's a very mean comment.
Yes it is.
 
> I sincerely hope that neoGFX gets a large user base.
Leigh's work looks solid. I think he will have a notable success.
 
> teachers. Make available complete examples to try out, make it easy to
> install and use the the library (if possible, easier than CMake).
 
> - Alf
He should accept Jesus Christ as His Lord and Savior, and release the
work open-source allowing people to take his initial offering and then
build a community around it. He should brand it as an offering unto
the Lord, and he would receive a reward for such a gift to people in
Christ's name in Heaven.
 
Serving Jesus in this world is not improper. It's what God expects and
commands us to do. It's only the enemy of God who teaches otherwise.
We do right when we look up to God and do not rely upon ourselves alone,
but instead seek to bring honor and glory to His Kingdom by our choices
here in this fallen-in-sin world.
 
I'm quite serious about this, by the way. Look at how the depravity
in this world is multiplying. In America it's becoming unruly, and I
read it's similar everywhere, even worse in many places.
 
Jesus taught us it would be like this in the end-most times, but that
doesn't mean we're supposed to participate in it. He wants us to still
serve Him in this world, and to shine our light (flex our skills and
abilities) for Him and His Kingdom in this world, not for money or some
other things that will exist only here on Earth and then perish.
 
Think of God when you are deciding what to do with your life. Make
conscious choices to serve and honor Him. You will receive less reward
from your fellow man down here, but you will be doing right in God's
sight and will not lose your reward in eternity.
 
--
Rick C. Hodgin
David Brown <david.brown@hesbynett.no>: Sep 09 09:51AM +0200

On 09/09/2020 06:25, Alf P. Steinbach wrote:
> get an established user base. Maybe starting with students and their
> teachers. Make available complete examples to try out, make it easy to
> install and use the the library (if possible, easier than CMake).
 
(Caveat - I haven't looked much at the library or webpages, simply
because it is not the kind of tool that is useful for me. Most of my
user interfaces are blinking LED's and push-buttons, rather than guis on
a PC. But I can see it being useful to many others, and maybe it will
be useful to me too in the future.)
 
Establishing a user base is certainly key. One thing is that it can
build up a reputation and spread recommendations amongst forums. The
other is that it is vital for feedback and making sure the project is
actually suitable for a wider base. At the moment, reports I have seen
here are all positive about the code and the appearance of the library
and tools so far. But if it is going to be be useful for many people,
then it's important to get many people to test it - otherwise you risk
ending up with a library that is perfect in the eyes of the author while
being awkward or limited in the eyes of others.
 
Another important point is to establish a team. Correct me if I'm
wrong, but this project is Mr. Flibble's alone, with a little outside
help in making some icons. That is not sustainable in the long term.
If people are going to use this system for anything serious, they need
to know that there is a team behind it. They need to know they still
get support and fixes while Mr. Flibble is on holiday, and that the
project will continue if he decides to move to the Andes to become a
llama farmer instead of a programmer. And the project needs people
involved in documentation, graphics design, marketing, etc. (Mr.
Flibble may also be good at these - though the skill sets are usually
somewhat separate - but there are limited hours in the day for any one
person.)
 
All these things are difficult to build up - and they are difficult in a
different way than designing the code and library.
 
 
Building up a base of "amateurs" - small users, students, etc., is one
possible route. But unless he also gets some "power users" who will
help out (without pay) in support forums or groups, there is a risk that
supporting and helping these users will take up too much time and leave
him unable to work on the project itself.
 
My recommendation (easy to say, hard to do!) would therefore be towards
getting a single good commercial corporate user interested in the
library. That would give immediately useful professional feedback on
what other users need from the tools, and a commercial contract. For a
customer company with a bit of size, this could easily have huge
potential savings compared to them buying commercial QT licenses for a
developer group - enough that it is worth the risk for them, even with a
contract size that is a large amount for Mr. Flibble's company. With
that contract in place, he can get other financial investors, hire some
people, and make a serious go of it as a commercial open source product.
 
 
However he does it, I too wish him luck with the project - it has a lot
of potential, and I think Mr. Flibble has enough practicality and
realism to make it work.
Brian Wood <woodbrian77@gmail.com>: Sep 08 06:00PM -0700

On Tuesday, September 8, 2020 at 5:29:32 PM UTC-5, Mr Flibble wrote:
> https://www.youtube.com/watch?v=ayDWlNqQyJg&fbclid=IwAR1BETwpmJIp8kcYV2r1kKtsQ6sk3ljB9wUT1N75YR_9e2lJvxQjxdx7kZ8
 
I don't trust you.
 
 
Brian
Ebenezer Enterprises
https://webEbenezer.net
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 09 02:06AM +0100

https://www.youtube.com/watch?v=dLAi78hluFc
https://www.youtube.com/watch?v=f2z-ahJ4uws
 
--
¬
rick.c.hodgin@gmail.com: Sep 08 06:24PM -0700

On Tuesday, September 8, 2020 at 9:06:43 PM UTC-4, Mr Flibble wrote:
> [snip]
 
Real change comes from the truth, from education:
 
One Race, One Blood
5 yrs ago -- https://www.youtube.com/watch?v=KbODW6XO8zY
2 yrs ago -- https://www.youtube.com/watch?v=n_TR4MHuBRE
 
One Race, One Blood -- The Origin of "Races"
https://www.youtube.com/watch?v=cjfECdgCUIk
 
Only One Biological Race
https://www.youtube.com/watch?v=a5ujsNj_S7g
 
We are all children of God, brothers and sisters. The reason why
there is division is because the enemy sows division between people.
He does it to drive people away from God and keep them from their
God-offered inheritance.
 
You sow division too, Leigh. You seek to make people feel guilty
for things they are not part of, nor have they ever been part of.
 
--
Rick C. Hodgin
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)