Tuesday, January 21, 2020

Digest for comp.lang.c++@googlegroups.com - 20 updates in 9 topics

Tim Rentsch <tr.17687@z991.linuxsc.com>: Jan 21 02:09AM -0800

Tiib writes:
 
 
>> That may be interesting but it doesn't address the question
>> I was asking.
 
> Your question was "Why do C++ fans hate the C preprocessor so much?".
 
Yes, and your responses don't speak to that question. They do
explain why you don't like how some people use macros, but
nothing about the macros themselves. My question is about
reactions to the preprocessor (and macros in particular), not
about reactions to how people might misuse it. Do you not
understand the difference?
James Kuyper <jameskuyper@alumni.caltech.edu>: Jan 21 05:14AM -0800

On Tuesday, January 21, 2020 at 5:09:42 AM UTC-5, Tim Rentsch wrote:
> reactions to the preprocessor (and macros in particular), not
> about reactions to how people might misuse it. Do you not
> understand the difference?
 
Do you don't understand that he considers that the way they invite
misuse, might be precisely the thing that he finds objectionable about
macros? That is a problem that involves both the macros and their users,
but you can't change the way most people behave, so it's fair to level
such a criticism against macros themselves. That certainly seems to me
to be the obvious interpretation of his words.
I say this without implying that I share that opinion.
boltar@nowhere.org: Jan 21 04:44PM

On Tue, 21 Jan 2020 02:09:32 -0800
>reactions to the preprocessor (and macros in particular), not
>about reactions to how people might misuse it. Do you not
>understand the difference?
 
The sort of developers who hate macros are the ones who've never had to do
cross platform development.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 21 08:01PM

On Tue, 2020-01-21, boltar@nowhere.org wrote:
...
> The sort of developers who hate macros are the ones who've never had to do
> cross platform development.
 
How about those of us who had to do it, and hated it?
 
By the way, even for that scenario, the preprocessor is overused.
See the "#ifdefs considered harmful" paper.
 
/Jorgen
 
PS. I don't hate macros.
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Daniel <danielaparker@gmail.com>: Jan 21 01:08PM -0800

On Tuesday, January 21, 2020 at 8:14:33 AM UTC-5, James Kuyper wrote:
 
> Do you don't understand that he considers that the way they invite
> misuse, might be precisely the thing that he finds objectionable about
> macros?
 
What is there in C++ that _doesn't_ invite misuse? Even features introduced
comparatively late collide with each other, e.g. uniform initialization and
initializer lists, or with features of the world, e.g. `std::error_category::operator==` and DLL's and shared libraries. It is in the nature of the language.
 
Daniel
boltar@nowhere.org: Jan 21 04:41PM

On Mon, 20 Jan 2020 17:58:37 +0000
>> documentation, please let me know.
 
>Why on Earth do you think I would want to help a bigot who hates all that I
>stand for? Talk about blinkered.
 
What is it you stand for exactly?
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 21 05:35PM


>> Why on Earth do you think I would want to help a bigot who hates all that I
>> stand for? Talk about blinkered.
 
> What is it you stand for exactly?
 
Women's rights and gay rights.
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne 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."
Juha Nieminen <nospam@thanks.invalid>: Jan 21 08:24AM

>> //------------------------------
 
> Doesn't matter if this is valid or not because no one does
> such stupid things.
 
I am tempted to use less-than-pleasant words as a response, but I think
I will abstain. Instead, I will present an actual real-life situation where
such a thing is useful.
 
When programming with something that uses OpenGL, and thus GLSL for shaders,
the shaders are their own programming language inside strings. You could have
these GLSL sources in separate files, or you could have them as string literals
inside your program. The advantage of having them as string literals is that
you don't need to include extraneous files in your project (which may even be
easily modified by somebody), and you can build your strings from parts.
 
If there's some common GLSL code that could be useful in several shaders, you
can create string literales by concatenating separate ones. One easy way to do
that is to use macros for the string literals containing common code.
 
So you could have something like:
 
#define GLSL_COMMON_FUNC R"#(
float func(float) {
... whatever ...
}
)#"
 
After which you can create a shader using that function like
 
const char* const myShader = GLSL_COMMON_FUNC
"void main() { etc etc }"
 
Sure, you could just add the \ symbols at the end of each line in the macro,
but why bother, if you don't have to?
boltar@nowhere.org: Jan 21 04:43PM

On Tue, 21 Jan 2020 08:24:22 -0000 (UTC)
> ... whatever ...
>}
>)#"
 
Not with Clang you can't:
 
t.c:3:27: warning: missing terminating '"' character [-Winvalid-pp-token]
#define GLSL_COMMON_FUNC R"#(
^
t.c:7:1: error: expected identifier or '('
)#"
^
t.c:7:3: warning: missing terminating '"' character [-Winvalid-pp-token]
)#"
 
Is this a gcc extension?
Paavo Helde <myfirstname@osa.pri.ee>: Jan 21 07:25PM +0200

> t.c:7:3: warning: missing terminating '"' character [-Winvalid-pp-token]
> )#"
 
> Is this a gcc extension?
 
https://godbolt.org/ shows that this compiles fine with clang 6.0.0 and
later. Clang 5.0.0 indeed fails - it looks like it's time to upgrade,
the current version is 9.0.0.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Jan 21 03:11AM -0800


> There's not a lot of difference there (basically all the same
> lines of code, except that the "if" in the bubble sort has been
> folded into insertion sort's inner loop termination test).
 
The first function body is shorter but that doesn't mean it is
simpler. The loop invariants in the first function are more
complicated than those in the second function. Also I think
you're being unfair in how the two function bodies are written.
In most cases bubble sort is presented using a "swap()" function
to exchange two elements. There are a few other deficiencies,
relative to how the InsertionSort function is written, for the
coding in the BubbleSort function. It's easy, and I think more
usual, to present bubble sort something like this:
 
void BubbleSort(int a[], int length)
{
int n, i;
 
for (n = length; n > 1; n--)
for (i = 1; i < n; i++)
if (a[i-1] < a[i])
swap( a, i-1, i );
}
 
Writing bubble sort this way also illustrates a key difference
between the two: swap() is a simple and easy-to-understand
abstraction. There is no analogous abstraction for the key
operation in insertion sort. That lack isn't just accidental.
 
> has been done in a pass, adding more code (and if you don't, the
> usual claim that bubble sort works well on already sorted files is
> false). [...]
 
More apples-and-oranges. Of course bubble sort can be enhanced
in that way, but the main point of doing so is to show that the
enhancement doesn't buy much. In contrast, the common follow-on
to insertion sort -- using binary search to find the insertion
point -- offers a significant theoretical (and often practical)
advantage, in that there is now an O( n log n ) bound on the
number of comparisons done. No one is arguing that bubble sort
is a better practical choice for actual coding; insertion sort
is clearly better, on several different axes. But supporting
that argument by claiming insertion sort is simpler than bubble
sort is overreaching. It's better, in the sense of making a more
convincing argument, to admit that bubble sort is simpler, and
then go on to explain that despite the relative simplicity of
bubble sort, insertion sort (or sometimes others, depending on
circumstances) is a better practical choice, for several reasons
that are compelling and also clearly defensible.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Jan 21 03:04PM


> Robert Wessel <robertwessel2@yahoo.com> writes:
<cut>
> between the two: swap() is a simple and easy-to-understand
> abstraction. There is no analogous abstraction for the key
> operation in insertion sort. That lack isn't just accidental.
 
Some people would say you can write insertion sort using only swap:
 
for (int i = 1; i < length; i++)
for (int j = i; j > 0 && a[j-1] < a[j]; j--)
swap(a, j-1, j);
 
and some people would not call your example bubble sort because it has
no "almost sorted" advantage. These discussions often end up a bit
ungrounded because the terms are not exact.
 
And if you don't want to do the insert using swaps, why not write an
insert function? In what way would that not be an easy-to understand
abstraction? Although insert is more complex that swap, it has the
effect of cutting the complexity of the sort function in half: one loops
inserts each element into a growing sorted array; inserting each element
needs a simple loop.
 
<cut>
--
Ben.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Jan 21 02:01AM -0800

> 2: simple, unadorned, blunt.
> So I feel that "bald assertion" carries what I meant.
> So it makes me unsure about what you complain.
 
Because I think the phrase doesn't convey the meaning you want
to convey. Or to say that another way, what you think the
phrase says is not how many or most people will read it.
 
(Incidentally, I wouldn't call my comment a complaint, but
that isn't important, just saying fyi.)
James Kuyper <jameskuyper@alumni.caltech.edu>: Jan 21 06:00AM -0800

On Tuesday, January 21, 2020 at 5:01:26 AM UTC-5, Tim Rentsch wrote:
> 嘱 Tiib <ootiib@hot.ee> writes:
...
 
> Because I think the phrase doesn't convey the meaning you want
> to convey. Or to say that another way, what you think the
> phrase says is not how many or most people will read it.
 
123456789012345678901234567890123456789012345678901234567890123456789012
As Öö Tiib has already mentioned, Wikipedia says that "bald assertion"
means a statement used "without proof or evidence of truth". Wiktionary
<https://en.wiktionary.org/wiki/bald> gives two meanings for bald that
specifically apply to statements: meaning #4 is "Unembellished", and
meaning #5 is "Without evidence or support being provided.". Meaning #5
can be seen as a special case of meaning #4 - the missing embellishments
include the evidence and support.
When I do a general Google search for "bald assertion", all of the top
hits support either meaning #4 or #5.
In 56 years of reading English, I can't remember ever having read a use
of "bald assertion" that didn't match meaning #5. I don't remember it
ever being used to point out the lack of any kind of embellishment other
than the lack of a supporting argument.
 
So what is it that you claim is the correct meaning of the phrase, one
that you don't think he meant when he used that phrase?
Tim Rentsch <tr.17687@z991.linuxsc.com>: Jan 21 05:31AM -0800

> use the variable name to indicate its purpose, the Hungarian
> decoration introduced some kind of naming convention with this
> respect.
 
In languages with static typing, type names can (and IMO should)
be used to indicate the purpose of identifiers declared with
those type names. Redundantly adding type or purpose information
to an identifier name is, well, redundant.
 
These comments don't apply to the orginal context (BCPL) of
Hungarian notation, since BCPL doesn't have any notion of
static typing.
 
> For example, I read it was initially used to identify the coordinate
> system some point would belong to (page, print margins, ...) in MS
> Office applications.
 
Hungarian notation predates Microsoft as a company, let alone
Microsoft word. It may be the case the Hungarian notation was
used to indicate a coordinate value (as opposed to, say, a string
length), but it was certainly not initially in any Microsoft
product.
Bonita Montero <Bonita.Montero@gmail.com>: Jan 21 12:53PM +0100

>     }
>     else
>         return code & _XABORT_RETRY ? 0 : -1;
return (code & (_XABORT_RETRY | _XABORT_EXPLICIT)) ==
_XABORT_RETRY ? 0 : -1;
> }
 
Otherwise aborted transaction will be returned as retryable.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Jan 21 02:03AM -0800

Tiib writes:
 
 
>> When T1 is 'int' and T2 is 'base' (aka 'struct base'), which of these
>> categories do you think applies?
 
> T1 is also 'base' so (a) applies.
 
No, it isn't. It appears that either you haven't been listening
or you aren't thinking clearly.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Jan 21 03:47AM -0800


>> In C there is often benefit to have a "stub" type that serves
>> mainly to differentiate the "concrete" types. AFAICT in C++
>> there is not, except perhaps as some sort of aid to the reader.
 
I should elaborate on this. In C, if there is a union with several
structs as members, it's okay to access a member in the common
initial sequence of a struct actually in a union object, __given
only a pointer to the struct__ (assuming the full definition of the
union is visible). In C++, I believe the "common initial sequence"
rule applies only when using the union type as part of the access
expression. The C++ rule is a significantly weaker guarantee than
the C rule. To me it seems to rob the feature of much of its
value, even not counting the incongruity with the C rule. At this
point there are so many differences between C and C++ that it seems
inappropriate to say C is a subset of C++, even just mostly.
 
> API is great for this. C++ can have some issues wrt creating, say
> .so, or .dlls.
 
> A C binding is okay with me.
 
Be warned: the different treatments, by C and by C++, of the
union "special guarantee", might mean that calling through a C
binding may result in undefined behavior in C++, even if the
C code is well-defined by the C standard. It isn't clear to me
what the implications of C++'s rules are in this area, and in
particular whether a C++ implementation may be allowed to make
some assumptions that would not be allowed under the C rules.
I'm sorry I don't have any better advice to offer other than
it would be wise to tread cautiously.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 20 11:52PM

On 20/01/2020 21:58, Chris M. Thomasson wrote:
>>> expert in every single feature? ;^)
 
>> He is probably sarcastic, trolling, or both.
 
> I most likely just consumed a sarcastic sandwich! Humm, tastes like sausages. ;^)
 
https://www.youtube.com/watch?v=9lru1Qxc1l8
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne 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."
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 20 03:56PM -0800

On 1/20/2020 3:52 PM, Mr Flibble wrote:
 
>> I most likely just consumed a sarcastic sandwich! Humm, tastes like
>> sausages. ;^)
 
> https://www.youtube.com/watch?v=9lru1Qxc1l8
 
I see.
 
Your not a cop! SkinJobs, any compassion? Your little people, perhaps
because he is not corrupt?
 
Nothing wrong with a synthetic.
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)