Friday, June 1, 2018

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

fir <profesor.fir@gmail.com>: Jun 01 07:56AM -0700

to make things somewhat clear ;c and make a bit of foam... i think 'Object Oriented Programming' when you sue it - making objects passing pointers (and yet more unfortunate biuldking more comple trashy patterns - is the new goto... ooop considered harmfull , dont use it as you dont use big gotos
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 01 06:31PM +0100

On 01/06/2018 15:56, fir wrote:
> to make things somewhat clear ;c and make a bit of foam... i think 'Object Oriented Programming' when you sue it - making objects passing pointers (and yet more unfortunate biuldking more comple trashy patterns - is the new goto... ooop considered harmfull , dont use it as you dont use big gotos
 
I wrote an article on a related matter (Law of Demeter) a decade ago:
 
http://i42.co.uk/stuff/spaghetti.htm
 
The Perils of Object Oriented Spaghetti (or Law of Demeter and Singletons)
Law of Demeter or Principle of Least Knowledge is a simple design style
for developing software that purportedly results in a lower coupling
between elements of a computer program. Lower coupling is beneficial as
it results in code which is easier to maintain and understand.
 
It is the opinion of this programmer however that the Law of Demeter is in
fact a load of old toot (rubbish) as it advocates invoking methods on
global objects: this is in contradiction to a "Principle of Least
Knowledge". "For pragmatic reasons" are weasel words. Global variables
(non-constants) are bad, period.
On a related matter singletons are an anti-pattern as well as a pattern;
use rarely not routinely. Singletons are little more than disguised
global variables and do themselves violate a principle of least knowledge
resulting in tighter coupling/hidden dependencies (or object oriented
"spaghetti" code) as well as being problematic for multi-threaded designs.
 
Of course it is not always possible to avoid singletons; one example is
when you have an external entry point into your program other than main
(e.g. a C callback function in a DLL) that doesn't provide context
information via a parameter.
 
____━━____┓━╭━━━━━━╮
____━━____┗┓|::::::::^━━━━^
____━━____━┗|:::::::::|｡◕‿‿ ◕｡|
____━━____━━╰O--O-O--O ╯
18 Dec 2009
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."
Siri Cruise <chine.bleu@yahoo.com>: Jun 01 11:35AM -0700

In article <b00eee21-8cb3-4bfb-a0b7-967379b79966@googlegroups.com>,
> Oriented Programming' when you sue it - making objects passing pointers (and
> yet more unfortunate biuldking more comple trashy patterns - is the new
> goto... ooop considered harmfull , dont use it as you dont use big gotos
 
A finite state machine is most succintly expressed with states as labels and
transitions as gotos. Give the states comprehensible names and write the states
in a consistent notation, and it will be as comprehensible as aught else.
 
The controversy arose because Fortran at that time had very few single-entry
single-exit control structures, so it required particular good discipline and
comments to allow the code modularisation and isolation needed to understand
programmes. Even with single-entry/exit code, you can encode the mess into
variables instead of labels that then have be tracked all over the place. And
now you encode the mess into objects.
 
Good programming then as now requires writing isolateable code with contractual
interfaces that make explicit what is done, in abstract, and make the control
and data transfers explicit. Then the software can be decomposed into small
chunks our monkey brains can cope with.
 
You can code in Fortran 66 no matter what language you use. (I need to finish my
object oriented Fortran 77 (OOF) compiler.)
 
--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
I'm saving up to buy the Donald a blue stone This post / \
from Metebelis 3. All praise the Great Don! insults Islam. Mohammed
David Brown <david.brown@hesbynett.no>: May 31 11:49PM +0200

(Please get a real news client, or fix your line endings if you have to
use Google's broken interface. It makes it a pain for others to sort
out your messed up line breaks.)
 
 
 
>> There is an even simpler (and better) solution: DON'T DECLARE
>> MULTIPLE VARIABLES ON THE SAME LINE.
 
> That's not a solution, it's a workaround.
 
It is a solution to the problem "how should I declare several pointer
variables in a way that won't be confusing?".
 
> T z;
 
> Then that relationship is lost, and it will need more maintenance to
> ensure they stay the same type.
 
That might, occasionally, be a relevant point. I can't speak for Mr.
Flibble, of course, but I would be okay with "T x, y, z;" in such simple
cases. But I am /not/ okay with "char* c, d;" or "char *c, d;" - it is
far too easy to misread these.
 
More commonly, however, you have longer type names (including
qualifiers), initialisers, descriptive variable names, comments, etc.,
which mean putting multiple object definitions on one line becomes a mess.
 
 
 
> So declaring several names with the same type spec is useful.
 
/Occasionally/ useful.
 
 
> The original C syntax however allows you to declare several names
> together but with *different* types (and they can be wildly
> different), which is not useful and is bad practice.
 
Agreed. And for me, that rule includes cases like the sample one here
with a "char" and a "char*".
Lynn McGuire <lynnmcguire5@gmail.com>: May 31 05:55PM -0500

On 5/31/2018 2:19 PM, Mr Flibble wrote:
 
> There is an even simpler (and better) solution: DON'T DECLARE MULTIPLE
> VARIABLES ON THE SAME LINE.
 
> /Flibble
 
+1,000,000
 
Lynn
"Öö Tiib" <ootiib@hot.ee>: May 31 11:28PM -0700

> > VARIABLES ON THE SAME LINE.
 
> That's not a solution, it's a workaround. And comes with a disadvantage; suppose that T includes any pointer, array, or function pointer modifiers, then instead of writing:
 
> T x, y, z;
 
That is supposing code of seventies. Then it was that function calls
were too expensive so program consisted of only few long functions.
Language rules did not let to group related data into structs and all
local variables had to be declared at function start. There it was
too early to initialize any. Giving 4-letter name to something was too
lot of bytes and also pointless since most variables were reused in
different roles during function call.
Only few rocket scientists had enough storage for comments so most
code was write-only.
 
It may be that in your self-developed programming language there are
still those issues and problems. But why should others care about
issues of half of century ago? When to look at actual source code of
software that is written by team then we do not see that pattern
anywhere.
In actual C++ code we often see even function parameter declarations
(when there are several) to be split each to different line, nothing
to talk of local variables.
bart4858@gmail.com: Jun 01 02:35AM -0700

On Thursday, 31 May 2018 22:49:41 UTC+1, David Brown wrote:
> (Please get a real news client, or fix your line endings if you have to
> use Google's broken interface. It makes it a pain for others to sort
> out your messed up line breaks.)
 
(I don't know if it's mine that's broken. My posts look fine via googlgroups. And also (since for some reason I get notified on it) on whatever app is used on my Android phone). Is it that hard for a newsreader to ensure that too-long lines are wrapped properly for display?)
 
--
bartc
Ian Collins <ian-news@hotmail.com>: Jun 01 09:50PM +1200


>> There is an even simpler (and better) solution: DON'T DECLARE MULTIPLE
>> VARIABLES ON THE SAME LINE.
 
> That's not a solution, it's a workaround.
 
It is also a very common coding standard rule.
 
> T y;
> T z;
 
> Then that relationship is lost, and it will need more maintenance to ensure they stay the same type.
 
In that case, put them is a struct/class and manage them as a group.
 
--
Ian.
bart4858@gmail.com: Jun 01 03:20AM -0700

On Friday, 1 June 2018 10:50:51 UTC+1, Ian Collins wrote:
> > T z;
 
> > Then that relationship is lost, and it will need more maintenance to ensure they stay the same type.
 
> In that case, put them is a struct/class and manage them as a group.
 
Are you serious? And even if I did that, surely I would have the same problem of ensuring they are the same type, unless they shared the same type specifier?
 
Here's an example of related identifiers (also an example of single-letter identfiers):
 
int64 evaliandexpr(void) {
int64 x, y;
 
x = evaleqexpr();
while (nextlx.symbol == iandsym) {
lexm();
x &= evaleqexpr();
}
return x;
}
 
Tell me what possible improvement in readability there can be by putting x and y into a managed struct (whatever that actually means). Or with this same code by declaring x and y on different lines (to address another poster's concern). Or by using longer identifiers for x and y (to address yet another).
 
Aren't some people also in favour of having a short function bodies as possible? These suggestions would tend to make them longer.
 
 
--
bart
David Brown <david.brown@hesbynett.no>: Jun 01 12:27PM +0200

> whatever app is used on my Android phone). Is it that hard for a
> newsreader to ensure that too-long lines are wrapped properly for
> display?)
 
It is your end that is broken - Google Group's interface does not follow
the standard Usenet formatting rules. Of course your GG posts look fine
in GG - and perhaps other Google apps - but they are not ideal for
standard newsreaders.
 
Of course, none of this is your fault or unique to you - it is a general
problem with Google Groups, and nothing personal.
 
 
I can't be sure about newsreaders other than Thunderbird, as that's what
I use, but your posts display okay. Thunderbird sees your long lines
from GG (each paragraph is a line) and wraps them to fit the window.
(Other newsreaders may not wrap well for reading either.)
 
But when I reply to your posts, your long lines get quoted as long lines
- quoting should not change the format. When quoted, however, they are
no longer wrapped by newsreaders. Thunderbird has a "re-wrap" command
to help that fixes the line breaks most of the time. But it also
"fixes" code by considering the adjacent lines as a paragraph, putting
them all together into one long line, then breaking that line at 72
character line widths as though it were text.
 
All this means that most people can usually read your posts okay, but
some might find it a pain if their newsreaders don't wrap. And replying
to your posts is extra effort and inconvenience. It is not uncommon in
some newsgroups for people to simply filter out every post made from
Google Groups as being too much effort to bother with.
 
 
If you can, I strongly recommend getting a real newsreader client, and a
real newsserver. People can, and do, argue endlessly about the best
software - I hope to avoid that here. I'll simply say that Thunderbird
is a fine choice for many people - it is free, works on Windows, Macs,
and *nix, and has the features most users need.
news.eternal-september.org is a fine choice of newsserver - again, it is
free. GG is handy if you want to search in archives or look
occasionally at an odd group, but a proper newsreader makes life easier
for the groups you follow.
 
And when you do use GG, you can enter line breaks manually.
bart4858@gmail.com: Jun 01 03:31AM -0700

On Friday, 1 June 2018 07:28:38 UTC+1, Öö Tiib wrote:
> code was write-only.
 
> It may be that in your self-developed programming language there are
> still those issues and problems.
 
That would be an interesting limitation of a programming language to insist on two or more variables declared together!
 
While I haven't recently come across a language where you can only have one-letter identifiers.
 
> issues of half of century ago? When to look at actual source code of
> software that is written by team then we do not see that pattern
> anywhere.
 
Tell me, how would such a team rewrite fragments of code like this:
 
void swap(int* x, int* y){...}
#define MAX(x, y) ...
A[i][j][k]; // inside a 3-nested loop indexed by i,j,k
 
Or the evaliandexpr() routine in my last post.
 
Single letter names are used extensively in mathematics, and for similar reasons they also work for local variables of functions in programming languages.
 
 
--
bart
Ian Collins <ian-news@hotmail.com>: Jun 01 11:11PM +1200


>> In that case, put them is a struct/class and manage them as a group.
 
> Are you serious? And even if I did that, surely I would have the same problem of ensuring they are the same type, unless they shared the same type specifier?
 
> Here's an example of related identifiers (also an example of single-letter identfiers):
 
It's also an example of an unused variable...
 
 
--
Ian.
David Brown <david.brown@hesbynett.no>: Jun 01 01:13PM +0200

> Or with this same code by declaring x and y on different lines (to
> address another poster's concern). Or by using longer identifiers for
> x and y (to address yet another).
 
int64 evaliandexpr(void) {
int64_t x = evaleqexpr();
while (nextlx.symbol == iandsym) {
lexm();
x &= evaleqexpr();
}
return x;
}
 
I'm happy with short identifier names in small contexts. I am not
impressed with short identifier names in a wider context (like "lexm"),
nor by jammedupidentifier styles - use camelCase or under_scores to
split up words.
 
And I can't see any advantage of putting the definition of "x" before
its initialisation. It is not going to make a difference to generated
code here, with a simple type like int64_t, but for more complex C++
types separate definitions then assignments can be a different thing and
lower efficiency than initialisation.
 
Certainly I see no advantage in putting the definition of "y" on the
same line as that of "x", when it is not used at all. Defining your
objects when you need them, and initialising them at the same time,
helps avoid the confusion and possible inefficiency of extra objects
like "y" in this example.
 
 
 
scott@slp53.sl.home (Scott Lurndal): Jun 01 01:11PM


>> T x, y, z;
 
>That is supposing code of seventies. Then it was that function calls
>were too expensive so program consisted of only few long functions.
 
What gives you that impression? Function calls were not expensive
in the 70's. Or in the 60's. Just a simple branch, generally saving
the return address in the first word of the target function (e.g. PDP-8)
or on a stack (Burroughs/IBM mainframes).
 
>Language rules did not let to group related data into structs and all
 
COBOL anyone?
 
>different roles during function call.
>Only few rocket scientists had enough storage for comments so most
>code was write-only.
 
Complete nonsense.
bart4858@gmail.com: Jun 01 07:38AM -0700

On Friday, 1 June 2018 12:13:33 UTC+1, David Brown wrote:
> }
 
> I'm happy with short identifier names in small contexts. I am not
> impressed with short identifier names in a wider context (like "lexm"),
 
'lexm' is a local function in this module, and it is clearly a function because it is followed by (). I don't see the problem.
 
> nor by jammedupidentifier styles - use camelCase or under_scores to
> split up words.
 
I mix and match styles just to break things up. Some names within a project will have underscores, some sets will have a common prefix, others a common suffix, and some both (see below). But all names in the same related set will use the same scheme

> And I can't see any advantage of putting the definition of "x" before
> its initialisation.
 
I have a problem with your version because the important initialisation of x is separated from the rest of the code.
 
I like to separate code that just provides information, like a declaration, from code that actualy does something, like the assigment. The algorithm here is to assign the first lhs term to x then loop for any rhs terms. Your version breaks that up.
 
It also involves the type of x (and y; see below) more than I would like. If one day I decide to change their type, then I would need to change the block of code that expresses the algorithm. As I have it, I could copy and paste that block unchanged into a place where x and y are different types. Or even where they have no types at all (eg. to in a dynamic language where x and y don't even need declaring).
 
 
> objects when you need them, and initialising them at the same time,
> helps avoid the confusion and possible inefficiency of extra objects
> like "y" in this example.
 
This function is one of set of a dozen, all with the same interface, all named 'evalOPexpr', all declaring 'int64 x,y'. Most will use y, in one or two it was dispensed with (such as the one I chose to post), but I yet make use of it in the future.
 
These functions evaluate the operands of a binary operator and it is natural to call those operands x and y.
Daniel <danielaparker@gmail.com>: Jun 01 07:41AM -0700

On Friday, June 1, 2018 at 9:11:56 AM UTC-4, Scott Lurndal wrote:
 
> >That is supposing code of seventies. Then it was that function calls
> >were too expensive so program consisted of only few long functions.
 
> What gives you that impression?
 
Possibly IBM FORTRAN documentation :-)
 
I recall from the late 70's that the IBM FORTRAN documentation contained a description of a function as something you wouldn't use very often, but could be used if you had some common code.
 
Daniel
scott@slp53.sl.home (Scott Lurndal): Jun 01 03:15PM


>> What gives you that impression?
 
>Possibly IBM FORTRAN documentation :-)
 
>I recall from the late 70's that the IBM FORTRAN documentation contained a description of a function as something you wouldn't use very often, but could be used if you had some common code.
 
Fortran (on IBM) was, perhaps atypical. COBOL and ALGOL used
functions/subroutines very heavily (e.g. the COBOL PERFORM verb)
as did more proprietary languages like Burroughs BPL or HP SPL.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 01 06:29PM +0100

>> its initialisation.
 
> I have a problem with your version because the important initialisation of x is separated from the rest of the code.
 
> I like to separate code that just provides information, like a declaration, from code that actualy does something, like the assigment.
 
But this is C++ not C and in C++ there is an important distinction between
initialization and assignment. There are likely many C++ coding standards
that prohibit defining variables without initializing them in the definition.
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."
Ralf Goertz <me@myprovider.invalid>: Jun 01 11:33AM +0200

Am Thu, 31 May 2018 21:25:39 +0300
> and approach a more or less stable level. However, if you have no
> explicit dynamic allocations in your code you probably won't have
> memory fragmentation either.
 
I thought it could have to do with fragmentation but
 
> the recursion depth is limited then it should not grow either.
 
> So I guess there is either a bug in the code you did not show, or a
> bug in the compiler related to recursion (very unlikely).
 
the "bug" assumption is of course correct. It turns out I had two
containers storing the solutions, one a set<Status> ouside BT, one a
vector<Status> within BT which is actually a templated structure I often
use but rarely to find more than one solution. When counting the
solutions I looked at the set<Status> variable not noticing that I also
stuffed every (equivalent or not) solution into the vector.
 
Thanks for taking a look (also to Barry) and sorry for the noise.
woodbrian77@gmail.com: May 31 06:07PM -0700

On Thursday, May 31, 2018 at 1:30:07 PM UTC-5, Scott Lurndal wrote:
> where moving to a newer compiler isn't feasible.
 
> On-line code generators aren't a viable solution - who wants to
> be dependent upon a third-party that may disappear tomorrow?
 
I think those who will consider risking their futures with
Ebenezer will either be individuals or a small company.
Probably someone who knows that G-d has blessed them with
ideas/insights. Perhaps https://duckduckgo.com or maybe
an Israeli company. See http://webEbenezer.net/about.html
for more info.
 
 
Brian
bintom <binoythomas1108@gmail.com>: May 31 09:02PM -0700

On Thursday, May 31, 2018 at 7:43:36 PM UTC+5:30, David Brown wrote:
 
> Unless you have very good reasons not to (and programmer knowledge and
> experience might be a good reason), I'd recommend using at least C++11
> standard for new code - it is a significant step up in the language.
 
The syllabus of our school board (in India) still uses C strings and pre C++98 standards.
 
Next year, we will be moving to Python and things will get more standardized.
Paavo Helde <myfirstname@osa.pri.ee>: Jun 01 08:43AM +0300

On 1.06.2018 7:02, bintom wrote:
 
> The syllabus of our school board (in India) still uses C strings and pre C++98 standards.
 
> Next year, we will be moving to Python and things will get more standardized.
 
Python and standardized? You must be joking!
David Brown <david.brown@hesbynett.no>: Jun 01 09:19AM +0200

> ideas/insights. Perhaps https://duckduckgo.com or maybe
> an Israeli company. See http://webEbenezer.net/about.html
> for more info.
 
Don't mix religion and professional work (unless you work as a minister
or priest). No one cares what religious beliefs you or anyone else
might hold, or whether you see those beliefs as being the inspiration or
purpose behind your work - that is a personal thing. If your site is
worth using professionally, then it is worth using professionally
regardless of the user's beliefs.
David Brown <david.brown@hesbynett.no>: Jun 01 10:40AM +0200

On 01/06/18 07:43, Paavo Helde wrote:
 
>> Next year, we will be moving to Python and things will get more
>> standardized.
 
> Python and standardized? You must be joking!
 
Python has a different sort of standardisation from C++. There is no
ISO committee - but there is a strong Python Foundation. Within the
major versions (1.x, 2.x, 3.x) there is high backwards compatibility.
 
It is impossible to have a language (and standard libraries) where you
have strong standardisation so that any code can work with any system,
and at the same time you have a living language with continuous
improvement and new features. Python and C++ are both languages with
steady growth and change - C is a language with much stronger standards
but far slower rate of change.
 
And for teaching programming, Python is a better choice than C++ -
certainly a vastly better choice than an ancient version of C++.
Vir Campestris <vir.campestris@invalid.invalid>: May 31 11:03PM +0100

On 31/05/2018 19:00, Scott Lurndal wrote:
> side-channel attacks"
 
> There are descriptions of and references to the various side-channel
> attacks via cache timing et alia in that paper.
 
This paper?
 
<http://www.cs.columbia.edu/~simha/preprint_isca12_tw.pdf>
 
That's a much more complete solution to a much wider range of problems,
but one that requires that the CPU is modified.
 
As they say you can't afford to cache flush on every context switch.
There's also no way to flush the branch predictor cache (which I'd
forgotten about TBH) but for the class of attacks which rely on the
pipeline pre-fetching stuff to which the program has no right of access,
which causes detectable changes in the cache, clearing the cache ought
to destroy all that side channel data. Leaving only the branch predictor
(which someone will of course use...)
 
I also feel that killing the process after a few exceptions would be a
good thing to do. Though no doubt there will be a way around that too.
 
After an exception for an illegal access the state of the cache (and the
branch predictor cache) will be different depending on whether the page
accessed did not exist or was blocked, and also depending on the
contents of that page.
 
The attacks I have read about rely on detecting the state of the cache
after the exception.
 
Flushing the cache after such an exception and before returning control
to the user program will destroy that information in the cache.
 
I do not see that such a change would be harmful, and it would block one
class of attacks.
 
Andy
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)