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

Try to compile this

45 views
Skip to first unread message

Bonita Montero

unread,
Sep 17, 2022, 5:52:03 AM9/17/22
to
#include <iostream>
#include <utility>

using namespace std;

int main()
{
auto pow = []<unsigned P>( double b, integral_constant<unsigned, P> )
-> double
{
auto unroll = [&]<size_t ... Indices>( index_sequence<Indices ...> )
-> double
{
return ((Indices, b) * ...);
};
if constexpr( P )
return unroll( make_index_sequence<P>() );
else
return b;
};
cout << pow( 2.0, integral_constant<unsigned, 10'000>() ) << endl;
}


Bonita Montero

unread,
Sep 17, 2022, 10:13:29 AM9/17/22
to
This was just a joke because the above code is just a compiler-killer

| C:\Users\Boni>timep cl -std:c++20 -Ox x.cpp -EHs
| Microsoft (R) C/C++ Optimizing Compiler Version 19.33.31630 for x64
| Copyright (C) Microsoft Corporation. All rights reserved.
|
| x.cpp
| Microsoft (R) Incremental Linker Version 14.33.31630.0
| Copyright (C) Microsoft Corporation. All rights reserved.
|
| /out:x.exe
| x.obj
| real 581305.97ms
| user 580703.12ms
| sys 968.75ms
| cycles 2.089.456.387.776

The above result is from a TR3990X Zen2 machine.
Compiling the same code with g++11 on a 1800X
Zen1 machine takes 48 seocnds.

Lynn McGuire

unread,
Sep 18, 2022, 12:05:39 PM9/18/22
to
Thanks, but no. What a mess !

And I do not allow namespaces to be generalized in our code. No using !

Lynn

Bonita Montero

unread,
Sep 18, 2022, 12:56:06 PM9/18/22
to
You're a very bad programmer for sure as I already have noticed.
Not because of this, but people having such narrow-minded attitudes
are unflexible.


Lynn McGuire

unread,
Sep 19, 2022, 4:02:26 PM9/19/22
to
Nope, I am stewarding 1.3 million lines of F77 and C++ code. Use of the
using command is incredibly dangerous across our incredibly large code base.

Lynn


Bonita Montero

unread,
Sep 19, 2022, 4:12:14 PM9/19/22
to
This doesn't depend on the size of the code.
As re-using symbols of std is uncommon in other namespaces and
the compiler would error for clashes anyway this isn't a deal.



Mr Flibble

unread,
Sep 19, 2022, 4:49:10 PM9/19/22
to
There is no reason to ever use "using namespace std;" at global scope
and any benefit is outweighed by disadvantages.

/Flibble

Lynn McGuire

unread,
Sep 19, 2022, 4:59:34 PM9/19/22
to
Good luck with that thought. The compiler uses the first method that
meets the conditions. If you are lucky you might get a warning that
there is more than one method that meets the conditions. Been there,
done that with Visual C++ back in the 2000s.

Lynn


Lynn McGuire

unread,
Sep 19, 2022, 9:23:29 PM9/19/22
to
I have to admit that we have the size () method sprinkled throughout a
least a hundred of our classes. std::size () really messed with that
when we jumped from MSVC 6 to MSVC 2005 ???. We used the "using
namespace std;" which bit us hard in a couple of cases.

Lynn

Bonita Montero

unread,
Sep 19, 2022, 11:37:56 PM9/19/22
to
There are no drawbacks except for compulsive people.


Bonita Montero

unread,
Sep 19, 2022, 11:38:46 PM9/19/22
to
You can't be a good programmer since your first thought here isn't
that you definitely get en error.


Juha Nieminen

unread,
Sep 20, 2022, 2:19:14 AM9/20/22
to
Bonita Montero <Bonita....@gmail.com> wrote:
> This doesn't depend on the size of the code.
> As re-using symbols of std is uncommon in other namespaces and
> the compiler would error for clashes anyway this isn't a deal.

If you are such a C++ expert as you portray yourself to be, you should
know better than that.

Using the same name with two different functions doesn't necessarily
cause a name clash. It's called overloading. And the funny thing about
overloading is that if a new overloaded version of a function is
introduced in addition to the old existing one, some already existing
function calls might suddenly start calling the new one rather than
the old one, if the new one matches better.

When that happens deliberately then it's fine. However, when that
happens inadvertently it can cause really obscure bugs, as code that
has been compiling and working for a long time still compiles just
fine... but starts working incorrectly at runtime.

And the thing is, the newly introduced "overloaded" function might
come from the standard library, when a new #include line is added
somewhere.

You say that "re-using symbols of std is uncommon". Yeah, I'm sure that
you remember the literally hundreds and hundreds, maybe thousands, of
names in the standard library by heart.

Juha Nieminen

unread,
Sep 20, 2022, 2:21:09 AM9/20/22
to
Bonita Montero <Bonita....@gmail.com> wrote:
>> Good luck with that thought.  The compiler uses the first method that
>> meets the conditions.  If you are lucky you might get a warning that
>> there is more than one method that meets the conditions.  Been there,
>> done that with Visual C++ back in the 2000s.
>
> You can't be a good programmer since your first thought here isn't
> that you definitely get en error.

Apparently you don't know what function overloading is.

Bonita Montero

unread,
Sep 20, 2022, 2:21:30 AM9/20/22
to
Am 20.09.2022 um 08:18 schrieb Juha Nieminen:
> Bonita Montero <Bonita....@gmail.com> wrote:
>> This doesn't depend on the size of the code.
>> As re-using symbols of std is uncommon in other namespaces and
>> the compiler would error for clashes anyway this isn't a deal.
>
> If you are such a C++ expert as you portray yourself to be, you should
> know better than that.

That's not a matter of knowledge but of personal style.
I wont't read the rest of what you write to persuade me
to adhere to your personal style.


Juha Nieminen

unread,
Sep 20, 2022, 2:39:08 AM9/20/22
to
Bonita Montero <Bonita....@gmail.com> wrote:
> I wont't read the rest of what you write to persuade me
> to adhere to your personal style.

Which automatically invalidates everything you say. You have no
counter-arguments to what I wrote, and you are too afraid to even
read what I wrote, and instead you are resorting to the age-old
arrogant and provocative "I'm so far beyond you that I'm not even
going to give you the dignity of reading what you have written".

Why people here are *still* taking you seriously and responding to
you seriously is beyond my comprehension.

Bonita Montero

unread,
Sep 20, 2022, 3:08:21 AM9/20/22
to
Am 20.09.2022 um 08:38 schrieb Juha Nieminen:
> Bonita Montero <Bonita....@gmail.com> wrote:
>> I wont't read the rest of what you write to persuade me
>> to adhere to your personal style.
>
> Which automatically invalidates everything you say. You have no
> counter-arguments to what I wrote, ...

The counter argument is: I'm programming like this for
29 years in C++ and I never ran into problems with that.


David Brown

unread,
Sep 20, 2022, 3:36:06 AM9/20/22
to
Nameclashes with std /are/ common, and get more common as the standard
library increases in size. The whole point of having the standard
library in the std:: namespace is that the C++ committee are free to add
whatever names they feel appropriate, without fear of breaking existing
code or limiting other programmers.

If you have a global "using namespace std;", and there are clashes, then
it /might/ lead to a clear compiler error. But it might not - it could
well be that overload or template resolution simply leads to the wrong
function being called, with no warning until you get obscure effects
during testing.

And even if compile-time errors were guaranteed, what help is that when
you take a large existing C++14 code base that has been extensively
tested and debugged, then suddenly there are problems and collisions
when you move to C++17 or C++20.

Namespaces were added to C++ because at that time, decades ago,
identifier collisions were a big problem in large C codebases. They
have been a major tool ever since. Adding global "using namespace"
directives, especially for namespaces that are not fully under your own
control, is throwing out that tool.

It is fine to have "using namespace" in smaller scopes - such as inside
a function. Occasionally you might want to import a namespace into an
entire implementation file (not a header), but not for "std". If you
had the habit of putting "using namespace std;" /inside/ main() or other
sample function, you'd see far fewer objections.

Bonita Montero

unread,
Sep 20, 2022, 6:08:27 AM9/20/22
to
Am 20.09.2022 um 09:35 schrieb David Brown:

> Nameclashes with std /are/ common, and get more common as the standard
> library increases in size.  The whole point of having the standard
> library in the std:: namespace is that the C++ committee are free to add
> whatever names they feel appropriate, without fear of breaking existing
> code or limiting other programmers.

This isn't the only aspect for that.


> If you have a global "using namespace std;", and there are clashes, then
> it /might/ lead to a clear compiler error.  But it might not - it could
> well be that overload or template resolution simply leads to the wrong
> function being called, with no warning until you get obscure effects
> during testing.

That's unlikely and that would be my problem.
And this problem has never been shown with the code I posted here.
>

> It is fine to have "using namespace" in smaller scopes - ...

No, the same name clashes could arise.

I'm sure you and Juha continue your mission for the next 10 years.
You're both insane.


Keith Thompson

unread,
Sep 20, 2022, 8:59:35 AM9/20/22
to
Yes, why do you continue to respond to her?

You need to learn the fine art of not replying.

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Scott Lurndal

unread,
Sep 20, 2022, 9:49:50 AM9/20/22
to
And apparently you don't know how to ignore the trolls.

Lynn McGuire

unread,
Sep 20, 2022, 5:18:54 PM9/20/22
to
Sadly it does appear that way.

Lynn

Bonita Montero

unread,
Sep 20, 2022, 5:48:58 PM9/20/22
to
Sorry, others try to dictate my style and we're not in the same project.
And you call me trollng ?


0 new messages