Friday, October 14, 2016

Digest for comp.lang.c++@googlegroups.com - 24 updates in 5 topics

Hergen Lehmann <hlehmann.expires.5-11@snafu.de>: Oct 14 06:26PM +0200

Am 14.10.2016 um 15:55 schrieb JiiPee:
 
 
> ye i thought about map, but its slow , isnt it? If I run a for-loop wich
> these indexes millions of times per second then map would be slow isnt
> it? Or is map-call as fast as an array call (to acquire the value)?
 
Yeah, it's slower than an array, although not horribly so. But it would
show the reader exactly, what you intend to do here - mapping an
direction to some other data structure.
 
If performance is absolutely crucial, something like this might be a
good compromise:
 
enum class Direction { North, East, South, West };
 
template <class T> class DirectionMap<T>
{
public:
T& operator [](Direction d)
{
if (unsigned(d)<sizeof(_array)) return _array[unsigned(d)];
else throw std::range_error("invalid direction");
}
public:
T _array[4];
};
 
DirectionMap<int> directions;
directions[Direction::East]=4;
 
Hergen
Cholo Lennon <chololennon@hotmail.com>: Oct 14 01:47PM -0300

On 10/14/2016 10:11 AM, JiiPee wrote:
>> In my case I'd write dirNorth, dirEast, etc
 
> I dont use capitals anymore, but isnt it DirNorth better? I think that
> is what many recommend
 
Better? I don't know, it's another possibility. BTW, there are several
coding conventions that use a capitalized initial letter only for
classes or structs (i.e. Google C++ style guide:
https://google.github.io/styleguide/cppguide.html#General_Naming_Rules)
 
Regards
 
--
Cholo Lennon
Bs.As.
ARG
"Öö Tiib" <ootiib@hot.ee>: Oct 14 09:50AM -0700

On Friday, 14 October 2016 19:18:29 UTC+3, JiiPee wrote:
> might be only used in vehicle currently, but later on some other class
> might use it as well. should we put it outside just in case others use
> it? Direction is quite general thing, isnt it?
 
I thought we *never* know about future. So trying to make something
compatible with future is pointless. When future arrives then we can
fix it. BTW, a direction containing of 4 discrete vales is not general
thing.
Paavo Helde <myfirstname@osa.pri.ee>: Oct 14 07:56PM +0300

On 14.10.2016 19:18, JiiPee wrote:
> might be only used in vehicle currently, but later on some other class
> might use it as well. should we put it outside just in case others use
> it? Direction is quite general thing, isnt it?
 
If the requirements change, the code will change as well. That's normal.
But often you do not know in what direction the requirements will
change, so there is usually little point in doing things in advance "for
any case". Instead, write readable and straightforward code which can be
easily refactored when requirements change.
 
Of course all the functionality should be covered by automatic unit
tests, otherwise refactoring becomes impossible.
 
Cheers
Paavo
JiiPee <no@notvalid.com>: Oct 14 06:00PM +0100

On 14/10/2016 17:50, Öö Tiib wrote:
> I thought we*never* know about future.
 
hehe
 
Well, God knows....
David Brown <david.brown@hesbynett.no>: Oct 14 07:02PM +0200

On 14/10/16 18:15, JiiPee wrote:
>> coords[ord(Direction::south)] = 3;
>> }
 
> yes i saw this on the internet. Is this a good idea?
 
I think you have to decide that for yourself. Collect together the
different approaches, and pick the one that works best for you.
 
There are other, more complex examples on the net for ways to make
type-safe enums that also support things like ++ and --, or even
printing out the enumeration element names.
JiiPee <no@notvalid.com>: Oct 14 06:25PM +0100

On 14/10/2016 18:02, David Brown wrote:
 
> There are other, more complex examples on the net for ways to make
> type-safe enums that also support things like ++ and --, or even
> printing out the enumeration element names.
 
yes that is the next best, simplest improvement.. better than putting
static cast everywhere.
 
But also checking the idea "wrap around the array with a class"...and
overload []
"Öö Tiib" <ootiib@hot.ee>: Oct 14 10:39AM -0700

On Friday, 14 October 2016 19:14:14 UTC+3, JiiPee wrote:
> > why you need array with 'North' elements.
 
> no sorry, i mean as an index:
 
> arr[North]
 
Arrays can not be indexed with directions but with integers. So some
conversion is happening there. If you want it implicit then use old
C enum. If you want safety but do not like static_cast then make
shorter converter for it like for example operator+:
 
enum class Direction { North, East, South, West, Count };

constexpr int operator +(Direction d) {return static_cast<int>(d);}

double arr[+Direction::Count];
 
Note how 'Direction::Count' makes sense as array dimension where 'North'
does not make sense as array dimension.
JiiPee <no@notvalid.com>: Oct 14 07:03PM +0100

On 14/10/2016 18:39, Öö Tiib wrote:
>> arr[North]
> Arrays can not be indexed with directions but with integers.
 
yes, i guess more logical way to code would be actually:
arr[index(North)]
where index function returns a corresponding index for North. But this
is slower... so its a performance issue why I always wanted to use only
plain enums.
 
Although I think its a bit more readable to have:
 
square[North] (the north side of the square)
 
> conversion is happening there. If you want it implicit then use old
> C enum. If you want safety but do not like static_cast then make
> shorter converter for it like for example operator+:
 
yes I like safety, and am just now testing the version where I wrap it
into class.. a bit like you show here.
I let the forum know my solution soon....It will be a mix of advices.
 
 
> enum class Direction { North, East, South, West, Count };
 
> constexpr int operator +(Direction d) {return static_cast<int>(d);}
 
> double arr[+Direction::Count];
 
this is interesting, i save this idea although not sure if can use it here.
I start liking the class-wrap idea... what I try now, becouse it can
check the enum values as well (that they have correct index values). I
ll show this solution soon.
 
 
> Note how 'Direction::Count' makes sense as array dimension where 'North'
> does not make sense as array dimension.
 
yes
Christian Gollwitzer <auriocus@gmx.de>: Oct 14 08:03PM +0200

Am 14.10.16 um 15:09 schrieb JiiPee:
>> prefer using "enum class" whenever possible.
 
> would you use enum class even if you use enum a lot as an array index?
> then you have to do static casts....
 
enum as an array index sounds like a misuse to me, why do you not use
struct members?
 
i.e. instead of int things[3]; cout<<thing[DIR::X];
 
struct point { int x; int y; int z };
point Thing; cout<<Thing.x;
 
Christian
JiiPee <no@notvalid.com>: Oct 14 07:06PM +0100

On 14/10/2016 19:03, Christian Gollwitzer wrote:
 
> struct point { int x; int y; int z };
> point Thing; cout<<Thing.x;
 
> Christian
 
 
I have to loop enum values/indexes: in a for loop from North to West.
Its actually a 2 dim vector, so I also loop anothen set of enums.
Jerry Stuckle <jstucklex@attglobal.net>: Oct 14 02:49PM -0400

On 10/14/2016 12:18 PM, JiiPee wrote:
> might be only used in vehicle currently, but later on some other class
> might use it as well. should we put it outside just in case others use
> it? Direction is quite general thing, isnt it?
 
Yes, but that's part of planning for reusable code. You have to think
ahead where something might be used in the future, and plan for it. You
won't always be right, but with practice and coding experience, you will
do better.
 
In a case like this, Direction is a pretty generic item I would consider
to be usable in other cases, also, so I would make it separate from the
class. After all, you might want to know which way the wind is blowing :)
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Jerry Stuckle <jstucklex@attglobal.net>: Oct 14 02:52PM -0400

On 10/14/2016 12:50 PM, Öö Tiib wrote:
> compatible with future is pointless. When future arrives then we can
> fix it. BTW, a direction containing of 4 discrete vales is not general
> thing.
 
Not at all. It's called reusable code, and it's quite possible to plan
for it - language libraries are an excellent example.
 
I've seen it being done for over 30 years. And the groups that do it
are much more efficient because they don't have to keep reinventing the
wheel.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid>: Oct 14 08:08PM +0100

On 14/10/2016 19:49, Jerry Stuckle wrote:
 
[...]
> Yes, but that's part of planning for reusable code.
 
It depends on how you decide to design your systems. Today's
methodologies are different from those used in the past. If you use
Agile methodologies, for example, you focus on the present and try to
stick to what you need at the moment. It's a successful way to work as
you avoid spending too long on unneeded functionality. Planning for
reusable code has a cost.
 
--
4ndre4
"Öö Tiib" <ootiib@hot.ee>: Oct 14 02:11PM -0700

On Friday, 14 October 2016 21:03:52 UTC+3, JiiPee wrote:
> where index function returns a corresponding index for North. But this
> is slower... so its a performance issue why I always wanted to use only
> plain enums.
 
Why it is slower? Unless you add some debug checks or the like the converter
function (like the one I posted) is typically optimized out by compiler.
 
> I start liking the class-wrap idea... what I try now, becouse it can
> check the enum values as well (that they have correct index values). I
> ll show this solution soon.
 
You can add debug checks to such function as well:
 
constexpr int operator +(Direction d)
{
if (d < Direction::North || d > Direction::Count)
throw std::logic_error("Down is not direction");
return static_cast<int>(d);
}
 
However such checks may make program to run slightly slower. You are
seemingly searching for silver bullet with what you get everything but
there are no such thing in our universe.
JiiPee <no@notvalid.com>: Oct 14 11:06PM +0100

On 14/10/2016 22:11, Öö Tiib wrote:
>> plain enums.
> Why it is slower? Unless you add some debug checks or the like the converter
> function (like the one I posted) is typically optimized out by compiler.
 
oh true, if its a constexp function then it would not take longer
 
 
> However such checks may make program to run slightly slower. You are
> seemingly searching for silver bullet with what you get everything but
> there are no such thing in our universe.
 
I want to eat the cake and keep the cake at the same time :)
 
JiiPee <no@notvalid.com>: Oct 14 11:09PM +0100

On 14/10/2016 19:49, Jerry Stuckle wrote:
> In a case like this, Direction is a pretty generic item I would consider
> to be usable in other cases, also, so I would make it separate from the
> class. After all, you might want to know which way the wind is blowing:)
 
 
yes you have a point. Although in this current program I do not see any
other use for that direction right now. So its unknown. So the question
is should I still make it separate. I quite strongly think that in this
project it will not be used in any other class. But cannot be 100% sure
though
Tim Rentsch <txr@alumni.caltech.edu>: Oct 14 07:04AM -0700


> As we have seen here earlier, MS points that out in the documentation
> for setlocale. You can only (legally) set locales where all characters
> fit in a 16-bit wchar_t. Everything else is, at best, an extension.
 
ISTM that you are either missing or ignoring a key point. The
standard stipulates only two locales (the "C" locale and the ""
locale) that must be supported. However, the required "" locale
is specified /as that of the 'native environment'/. Clearly the
native environment understands code points outside the set of
16-bit characters (eg, by means of surrogate pairs). Whatever
other statements might be made about "OS locales" or "character
code pages", that fact by itself implies that wchar_t cannot be
as narrow as 16 bits. Given that the term 'native environment'
is not defined in the standard, there is probably enough weasel
room to make an argument for technical conformance. Certainly
though it is outside the domain of what was clearly intended.
neborson@gmail.com: Oct 14 02:03PM -0700

On Wednesday, September 28, 2016 at 3:52:33 PM UTC-7, Alf P. Steinbach wrote:
 
> - Alf
 
> Links:
> ¹ <url: http://stackoverflow.com/a/39552788/464581>
 
Your interpretation makes sense to me, but Windows use of UTF-16 is the
only sensible choice given history. Unicode APIs in Windows date back to
Windows NT 3.1, which was released in 1993. At that time, Unicode was a
16-bit character set, full stop. Unicode 2.0 introduced surrogates later,
in 1996.
red floyd <no.spam@its.invalid>: Oct 14 10:22AM -0700

On 10/13/2016 11:33 PM, Gareth Owen wrote:
>> ::std::cout << d << '\n';
>> }
 
> Yes, but you can't dynamically resize it later.
 
That wasn't specified as a requirement.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 14 07:29PM +0100

On 14/10/2016 18:22, red floyd wrote:
>>> }
 
>> Yes, but you can't dynamically resize it later.
 
> That wasn't specified as a requirement.
 
It should be an obvious requirement for a small-vector optimized vector.
 
/Flibble
woodbrian77@gmail.com: Oct 14 11:06AM -0700

> C++ has some advantages over those languages, but
> their support for reflection has also given them an
> advantage over C++ in this area.
 
 
I've been keeping an eye on that search for the past
few months and it looks to me like C# and Java are
still the most popular. It also looks like Python
and PHP are used some.
 
> the ID in code generation requests, thereby giving
> tier-1 users an advantage over those who are slower
> to start using the CMW.
 
Over the years I've done my best to warn people about
Obama and Obamacare... Now I've come across this video
by Twila Brase and Ginni Thomas:
 
http://www.cchfreedom.org/about.php
 
 
Brian
Ebenezer Enterprises - Over the years I've tried to warn
people about Obama and Obamacare. This video by Twila Brase
and Ginni Thomas is 100x better at exposing the lies than
my efforts:
 
http://www.cchfreedom.org/about.php
bitrex <bitrex@de.lete.earthlink.net>: Oct 14 01:08PM -0400

I'm trying to write some code to manage large numbers of sprites on the
screen using Allegro 5 as the graphics engine.
 
As many of the sprites will be using the same underlying bitmap, I'd
like to use the boost::flyweight library to template the bitmap type, so
bitmaps which are associated with the same object will not be repeatedly
loaded into memory.
 
The underlying ALLEGRO_BITMAP straight-C type is wrapped up in a
structure allegro_bitmap_t with appropriate user-defined conversions so
it can be used directly as the underlying type when necessary. I'm
trying to set up the flyweight type so that it can be dereferenced from
the unique_ptr the same as the "regular" type without calling the "get"
method, but it's not working. Here's the code (the types are wrapped in
a namespace):
 
using allegro_bitmap_t = struct B
{
public:
B(int bitmap_w, int bitmap_h) : current_id(id())
{
_bitmap_ptr = al_create_bitmap(bitmap_w, bitmap_h);
if (_bitmap_ptr == nullptr) throw std::bad_alloc();
}
 
B(const char* filename) : current_id(id())
{
_bitmap_ptr = al_load_bitmap(filename);
if (_bitmap_ptr == nullptr) throw std::bad_alloc();
}
 
~B() = default;
 
operator ALLEGRO_BITMAP*() const
{
return _bitmap_ptr;
}
 
const ALLEGRO_BITMAP& operator* () const
{
return *_bitmap_ptr;
}
 
const int current_id;
 
private:
static int id()
{
static int _id = 0;
return _id++;
}
 
ALLEGRO_BITMAP* _bitmap_ptr;
};
 
using allegro_flyweight_bitmap_t = struct FB : public
boost::flyweights::flyweight<allegro_bitmap_t>
{
using super = boost::flyweights::flyweight<allegro_bitmap_t>;
using super::super;
using allegro_bitmap_t = super::value_type::allegro_bitmap_t;
 
const allegro_bitmap_t& operator*() const{return *(this->get());}
const allegro_bitmap_t* operator->()const{return &*(this->get());}
};
 
inline bool operator==(const B& l, const B& r)
{
return l.current_id == r.current_id;
}
 
inline std::size_t hash_value(B const& b)
{
boost::hash<int> hasher;
return hasher(b.current_id);
}
 
 
 
Compile errors i am getting:
 
||=== Build: Debug in GraphicsTest (compiler: GNU GCC Compiler) ===|
include/GraphicsTypes.h|73|error: 'allegro_bitmap_t' in
'boost::flyweights::flyweight<GraphicsTypes::B>::value_type {aka struct
GraphicsTypes::B}' does not name a type|
 
include/GraphicsTypes.h||In member function 'const allegro_bitmap_t&
GraphicsTypes::FB::operator*() const':|
 
include/GraphicsTypes.h|75|error: invalid initialization of reference of
type 'const allegro_bitmap_t& {aka const GraphicsTypes::B&}' from
expression of type 'const ALLEGRO_BITMAP'|
 
include/GraphicsTypes.h||In member function 'const allegro_bitmap_t*
GraphicsTypes::FB::operator->() const':|
 
include/GraphicsTypes.h|76|error: cannot convert 'const ALLEGRO_BITMAP*'
to 'const allegro_bitmap_t* {aka const GraphicsTypes::B*}' in return|
 
/usr/include/allegro5/bitmap.h|12|note: class type 'const
ALLEGRO_BITMAP' is incomplete|
bitrex <bitrex@de.lete.earthlink.net>: Oct 14 01:16PM -0400

On 10/14/2016 01:08 PM, bitrex wrote:
 
> bitmaps which are associated with the same object will not be repeatedly
> loaded into memory.
 
Same type of object I should say
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)