Monday, September 30, 2019

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

queequeg@trust.no1 (Queequeg): Sep 30 12:02PM


>> Thanks! I found it online.
 
> It's funny how casually people just admit to their illegal piracy of
> intellectual property.
 
It's funny how quick people are to jump to wrong conclusions based on
limited input and their own experience.
 
--
https://www.youtube.com/watch?v=9lSzL1DqQn0
Frederick Gotham <cauldwell.thomas@gmail.com>: Sep 30 05:32AM -0700

On Wednesday, September 25, 2019 at 2:16:43 PM UTC+1, Juha Nieminen wrote:
 
> It's funny how casually people just admit to their illegal piracy of
> intellectual property.
 
 
Is piracy theft? Is it stealing?
Bonita Montero <Bonita.Montero@gmail.com>: Sep 30 03:06PM +0200


>> Thanks! I found it online.
 
> It's funny how casually people just admit to their illegal piracy of
> intellectual property.
 
https://www.google.com/search?client=firefox-b-d&q=%22Effective+Modern+C%2B%2B%22+doctype%3Apdf
;-)
David Brown <david.brown@hesbynett.no>: Sep 30 03:30PM +0200

On 30/09/2019 14:32, Frederick Gotham wrote:
 
>> It's funny how casually people just admit to their illegal piracy of
>> intellectual property.
 
> Is piracy theft? Is it stealing?
 
Yes, piracy is theft (and therefore stealing). But copyright abuse is
not piracy, nor is any unlicensed use of intellectual property. (To be
"theft", you have to take something away from the rightful owner, so
making a copy is not theft.) However, accurate terms such as
"unlicensed copyright abuse" do not sound as dramatic as "piracy".
 
Not that there was any suggestion of copyright abuse here - Queequeg
(presumably) found a legitimate website selling the book.
Frederick Gotham <cauldwell.thomas@gmail.com>: Sep 30 07:14AM -0700

On Monday, September 30, 2019 at 2:31:01 PM UTC+1, David Brown wrote:
 
> "theft", you have to take something away from the rightful owner, so
> making a copy is not theft.) However, accurate terms such as
> "unlicensed copyright abuse" do not sound as dramatic as "piracy".
 
 
I can't keep track of the meaning in the paragraph.
queequeg@trust.no1 (Queequeg): Sep 30 02:47PM


>> It's funny how casually people just admit to their illegal piracy of
>> intellectual property.
 
> Is piracy theft? Is it stealing?
 
Fun fact: in my jurisdiction, downloading music, movies or ebooks is
completely legal. Only sharing (therefore, downloading with torrents
qualify) is not. For some reason it's different only with computer
programs and games.
 
--
https://www.youtube.com/watch?v=9lSzL1DqQn0
David Brown <david.brown@hesbynett.no>: Sep 30 04:48PM +0200

On 30/09/2019 16:14, Frederick Gotham wrote:
>> making a copy is not theft.) However, accurate terms such as
>> "unlicensed copyright abuse" do not sound as dramatic as "piracy".
 
> I can't keep track of the meaning in the paragraph.
 
Piracy is theft.
 
Making unlicensed copies, like copying e-books, games, music, etc., that
you are supposed to buy, is not theft. It is illegal, but it is not
theft. And it is certainly not piracy.
 
I hope that answers your original question.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 30 02:02PM +0200

I know alloca() neither is an official part of the C nor C++ program-
ming-language. But I use it for performance-reasons. Can anyone name
compilers that don't support alloca()?
Frederick Gotham <cauldwell.thomas@gmail.com>: Sep 30 07:02AM -0700

On Monday, September 30, 2019 at 1:02:16 PM UTC+1, Bonita Montero wrote:
> I know alloca() neither is an official part of the C nor C++ program-
> ming-language. But I use it for performance-reasons. Can anyone name
> compilers that don't support alloca()?
 
 
I'm curious, can you give an example of where you'd use this?
Bonita Montero <Bonita.Montero@gmail.com>: Sep 30 04:09PM +0200

>> ming-language. But I use it for performance-reasons. Can anyone name
>> compilers that don't support alloca()?
 
> I'm curious, can you give an example of where you'd use this?
 
At a point where I did know I needed only a small variable sized array
of pointers.
Anton Shepelev <anton.txt@g{oogle}mail.com>: Sep 30 05:12PM +0300

Bonita Montero:
 
>C++ programming-language. But I use it for performance-
>reasons. Can anyone name compilers that don't support
>alloca()?
 
At least, it is absent from TCC, but the specific compilers
are of no importance. The problem is that code with
`alloca()' is no longer starndard C and depends on specific
compilers, which harms the freedom of the users of your code
to compile it with *any* C compiler. Are the benefits of
`alloca(I)' worth it? Is not there a reasonably simple
solution within standard C, such as an array, a variable-
length array, or a pre-allocated memory block on the heap?
 
--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
Bonita Montero <Bonita.Montero@gmail.com>: Sep 30 04:16PM +0200

> `alloca()' is no longer starndard C and depends on specific
> compilers, which harms the freedom of the users of your code
> to compile it with *any* C compiler.
 
Depending on the set of compilers that support alloca() this doesn't
count. And usually you have dependencies on functions becond those
of standard-C/C++ anyway.
 
> Are the benefits of `alloca(I)' worth it?
 
Yes, alloca() is fast.
 
> Is not there a reasonably simple solution within standard C,
> such as an array, a variable-length array, or a pre-allocated
> memory block on the heap?
 
VLAs aren't part of C++ and heap-allocations haver a magnitude
higher cost.
scott@slp53.sl.home (Scott Lurndal): Sep 30 02:30PM

>`alloca()' is no longer starndard C and depends on specific
>compilers, which harms the freedom of the users of your code
>to compile it with *any* C compiler.
 
Good grief. 90% of all C code isn't open source and the programmer
is free to use whatever features necessary for the program to
function as required.
 
And, FWIW, alloca() has never been "starndard" C.
Anton Shepelev <anton.txt@g{oogle}mail.com>: Sep 30 05:30PM +0300

Bonita Montero:
 
>Depending on the set of compilers that support `alloca()'
>this doesn't count.
 
I disagree. It is a difference between standard code and
compiler-dependent code. You are forcing users to use
specific compilers, regardless of how large a subset it is.
 
>And usually you have dependencies on functions becond those
>of standard-C/C++ anyway.
 
Those dependencies are available as C code or libraries,
whereas `alloca()' is not and cannot be.
 
>>Are the benefits of `alloca(I)' worth it?
 
>Yes, alloca() is fast.
 
I didn't say it wasn't, but suggested that you consider a
fast solution in standard C. By the way, have you made
certain that dynamic memory allocation would be the
bottleneck of your algorithm?
 
>>C, such as an array, a variable-length array, or a pre-
>>allocated memory block on the heap?
 
>VLAs aren't part of C++ ->
 
You have written to comp.lang.c too.
 
>-> and heap-allocations haver a magnitude higher cost.
 
I proposed to reuse the same heap block in many invocations
of your functions. Sometimes it is possibe.
 
--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
Anton Shepelev <anton.txt@g{oogle}mail.com>: Sep 30 05:33PM +0300

Scott Lurndal to Anton Shepelev:
 
 
>Good grief. 90% of all C code isn't open source and the
>programmer is free to use whatever features necessary for
>the program to function as required.
 
Reliance on compiler features puts the same fetters on free
and commerical code.
 
>And, FWIW, alloca() has never been "starndard" C.
 
You misunderstood my usage of "no longer". I meant that
once you start using alloca() your program is no longer
standard C.
 
--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
Bonita Montero <Bonita.Montero@gmail.com>: Sep 30 04:44PM +0200


> I disagree. It is a difference between standard code and
> compiler-dependent code. You are forcing users to use
> specific compilers, regardless of how large a subset it is.
 
Most programs use platform-specific means; that's rarely an issue.
 
>> those of standard-C/C++ anyway.
 
> Those dependencies are available as C code or libraries,
> whereas `alloca()' is not and cannot be.
 
I only wanted to give an example that you often depend not
only on C or C++. And alloca() is only one of this examples.
 
> I didn't say it wasn't, but suggested that you consider a
> fast solution in standard C.
 
I need it in C++. But the genral issue applies for both C
and C++. So I posted it in both newsgroups.
 
>> VLAs aren't part of C++ ->
 
> You have written to comp.lang.c too.
 
I don't want to discuss VLAs but alloca().
Ian Collins <ian-news@hotmail.com>: Sep 30 04:36PM +1300

On 30/09/2019 09:45, Vir Campestris wrote:
 
> Our coding standard says to use a sensible name - and then stick a
> random 8-digit hex value after it. It even tells you how to derive the 8
> digits if like most of us you are on Linux.
 
Are there any mainstream compilers that don't support #pragma once? It
makes life much simpler.
 
--
Ian.
James Kuyper <jameskuyper@alumni.caltech.edu>: Sep 30 01:11AM -0400

On 9/27/19 10:37 PM, Mark wrote:
> kFavoriteWine xx = XXX_YYY ;
 
> }
> Why does the upper case enumerator collided with the preprocessor macro even though the macro is wrapped in a namespace? Can someone point me to some standard verbiage saying why that's wrong
 
The key point is that preprocessing (including the expansion of macros)
occurs during translation phase 4 (5.2p4). Namespaces aren't recognized
as such until translation phase 8 (5.2p8), and therefore have no effect
on preprocessing.
Frederick Gotham <cauldwell.thomas@gmail.com>: Sep 30 01:34AM -0700

On Saturday, September 28, 2019 at 3:37:42 AM UTC+1, Mark wrote:
> kFavoriteWine xx = XXX_YYY ;
 
> }
> Why does the upper case enumerator collided with the preprocessor macro even though the macro is wrapped in a namespace? Can someone point me to some standard verbiage saying why that's wrong
 
Every source code file (.c, .cpp) in your project gets all of its header files added into it, and the preprocessor performs substitutions. What you're left with is called a translation unit.
 
source file (and it's headers) ------> PREPROCESSOR -------------> translation unit
 
It is the translation units that are then fed into the compiler:
 
translation unit -----------------> COMPILER -------------------> object file
 
And then it is the object files that are fed into the linker:
 
object files -----------------> LINKER --------------------> executable file
Jorgen Grahn <grahn+nntp@snipabacken.se>: Sep 30 12:25PM

On Mon, 2019-09-30, Ian Collins wrote:
>> digits if like most of us you are on Linux.
 
> Are there any mainstream compilers that don't support #pragma once? It
> makes life much simpler.
 
Life is already simple; I think this thread exaggerates the problem.
In a header foo/bar.h in project someproj:
 
#ifndef SOMEPROJ_FOO_BAR_H
 
The include guard will be unique (as an include guard) and very
unlikely to clash with anything else.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Ben Bacarisse <ben.usenet@bsb.me.uk>: Sep 30 02:55PM +0100


> #ifndef SOMEPROJ_FOO_BAR_H
 
> The include guard will be unique (as an include guard) and very
> unlikely to clash with anything else.
 
A handy tip is to start with the H_:
 
#ifndef H_SOMEPROJ_FOO_BAR
 
because SOMEPROJ might begin with E and, at least in C, macro names
beginning with E are reserved for future library versions.
 
--
Ben.
Frederick Gotham <cauldwell.thomas@gmail.com>: Sep 30 02:16AM -0700

On Saturday, September 28, 2019 at 12:55:24 PM UTC+1, Rick C. Hodgin wrote:
 
> When you do, you will find what I'm talking about, and not
> because I say so, but because it's all real.
 
 
Rick, are you doing anything in December from 20th til 30th?
rick.c.hodgin@gmail.com: Sep 30 02:59AM -0700

On Monday, September 30, 2019 at 5:17:06 AM UTC-4, Frederick Gotham wrote:
> > When you do, you will find what I'm talking about, and not
> > because I say so, but because it's all real.
 
> Rick, are you doing anything in December from 20th til 30th?
 
 
Private inquiries can be asked and addressed in email.
 
--
Rick C. Hodgin
Frederick Gotham <cauldwell.thomas@gmail.com>: Sep 30 03:31AM -0700


> > Rick, are you doing anything in December from 20th til 30th?
 
> Private inquiries can be asked and addressed in email.
 
I propose to you that we discuss this publicly in the midst of the disbelievers.
David Brown <david.brown@hesbynett.no>: Sep 30 03:22PM +0200

On 30/09/2019 12:31, Frederick Gotham wrote:
 
>> Private inquiries can be asked and addressed in email.
 
> I propose to you that we discuss this publicly in the midst of the disbelievers.
 
I suspect you'll find the disbelievers will be happier for you to
discuss private inquiries by email.
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)