Thursday, April 30, 2020

Fwd: Dancing... of an unusual sort



Sent from my iPad

Begin forwarded message:

From: Sharon Kahn <sharon62kahn@gmail.com>
Date: April 30, 2020 at 7:03:14 PM CDT
Subject: Fwd: Dancing... of an unusual sort






Posted by at No comments:

Digest for comp.lang.c++@googlegroups.com - 19 updates in 3 topics

Juha Nieminen <nospam@thanks.invalid>: Apr 30 06:19AM

> (IMHO both C and C++ should have made internal linkage the default for
> all data and functions from the start, and required an explicit "extern"
> for external linkage, but it's far too late to fix that!)
 
I think that there's a slight problem with that in that if you define a
const variable in a header file, if it has internal linkage by default,
it will be duplicated in every compilation unit where it's used (unless
the compiler can "inline" it).
 
This *is* actually a slight problem in C++, IMO. It's easy to put
something like
 
namespace MySpace
{
const std::vector<int> values = { 1, 2, 3, 4 };
}
 
in a header file without realizing that the vector will be duplicated in
all compilation units where it's used, and thus duplicated that many times
in the executable binary (unless the compiler somehow optimizes this).
 
Of course nowadays we can declare it as 'inline' which solves the problem,
but that has to be explicitly specified, and it needs compiler support.
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 30 06:57AM

> in the executable binary (unless the compiler somehow optimizes this).
 
> Of course nowadays we can declare it as 'inline' which solves the problem,
> but that has to be explicitly specified, and it needs compiler support.
 
What's difference if `inline`?
 
 
--
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>: Apr 30 09:20AM +0200

On 30/04/2020 08:19, Juha Nieminen wrote:
> const variable in a header file, if it has internal linkage by default,
> it will be duplicated in every compilation unit where it's used (unless
> the compiler can "inline" it).
 
You put const definitions in a header if you are happy to have them
duplicated - if not, you put the definition and initialisation in a
single file and make the "const" external. The C++ "default to static"
rule for const is so that you can easily use "const int noOfThings = 4;"
instead of C-style "#define noOfThings 4". The expectation is that the
const objects defined in a header have less than zero cost - they don't
take up space, they don't require run-time initialisation, and they get
folded into code just like a literal constant.
 
If you are putting large "const" data in headers, then surely you /know/
that this will may take duplicate space?
 
It can still be a useful thing that people want to do - hence the trick
of using static members in a template, and then the much nicer step of
adding inline variables to the language.
 
 
> in a header file without realizing that the vector will be duplicated in
> all compilation units where it's used, and thus duplicated that many times
> in the executable binary (unless the compiler somehow optimizes this).
 
Do people do this sort of thing without realising the consequences?
 
Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 30 07:58AM

On Thu, 2020-04-30, David Brown wrote:
> On 30/04/2020 08:19, Juha Nieminen wrote:
...
 
>> all compilation units where it's used, and thus duplicated that many times
>> in the executable binary (unless the compiler somehow optimizes this).
 
> Do people do this sort of thing without realising the consequences?
 
Looks like something I might easily do. I'm weak in this area (but
not weaker than my coworkers, I think).
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
David Brown <david.brown@hesbynett.no>: Apr 30 01:01PM +0200

On 30/04/2020 09:58, Jorgen Grahn wrote:
 
>> Do people do this sort of thing without realising the consequences?
 
> Looks like something I might easily do. I'm weak in this area (but
> not weaker than my coworkers, I think).
 
Perhaps it is just that for my type of work, I think about such
efficiencies all the time - and thus don't make that kind of mistake.
(I make other mistakes instead :-) )
Tim Rentsch <tr.17687@z991.linuxsc.com>: Apr 30 04:49AM -0700


> One curious difference between C and C++, which I only learned the
> details of recently, is the difference in semantics of a const
> variable at the global scope. [elaboration]
 
Right. I did actually think of this one, but it didn't
pop up in my test compiles so I forgot to include it.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Apr 30 04:59AM -0700


> Since C libraries often use more than just function declarations,
> C++ still needs to support eg. C style structs, typedefs, etc.
> Breaking compatibility with C libraries would be a huge setback.
 
What I would like to see is for C++ to define how extern "C" blocks
work so that inside extern "C" { ... } what is accepted is C syntax,
and for that part of the source uses C semantics. If this were
done it is then trivial to write C headers that C++ can #include,
and guaranteed that what they do in C++ is the same as what they do
in C. Since it is C++ that wants to include C headers, and not the
other way around, it is C++ that should more of the heavy lifting
needed to get that to happen.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Apr 30 05:08AM -0700


> Since C libraries often use more than just function declarations,
> C++ still needs to support eg. C style structs, typedefs, etc.
> Breaking compatibility with C libraries would be a huge setback.
 
Postscript: I wouldn't mind adding a construct in C so that
 
extern "C" {
...
}
 
were accepted as C source, with the same effect as leaving off
the enclosing tokens. Surely it is almost no effort to add such
a rule to the language, and it would make writing C++-compatible
headers even easier. This idea, coupled with the suggestion
given in my other posting, is all that is needed to "harmonize"
C and C++ as far as headers are concerned.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 30 07:53PM

On Thu, 2020-04-30, David Brown wrote:
>> not weaker than my coworkers, I think).
 
> Perhaps it is just that for my type of work, I think about such
> efficiencies all the time - and thus don't make that kind of mistake.
 
That's surely part of it: I work with large and old programs where the
worst inefficiencies are in the I/O, and the other inefficiencies are
lost in the background noise.
 
(Although in a recent hobby project, I kicked out std::regex when I noticed
it doubled the code segment size.)
 
> (I make other mistakes instead :-) )
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Apr 30 02:18PM -0700

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
> in C. Since it is C++ that wants to include C headers, and not the
> other way around, it is C++ that should more of the heavy lifting
> needed to get that to happen.
 
Interesting idea, but I'm not convinced that requiring C++ compilers to
handle
extern "C" {
int *class = malloc(sizeof 'A');
}
would be worth the implementation effort.
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 30 07:19PM -0400

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
> in C. Since it is C++ that wants to include C headers, and not the
> other way around, it is C++ that should more of the heavy lifting
> needed to get that to happen.
 
Interesting - that would turn a popular misconception into reality,
which might qualify as an argument in favor of the idea.
 
However, code inside an extern "C" {} block has had C++ semantics for at
least as long as those semantics have been different from C semantics
(early versions of C++ were simply "C with classes" - the semantics
weren't very different at that time). As a result, a fair amount of code
has been written that either accidentally or intentionally depends upon
that fact. As a result, such a change would probably break a fair amount
of existing code.
 
There's another closely related problem. I get the impression that
you're thinking primarily in terms of using extern "C" function
declarations in C++ code to give that C++ code the ability to call
functions implemented in C. However, you're also allowed to provide
extern "C" definitions for C++ functions that are callable from C. I'm
assuming, in particular, that "C semantics" would prohibit calling
functions declared with other language linkages. If that's not the case,
you need to more precisely specify what you mean by "C semantics".
 
If the C++ standard were modified as you describe, how could such code
be re-written?
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Apr 29 10:47PM -0400

Vir Campestris wrote:
 
> (I'd be happier if the parameter was a Collection<Object> for better type safety)
 
> Any ideas?
 
> Andy
 
This seems to work for me:
 
#include <iostream>
#include <vector>
#include <list>
 
using namespace std;
 
struct Object {
};
 
ostream&
operator<<(ostream &os, const Object &o)
{
return os << "Object " << (void*)&o;
}
 
vector<Object> vec{Object(), Object()};;
list<Object> lst{Object(), Object(), Object()};
 
template <typename Collection, typename T = typename Collection::value_type>
ostream&
operator<<(
ostream& o,
const Collection& objects) {
for (const T & e: objects)
o << e << '\t';
return o;
}
 
int
main(int, char*[])
{
cout << vec << ' ' << lst << endl;
return 0;
}
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 30 06:39AM +0200

On 30.04.2020 04:47, Pavel wrote:
> cout << vec << ' ' << lst << endl;
> return 0;
> }
 
Detecting that a type is a collection type, without false positives, is
difficult. Consider that e.g. `std::is_same` is an
`std::integral_constant<bool, V>` with V either `true` or `false`. This
is a type with a `value_type`, and implicit conversion to `bool`:
 
 
----------------------------------------------------------------
#include <iostream>
#include <type_traits>
using namespace std;
 
auto main()
-> int
{
cout << boolalpha;
cout << is_same<short, short>() << endl; // "true"
cout << is_same<short, long>() << endl; // "false"
}
----------------------------------------------------------------
 
 
But with your `operator<<` template in the picture it will be selected
to output those `std::integral_constant` instances, and treating those
instances as collections will just fail to compile.
 
So, instead, check for the features that are actually used.
 
The following appears to work for standard library collections:
 
 
template <typename Collection, typename T = typename
Collection::const_iterator>
ostream&
operator<<(
ostream& o,
const Collection& objects) {
for (const auto& e: objects)
o << e << '\t';
return o;
}
 
 
However, for a more general solution I think I would define a general
thin wrapper type à la `std::reference_wrapper` to use as argument, and
let the client code explicitly specify (via use of that wrapper type)
that it wants to invoke the for-collections overload of `<<`.
 
Simply, explicit = good, implicit = not so good, in general.
 
 
- Alf
Juha Nieminen <nospam@thanks.invalid>: Apr 30 06:24AM

> Detecting that a type is a collection type, without false positives, is
> difficult.
 
Would C++20 concepts help here?
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 30 01:10PM +0200

On 30.04.2020 08:24, Juha Nieminen wrote:
>> Detecting that a type is a collection type, without false positives, is
>> difficult.
 
> Would C++20 concepts help here?
 
I hope so. But I don't know. Sorry.
 
- Alf
Vir Campestris <vir.campestris@invalid.invalid>: Apr 30 09:26PM +0100

On 30/04/2020 05:39, Alf P. Steinbach wrote:
> thin wrapper type à la `std::reference_wrapper` to use as argument, and
> let the client code explicitly specify (via use of that wrapper type)
> that it wants to invoke the for-collections overload of `<<`.
 
It's a little hacky project I'm doing purely for my own amusement. It
doesn't need to be clean really :)
 
But thank you both. It was annoying me!
 
Andy
Ralf Goertz <me@myprovider.invalid>: Apr 30 03:46PM +0200

Hi,
 
I just noticed that std::filesystem::copy_options::overwrite_existing
doesn't have an effect using gcc 9.3.0 under windows but works fine
under linux. That is, the program
 
#include <filesystem>
 
int main() {
std::filesystem::copy_file("foo","bar",std::filesystem::copy_options::overwrite_existing);
}
 
throws with
 
terminate called after throwing an instance of 'std::filesystem::__cxx11::filesystem_error'
what(): filesystem error: cannot copy file: File exists [foo] [bar]
 
provided that the regular files "foo" and "bar" exist. Under linux this
only happens if I omit the copy option. Since this is such a trivial
thing and I don't find any reports on gcc's bugzilla I wonder if this
behaviour is standard conforming. But then there is also nothing on
cpprefererence.com on that (AFAICT). Can this really be a bug?
James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 30 10:37AM -0400

On 4/30/20 9:46 AM, Ralf Goertz wrote:
> thing and I don't find any reports on gcc's bugzilla I wonder if this
> behaviour is standard conforming. But then there is also nothing on
> cpprefererence.com on that (AFAICT). Can this really be a bug?
 
The standard only allows an implementation to "Report a file already
exists error as specified in 30.10.7 if:
(4.1.1) — !is_regular_file(from), or
(4.1.2) — exists(to) and !is_regular_file(to), or
(4.1.3) — exists(to) and equivalent(from, to), or
(4.1.4) — exists(to) and
(options & (copy_options::skip_existing |
copy_options::overwrite_existing |
copy_options::update_existing)) == copy_options::none"
 
Do any of those possibilities apply? If not, it's a bug.
Paavo Helde <eesnimi@osa.pri.ee>: Apr 30 10:58PM +0300

30.04.2020 16:46 Ralf Goertz kirjutas:
> thing and I don't find any reports on gcc's bugzilla I wonder if this
> behaviour is standard conforming. But then there is also nothing on
> cpprefererence.com on that (AFAICT). Can this really be a bug?
 
FWIW, compiling this program with my Cygwin gcc 9.3.0 in Windows works
as expected (copies the file).
 
Note that in Windows the files may be easily locked by other programs
(including non-obvious ones like virus scanners) so that they cannot be
deleted (though in this case the error message should probably be
something like "Access denied").
 
In Unix world file deletion means just a refcount drop in inode which
has a much better chance to succeed. To cope with that deficiency there
is even a special Windows feature (MoveEx) to schedule files for
deletion on next restart.
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:

Digest for comp.programming.threads@googlegroups.com - 1 update in 1 topic

Amine Proffet <amineisthetrueprophetofgod@gmail.com>: Apr 29 10:20PM -0700

> The only thing I believe is that you don't have any sex.
 
Amine is a prophet of God! He does not partake in whimsical fancies of flesh!
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.programming.threads+unsubscribe@googlegroups.com.
Posted by at No comments:

Wednesday, April 29, 2020

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

Vir Campestris <vir.campestris@invalid.invalid>: Apr 29 09:49PM +0100

I've got a bit of code where I want to serialise collections of Objects.
 
I have for example
 
std::vector<Object> vec;
std::list<Object> lst;
 
It seems to me as if I should be able to write an operator<< to write
them out something like
 
template <typename Collection>
std::ostream& operator<<(
std::ostream& o,
const Collection& objects) {
for (auto e:objects)
o << e << '\t';
return o;
}
 
But I can't find a syntax that works. That one above will build - except
then the compiler can't work out which operator<< to use. I'm not
convinced it's even considering that one.
 
(I'd be happier if the parameter was a Collection<Object> for better
type safety)
 
Any ideas?
 
Andy
Juha Nieminen <nospam@thanks.invalid>: Apr 29 08:01AM

> there is some sort of significant common ground between them.
> Thirty years ago there was, but now there isn't, and it's time to
> move on.
 
At a very minimum enough compatibility would be good to maintain that
C libraries can be used directly from C++ (with a simple extern "C" {}
declaration of the C stuff).
 
Since C libraries often use more than just function declarations,
C++ still needs to support eg. C style structs, typedefs, etc.
Breaking compatibility with C libraries would be a huge setback.
Juha Nieminen <nospam@thanks.invalid>: Apr 29 08:10AM

> Certainly there are ones I didn't think of until just recently
> when I ran a piece of C code through a C++ compiler. Some of
> the obvious problems:
 
One curious difference between C and C++, which I only learned the
details of recently, is the difference in semantics of a const
variable at the global scope.
 
For example, if you have this in one compilation unit:
 
extern const char* const gName;
 
and this in another compilation unit:
 
const char* const gName = "Name";
 
and try to use that gName in that first compilation unit, in C it will
compile fine, but in C++ you'll get a linker error about "gName" not
being found.
 
The reason for this is that in C a const at the global scope has
external linkage by default, while in C++ it has internal linkage.
In other words, in C++
 
const char* const gName = "Name";
 
is the same thing as
 
static const char* const gName = "Name";
 
while in C it's not. In order to define that variable with external
linkage in C++ you have to say it explicitly:
 
extern const char* const gName = "Name";
 
(The same is true for consts inside a namespace. In this case "global scope"
also means "namespace scope".)
David Brown <david.brown@hesbynett.no>: Apr 29 11:15AM +0200

On 29/04/2020 10:10, Juha Nieminen wrote:
 
> extern const char* const gName = "Name";
 
> (The same is true for consts inside a namespace. In this case "global scope"
> also means "namespace scope".)
 
Yes. But this is easily solved by the common practice of declaring any
data that needs external linkage with an "extern" declaration in a
header file, and including that header both from the file that defines
the object, and any file that uses it.
 
(IMHO both C and C++ should have made internal linkage the default for
all data and functions from the start, and required an explicit "extern"
for external linkage, but it's far too late to fix that!)
Lynn McGuire <lynnmcguire5@gmail.com>: Apr 28 07:43PM -0500

On 4/28/2020 6:04 PM, Ian Collins wrote:
 
>> I like explicitly initializing variables since I have been so burned in
>> the past.  Just an old Fortran hacker writing C++.
 
> What did your "expert" claim is wrong with the code?
 
The string and int initializations were not allowed. Others in the
above postings said those came about in the C++2011 spec.
 
Lynn
Ian Collins <ian-news@hotmail.com>: Apr 29 12:47PM +1200

On 29/04/2020 12:43, Lynn McGuire wrote:
 
>> What did your "expert" claim is wrong with the code?
 
> The string and int initializations were not allowed. Others in the
> above postings said those came about in the C++2011 spec.
 
Okay, so Juha's guess was on the money!
 
--
Ian.
Lynn McGuire <lynnmcguire5@gmail.com>: Apr 28 08:54PM -0500

On 4/28/2020 7:47 PM, Ian Collins wrote:
 
>> The string and int initializations were not allowed.  Others in the
>> above postings said those came about in the C++2011 spec.
 
> Okay, so Juha's guess was on the money!
 
I am sorry that I did not make that clear.
 
And I got hung out by my Open Watcom pre C++2011 compiler which refused
the class variable initializations. So I got to put in a #ifndef. Lovely.
 
class ExcelSelection
{
public:
#ifndef __WATCOMC__
std::string spreadsheetName = "";
std::string sheetName = "";
std::string beginRow = "";
std::string beginColumn = "";
std::string endRow = "";
std::string endColumn = "";
bool isRange = false;
#else
std::string spreadsheetName;
std::string sheetName;
std::string beginRow;
std::string beginColumn;
std::string endRow;
std::string endColumn;
bool isRange;
Posted by at No comments:

Tuesday, April 28, 2020

Digest for comp.lang.c++@googlegroups.com - 15 updates in 3 topics

Lynn McGuire <lynnmcguire5@gmail.com>: Apr 27 10:41PM -0500

Is this class variable initialization legal ?
 
class ExcelSelection
{
public:
std::string selectionSpreadsheetName = "";
std::string selectionSheetName = "";
std::string selectionBeginRow = "";
std::string selectionBeginColumn = "";
std::string selectionEndRow = "";
std::string selectionEndColumn = "";
int isRange = false;
public:
};
 
My C++ expert on staff says no. I say yes since Visual C++ 2015 likes it.
 
Thanks,
Lynn
Ian Collins <ian-news@hotmail.com>: Apr 28 03:53PM +1200

On 28/04/2020 15:41, Lynn McGuire wrote:
> public:
> };
 
> My C++ expert on staff says no. I say yes since Visual C++ 2015 likes it.
 
What does your "expert" claim is wrong with it?
 
By the way, you don't need to initialise the strings.
 
--
Ian.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 28 06:55AM +0200

On 28.04.2020 05:41, Lynn McGuire wrote:
> public:
> };
 
> My C++ expert on staff says no.  I say yes since Visual C++ 2015 likes it.
 
The explicit initializations of the strings have the same effect as the
default initialization, so it's verbosity that IMO is best removed.
 
The `isRange` member is evidently intended to be a `bool`, not an `int`,
so that's a likely typo (although it could be a thinko, but anyway
better fix).
 
It's generally a good idea to adopt a special naming convention for
non-`static` data members. Boost uses an underscore suffix. I use prefix
`m_` because that supports auto-complete in various editors.
 
However, for a simple pure data class with just public data members and
nothing else, I don't use such prefixes, but then instead of `class` and
`public:` I just use `struct`. To my mind that communicates the intended
usage much more clearly. It's also shorter, and it's idiomatic (so much
that the Holy Standard™ defines terms like `standard-layout struct`).
 
Whether explicit namespace qualification is good or bad or doesn't
matter is debatable and most people have strong opinions. I see such
qualifications as being very much in violation of the Don't Repeat
Yourself principle, i.e. this is decidedly not DRY code. To improve the
DRY-ness I would put that class in a namespace with a `using
std::string` in that namespace.
 
namespace excel {
using std::string;
 
struct Selection
{
string spreadsheet_name;
string sheet_name;
string begin_row;
string begin_column;
string end_row;
string end_column;
bool is_range = false;
};
} // namespace excel
 
Apart from these clarity issues the code is technically OK as of C++11
and later.
 
 
- Alf
Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 28 05:47AM

On Tue, 2020-04-28, Lynn McGuire wrote:
> int isRange = false;
> public:
> };
 
To add to the style advice you didn't ask for:
 
- I'd remove the "selection" prefix from the ExcelSelection members.
People use redundancy in names a lot, but it confuses me: I read it
in this case as a second level of selection within the selection,
and have to stop and read again more carefully[0].
(Alf also removed them in his rewrite, but didn't comment on
it I think.)
 
- I'd wrap (row, column) pairs and call them a Position, or CellName,
or something (I'm not so familiar with Excel). That kind of
refactoring is cheap and IME very helpful.
 
struct ExcelSelection {
std::string spreadsheetName;
std::string sheetName;
Position begin;
Position end;
bool isRange = false;
};
 
/Jorgen
 
[0] I get the same mental effect when I read the phrase "The
Department of Redundancy Department", which someone used
recently over in alt.folklore.computers.
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Juha Nieminen <nospam@thanks.invalid>: Apr 28 06:36AM

> public:
> };
 
> My C++ expert on staff says no. I say yes since Visual C++ 2015 likes it.
 
It's perfectly legal in C++11 and newer. It's not valid syntax in C++98.
 
Unfortunately many a C++ "expert" out there still lives in the pre-C++11
era.
 
On a side note, initializing an std::string object with "" is rather useless
because the default constructor of std::string already initializes it to be
an emptry string. (In fact, it's actually potentially more efficient to just
let it be initialized by the default constructor. It might be possible that
a compiler will optimize that useless ="" initialization away, but unlikely,
as I doubt that compilers have been made aware of what the std::string
constructors actually do internally.)
Juha Nieminen <nospam@thanks.invalid>: Apr 28 06:42AM

> Yourself principle, i.e. this is decidedly not DRY code. To improve the
> DRY-ness I would put that class in a namespace with a `using
> std::string` in that namespace.
 
That's exactly as silly as saying that you should do this:
 
#define f for
 
in order to avoid repeating the "or" part needlessly. Don't repeat yourself!
 
I am almost 100% certain that if the standardization committee had originally
decided to prepend all standard library names with "std_" (and reserved that
prefix for use by the standard library), you would not be advising people
to write
 
#define string std_string
 
in order to avoid writing that "std_" part. So why are you advising them
against writing "std::"? What's the problem there? The two colons? Is that
the problem here?
Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 28 08:01AM

On Tue, 2020-04-28, Juha Nieminen wrote:
>> DRY-ness I would put that class in a namespace with a `using
>> std::string` in that namespace.
 
> That's exactly as silly as [...]
 
I don't want to be part of the argument (not this rerun of it, anyway)
but I note that in larger code bases I've seen at work, in various
organizations, people generally keep the std:: prefix, Juha-style.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Lynn McGuire <lynnmcguire5@gmail.com>: Apr 28 01:38PM -0500

On 4/28/2020 3:01 AM, Jorgen Grahn wrote:
> but I note that in larger code bases I've seen at work, in various
> organizations, people generally keep the std:: prefix, Juha-style.
 
> /Jorgen
 
This is 500,000 lines of C++ code. We put the std:: in on purpose. We
have another code library that has a string class also. Avoids confusion.
 
Thanks,
Lynn
Lynn McGuire <lynnmcguire5@gmail.com>: Apr 28 01:40PM -0500

On 4/28/2020 1:36 AM, Juha Nieminen wrote:
> a compiler will optimize that useless ="" initialization away, but unlikely,
> as I doubt that compilers have been made aware of what the std::string
> constructors actually do internally.)
 
Thanks !
 
I like explicitly initializing variables since I have been so burned in
the past. Just an old Fortran hacker writing C++.
 
Lynn
Lynn McGuire <lynnmcguire5@gmail.com>: Apr 28 05:08PM -0500

On 4/28/2020 12:47 AM, Jorgen Grahn wrote:
 
> [0] I get the same mental effect when I read the phrase "The
> Department of Redundancy Department", which someone used
> recently over in alt.folklore.computers.
 
I agree with your selection prefix for the class variables and have
removed them. They were the old instance variables in the code before I
added this class.
 
Structs are so C code. This is a C++ forum.
 
Thanks !
 
Lynn
Lynn McGuire <lynnmcguire5@gmail.com>: Apr 28 05:13PM -0500

On 4/28/2020 1:42 AM, Juha Nieminen wrote:
 
> in order to avoid writing that "std_" part. So why are you advising them
> against writing "std::"? What's the problem there? The two colons? Is that
> the problem here?
 
My thoughts exactly. We went through an enormous amount of work adding
std:: all over our 500,000 lines of C++ code.
 
Thanks !
 
Lynn
Ian Collins <ian-news@hotmail.com>: Apr 29 11:04AM +1200

On 29/04/2020 06:40, Lynn McGuire wrote:
 
> Thanks !
 
> I like explicitly initializing variables since I have been so burned in
> the past. Just an old Fortran hacker writing C++.
 
What did your "expert" claim is wrong with the code?
 
--
Ian.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Apr 28 09:50AM -0700

>> programs. That number is closer to 0%.
 
> Can you explain why? I can't immediately think of a reason why no
> C program would be valid C++ without modification [...]
 
There are a lot of ways that C code doesn't work as C++. If a C
program violates even one of these ways it is no longer a valid C++
program. As programs get larger, and as more third-party libraries
are used, the chance of using one of the non-C++ forms gets bigger;
asymptotically the ratio of C++-valid C programs to C programs goes
to zero.
 
I'm sure you know many of the ways that C code can fail to be
valid C++, but probably there are some you haven't thought of.
Certainly there are ones I didn't think of until just recently
when I ran a piece of C code through a C++ compiler. Some of
the obvious problems:
 
use of C++ keywords
use of _Bool
use of restrict
string literal not const
conversion of void* without a cast
 
Several items related to enumerated types:
 
mismatch of type chosen for enumerated types
overflow in implicit constant conversion
invalid conversion (basic integer type to enumerated type)
 
Some C constructs that are either not supported or not completely
supported in C++:
 
designated initializers
compound literals
anonymous structs
parameter declarators (related to variable length arrays)
uninitialized const (forward/"tentative" definition)
 
Some C++ constraints are not satisfied by the C code:
 
narrowing conversion
comparison of distinct pointer types (eg, int(*)[3] == int(*)[])
no user-provided default constructor (I'm not sure what
caused this error but the C code compiles without
problem)
 
Some error messages I didn't understand (I didn't spend time
trying to track these down; it's possible they are cascaded
errors):
 
redefinition of type (?)
name redeclared as a different kind of symbol (?)
 
All of the above errors were produced compiling a single C
translation unit, encompassing about 3000 lines of source
(include non-system header includes). The C++ compiles were done
using g++, as C++14, and again as C++17 (the C++17 was done as
a sanity check to see if some particular errors might have
disappeared; AFAICS none did).
 
Besides the problems that show up as compile errors, there are
semantic differences. These incompatibilities are worse than the
ones that get compiler warnings, as there may silently produce
different behavior or be undefined behavior. I haven't tried to
do an exaustive search for these, but there are at least three:
 
inline functions - semantic differences between C and C++.
unions - C allows type punning, C++ does not.
"common initial sequence" - the rules for which members
belong to the common initial sequence are (I think)
the same in C and C++, but how those members may be
used is different in C and C++. In particular, some
cases that have defined behavior in C are undefined
behavior in C++.
 
Of course, it is possible to avoid all of these incompatibilities
if one is determined to do so. But people who are writing C
don't do that, partly because it's a big pain in the ass to try
to do it, and partly because there is no particular incentive to
do so. There isn't anything especially exotic about the C code
I used for my C++ test compilations; probably some of the error
conditions shown above are a product of less common usages, but
certainly not all of them were. Given the number and variety of
differences between the two languages, the chance of any given C
program of any size also being a valid C++ program seems rather
remote. But don't take my word for it - take any open source C
program and try compiling it as C++. What results do you see?
Tim Rentsch <tr.17687@z991.linuxsc.com>: Apr 28 10:14AM -0700

> of heat, over and over again ... but as I see it, pretty much
> everyone has a C compiler and a C++ compiler, and will compile
> their C code with the former and their C++ code with the latter.
 
Speaking for myself, I am not bothered at all that C and C++ are
different languages. In fact I think it's good that they are, and
they should be free to go their separate ways. It would be better
for both languages to give up on the idea of "harmonizing" C and
C++, which is a pointless fiction (or worse, a way of making C be
more like C++, without C++ changing in any significant way). I
would much rather see two clearly delineated choice points than
some sort of muddled middle ground. If and when I want to take
the C++ view, I write C++; if and when I want to take the C view,
I write C. I see no reason to confuse the issue by pretending
there is some sort of significant common ground between them.
Thirty years ago there was, but now there isn't, and it's time to
move on.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Apr 28 06:44AM -0700

>> available on Amazon for $144.
 
> Thanks for your comments. I would probably use FreeBSD
> rather than Linux for that.
 
You're welcome. I didn't mean to suggest that Linux is the only
viable choice. I have a fair amount of experience using Linux
(and also other systems) to do routing/networking, and am happy to
recommend it, but FreeBSD (where I have very little experience)
may also be fine.
 
> I'm trying to avoid Amazon.
 
I wasn't recommending Amazon, just providing a convenient point of
reference and one that is a known quantity.
 
> One alternative I've found is https://www.bhphotovideo.com
 
Great, I will try to take a look.
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:

Digest for comp.programming.threads@googlegroups.com - 3 updates in 3 topics

aminer68@gmail.com: Apr 27 12:51PM -0700

Hello,
 
 
I will explain more my poem of Love below:
 
When i am saying the following in the end of my poem of Love:
 
"Baby i want to hold you in my arms under this beautiful Sun !
Since my love is not the evil of drugs or the methadone
Since my beautiful love is here for everyone !"
 
The last sentence of:
 
"Since my beautiful love is here for everyone !"
 
What does it means ?
 
It means that it is: "L'ivresse de l'amour" in french, it is like i am so intoxicated with Love that i am saying the following:
 
"Since my beautiful love is here for everyone !"
 
 
This doesn't mean that i love evil, because you have to place
it in the right context.
 
Or this can mean also that the word Love is defined by morality that is
like the King, and as you have noticed, i have already defined in my political philosophy what morality means, so hope you are understanding more.
 
So now you can reread my following poem of Love:
 
Here is my new poem: "Baby i want to hold you in my arms under this beautiful Sun !"
 
I was just listening at the following beautiful music from Greece,
and i have just decided to think fast and write fast
a new poem of Love, so i invite you to listen to the following
beautiful music from Greece reading at the same time my new poem of Love below:
 
https://www.youtube.com/watch?v=Zf87GGVtiIM
 
 
And here is my new poem of Love:
 
 
Baby i want to hold you in my arms under this beautiful Sun !
 
Since i am here and not like anyone
 
Since my love for you is a so beautiful phenomenon !
 
Baby i want to hold you in my arms under this beautiful Sun !
 
As i am also speaking beautifully in many tongues !
 
Baby i want to hold you in my arms under this beautiful Sun !
 
And what about this earthly marathon ?
 
As you can notice that the beautiful love is not of the dumb !
 
Baby i want to hold you in my arms under this beautiful Sun !
 
Since i am as not of the wrong as i am like a smart automaton
 
Baby i want to hold you in my arms under this beautiful Sun !
 
So look at this beautiful weather and how it is really fun !
 
Baby i want to hold you in my arms under this beautiful Sun !
 
So is my Love the Dollar or Yuan or an Amazon ?
 
No, since look at our peaceful and beautiful plan !
 
Baby i want to hold you in my arms under this beautiful Sun !
 
Since it is as our beautiful and forever love can not be undone !
 
Baby i want to hold you in my arms under this beautiful Sun !
 
Since my love is not the evil of drugs or the methadone
 
Since my beautiful love is here for everyone !
 
 
 
Thank you,
Amine Moulay Ramdane.
aminer68@gmail.com: Apr 27 08:38AM -0700

Hello,
 
 
Here is my new poem: "Baby i want to hold you in my arms under this beautiful Sun !"
 
I was just listening at the following beautiful music from Greece,
and i have just decided to think fast and write fast
a new poem of Love, so i invite you to listen to the following
beautiful music from Greece reading at the same time my new poem of Love below:
 
https://www.youtube.com/watch?v=Zf87GGVtiIM
 
 
And here is my new poem of Love:
 
 
Baby i want to hold you in my arms under this beautiful Sun !
 
Since i am here and not like anyone
 
Since my love for you is a so beautiful phenomenon !
 
Baby i want to hold you in my arms under this beautiful Sun !
 
As i am also speaking beautifully in many tongues !
 
Baby i want to hold you in my arms under this beautiful Sun !
 
And what about this earthly marathon ?
 
As you can notice that the beautiful love is not of the dumb !
 
Baby i want to hold you in my arms under this beautiful Sun !
 
Since i am as not of the wrong as i am like a smart automaton
 
Baby i want to hold you in my arms under this beautiful Sun !
 
So look at this beautiful weather and how it is really fun !
 
Baby i want to hold you in my arms under this beautiful Sun !
 
So is my Love the Dollar or Yuan or an Amazon ?
 
No, since look at our peaceful and beautiful plan !
 
Baby i want to hold you in my arms under this beautiful Sun !
 
Since it is as our beautiful and forever love can not be undone !
 
Baby i want to hold you in my arms under this beautiful Sun !
 
Since my love is not the evil of drugs or the methadone
 
Since my beautiful love is here for everyone !
 
 
 
Thank you,
Amine Moulay Ramdane.
Bonita Montero <Bonita.Montero@gmail.com>: Apr 27 04:48PM +0200

> inventor of many scalable algorithms and there implementations, and when
> you have studies operational research like me, you will find management
> or operation management easy to learn.
 
The only thing I believe is that you don't have any sex.
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.programming.threads+unsubscribe@googlegroups.com.
Posted by at No comments:

Monday, April 27, 2020

Digest for comp.lang.c++@googlegroups.com - 2 updates in 1 topic

Juha Nieminen <nospam@thanks.invalid>: Apr 27 12:06PM

> Another is that C++ string literals are const, so this:
> char *s = "hello";
> is invalid C++.
 
Wouldn't that be UB even in C?
 
(Ok, using a non-const pointer to point to a string literaly is not in
itsef UB, but if you ever try to modify it...)
 
I believe that most competent C programmers would never use non-const
char*'s to handle string literals (and most competent C compilers will
give a huge-ass warning about it).
James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 27 10:11AM -0400

On 4/27/20 8:06 AM, Juha Nieminen wrote:
>> char *s = "hello";
>> is invalid C++.
 
> Wouldn't that be UB even in C?
 
No, it's code with perfect well-defined behavior. "hello" has the type
char[6], and in this context gets implicitly converted into a char*
pointing at the first element of that array. In C++, it has the type
const char[6], and gets implicitly converted to const char*. Assigning a
const char* value to a char* object would violate the rules of either
language, but it isn't a const char* in C.
 
> (Ok, using a non-const pointer to point to a string literaly is not in
> itsef UB, but if you ever try to modify it...)
 
Correct - any attempt to modify that string has undefined behavior. But
if no such attempt is made, the behavior is well-defined (though such
code is a potential trap for future maintainers of the code).
 
> I believe that most competent C programmers would never use non-const
> char*'s to handle string literals (and most competent C compilers will
> give a huge-ass warning about it).
 
A lot of people don't bother with that; they may not qualify as
"competent", but they're quite numerous, and a lot of them seem to be
currently earning money writing C code, so it is important to look out
for such problems.
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:

Digest for comp.programming.threads@googlegroups.com - 2 updates in 2 topics

killvirus@coronavirus.com: Apr 18 04:26PM

coronavirus COVID-19
http://www.grex.org/~henced/coronavirus.html
Wisdom90 <d@d.d>: Apr 26 05:02PM -0400

Hello..
 
Read this:
 
More about my kind of personality..
 
I am not just a gentleman type of person, i am like a wise man type of
person, but i am not just like a wise man type of person, i have
something special like an smart secret service agent that is able to
detect rapidly this or that, and i don't take drugs
and i don't take alcohol, and i have no sex because i am more
sophisticated than that, what i want is to share my poetry with others
and to share my thoughts of political philosophy with others, and i am
an inventor of many scalable algorithms etc. but i am not just a
software developer, because i am multidisciplinary because i have a
Diploma in Microelectronics and informatics and i have studied more
mathematics and i have studied operational research and i am also an
inventor of many scalable algorithms and there implementations, and when
you have studies operational research like me, you will find management
or operation management easy to learn.
 
 
And now you know more my kind of personality, this is why i am writing
my poetry as i am writing it.
 
 
Thank you,
Amine Moulay Ramdane.
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.programming.threads+unsubscribe@googlegroups.com.
Posted by at No comments:

Sunday, April 26, 2020

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

jacobnavia <jacob@jacob.remcomp.fr>: Apr 19 03:21PM +0200

Le 19/04/2020 à 14:42, Öö Tiib a écrit :
 
>> A recent paper shows that Rust has the same problems as C or C++.
 
>> https://arxiv.org/pdf/2003.03296.pdf
 
> I am maybe misunderstanding what I read again but huh.
 
No, it is simply that your evangelical positions are getting upset.
 
> Is it really article that states that stuff in Rust encapsulated in
> unsafe{ ... } is unsafe?
 
Exactly. But why are those unsafe APIs necessary?
 
Because they are essential. And that means that Rust has the same
problems than C with usage after free() etc.
 
Is it really meant to distribute FUD
> against Rust?
 
No, it is an investigation of Rust's claims and its FUD about C.
 
 
> Appearance of such clearly mud slinging articles
> has always indicated that target is doing far stronger than I
> thought and it is time to invest into it!
 
Evangelist position noted...
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Apr 19 09:39PM +0100

On Sun, 19 Apr 2020 21:35:15 +0100
> Destructors are not in tail position.
 
Err, only the last destructor is in tail position and the recursive call
is not.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Apr 20 08:12PM +0100

On Mon, 20 Apr 2020 18:08:18 +0200
> interface functions. The only thing you need to do is a mapping from the
> C types to the Rust types.
 
> I have done that and is absolutely doable...
 
Rust already has an FFI for C. It doesn't need another. The point is
that if you call into C code then your Rust code cannot be any safer
than your C code.
James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 20 10:23AM -0400

On 4/20/20 9:20 AM, Juha Nieminen wrote:
> C++ doesn't allow implicitly casting between incompatible
> pointer types while C does, but doing so in C is often frowned
> upon in programming style guidelines.)
 
<pedantic>A cast is a particular piece of syntax. That syntax in the
source causes the implementation to generate code which implements the
corresponding conversion. That syntax is not always required in order
for the conversion to occur. When that is the case, it's called an
implicit conversion, not an implicit cast - because it isn't a cast
without that syntax, but it is still a conversion.</pedantic>
 
Your wording could be interpreted as implying that incompatibility is
not a barrier to C pointer conversions. In fact, in most cases it is a
barrier. Such a conversion is allowed only if one of the two types is
void*. Many people consider this an advantage - creating that advantage
was one of the purposes behind the invention of "void*", though Bjarne
clearly disagreed. Those people write programming style guidelines that
reflect that opinion.
Richard Damon <Richard@Damon-Family.org>: Apr 19 09:31AM -0400

On 4/19/20 8:39 AM, Paavo Helde wrote:
 
> This paper compares Rust with an hypothetical language called C/C++.
> There is no such language in existence, which makes the whole paper a
> bit suspect.
 
But C and C++ are very related languages, so there IS a language family
that can be described as C/C++, and there is a common core that is
common between the two languages. C++ adds a number of features, that
when used can abstract out may of the things that cause one class of
memory errors, but at the same time adds a layer of complexity that
might enable others.
 
C++ also doesn't force you to use the abstractions that help eliminate
some of the memory problems, but allows you to do the low level
operations that open the door to memory access issues, and in fact the
abstractions tend to be based on using those lower level operations, its
just that the scope of those operations are tried to be kept smaller so
it is hopefully easier to reason that it is being done correctly.
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 19 08:40PM

> [snip]
 
> I don't write Rust code. I am merely interested in its type system (as
> are a number of other languages, now).
 
Heh in 2013 or so I submitted patch in Rust compiler to fix inheritance in Vtable
bug :P
 
 
 
--
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
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 20 12:37AM +0100

Sausages. That is all.
 
/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."
Vir Campestris <vir.campestris@invalid.invalid>: Apr 18 09:53PM +0100

On 17/04/2020 14:41, James Kuyper wrote:
> it predates C++, going all the way back to the early days of C.
> Experienced C and C++ programmers are necessarily used to this problem,
> and know how to deal with it.
 
Interesting. I think I count myself as experienced - I've been writing C
and C++ for nearly 40 years - and yet it's never bitten me.
 
probably because
short plus = 42;
short minus = -plus;
 
tends to end up as something like
 
load 16 into register
store into plus as 16 bit
negate
store into minus as 16 bit
 
This case where
auto minus = -plus;
results in a 32 bit (or more!) size for minus is to me just another
reason not to use auto where I can avoid it.
 
Andy
Christian Gollwitzer <auriocus@gmx.de>: Apr 18 07:14PM +0200

Am 17.04.20 um 17:34 schrieb Ben Bacarisse:
 
> It may be simpler to fall into the trap in that case, but there are so
> many others (~42_i16, 42_i16 + 10, 42_i16 << 1, printf("...", 42_i26))
> that knowing the underlying truth really helps.
 
I've designed a Matlab-like language, and the integer promotion rules
also got me thinking. In the end I concluded that the base integer type
(like int in C++) should be disctinct from the fixed-widths types and
treated as an ideal integer. i.e., even if int== int32_t, the type
promotion should not widen smaller types in this case.
 
Therefore (in my language):
 
auto x = -42i16;
// x is -42i16
// unary - is defined for int16_t -> int16_t
 
auto i = x + 1
// i is -41i16
// no promotion, because int is special
 
auto j = x + 1i32;
// j is -41i32
// promoted because int32_t has more bits than int16_t
 
uint8_t byte=0;
auto t = byte - 1;
// t is 255u8
 
auto u = byte - 1i32;
// u is -1i32
 
Christian
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 18 08:46PM +0100


> See how Christ was at work in her life, even through the
> bad times, even when she had given up.
 
> We all need that rope she talks about.
 
Fuck. Off.
 
/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."
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:
Subscribe to: Posts (Atom)