Friday, December 13, 2019

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

fir <profesor.fir@gmail.com>: Dec 13 09:04AM -0800

im a c man and dislike c++, i remember i was learning c++ a bot about year 2001 or so and
one things about the pooffed tutaorials and people about it was 'inheritance'
 
i disliked it a alot then as it seemed shit to me as looking from c perspectiev of structures and arrays manegement but i van add something i noticed on it in that span of years)probably some people noticed that but most if not all c++ people i met like was unaware of this realization of me:
 
 
if you want to catologue some things and make some net/graph of some dependencies what fives you inheritance is crap (abstracting even of the low lewel realization of it) this is becouse say, take some things that are especially good to make some organization of it say big set of books (or some more writhings like boook+articles+papers+etc like in pdf form),
or take set of musical records (songs, or variouse mp3) or set of youtube videos, or what else you can take
 
what you need to desctibe it and make it searchable. accesible is rather a tag, then you may and its ok to do give some relations to this tags itself but those tahs like are by nature multidimensional and cross itself i mean if you wwant to catalogue books one tag will be proper author of it, other tah will be say year of making it, other tag will be kind of it, then you may give relation of this tag like say this author belongs to tag of 'european authors' or this date belongs to 19-th century and so on but this thing is for sure not what inheritance gives you but some far more proper kind of typization/classification and if so this is what progarmming languages may eventually need - and now i realize it as clearly as i wrote it here , bac then in 2001 or so i only realized that thic c++ inheritance shit is not logiacally well done
 
(and what i write here i realized few years ago, but forgot to mention it)
fir <profesor.fir@gmail.com>: Dec 13 09:13AM -0800

i added some commas, as it maybe was to weak readable:, this is sligjtly corrected form:
 
 
im a c man and dislike c++, i remember i was learning c++ a bit about year 2001 or so and
one things about the pooffed tutorials and people about it was 'inheritance'
 
i disliked it a alot then as it seemed shit to me as looking from c perspective of structures and arrays manegement but i can add something i noticed on it in that span of years) probably some people noticed that, but most, if not all, c++ people i met, like was unaware of this realization of me:
 
 
if you want to catologue some things and make some net/graph of some dependencies what gives you inheritance is crap (abstracting even of the low lewel realization of it) this is becouse, say, take some things that are especially good to make some organization of it say big set of books (or some more writhings like boook+articles+papers+etc like in pdf form),
or take set of musical records (songs, or variouse mp3) or set of youtube videos, or what else you can take
 
what you need to desctibe it and make it searchable/ accesible is rather a tag, then you may (and its ok to do it) give some relations to this tags itself, but those tags are by nature multidimensional and cross itself; i mean if you wwant to catalogue books one tag will be proper author of it, other tag will be, say, year of making it, other tag will be kind of it; then you may give relation of this tag like, say, this author belongs to tag of 'european authors' or this date belongs to 19-th century and so on, but this thing is for sure not what inheritance gives you but some far more proper kind of typization/classification and, if so, this is what progarmming languages may eventually need - and now i realize it as clearly as i wrote it here , back then, in 2001 or so i only realized that this c++ inheritance shit is not logiacally well done
 
(and what i write here i realized few years ago, but forgot to mention it)
Bonita Montero <Bonita.Montero@gmail.com>: Dec 13 06:17PM +0100

People that can't see the massive productivity- and
maintainability-advantages of C++ over C can't program.
fir <profesor.fir@gmail.com>: Dec 13 09:33AM -0800

W dniu piątek, 13 grudnia 2019 18:18:02 UTC+1 użytkownik Bonita Montero napisał:
> People that can't see the massive productivity- and
> maintainability-advantages of C++ over C can't program.
 
lol...
 
for me its only dependency od some trash dlls of c++ runtime, and also a lot of troubles with incompatible binaries even amongts the sme compilers in same versions (+ a lot of boring things to spare time on)
 
(but i dont want to discuss it , the post is about inheritance)
Thiago Adams <thiago.adams@gmail.com>: Dec 13 12:43PM -0800

On Friday, December 13, 2019 at 2:18:02 PM UTC-3, Bonita Montero wrote:
> People that can't see the massive productivity- and
> maintainability-advantages of C++ over C can't program.
 
You can open a new topic about that and give us more
details.
Barry Schwarz <schwarzb@delq.com>: Dec 13 02:30PM -0800

On Fri, 13 Dec 2019 12:43:01 -0800 (PST), Thiago Adams
>> maintainability-advantages of C++ over C can't program.
 
>You can open a new topic about that and give us more
>details.
 
Please don't. We don't need another discussion from someone who has
no idea what my requirements are telling me what tools I should be
using.
 
--
Remove del for email
Vir Campestris <vir.campestris@invalid.invalid>: Dec 13 09:51PM

On 12/12/2019 12:06, Frederick Gotham wrote:
 
>> 4GB of source files?
 
>> Out of interest, how long does it take to compile that lot?
 
> Around about 55min - 65min with our PC's that have 20 cores.
 
Look at icecream
 
https://github.com/icecc/icecream
 
It shares your compilation around the network.
 
Andy
Bonita Montero <Bonita.Montero@gmail.com>: Dec 13 11:57AM +0100

I wrote a class where all the memory allocated from it must come from
a single allocator. I've derived my own allocator from mimalloc to make
it NUMA-aware. So I had the idea of a simple helper-class that is like
uniuqe_ptr but also has a attached allocator. So here it is:
 
#pragma once
#include <memory>
#include <utility>
#include "cpp_attr.h"
 
template<typename T, typename Alloc = std::allocator<T>>
class alloc_ptr
{
public:
template<typename ... Args>
alloc_ptr( Alloc const &alloc, Args ... args );
alloc_ptr( alloc_ptr &&other );
~alloc_ptr();
T &operator *();
T *operator ->();
T *release();
void swap( alloc_ptr &other );
T *get();
operator bool();
 
private:
using t_allocator = typename std::allocator_traits<Alloc>::template
rebind_alloc<T>;
using atraits = std::allocator_traits<t_allocator>;
T *m_object;
[[no_unique_address]]
t_allocator m_alloc;
};
 
template<typename T, typename Alloc>
template<typename ... Args>
inline
alloc_ptr<T, Alloc>::alloc_ptr( Alloc const &alloc, Args ... args ) :
m_alloc( t_allocator( alloc ) )
{
m_object = atraits::allocate( m_alloc, 1 );
try
{
atraits::construct( m_alloc, m_object, args ... );
}
catch( ... )
{
atraits::deallocate( m_alloc, m_object, 1 );
throw;
}
}
 
template<typename T, typename Alloc>
inline
alloc_ptr<T, Alloc>::~alloc_ptr()
{
atraits::deallocate( m_alloc, m_object, 1 );
atraits::destroy( m_alloc, m_object );
}
 
template<typename T, typename Alloc>
inline
alloc_ptr<T, Alloc>::alloc_ptr( alloc_ptr &&other )
{
m_alloc = other.m_alloc;
m_object = other.m_object;
other.m_object = nullptr;
}
 
template<typename T, typename Alloc>
inline
T &alloc_ptr<T, Alloc>::operator *()
{
return *m_object;
}
template<typename T, typename Alloc>
inline
T *alloc_ptr<T, Alloc>::operator ->()
{
return m_object;
}
 
template<typename T, typename Alloc>
inline
T *alloc_ptr<T, Alloc>::release()
{
T *object = m_object;
m_object = nullptr;
return object;
}
 
template<typename T, typename Alloc>
inline
void alloc_ptr<T, Alloc>::swap( alloc_ptr &other )
{
swap( m_alloc, other.m_alloc );
swap( m_object, other.m_object );
}
 
template<typename T, typename Alloc>
inline
T *alloc_ptr<T, Alloc>::get()
{
return m_object;
}
 
template<typename T, typename Alloc>
inline
alloc_ptr<T, Alloc>::operator bool()
{
return m_object != nullptr;
}
 
I'm deriving my own allocator-type with allocator_traits<A>
::rebind_alloc<A2) to have more convenience. So I won't have
to convert my internal allocator on every definition of an
alloc_ptr.
Bonita Montero <Bonita.Montero@gmail.com>: Dec 13 12:00PM +0100

>     m_object       = other.m_object;
>     other.m_object = nullptr;
> }
 
I have to fix this.
Bonita Montero <Bonita.Montero@gmail.com>: Dec 13 12:05PM +0100

>>      other.m_object = nullptr;
>> }
 
> I have to fix this.
 
Now everything should be fine:
 
template<typename T, typename Alloc>
inline
alloc_ptr<T, Alloc>::alloc_ptr( alloc_ptr &&other )
{
if( m_object )
atraits::deallocate( m_alloc, m_object, 1 ),
atraits::destroy( m_alloc, m_object );
m_object = other.m_object;
m_alloc = other.m_alloc;
other.m_object = nullptr;
}
 
template<typename T, typename Alloc>
inline
alloc_ptr<T, Alloc>::~alloc_ptr()
{
if( m_object )
atraits::deallocate( m_alloc, m_object, 1 ),
atraits::destroy( m_alloc, m_object );
}
Bonita Montero <Bonita.Montero@gmail.com>: Dec 13 02:28PM +0100

Sorry, deallocate and destroy have to be reversed.
And a move assignment operator would be also convenient.
Bonita Montero <Bonita.Montero@gmail.com>: Dec 13 06:35AM +0100

>> No, very good idea.
 
> In your opinion; unfortunately you haven't thought through the
> implications of what you are suggesting.  It is a *really* bad idea.
 
Then tell me the implications.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 13 09:23AM +0100

On 12.12.2019 18:40, Öö Tiib wrote:
> It uses `_` everywhere there are texts to localize in code:
 
> printf(_("Report bugs to <%s>.\n"), PACKAGE_BUGREPORT);
 
> So its usages can be found by searching for `_("`.
 
Oh, that's ugly.
 
But I still don't see the conflict, if that's a macro with params.
 
Example?
 
 
- Alf
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)