Tuesday, March 12, 2019

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

woodbrian77@gmail.com: Mar 12 12:55PM -0700

Shalom
 
https://www.reddit.com/r/cpp_questions/comments/b045qp/porting_code_generator_to_android/
 
 
I'd like to know what to do with Gradle to package it,
and how do you suggest I integrate the new files into my repo?
Thanks in advance.
 
Can anyone point me to a C++ repository that has an executable
that runs on Linux, Windows, and Android? I'm wondering
whether I should use ifdefs to merge everything into one file
or use separate files for Android.
 
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
cdalten@gmail.com: Mar 12 02:54PM -0700

I was always under the impression that Android was more like middleware. This is because I write and test programs on a 64 bit Windows machine. From there I can upload the app directly, via a USB cable, to my $89.99 32 bit MetroPCS phone that I bought by the liquor store. No additional software nor programming is needed to make this happen.
 
And as far as I know, this isn't possible with Linux running on Windows.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Mar 12 08:42AM -0700

> declared. 2) The signature of a function template specialization
> includes the types of its template arguments (14.5.5.1).
> [/quote]
 
Interesting, I didn't know that. But I think that strengthens
the case for preferring the correct term 'type', which is right
for both pre-C++11 and C++11 onwards, to 'signature', which is
wrong in both cases. (Note that the C++98/C++03 definition of
'signature' does not include the return type.) Furthermore,
based on how the term 'signature' was used in C++98/C++03, it
looks like either (a) the definition was meant to include the
function name, or (b) needing the function name was overlooked
when writing the definition. For example, in section 17.4.3.1.3
("External linkage"), paragraph 2 says
 
Each global function signature declared with external
linkage in a header is reserved to the implementation to
designate that function signature with external linkage.
 
This statement makes sense only if 'signature' is understood
to include the function name along with the types of the
parameters.
 
> C++11.
 
> The language independent meaning, and the C++98/C++03 meaning,
> does not include the function name.
 
A more accurate statement is that the term 'signature' means
different things in different languages. The original use of
'signature' in programming languages was, IIANM, in the language
Russell, where it was not associated (directly) with functions.
The ML family of languages uses 'signature' in a different way,
to define module interfaces: the signature of a module might be
called the "type" of that module. I don't know when the ML
languages introduced modules and module signatures; the usage in
Russell predates C++98 by 20 years. It's true that many people
misuse the term "signature" to mean what C and C++ call the type
of a function. But "signature" does not mean, and has never
meant (at least in C++), the same thing as the property that
Richard was alluding to in his comment.
 
> used as part of an in-group language to let language lawyers more
> easily identify each other as such, and to let them identify
> non-lawyers.
 
I think you're misreading the history. Looking at usages in the
C++03 and C++98 standards, it seems clear that it was intended
all along that "signature" include the name of the function in
question. The changes in C++11 were done to correct what had
been an oversight or unintended omission. Furthermore the misuse
of "signature" to mean the type of a function didn't become
commonplace until after the C++98 standard was released. It
isn't that C++98 was following a common usage, and probably the
other way around - it was people misunderstanding the C++98
meaning to equate "signature" with "function type" that caused
"signature" to be widely misused to mean the type of a function.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Mar 12 09:48AM -0700

>> one could be used in place of the other.
 
> This is a difference that makes no difference. Playing language
> lawyer in this circumstance is boring and yields no insight.
 
There is nothing especially language lawyerish about my comment.
Being precise doesn't always imply being a language lawyer.
 
I'm sure some people found my comment boring. As for insight
however I think there are two:
 
(1) IME being careless in use of language correlates with
being careless in programming. I think it's important
to encourage good programming, and this is one aspect
of that.
 
(2) There is a tendency in some people to want to use
fancy words and ornate language. Usually this is a
false erudition. Every writer should read what
Ernest Hemingway wrote on the subject:
 
"Poor Faulkner. Does he really think big emotions come
from big words? He thinks I don't know the ten-dollar
words. I know them all right. But there are older and
simpler and better words, and those are the ones I use."
 
In technical discussions, precise and correct language is
always better than fancy language.
 
And, dare I say it, in comp.lang.c++, normally terms should be
used in the same way that the Standard(s) define them.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Mar 12 05:48AM -0700


>> Compiles fine here.
 
> Interesting. Was I wrong that it's a literal syntax, or are both g++
> and Visual C++ wrong to accept the code?
 
I didn't look, I just tried compiling it. Looking now in n4659,
it looks like the relevant passage is in 11.3.5 p4 (the two "`"
characters added to indicate a code typeface):
 
A parameter list consisting of a single unnamed parameter of
non-dependent type `void` is equivalent to an empty parameter
list.
 
The type X is a not a dependent type (I had to look up dependent
types to know what that meant), so I think this form is blessed
by the standard.
"Fred.Zwarts" <F.Zwarts@KVI.nl>: Mar 12 12:17PM +0100

"Tim Rentsch" schreef in bericht news:86tvg9s3ex.fsf@mailhub.linuxsc.com...
>> for more explanations.
 
>I found this article to be an excellent tutorial. Thank you
>for posting this.
 
Indeed.
James Kuyper <jameskuyper@alumni.caltech.edu>: Mar 11 08:20PM -0400

On 3/11/19 10:38, Stefan Ram wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> I learned how to implement binary trees in C,
 
> Since they say that every C program is a C++ program,
 
Those who say that aren't quite correct. Almost every C program can,
usually with only minor modifications, be converted into a program that
has the same required behavior whether compiled as C code or as C++
code. This is proof that the languages share a common heritage which has
not yet disappeared, but I would not recommend actually writing code
that way. Those changes often involve code that is sub-optimal in one of
the two languages, and possibly in both.
 
> I hope C is not too off-topic here.
 
He explicitly said:
> I'd still be interested to hear if you learned it in C or maybe even Java since those languages can make similar trade offs and are not as distant in memory semantics as say Python or Haskell
 
so mention of C code is entirely appropriate a response to his message.
However, if he's interested in those other languages as well, he should
have changed his question to be directly language independent, and he
should have either posted it in a language-independent forum, or
cross-posted it to all the languages he's interested in.
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)