Sunday, April 21, 2019

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

Juha Nieminen <nospam@thanks.invalid>: Apr 21 12:33PM

> Why are those other modules also defining 'string'? Which is known to be
> a built-in type.
 
"string" is not a built-in type.
 
But perhaps in this situation "string" in particular is a poor
example because it's so ubiquitously known. But how about the
more obscure and less used names in the standard library? Can you
say that you remember by heart every single one of them, and avoid
using any of those names in your code? Every time you declare a new
function, type or variable, do you check if that name might be used
in the standard library? I doubt it.
 
Therefore, if you for example find a function named "equal" being
called in some code, do you know from looking at that line alone
whether it's a custom function or a standard library function?
Juha Nieminen <nospam@thanks.invalid>: Apr 21 12:34PM

> With std:: the types and functins are well known to the deveopers so
> there isn't any confusion when std:: is stripped.
 
Really? Given the literally *hundreds* of names used in the standard
library, can you remember by heart every single one of them? When you
see a name being used in code, can you be absolutely certain that it's
a name in the standard library, or a custom name?
Juha Nieminen <nospam@thanks.invalid>: Apr 21 12:37PM

> If that's out of sight then I find it easier to hover the mouse over the
> word than to scroll.
 
I have always been of the opinion that the readability and
undrestandability of code shouldn't be reliant on an IDE. The code
should remain readable and understandable even if you are just looking
at it with a vanilla text editor.
Bart <bc@freeuk.com>: Apr 21 01:50PM +0100

On 21/04/2019 13:37, Juha Nieminen wrote:
> undrestandability of code shouldn't be reliant on an IDE. The code
> should remain readable and understandable even if you are just looking
> at it with a vanilla text editor.
 
Or on a printout, if anyone still uses those.
Bart <bc@freeuk.com>: Apr 21 02:09PM +0100

On 21/04/2019 13:33, Juha Nieminen wrote:
 
> Therefore, if you for example find a function named "equal" being
> called in some code, do you know from looking at that line alone
> whether it's a custom function or a standard library function?
 
I think if you have code dominated by a sea of "std::" then that is a
problem that needs solving.
 
In this case caused by having too few things that are built-in and
unambiguous, and too much implemented in a library which, since the same
names could be used in a different library, mean this namespace prefix
is required.
 
I don't write C++ myself. But if I look at rextester.com (online C++),
it starts with this program:
 
#include <iostream>
 
int main()
{
std::cout << "Hello, world!\n";
}
 
I find that "std::" irritating. And that's not all. If I get rid of the
#include, it doesn't work (doesn't know 'std'); if I keep that but get
rid of std::, it doesn't work either (doesn't know 'cout'). And this is
the simplest possible program.
 
(Mind you I find 'cout' and '<<' equally irritating, but that's another
subject.)
 
This isn't just a C++ thing. On that same site, you will find:
 
fmt.Printf (Go; requires import "fmt")
System.out.println (Java; requires imports)
Console.WriteLine (C# and VB; requires various 'using')
 
But then the majority are much cleaner:
 
Put_Line (Ada; requires "with" and "use")
echo (Bash)
print (Lisp)
writeln (D; requires import "std.stdio")
print (Fortran)
print (Haskell)
print (Javascript)
print (Lua)
writeln (Pascal)
print (Perl)
print (Python)
println (Scala)
print (Swift)
printf (C; requires include <stdio.h>)
 
So what is with C++ and those other long-winded languages? How do all
these others solve the problem of ambiguity when you leave out those
prefixes?
Bonita Montero <Bonita.Montero@gmail.com>: Apr 21 04:18PM +0200

> library, can you remember by heart every single one of them? When you
> see a name being used in code, can you be absolutely certain that it's
> a name in the standard library, or a custom name?
 
Then you google in 5 seconds "C++ name" if a name is already defined
in the standard-library or any relvant C++-library.
Bonita Montero <Bonita.Montero@gmail.com>: Apr 21 04:19PM +0200

> I have always been of the opinion that the readability and
> undrestandability of code shouldn't be reliant on an IDE.
 
I don't see any reason for that.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 21 04:30PM +0200

On 21.04.2019 14:50, Bart wrote:
>> should remain readable and understandable even if you are just looking
>> at it with a vanilla text editor.
 
> Or on a printout, if anyone still uses those.
 
That's what we have mobile phones for, when one sits down to read code
on paper.
 
 
Cheers!,
 
- Alf
Ian Collins <ian-news@hotmail.com>: Apr 22 08:51AM +1200

On 22/04/2019 00:37, Juha Nieminen wrote:
> undrestandability of code shouldn't be reliant on an IDE. The code
> should remain readable and understandable even if you are just looking
> at it with a vanilla text editor.
 
Ah but readability is in the eye of the beholder :)
 
Which would be more readable, a ten character name prefixed bay thirty
characters of namespaces, or a using directive and a ten character name?
 
--
Ian.
Ian Collins <ian-news@hotmail.com>: Apr 22 10:49AM +1200

On 22/04/2019 01:09, Bart wrote:
> unambiguous, and too much implemented in a library which, since the same
> names could be used in a different library, mean this namespace prefix
> is required.
 
What gets built in and what gets included in libraries is always a trade
off. The more you build in, the more you restrict the environments
where the language can be used.
 
We are lucky that C++ is designed to allow extension through libraries.
 
--
Ian.
David Brown <david.brown@hesbynett.no>: Apr 21 10:03AM +0200


> I don't really see the point of these syntatic games that constexpr allows.
> If its a constant expression then by definition you know the value when you
> write the code so why not just have "static const int one = 1"?
 
Obviously the real functions here are not as simple as "x + 1".
blt__k4yrjhiu@dmq3k.co.uk: Apr 21 10:15AM

On Sun, 21 Apr 2019 10:03:01 +0200
>> If its a constant expression then by definition you know the value when you
>> write the code so why not just have "static const int one = 1"?
 
>Obviously the real functions here are not as simple as "x + 1".
 
They're never going to contain anything more than simple arithmetic formulas
if the output can be computed at compile time so why not just make them a
const.
David Brown <david.brown@hesbynett.no>: Apr 21 01:34PM +0200


> They're never going to contain anything more than simple arithmetic formulas
> if the output can be computed at compile time so why not just make them a
> const.
 
/I/ am the person writing these functions here. /I/ know they are not
simple arithmetic. The result of some of the functions is a single
integer, others result in arrays of data, but the functions involved are
not simple. There are good reasons why I am using functions, not just
doing the arithmetic in my head, and there are good reasons why I want
them to be constexpr.
Rosario19 <Ros@invalid.invalid>: Apr 21 11:51AM +0200

Happy Easter to all, to all C and C++ programmers
Bonita Montero <Bonita.Montero@gmail.com>: Apr 21 09:20AM +0200


>> You won't store this and everything in the size-magnitude of this on the
>> stack.
 
> And why not? The only problem is the technical limitation.
 
When you do an allocation with alloca() you do it because of the
performance. But for larger allocations the performance-difference
on the heap is negligible.
 
> Even if there is not much data on stack the issue still remains. Let's
> say I have 4 bytes local data per stack frame, and the stack is 1MB.
> This means I am limited to ca 250,000 recursions.
 
... very realistic.
 
> At the same time my machine has 16 GB of memory, meaning in principle
> I could have ca 4,000,000,000 recursions instead. Why am I limited to
> 0.006 % of the machine capabilities?
 
Because no one will do a recursion with 4e9 levels, even not with 2,5E4
levels.
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)