Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Advent of Code 2020

113 views
Skip to first unread message

Jorgen Grahn

unread,
Dec 6, 2020, 7:29:35 AM12/6/20
to
Advent of Code
https://adventofcode.com/2020

One programming problem a day, until Christmas. I don't know how
well-known it is; it's popular among my coworkers.

So far this year, not very interesting problems, but just /having/ a
well-defined and smallish problem, with test data, can be refreshing.

I find C++ a good choice for solving these. You'd think a language
like Python would be better fit, but I've found no use for it yet.
Perhaps that's just a sign my Python is rusty.

On the other hand, if you used C you would have to reinvent a lot of
wheels.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Mr Flibble

unread,
Dec 6, 2020, 7:55:46 AM12/6/20
to
On 06/12/2020 12:29, Jorgen Grahn wrote:
> Advent of Code
> https://adventofcode.com/2020
>
> One programming problem a day, until Christmas. I don't know how
> well-known it is; it's popular among my coworkers.

Please don't push your Christian agenda here; we have enough fruit loops doing that already.

/Flibble

--
😎

Rick C. Hodgin

unread,
Dec 6, 2020, 10:15:57 AM12/6/20
to
Said the man who pushes his obscene, vulgar, anti-Christian agenda here.

There's so much more than you acknowledge today, Leigh. Your future can
be bright. Full of love to those around you. Full of hope and
affirmation of security and a future. Full of inner peace, love, and joy.

You're missing it, Leigh, and you're doing so in support of the purposes
of raging hatred spewing out toward others.

-----
Your life is not your own.
You are dominated right now by hateful masters using you.

They have blinded you to their presence as they literally usurp your
life, your future, your birthright, your heritage, all opportunity God's
given you to gain for yourself and others in eternity.

You are being robbed blind and stripped of everything, and they who are
doing this are preying on your love and embrace of sin to accomplish it.
They hate you, and they want to see you destroyed in Hell. And today,
they are having a full-on, 100% victory and success in their efforts.
They have wasted you and the sad thing is, you are loving every minute
of it ... today.

--
Rick C. Hodgin

Mr Flibble

unread,
Dec 6, 2020, 11:30:57 AM12/6/20
to
And Satan invented fossils, yes? Spammer?

/Flibble

--
😎

Alf P. Steinbach

unread,
Dec 6, 2020, 5:40:00 PM12/6/20
to
On 06.12.2020 13:29, Jorgen Grahn wrote:
> Advent of Code
> https://adventofcode.com/2020

Minimal support library: <url:
https://github.com/alf-p-steinbach/kickstart/blob/master/source/examples/hello-world.md>

------------------------------------------------------------------------
const int data[] =
{
1310,
// ...
};

#include <unordered_set>
using std::unordered_set;

#include <kickstart/all.hpp>
using namespace kickstart::all; // out, endl, fail, begin, end

void cpp_main()
{
const auto values = unordered_set<int>( begin( data ), end( data ) );
for( const int v: values ) {
const int other = 2020 - v;
if( values.count( other ) > 0 ) {
out << v*other << endl;
return;
}
}
fail( "No such value" );
}

auto main() -> int { return with_exceptions_displayed( cpp_main ); }
------------------------------------------------------------------------


- Alf (coding mode)

Alf P. Steinbach

unread,
Dec 6, 2020, 5:56:26 PM12/6/20
to
On 06.12.2020 13:29, Jorgen Grahn wrote:
> Advent of Code
> https://adventofcode.com/2020



Minimal support library: <url:
https://github.com/alf-p-steinbach/kickstart/blob/master/source/examples/hello-world.md>

------------------------------------------------------------------------
const int data[] = ...;

#include <unordered_set>
using std::unordered_set;

#include <kickstart/all.hpp>
using namespace kickstart::all; // out, endl, fail, begin, end

void cpp_main()
{
const auto values = unordered_set<int>( begin( data ), end( data ) );
for( const int v: values ) {
const int remainder = 2020 - v;
for( const int w: values ) {
const int third = remainder - w;
if( values.count( third ) > 0 ) {
out << int64_t(1)*v*w*third << endl;

Alf P. Steinbach

unread,
Dec 6, 2020, 6:14:56 PM12/6/20
to
On 06.12.2020 13:29, Jorgen Grahn wrote:
> Advent of Code
> https://adventofcode.com/2020


Minimal support library: <url:
https://github.com/alf-p-steinbach/kickstart/blob/master/source/examples/hello-world.md>

------------------------------------------------------------------------
#include <fstream>
#include <sstream>
using std::ifstream,
std::istringstream;

#include <kickstart/all.hpp>
using namespace kickstart::all;


void cpp_main()
{
const auto& filename = "pw-data.txt";
ifstream f( filename );
hopefully( not f.fail() )
or fail( ""s << "Failed to open '" << filename << "'." );
string line;
int n_valid = 0;
while( getline( f, line ) ) {
auto line_stream = istringstream( line );
int min;
int max;
char ch;
char dummy;
string password;

line_stream >> min >> dummy >> max >> ch >> dummy >> password
or fail( ""s << "Parsing '" << line << "' failed." );

int ch_count = 0;
for( const char pw_char: password ) {
ch_count += (pw_char == ch);
}
n_valid += (min <= ch_count and ch_count <= max);
}
out << n_valid << endl;

Alf P. Steinbach

unread,
Dec 6, 2020, 6:20:41 PM12/6/20
to
On 06.12.2020 13:29, Jorgen Grahn wrote:
> Advent of Code
> https://adventofcode.com/2020

Minimal support library: <url:
https://github.com/alf-p-steinbach/kickstart/blob/master/source/examples/hello-world.md>

------------------------------------------------------------------------
#include <algorithm>
#include <fstream>
#include <sstream>
using std::max,
std::ifstream,
std::istringstream;

#include <kickstart/all.hpp>
using namespace kickstart::all;


void cpp_main()
{
const auto& filename = "pw-data.txt";
ifstream f( filename );
hopefully( not f.fail() )
or fail( ""s << "Failed to open '" << filename << "'." );
string line;
int n_valid = 0;
while( getline( f, line ) ) {
auto line_stream = istringstream( line );
int i1;
int i2;
char ch;
char dummy;
string password;

line_stream >> i1 >> dummy >> i2 >> ch >> dummy >> password
or fail( ""s << "Parsing '" << line << "' failed." );

n_valid +=
(ssize(password) >= max( i1, i2 ) )
and (password.at( i1 - 1 ) == ch) != (password.at( i2 - 1 )
== ch);

Mr Flibble

unread,
Dec 6, 2020, 8:22:02 PM12/6/20
to
Your use of "using" directives and your omission of "std::" in function bodies makes you code less readable IMO.

/Flibble

--
😎

Alf P. Steinbach

unread,
Dec 7, 2020, 1:27:17 AM12/7/20
to
On 06.12.2020 13:29, Jorgen Grahn wrote:
> Advent of Code
> https://adventofcode.com/2020

I found that one way to screw up this exercise is to inadvertently save
the data file as UTF-8 with BOM. :-o

------------------------------------------------------------------------
#include <algorithm>
#include <fstream>
#include <sstream>
using std::max,
std::ifstream;

#include <kickstart/all.hpp>
using namespace kickstart::all;

auto read_map()
-> vector<string>
{
vector<string> result;
const auto& filename = "map-data.txt";
ifstream f( filename );
hopefully( not f.fail() )
or fail( ""s << "Failed to open '" << filename << "'." );
string line;
while( getline( f, line ) ) {
result.push_back( line );
}
hopefully( f.eof() ) or fail( ""s << "Error reading file '" <<
filename << "'." );
return result;
}

struct Point{ int x; int y; };

void cpp_main()
{
const vector<string> map = read_map();
const int w = static_cast<int>( ssize( map.front() ) );
const int h = static_cast<int>( ssize( map ) );

Point current = {0, 0};
int count = 0;
while( current.y < h ) {
count += (map[current.y][current.x] == '#');
{ //with
auto& _ = current;
_.x = (_.x + 3) % w; _.y += 1;
}
}
out << count << endl;
}

auto main() -> int { return with_exceptions_displayed( cpp_main ); }
------------------------------------------------------------------------


- Alf (morning coding mode)

Juha Nieminen

unread,
Dec 7, 2020, 2:49:54 AM12/7/20
to
Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
> using std::unordered_set;

You wrote 27 characters in order to save writing 5 characters later.

Seems like quite counter-productive. You write more code in order to make
your code less legible.

If I were reviewing your production code, I would never give this a pass.

> #include <kickstart/all.hpp>
> using namespace kickstart::all; // out, endl, fail, begin, end

This whole program is invalid because it fails to compile.

No matter how much you try to push your personal libraries, they will not
catch on.

Just stick to *standard* C++, which is all this newsgroup is about.

Juha Nieminen

unread,
Dec 7, 2020, 2:55:41 AM12/7/20
to
Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
> Point current = {0, 0};
> int count = 0;
> while( current.y < h ) {
> count += (map[current.y][current.x] == '#');
> { //with
> auto& _ = current;
> _.x = (_.x + 3) % w; _.y += 1;
> }
> }

It will perhaps never cease to amaze me your insistence in making your
code less readable, harder to decipher, needlessly long, and needlessly
requiring personal header files that nobody else gives a flying f about.

Alf P. Steinbach

unread,
Dec 7, 2020, 6:01:26 AM12/7/20
to
If you don't understand that code then you're stupid.


- Alf


Alf P. Steinbach

unread,
Dec 7, 2020, 6:05:43 AM12/7/20
to
On 07.12.2020 08:49, Juha Nieminen wrote:
> Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
>> using std::unordered_set;
>
> You wrote 27 characters in order to save writing 5 characters later.
>
> Seems like quite counter-productive. You write more code in order to make
> your code less legible.
>
> If I were reviewing your production code, I would never give this a pass.

In any realistic setting I would review your code, not opposite.


>> #include <kickstart/all.hpp>
>> using namespace kickstart::all; // out, endl, fail, begin, end
>
> This whole program is invalid because it fails to compile.

For example, here you prove that you don't even master the basic tool usage.

The code is perfectly fine, it compiles cleanly.


> No matter how much you try to push your personal libraries, they will not
> catch on.

I wonder what's wrong with you with all that negativity and pushing your
ideas of others' motivations. You are evidently not a good person. Why
don't you take a hike.


> Just stick to *standard* C++, which is all this newsgroup is about.
This code is all standards-compliant C++17 code. You're an incompetent.


- Alf

spu...@isnotyourbuddy.co.uk

unread,
Dec 7, 2020, 6:31:30 AM12/7/20
to
On Mon, 7 Dec 2020 12:01:04 +0100
You're the typical know it all insecure programmer - you write unnecessarily
complex code simply in order to show off then call people stupid if they have
an issue with it. You have an attitude problem that would make you a nightmare
to work with.

Alf P. Steinbach

unread,
Dec 7, 2020, 6:33:24 AM12/7/20
to
On 07.12.2020 12:31, spu...@isnotyourbuddy.co.uk wrote:
> On Mon, 7 Dec 2020 12:01:04 +0100
> "Alf P. Steinbach" <alf.p.stein...@gmail.com> wrote:
>> On 07.12.2020 08:55, wrote:
>>> Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
>>>> Point current = {0, 0};
>>>> int count = 0;
>>>> while( current.y < h ) {
>>>> count += (map[current.y][current.x] == '#');
>>>> { //with
>>>> auto& _ = current;
>>>> _.x = (_.x + 3) % w; _.y += 1;
>>>> }
>>>> }
>>>
>>> It will perhaps never cease to amaze me your insistence in making your
>>> code less readable, harder to decipher, needlessly long, and needlessly
>>> requiring personal header files that nobody else gives a flying f about.
>>
>> If you don't understand that code then you're stupid.
>
> You're the typical know it all insecure programmer - you write unnecessarily
> complex code simply in order to show off then call people stupid if they have
> an issue with it. You have an attitude problem that would make you a nightmare
> to work with.

Juha Nieminen, you're an idiot. And perhaps very lonely, to try to troll
this way. But definitely an idiot, and not a very nice person.

- Alf

spu...@isnotyourbuddy.co.uk

unread,
Dec 7, 2020, 6:35:02 AM12/7/20
to
On Mon, 7 Dec 2020 12:05:21 +0100
"Alf P. Steinbach" <alf.p.stein...@gmail.com> wrote:
>On 07.12.2020 08:49, Juha Nieminen wrote:
>> Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
>>> using std::unordered_set;
>>
>> You wrote 27 characters in order to save writing 5 characters later.
>>
>> Seems like quite counter-productive. You write more code in order to make
>> your code less legible.
>>
>> If I were reviewing your production code, I would never give this a pass.
>
>In any realistic setting I would review your code, not opposite.

Have you been promoted out of harms way then? Did you company get sick of
your unmaintainable convoluted obtuse code but couldn't fire you so promoted
you to some meaningless management role instead?

Any idiot can write convoluted code , it takes a good programmer to write
code that does a good job AND is clear and easy to understand. I would suggest
you have a think about that.

spu...@isnotyourbuddy.co.uk

unread,
Dec 7, 2020, 6:53:48 AM12/7/20
to
On Mon, 7 Dec 2020 12:33:03 +0100
The fact that you think I'm a sock puppet says it all. Are you too stupid or
just too arrogant to search what other groups I post to? I've been lurking on
here for a while and used to post under a different name.

Alf P. Steinbach

unread,
Dec 7, 2020, 3:31:27 PM12/7/20
to
On 06.12.2020 13:29, Jorgen Grahn wrote:
> Advent of Code
> https://adventofcode.com/2020

------------------------------------------------------------------------
#include <fstream>
#include <sstream>
using std::ifstream;

#include <kickstart/all.hpp>
using namespace kickstart::all;

auto read_map()
-> vector<string>
{
vector<string> result;
const auto& filename = "map-data.txt";
ifstream f( filename );
hopefully( not f.fail() )
or fail( ""s << "Failed to open '" << filename << "'." );
string line;
while( getline( f, line ) ) {
result.push_back( line );
}
hopefully( f.eof() ) or fail( ""s << "Error reading file '" <<
filename << "'." );
return result;
}

struct Point
{
int x;
int y;

void operator+=( const Point& other )
{
x += other.x;
y += other.y;
}
};

void cpp_main()
{
const vector<string> map = read_map();
const int w = static_cast<int>( ssize( map.front() ) );
const int h = static_cast<int>( ssize( map ) );

int64_t product = 1;
const Point deltas[] = {{1, 1}, {3, 1}, {5, 1}, {7, 1}, {1, 2}};
for( const Point delta: deltas )
{
Point current = {0, 0};
int count = 0;
while( current.y < h ) {
count += (map[current.y][current.x] == '#');
{ //with
auto& _ = current;
_ += delta;
_.x %= w;
}
}
product *= count;
}
out << product << endl;
}

auto main() -> int { return with_exceptions_displayed( cpp_main ); }
------------------------------------------------------------------------


- Alf (evening coding mode)

Mr Flibble

unread,
Dec 7, 2020, 5:34:29 PM12/7/20
to
Juha is correct, Alf, your code is hard to read.

My biggest gripe is that you don't use "std::vector" but instead use "vector"; namespaces where invented to make code easier to grok so please stop trying to defeat their purpose.

YOUR CODE IS HARD TO READ.

/Flibble

--
😎

spu...@isnotyourbuddy.co.uk

unread,
Dec 8, 2020, 3:32:32 AM12/8/20
to
On Mon, 7 Dec 2020 22:34:08 +0000
Mr Flibble <fli...@i42.REMOVETHISBIT.co.uk> wrote:
>My biggest gripe is that you don't use "std::vector" but instead use "vector";
>namespaces where invented to make code easier to grok so please stop trying to
>defeat their purpose.

I disagree. I find <namespace>:: peppered all over the code annoying and messy.
There's a reason the "using" command was included as part of the standard.

Öö Tiib

unread,
Dec 8, 2020, 7:09:48 AM12/8/20
to
Whoosh.

Christian Gollwitzer

unread,
Dec 8, 2020, 3:33:32 PM12/8/20
to
Am 06.12.20 um 13:29 schrieb Jorgen Grahn:
> Advent of Code
> https://adventofcode.com/2020
>
> One programming problem a day, until Christmas. I don't know how
> well-known it is; it's popular among my coworkers.
>
> So far this year, not very interesting problems, but just /having/ a
> well-defined and smallish problem, with test data, can be refreshing.
>
> I find C++ a good choice for solving these. You'd think a language
> like Python would be better fit, but I've found no use for it yet.
> Perhaps that's just a sign my Python is rusty.
>

Well, Python shines for lot of these tasks, albeit it may suffer from
low performance.

For example, the very first thing (find the product of two numbers in
the list that sums to 2020), can be expressed in a list comprehension:


# input data list
# for the real program we need to read it from stdin somehow
report=[1721,979,366,299,675,1456]

# compute product
prod = [x*y for x in report for y in report if x+y==2020]

The result is then the first entry of the list prod[0].

As you can see, this single line expresses almost verbatim the problem
and solves it in Python. List comprehension is a powerful feature that
was borrowed from Haskell. Python is a very complex language today, just
like C++ it got features after features, but because it started from a
more recent base it is less crufty than C++.

OTOH it was never meant to be compiled to machine code, that's why
Python is often 100 times slowere than the equivalent C++ program, but
for tasks where the programmer time takes longer than the computation,
it is really handy.

Christian

Jorgen Grahn

unread,
Dec 8, 2020, 6:18:17 PM12/8/20
to
On Tue, 2020-12-08, Christian Gollwitzer wrote:
> Am 06.12.20 um 13:29 schrieb Jorgen Grahn:
>> Advent of Code
>> https://adventofcode.com/2020
>>
>> One programming problem a day, until Christmas. I don't know how
>> well-known it is; it's popular among my coworkers.
>>
>> So far this year, not very interesting problems, but just /having/ a
>> well-defined and smallish problem, with test data, can be refreshing.
>>
>> I find C++ a good choice for solving these. You'd think a language
>> like Python would be better fit, but I've found no use for it yet.
>> Perhaps that's just a sign my Python is rusty.
>>
>
> Well, Python shines for lot of these tasks, albeit it may suffer from
> low performance.
>
> For example, the very first thing (find the product of two numbers in
> the list that sums to 2020), can be expressed in a list comprehension:
>
>
> # input data list
> # for the real program we need to read it from stdin somehow
> report=[1721,979,366,299,675,1456]
>
> # compute product
> prod = [x*y for x in report for y in report if x+y==2020]
>
> The result is then the first entry of the list prod[0].
>
> As you can see, this single line expresses almost verbatim the problem
> and solves it in Python.

Sure, but my point was that C++ is suitable, not that some other
language is unsuitable. I haven't written anything so far (days 1--7)
that has felt painful or tedious (except the input parsing, but then I
wished for Perl).

I only brought up Python as an example of a well-known language,
general and popular for small tasks.

Juha Nieminen

unread,
Dec 9, 2020, 5:01:33 AM12/9/20
to
spu...@isnotyourbuddy.co.uk wrote:
> I disagree. I find <namespace>:: peppered all over the code annoying and messy.
> There's a reason the "using" command was included as part of the standard.

The "std::" prefix makes the code more readable because it acts as a visual
clue that something from the standard library is being used there. With a
quick visual scan you can immediately see where standard library utilities
are being used. Without the prefix it requires a deeper look, and a deeper
experience and knowledge of what's from the standard library and what isn't.

The "std::" prefix also conveys information that makes it easier to
undestand what code is doing, or gives you immediately a hint of where to
look. For example, suppose you see a line of code like this:

if(equal(a, b, c))

what does that mean? Without further knowledge it's hard to say. Is that
"equal()" function some custom function (or even macro) somewhere else
in the code? Maybe it's declared in some header file? An IDE would tell
you quickly, but you don't always have an IDE at hand.

The name alone also doesn't tell you much about what it's doing. Maybe
it's comparing if all three parameters are equal? What is the type of
the parameters?

However, consider if the line had been written like this instead:

if(std::equal(a, b, c))

that change alone conveys an enormous amount of useful information,
which you can discern without having to see anything else in the code.
You immediately know that it's a standard library function. Even if
you don't know what it does, you immediately know where to look for it.

If you do know what std::equal() does, you also know what it's doing
there and, moreover, what kind of variables a, b and c are.
(Particulary, they are iterators of some kind.)

The line of code did not become harder to read and understand by the
addition of the prefix, but the exact opposite.

spu...@isnotyourbuddy.co.uk

unread,
Dec 9, 2020, 5:41:24 AM12/9/20
to
On Wed, 9 Dec 2020 10:01:09 +0000 (UTC)
Juha Nieminen <nos...@thanks.invalid> wrote:
>spu...@isnotyourbuddy.co.uk wrote:
>> I disagree. I find <namespace>:: peppered all over the code annoying and
>messy.
>> There's a reason the "using" command was included as part of the standard.
>
>The "std::" prefix makes the code more readable because it acts as a visual
>clue that something from the standard library is being used there. With a
>quick visual scan you can immediately see where standard library utilities
>are being used. Without the prefix it requires a deeper look, and a deeper
>experience and knowledge of what's from the standard library and what isn't.

Everyone is different I suppose. I disagree completely - I find a screen full
of std:: everywhere is just useless visual noise and clutter that detracts from
being able to read the code but perhaps because I started with C decades ago
I'm used to just knowing unqualified names. If I see vector its more readable
than std::vector but each to their own.

Richard Damon

unread,
Dec 9, 2020, 7:31:33 AM12/9/20
to
I grew up as a C programmer, and used to think that same way. Finally I
realized that the typical C program and the typical C++ program were
very different. C++ programs get MUCH bigger and more complicated, and
code ends up looking into more scopes for name resolution, so habitually
adding the std:: can be a useful cognitive load reducing agent.

It somewhat depends on how well the problem partitions. If you can break
the problem into a whole lot of little files it is less needed, but even
with small 'files' the includes may bring in a lot of context. If your
using statements are limited (using std::equal; instead of using std;)
then at least a simple search will find where it is coming from.

The next step past this, where the prefix becomes ::std:: is in my mind
a bit too far, but then I don't create foo.std namespaces, so I don't
need that level of protection. If this became somewhat common, then I
could see the need.

spu...@isnotyourbuddy.co.uk

unread,
Dec 9, 2020, 9:35:25 AM12/9/20
to
On Wed, 9 Dec 2020 07:31:10 -0500
Richard Damon <Ric...@Damon-Family.org> wrote:
>I grew up as a C programmer, and used to think that same way. Finally I
>realized that the typical C program and the typical C++ program were
>very different. C++ programs get MUCH bigger and more complicated, and

Do you want to take take a guess at which language the 28 million line
linux kernel is written in? Ditto Windows and MacOS.

>code ends up looking into more scopes for name resolution, so habitually
>adding the std:: can be a useful cognitive load reducing agent.

I'm not saying it can't be useful if there's a potential name clash, but
generally I just find it irritating.

Richard Damon

unread,
Dec 9, 2020, 1:19:54 PM12/9/20
to
On 12/9/20 9:35 AM, spu...@isnotyourbuddy.co.uk wrote:
> On Wed, 9 Dec 2020 07:31:10 -0500
> Richard Damon <Ric...@Damon-Family.org> wrote:
>> I grew up as a C programmer, and used to think that same way. Finally I
>> realized that the typical C program and the typical C++ program were
>> very different. C++ programs get MUCH bigger and more complicated, and
>
> Do you want to take take a guess at which language the 28 million line
> linux kernel is written in? Ditto Windows and MacOS.

Not saying that there aren't massive C programs, but the typical
application / module that was written in C is going to be smaller than a
typical project done in C++.

Also, its been a while since I browsed kernal code, but my memory is
that it isn't what most would think of as 'typical' C code,
>
>> code ends up looking into more scopes for name resolution, so habitually
>> adding the std:: can be a useful cognitive load reducing agent.
>
> I'm not saying it can't be useful if there's a potential name clash, but
> generally I just find it irritating.
>

It isn't just to resolve clashes, but to reduce the cognative load to
decide if this is referring to a local concept or some global standard one.

If I see just string, does my local namespace provide an enhanced
version, or is this the standard one.

Alf P. Steinbach

unread,
Dec 9, 2020, 3:53:43 PM12/9/20
to
Corresponding O(n^2) non-failure-checking code is somewhat but not much
more complex in C++:


int product = []{ for( int x: values ) for( int y: values ) if( x +
y == 2020 ) { return x*y; } }();


However C++ requires a minimum of standard scaffolding around that, like


#include <stdio.h>
auto main() -> int
{
int product = []{ for( int x: values ) for( int y: values ) if( x +
y == 2020 ) { return x*y; } }();
printf( "%d\n", product );
}


> OTOH it was never meant to be compiled to machine code, that's why
> Python is often 100 times slowere than the equivalent C++ program, but
> for tasks where the programmer time takes longer than the computation,
> it is really handy.

For a large data set (which is where it counts) the main slowness of the
Python one-liner in this case is the O(n^2) behavior.

Python code with I believe the same O(n) behavior as the posted C++
code, and about the same failure detection, could go like this:


values = {
1310,
# ...
}

for v in values:
other = 2020 - v
if other in values:
print( v*other )
exit()
raise Exception( "No such value" )


For comparison, that earlier posted O(n) C++ code, sans the outer
scaffolding:


const int data[] =
{
1310,
// ...
};

void cpp_main()
{
const auto values = unordered_set<int>( begin( data ), end( data ) );
for( const int v: values ) {
const int other = 2020 - v;
if( values.count( other ) > 0 ) {
out << v*other << endl;
return;
}
}
fail( "No such value" );
}


One little difference is that with Python the presumably constant time
lookup structure (here a key -> value dictionary without values) can be
expressed as a simple literal, the curly braces, while in C++ it has to
be constructed from more fundamental data.

- Alf

Jorgen Grahn

unread,
Dec 10, 2020, 2:06:21 AM12/10/20
to
On Wed, 2020-12-09, spu...@isnotyourbuddy.co.uk wrote:
> On Wed, 9 Dec 2020 10:01:09 +0000 (UTC)
> Juha Nieminen <nos...@thanks.invalid> wrote:
>>spu...@isnotyourbuddy.co.uk wrote:
>>> I disagree. I find <namespace>:: peppered all over the code annoying and
>>messy.
>>> There's a reason the "using" command was included as part of the standard.
>>
>>The "std::" prefix makes the code more readable because it acts as a visual
>>clue that something from the standard library is being used there. With a
>>quick visual scan you can immediately see where standard library utilities
>>are being used. Without the prefix it requires a deeper look, and a deeper
>>experience and knowledge of what's from the standard library and what isn't.
>
> Everyone is different I suppose. I disagree completely - I find a screen full
> of std:: everywhere is just useless visual noise and clutter that detracts from
> being able to read the code

You won't see std:: everywhere though. Juha might have mentioned it
upthread, but there won't be as many as you'd think. At least that's
how it felt to me when I stopped using 'using namespace std'.

Try it on a piece of code you already have, and see. Or read someone
else's code.

spu...@isnotyourbuddy.co.uk

unread,
Dec 10, 2020, 3:45:04 AM12/10/20
to
On 10 Dec 2020 07:06:00 GMT
Thats the problem , I spend huge amounts of time working on other peoples
code that is littered with std:: all over the damn place that adds zero
to readability for me. If I can I usually do :s/std:://g and be done with it.

spu...@isnotyourbuddy.co.uk

unread,
Dec 10, 2020, 3:45:40 AM12/10/20
to
On Wed, 9 Dec 2020 13:19:32 -0500
Not a problem I've ever encountered.

Mr Flibble

unread,
Dec 10, 2020, 5:21:13 AM12/10/20
to
On 10/12/2020 08:44, spu...@isnotyourbuddy.co.uk wrote:
> If I can I usually do :s/std:://g and be done with it.

Totally irrational, take your meds.

/Flibble

--
😎

Juha Nieminen

unread,
Dec 10, 2020, 6:05:39 AM12/10/20
to
spu...@isnotyourbuddy.co.uk wrote:
>>The "std::" prefix makes the code more readable because it acts as a visual
>>clue that something from the standard library is being used there. With a
>>quick visual scan you can immediately see where standard library utilities
>>are being used. Without the prefix it requires a deeper look, and a deeper
>>experience and knowledge of what's from the standard library and what isn't.
>
> Everyone is different I suppose. I disagree completely

You disagree completely... So absolutely nothing of what I wrote you agree
with. Not a single point or detail.

When you see even the most obscure and least-used standard library names
being used, you immediately recognize it as a standard library name with
a quick visual scan, and immediately know what it does. When you see
something like "if(equal(a, b, c))" you immediately think "of course it's
the equal() function in the standard library! What else could it possibly
be? It can't be anything else!"

When you see name like "kill_dependency", or "perm_options", or "exists",
or "gamma_distribution" in a piece of code, you immediately know that they
are from the standard library. No need to guess or look further!


Some time in the past in another forum someone tried to prove how
unreadable code becomes when using the std:: prefix and wrote a piece
of code of a few lines in length that deliberately had as many uses
of standard library names as possible, and compared it to not using
the prefix. Ironically, I found the version with the prefixes a lot
easier to read and understand because of all the visual clues that
the prefix was giving me.

spu...@isnotyourbuddy.co.uk

unread,
Dec 10, 2020, 6:11:38 AM12/10/20
to
On Thu, 10 Dec 2020 10:20:53 +0000
Mr Flibble <fli...@i42.REMOVETHISBIT.co.uk> wrote:
>On 10/12/2020 08:44, spu...@isnotyourbuddy.co.uk wrote:
>> If I can I usually do :s/std:://g and be done with it.
>
>Totally irrational, take your meds.

I doubt you even know what thats refering to Windows Guy.

spu...@isnotyourbuddy.co.uk

unread,
Dec 10, 2020, 6:42:24 AM12/10/20
to
On Thu, 10 Dec 2020 11:05:17 +0000 (UTC)
Juha Nieminen <nos...@thanks.invalid> wrote:
>spu...@isnotyourbuddy.co.uk wrote:
>>>The "std::" prefix makes the code more readable because it acts as a visual
>>>clue that something from the standard library is being used there. With a
>>>quick visual scan you can immediately see where standard library utilities
>>>are being used. Without the prefix it requires a deeper look, and a deeper
>>>experience and knowledge of what's from the standard library and what isn't.
>>
>> Everyone is different I suppose. I disagree completely
>
>You disagree completely... So absolutely nothing of what I wrote you agree
>with. Not a single point or detail.

Don't split hairs, you know what I meant. An experience developer shouldn't
need std:: nor care what is being used from the STL. How does that make
debugging any easier?

>When you see even the most obscure and least-used standard library names
>being used, you immediately recognize it as a standard library name with
>a quick visual scan, and immediately know what it does. When you see

No, it just gets lost in a sea of ::

>something like "if(equal(a, b, c))" you immediately think "of course it's
>the equal() function in the standard library! What else could it possibly
>be? It can't be anything else!"
>
>When you see name like "kill_dependency", or "perm_options", or "exists",
>or "gamma_distribution" in a piece of code, you immediately know that they
>are from the standard library. No need to guess or look further!

Who cares? If they're obscure parts of the STL you won't know what they do
anyway so knowing they're from the STL makes no difference since sticking
them in google will tell you all you need to know.

>Some time in the past in another forum someone tried to prove how
>unreadable code becomes when using the std:: prefix and wrote a piece
>of code of a few lines in length that deliberately had as many uses
>of standard library names as possible, and compared it to not using
>the prefix. Ironically, I found the version with the prefixes a lot
>easier to read and understand because of all the visual clues that
>the prefix was giving me.

As I said, each to their own. That simply demostrates your personal psychology,
not whether code is readable.

Mr Flibble

unread,
Dec 10, 2020, 7:06:17 AM12/10/20
to
It means you are doing a search/replace of "std::" with "" and unlike you I use a variety of POSIX-compliant operating systems as well Windows (not sure if Windows 10 is currently POSIX-compliant), Fucktarded Guy.

So, again, irrational, take your meds.

/Flibble

--
😎

Mr Flibble

unread,
Dec 10, 2020, 7:07:41 AM12/10/20
to
Your personal psychology is that of the irrational kind, mate.

/Flibble

--
😎

spu...@isnotyourbuddy.co.uk

unread,
Dec 10, 2020, 7:37:39 AM12/10/20
to
On Thu, 10 Dec 2020 12:05:54 +0000
Mr Flibble <fli...@i42.REMOVETHISBIT.co.uk> wrote:
>On 10/12/2020 11:11, spu...@isnotyourbuddy.co.uk wrote:
>> On Thu, 10 Dec 2020 10:20:53 +0000
>> Mr Flibble <fli...@i42.REMOVETHISBIT.co.uk> wrote:
>>> On 10/12/2020 08:44, spu...@isnotyourbuddy.co.uk wrote:
>>>> If I can I usually do :s/std:://g and be done with it.
>>>
>>> Totally irrational, take your meds.
>>
>> I doubt you even know what thats refering to Windows Guy.
>
>It means you are doing a search/replace of "std::" with "" and unlike you I
>use a variety of POSIX-compliant operating systems as well Windows (not sure
>if Windows 10 is currently POSIX-compliant), Fucktarded Guy.
>
>So, again, irrational, take your meds.

I see youre up to your usual level of debate.

Richard Damon

unread,
Dec 10, 2020, 8:03:20 AM12/10/20
to
On 12/10/20 6:42 AM, spu...@isnotyourbuddy.co.uk wrote:
> Who cares? If they're obscure parts of the STL you won't know what they do
> anyway so knowing they're from the STL makes no difference since sticking
> them in google will tell you all you need to know.

But you at least know where to look for the description. The std::
prefix bdcomes useful when the program grows bigger than you can hold
most of its parts description in your head at once.

Before you hit that point, the std:: may seem to be 'noise', but once
the program passes that point, it become essential 'signal' to help with
understanding.

Juha Nieminen

unread,
Dec 11, 2020, 1:59:06 AM12/11/20
to
spu...@isnotyourbuddy.co.uk wrote:
> No, it just gets lost in a sea of ::

That's the most ridiculous thing I have heard in a while.

You could use the exact same argument to advocate for the removal of all
parentheses, curly braces, brackets, semicolons, commas, hash symbols and
so on and so forth.

From all non-ascii characters that are used abundanty in C++ code, why
are you singling out "::" in particular? From all the ones that exist,
why those in particular? What's so special about those?

spu...@isnotyourbuddy.co.uk

unread,
Dec 11, 2020, 5:25:23 AM12/11/20
to
I'm tired of this argument. Why can't Aspies like you understand that not
everyone is the same or processes visual information in the same way.

Juha Nieminen

unread,
Dec 11, 2020, 6:33:58 AM12/11/20
to
Ah, finally the insults.

I'll take that as a concession of defeat.

spu...@isnotyourbuddy.co.uk

unread,
Dec 11, 2020, 9:34:34 AM12/11/20
to
On Fri, 11 Dec 2020 11:33:35 +0000 (UTC)
Thank you for proving my point so emphatically.

Mr Flibble

unread,
Dec 11, 2020, 9:36:12 AM12/11/20
to
You lost the argument, mate, I suggest you move on (and consider your irrationality whilst you are at it).

/Flibble

--
😎

spu...@isnotyourbuddy.co.uk

unread,
Dec 11, 2020, 11:43:48 AM12/11/20
to
There is no argument "mate" because there's no right answer since its
subjective not objective. Perhaps you lot should stop your circle jerking for 5
minutes and go look up the difference.

Chris Vine

unread,
Dec 11, 2020, 1:14:46 PM12/11/20
to
Ah, so you are the person who used to post as "Boltar". You were a
juvenile nobody then, and still a juvenile nobody now.

spu...@isnotyourbuddy.co.uk

unread,
Dec 14, 2020, 3:54:14 AM12/14/20
to
I do love irony :)

0 new messages