Monday, June 14, 2021

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

Bonita Montero <Bonita.Montero@gmail.com>: Jun 14 05:16AM +0200

>>> developers". It's still only you.
 
>> There are no good reasons to do it in a different way.
 
> Just because you can't think of any doesn't mean there isn't.
 
You have too much phantasy.
Bonita Montero <Bonita.Montero@gmail.com>: Jun 14 05:18AM +0200


>> No, we're talking about replacing malloc() and thereby changing
>> how C++-implementations allocate at last.
 
> Noone is replacing malloc. ...
 
There are a lot of people which change the implementation.
 
> It's the operator new/delete that gets replaced with code that uses
> an alternative allocator that offer container-specific optimizations.
 
No, it's actually sufficient to replace malloc(). A lot of benchmarks
wich malloc()-replacement like mimalloc show that this works with
arbitrary C++-code.
Sam <sam@email-scan.com>: Jun 14 07:00AM -0400

Bonita Montero writes:
 
 
>>> There are no good reasons to do it in a different way.
 
>> Just because you can't think of any doesn't mean there isn't.
 
> You have too much phantasy.
 
You can never have too much "phantasy".
Sam <sam@email-scan.com>: Jun 14 07:00AM -0400

Bonita Montero writes:
 
>>> how C++-implementations allocate at last.
 
>> Noone is replacing malloc. ...
 
> There are a lot of people which change the implementation.
 
Speaking of "phantasies"…
 
 
> No, it's actually sufficient to replace malloc(). A lot of benchmarks
> wich malloc()-replacement like mimalloc show that this works with
> arbitrary C++-code.
 
Until it doesn't.
Bonita Montero <Bonita.Montero@gmail.com>: Jun 14 01:08PM +0200

>> wich malloc()-replacement like mimalloc show that this works with
>> arbitrary C++-code.
 
> Until it doesn't.
 
It has always worked because people expected that and because
of that standard libraries are designed in that way.
Sam <sam@email-scan.com>: Jun 14 06:35PM -0400

Bonita Montero writes:
 
 
>> Until it doesn't.
 
> It has always worked because people expected that and because
> of that standard libraries are designed in that way.
 
If I only had a nickel for every time something "always worked", until it
didn't, because it turned out to be undefined or unspecified behavior.
 
Hint: when that happens to you your earnest appeal to the maintainers of
those "standard libraries" (that were always "designed in that way", until
they didn't) is not going to go very far.
Nikki Locke <nikki@trumphurst.com>: Jun 14 10:23PM

Available C++ Libraries FAQ
 
URL: http://www.trumphurst.com/cpplibs/
 
This is a searchable list of libraries and utilities (both free
and commercial) available to C++ programmers.
 
If you know of a library which is not in the list, why not fill
in the form at http://www.trumphurst.com/cpplibs/cppsub.php
 
Maintainer: Nikki Locke - if you wish to contact me, please use the form on the website.
David Brown <david.brown@hesbynett.no>: Jun 14 02:29PM +0200

If I am inside a namespace, is there a way to declare a function as
being outside the namespace without closing and reopening it? I.e., can
I do:
 
 
namespace N {
 
int f(int x) { return x; }
 
}
 
int g(int x) { return x; }
 
 
namespace N {
 
int h(int x) { return x; }
 
}
 
/without/ having to have "namespace N" twice?
Bonita Montero <Bonita.Montero@gmail.com>: Jun 14 03:00PM +0200

Do you think about sth. like:
 
namespace fuck
{
void fn();
}
 
void fuck::fn()
{
}
David Brown <david.brown@hesbynett.no>: Jun 14 03:31PM +0200

On 14/06/2021 15:00, Bonita Montero wrote:
 
> void fuck::fn()
> {
> }
 
No.
 
The aim is to declare a function that is outside the namespace, but to
be able to do so from within the namespace.
"Öö Tiib" <ootiib@hot.ee>: Jun 14 10:05AM -0700

On Monday, 14 June 2021 at 15:30:13 UTC+3, David Brown wrote:
> If I am inside a namespace, is there a way to declare a function as
> being outside the namespace without closing and reopening it?
 
Can be that it is <https://en.wikipedia.org/wiki/XY_problem> as it is unclear
why you do not want to define whatever functions of whatever namespace
within that namespace. Repeating namespace N twice is not needed:
 
namespace N {
 
int f(int x) { return x; }
 
int h(int x) { return x; }
 
}
 
int g(int x) { return x; }
David Brown <david.brown@hesbynett.no>: Jun 14 07:43PM +0200

On 14/06/2021 19:05, Öö Tiib wrote:
 
> int h(int x) { return x; }
 
> }
 
> int g(int x) { return x; }
 
Oh, I know I can do /that/. I could also define g() before the
"namespace N" at the start - and of course I could write it as I did
originally. But in my code, the global namespace function "g" fits
naturally along with other code that is within the namespace of the
model. If there is a syntax unknown to me that could be used declare
"g" as being outside the namespace, it would be neater in my code structure.
"Öö Tiib" <ootiib@hot.ee>: Jun 14 11:28AM -0700

On Monday, 14 June 2021 at 20:43:35 UTC+3, David Brown wrote:
> naturally along with other code that is within the namespace of the
> model. If there is a syntax unknown to me that could be used declare
> "g" as being outside the namespace, it would be neater in my code structure.
 
Probably there are no such way.
I only have functions with internal linkage in global namespace as code
bases tend to be huge lately. Why you need it to be in global namespace?
I prefer to qualify explicitly instead of wrapping into namespace N {}.
When it is something long like depths::of_various::spaces then I
can shorten it with alias first:
 
namespace N = depths::of_various::spaces;
 
static int g(int x);
 
int N::f(int x) { return x; }
 
int g(int x) { return x; }
 
int N::h(int x) { return x; }
Louis Krupp <lkrupp@invalid.pssw.com.invalid>: Jun 14 02:26PM -0600

On 6/14/2021 6:29 AM, David Brown wrote:
 
> int h(int x) { return x; }
 
> }
 
> /without/ having to have "namespace N" twice?
 
For what it's worth, the obvious attempt at a solution:
 
===
namespace n
{
    void   nf1() {}
    void ::gf2() {}
    void   nf3() {}
}
===
 
doesn't work with g++:
 
===
:4:16: error: declaration of 'void gf2()' not in a namespace surrounding
'::'
    4 |     void ::gf2() {}
      |                ^
:4:16: error: 'void gf2()' should have been declared inside '::'
===
 
But you've probably tried that.
 
Louis
Paavo Helde <myfirstname@osa.pri.ee>: Jun 14 11:28PM +0300

14.06.2021 20:43 David Brown kirjutas:
> naturally along with other code that is within the namespace of the
> model. If there is a syntax unknown to me that could be used declare
> "g" as being outside the namespace, it would be neater in my code structure.
 
If g "fits naturally" between f and h then they all should be in the
same namespace. This does not prohibit you from having it also in the
global namespace:
 
namespace N {
int f(int x) { return x; }
int g(int x) { return x; }
int h(int x) { return x; }
}
 
int global_g(int x) {
return N::g(x);
}
 
.. OR ..
 
using N::g;
David Brown <david.brown@hesbynett.no>: Jun 14 11:07PM +0200

On 14/06/2021 20:28, Öö Tiib wrote:
>> model. If there is a syntax unknown to me that could be used declare
>> "g" as being outside the namespace, it would be neater in my code structure.
 
> Probably there are no such way.
 
I suspect that is the case. But there is always the hope that I am
missing something!
 
> I only have functions with internal linkage in global namespace as code
> bases tend to be huge lately. Why you need it to be in global namespace?
 
It is in connection with interrupts and weak linkage (again, this isn't
the only way to handle this, but it would be convenient for my code
structure).
 
 
> int N::f(int x) { return x; }
 
> int g(int x) { return x; }
 
> int N::h(int x) { return x; }
 
That would be possible, I suppose, but there are quite a few internal
functions and a fair amount of internal data within the namespace.
These could themselves be put inside a singleton class, but a namespace
does that job just as well.
David Brown <david.brown@hesbynett.no>: Jun 14 11:17PM +0200

On 14/06/2021 22:28, Paavo Helde wrote:
> }
 
>  .. OR ..
 
> using N::g;
 
That's a neat suggestion - but it won't work in my particular case
because "g" should be a weak elf symbol. The reason it should be
outside the module's (in the old-fashioned sense of a cpp file with a
namespace - I am not yet using real C++ modules) namespace is that
another part of the code could override it by defining its own function
with that name. I don't want the overriding code to define the
overriding function inside the module's namespace.
 
At the moment, I am declaring "g" to be "extern C", which is a bit of a
sledgehammer solution but works.
David Brown <david.brown@hesbynett.no>: Jun 14 11:18PM +0200

On 14/06/2021 22:26, Louis Krupp wrote:
> :4:16: error: 'void gf2()' should have been declared inside '::'
> ===
 
> But you've probably tried that.
 
I have, yes - I too thought it was the obvious solution!
Bonita Montero <Bonita.Montero@gmail.com>: Jun 14 01:10PM +0200

int main()
{
auto f = []<typename T>() -> T
{
return 123;
};
f.operator ()<int>(); // only way ?
}
 
Is the above code the only way to call the lambda ?
David Brown <david.brown@hesbynett.no>: Jun 14 02:23PM +0200

On 14/06/2021 13:10, Bonita Montero wrote:
>     f.operator ()<int>(); // only way ?
> }
 
> Is the above code the only way to call the lambda ?
 
You made a templated lambda - you have to give the type /somehow/. What
are you actually trying to do?
Bonita Montero <Bonita.Montero@gmail.com>: Jun 14 02:58PM +0200

>> }
 
>> Is the above code the only way to call the lambda ?
 
> You made a templated lambda - you have to give the type /somehow/.
 
No, I just want to return a value of that type.
"Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Jun 14 03:12PM +0200

On 14 Jun 2021 13:10, Bonita Montero wrote:
>     f.operator ()<int>(); // only way ?
> }
 
> Is the above code the only way to call the lambda ?
 
I've never used a templated lambda, but if I needed something like that
I think I'd use a type-indicating argument, like (off the cuff)
 
template< class T > struct Use_type_{ using Type = T; };
 
auto main() -> int
{
const auto f = []( auto t )
{ return static_cast<decltype(t)::Type>( 123 ); };
 
return f( Use_type_<int>() );
}
 
- Alf
MrSpook_5fdc40@qvqo7xsmj4s.co.uk: Jun 14 01:16PM

On Mon, 14 Jun 2021 15:12:37 +0200
>I think I'd use a type-indicating argument, like (off the cuff)
 
> template< class T > struct Use_type_{ using Type = T; };
 
> auto main() -> int
 
Or back in the real world: int main()
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)