Sunday, November 15, 2015

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

Prroffessorr Fir Kenobi <profesor.fir@gmail.com>: Nov 15 03:18PM -0800

W dniu sobota, 7 listopada 2015 21:26:46 UTC+1 użytkownik Vlad from Moscow napisał:
 
> As I was already said several times at the same Stackoverflow the problem is that I am from Russia and this is clear from my nickname Vlad from Moscow.
 
> I asked a question at Meta that to discuss the situation but again I was ignored and my question was just removed.
 
> So I am again banned after my correct answer was deliberately down-voted and after I asked a question how to behave in such situations.:)
 
SO is heavy shit last years.. This is place full of lamas they are usually not able to understand the question and so on.. they find some kind of 'dorkism' as a norm there i noticed that like five times than gave up - let them die in peace
Vladislav Yaroslavlev <vladon@vladon.ru>: Nov 15 12:23PM -0800

On Wednesday, November 11, 2015 at 9:39:26 PM UTC+3, JiiPee wrote:
 
> ?
> is there some/any benefit for using define here? I thought that was
> C-programming...
 
If you can use C++11, then better use `constexpr`:
 
constexpr int ERROR_IN_INPUT = 1;
constexpr int TOO_LONG_INPUT = 2;
constexpr int PARAMETER_ERROR = 3;
Vladislav Yaroslavlev <vladon@vladon.ru>: Nov 15 12:29PM -0800

On Sunday, November 15, 2015 at 11:23:22 PM UTC+3, Vladislav Yaroslavlev wrote:
 
> constexpr int ERROR_IN_INPUT = 1;
> constexpr int TOO_LONG_INPUT = 2;
> constexpr int PARAMETER_ERROR = 3;
 
Or much better variant:
 
===
using input_error_t = int;
 
enum class input_error : input_error_t
{
error_in_input = 1,
too_long_input = 2,
parameter_error = 3
};
===
 
Then use it:
 
===
// ... code ...
 
if (error == input_error::too_long_input)
{
// ... code ...
}
 
// ... code ...
===
 
This is IMHO the best variant.
jacobnavia <jacob@jacob.remcomp.fr>: Nov 15 10:48PM +0100

Le 15/11/2015 21:29, Vladislav Yaroslavlev a écrit :
> too_long_input = 2,
> parameter_error = 3
> };
Mmmmmmmm
 
I fail to see why this is better than
 
enum error {input_error=1, too_long_input,parameter_error};
 
Can you maybe explain me that?
 
Thanks
Ian Collins <ian-news@hotmail.com>: Nov 16 10:55AM +1300

jacobnavia wrote:
 
> I fail to see why this is better than
 
> enum error {input_error=1, too_long_input,parameter_error};
 
> Can you maybe explain me that?
 
If we leave aside the poor naming, the answer would be scope. Consider
the case where you want to reuse enumeration names. Here's a contrived
example:
 
enum OutputError { ToBig, ToSmall };
enum InputError { ToBig, ToSmall };
 
Obviously this will fail to compile, bu if we use an enum class:
 
enum class OutputError { ToBig, ToSmall };
enum class InputError { ToBig, ToSmall };
 
All is well.
 
--
Ian Collins
Vladislav Yaroslavlev <vladon@vladon.ru>: Nov 15 02:10PM -0800

On Monday, November 16, 2015 at 12:49:06 AM UTC+3, jacobnavia wrote:
 
> enum error {input_error=1, too_long_input,parameter_error};
 
> Can you maybe explain me that?
 
> Thanks
 
First of all, it will not be implicitly converted to int. And it is great. Remember it's not C, it is C++.
 
And `enum class` is better than `enum` because you must specify enum class name before value, which is more readable.
 
See also here: Enums at C++ Core Guidelines: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#S-enum
jacobnavia <jacob@jacob.remcomp.fr>: Nov 15 11:14PM +0100

Le 15/11/2015 22:55, Ian Collins a écrit :
> If we leave aside the poor naming, the answer would be scope. Consider
> the case where you want to reuse enumeration names.
 
 
Is that a good idea?
 
 
Besides, very often I use enums as bitfields:
 
enum foo{ property1=1,property2=2,property3=4,property4=8,property5=16};
 
Then I can say
if (val & property5)
 
That can't be done with scoped enums since there is no automatic
conversion to an integer. You would have to plaster your code with
static_cast<int>
 
The crux of the matter is the urge to compleixfy everything and not use
constructs that are simple to understand. I think that attitude leads to
bugs that are completely unnecessary and easy to avoid.
 
KEEP IT SIMPLE IAN!
jacobnavia <jacob@jacob.remcomp.fr>: Nov 15 11:19PM +0100

Le 15/11/2015 23:10, Vladislav Yaroslavlev a écrit :
> First of all, it will not be implicitly converted to int. And it is great
 
Sure. But if you want to use the enums as a bitfield;
 
enum flags {
Archived=1,
Pending=2,
Received=4,
Sent=8,
Forwarded=16
};
 
I can now say
 
if (val &(Sent|Forwarded))
 
to test for some bit.
 
Using scoped enums I have to plaster all that with static_cast<int>
 
Remember, this is C++, not C. Everything must be a lot more complex than
it needs to!
 
:-)
Vladislav Yaroslavlev <vladon@vladon.ru>: Nov 15 02:23PM -0800

On Monday, November 16, 2015 at 1:14:33 AM UTC+3, jacobnavia wrote:
 
> enum foo{ property1=1,property2=2,property3=4,property4=8,property5=16};
 
> Then I can say
> if (val & property5)
 
Why you need to do so? Please give a more full example.
We talk about particular case: constants for errors. Your example is from another area. Nobody removes old `enum`s from the language.
 
> constructs that are simple to understand. I think that attitude leads to
> bugs that are completely unnecessary and easy to avoid.
 
> KEEP IT SIMPLE IAN!
 
You wrote in plain old C style, not C++.
jacobnavia <jacob@jacob.remcomp.fr>: Nov 15 11:27PM +0100

Le 15/11/2015 23:23, Vladislav Yaroslavlev a écrit :
> Why you need to do so? Please give a more full example.
 
enum flags {
Archived=1,
Pending=2,
Received=4,
Sent=8,
Forwarded=16
};
 
I can now say
 
if (val &(Sent|Forwarded))
 
to test for several conditions with one VERY CHEAP operation.
 
That is the nice things about bit fields: compact (you can fit up to 32
properties in a single int in most systems), fast testing (a single
machine instruction) and clear.
 
True you can't reuse property names but that is so easy to solve...
Paavo Helde <myfirstname@osa.pri.ee>: Nov 15 04:34PM -0600

jacobnavia <jacob@jacob.remcomp.fr> wrote in news:n2avva$rbm$1@dont-
email.me:
 
 
> That can't be done with scoped enums since there is no automatic
> conversion to an integer. You would have to plaster your code with
> static_cast<int>
 
No, you define the needed operators like & and | for those enums with a
couple of one-liners. Sure, these lines consist mostly of casts, but the
rest of the code would be clean.
 
Cheers
Paavo
Ian Collins <ian-news@hotmail.com>: Nov 16 11:37AM +1300

jacobnavia wrote:
 
> That can't be done with scoped enums since there is no automatic
> conversion to an integer. You would have to plaster your code with
> static_cast<int>
 
Or provide the appropriate operator. One of the reasons for adding enum
class was to prevent inadvertent conversion to int. Given bit fields
are unsigned types, enum class allows you to specify the underlying
type. So you could still write:
 
#include <stdint.h>
 
enum class Bit : uint8_t { Zero = 1, One = 2 };
 
bool operator | ( Bit b, uint8_t u )
{
return static_cast<uint8_t>(B) | u;
}
 
bool operator | ( uint8_t u, Bit b )
{
return u | static_cast<uint8_t>(b);
}
 
void f( uint8_t val )
{
Bit b;
 
if( val | Bit::Zero )
{
}
}
 
> The crux of the matter is the urge to compleixfy everything and not use
> constructs that are simple to understand. I think that attitude leads to
> bugs that are completely unnecessary and easy to avoid.
 
Inadvertent conversion to int can lead to unexpected bugs! The problem
is worse in C where assignment to an enum object from int is permitted.
Adding enum class just closes the gap the other way.
 
> KEEP IT SIMPLE IAN!
 
If you don't want to use an enum class, just carry on using an enum.
It's that simple!
 
--
Ian Collins
Vladislav Yaroslavlev <vladon@vladon.ru>: Nov 15 02:38PM -0800

On Monday, November 16, 2015 at 1:27:42 AM UTC+3, jacobnavia wrote:
> properties in a single int in most systems), fast testing (a single
> machine instruction) and clear.
 
> True you can't reuse property names but that is so easy to solve...
 
The truth is that `enum` here is not semantically correct. You DO NOT enumerate anything. It's the hack: use one language feature for the purpose of another meaning.
 
You may choose for your flags is `constexpr` within its namespace:
 
namespace flags
{
constexpr auto Archived = 1,
constexpr auto Pending = 1 << 1,
constexpr auto Received = 1 << 2,
constexpr auto Sent = 1 << 3,
constexpr auto Forwarded = 1 << 4
}
 
No need for enum here, it is misunderstanding of enum.
 
But the best option for you is `std::bitset`.
jacobnavia <jacob@jacob.remcomp.fr>: Nov 15 11:43PM +0100

Le 15/11/2015 23:38, Vladislav Yaroslavlev a écrit :
> The truth is that `enum` here is not semantically correct. You DO NOT enumerate anything
 
What?
 
I am enumerating the different states that a message can have: archived,
sent, whatever.
 
I do not see why you suppose that it is not an enumeration!
jacobnavia <jacob@jacob.remcomp.fr>: Nov 15 11:45PM +0100

Le 15/11/2015 23:34, Paavo Helde a écrit :
> No, you define the needed operators like & and | for those enums with a
> couple of one-liners.
 
GOSH!
 
You want me to add lines of code to be able to do what plain enums give
me without any effort?
 
And I have to do that for each of these enums in my program?
 
KEEP IT SIMPLE ...
 
PLeeeeeeze.
 
:-)
jacobnavia <jacob@jacob.remcomp.fr>: Nov 15 11:48PM +0100

Le 15/11/2015 23:37, Ian Collins a écrit :
> {
> }
> }
 
 
That's 13 lines of code to be done for each of those enums to do what
plain enum gives me for free.
 
Great Progress!
 
Look this is C++, I am no expert. I will just go on using enums...
Paavo Helde <myfirstname@osa.pri.ee>: Nov 15 05:13PM -0600

jacobnavia <jacob@jacob.remcomp.fr> wrote in news:n2b1q9$ul$2@dont-
email.me:
 
> Le 15/11/2015 23:34, Paavo Helde a écrit :
>> No, you define the needed operators like & and | for those enums with
a
 
> GOSH!
 
> You want me to add lines of code to be able to do what plain enums give
> me without any effort?
 
Already the plain enums need casting when constructed from integers (like
the result of &), so in my code I have those operators also for many
plain enums.
 
 
> And I have to do that for each of these enums in my program?
 
No, only for those which need bitwise operations...
 
 
> KEEP IT SIMPLE ...
 
One can argue that having the enum and int types strictly separated makes
things simpler. There is a reason why we have types in the language.
 
I agree adding bitwise operators to an enum could be made simpler, e.g
"enum bitwise class foo {...}". With the current C++, one can probably
use template CRTP trick to avoid defining the operators separately for
each enum (I am not sure though that this will win "simplicity" points).
 
Cheers
Paavo
Vladislav Yaroslavlev <vladon@vladon.ru>: Nov 15 02:12PM -0800

On Wednesday, September 23, 2015 at 2:09:14 PM UTC+3, Öö Tiib wrote:
 
> Those are "rule of five" (define all 5 or none) and "rule of zero" (prefer
> none) . Unfortunately the Microsoft's newest compiler does not
> support "rule of zero" since it can not make implicit move constructors.
 
It is fixed in VS 2013 Update 5 and in VS 2015.
Vladislav Yaroslavlev <vladon@vladon.ru>: Nov 15 01:11PM -0800

On Wednesday, November 11, 2015 at 9:28:22 PM UTC+3, Lynn McGuire wrote:
> Is there a way to return the name of the class that is being compiled?
 
> Thanks,
> Lynn
 
There is no standardised way. Depends on your compiler.
woodbrian77@gmail.com: Nov 15 09:26AM -0800

> And Java is listed before C++. Are others interested
> in seeing the languages listed in chronological order?
> There doesn't seem to be any order to the listing now.
 
Would others like to join me in making suggestions on how
to change that page? As Geoff mentioned, the order could
be alphabetical. That would be okay with me.

Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
"Öö Tiib" <ootiib@hot.ee>: Nov 15 11:35AM -0800


> Would others like to join me in making suggestions on how
> to change that page? As Geoff mentioned, the order could
> be alphabetical. That would be okay with me.
 
Suggestion is on top of page near the icon of broom:
"This article is written in the style of a debate rather
than an encyclopedic summary."
 
IOW it stinks. It mostly represents pride, greed, envy and
wrath of its writers after briefly mentioning what
"serialization" is.
Saliya Hamparawa <hamparawa@googlemail.com>: Nov 15 05:18AM -0800

Hi,
I have a custom allocator which supports only one element per allocation. I am trying to making the allocator complaint with the STL containers.
 
As per the standard, I need to provide allocator::max_size() function, which should Return the maximum theoretically possible value of n, for which the call allocate(n, 0) could succeed.
 
In my case it is 1, as I only support one object per allocation.
 
However, with that implementation, I'm finding it problematic to use the allocator with std::list.
 
std::list also provides a function std::list::max_size(), which should return the maximum number of elements the container is able to hold due to system or library implementation limitations. In theory, this should not be related with the number of elements the allocator can allocate per call, but GCC 4.82 has implemented it in this way.
 
/** Returns the size() of the largest possible %list. */
size_type
max_size() const _GLIBCXX_NOEXCEPT
{ return _M_get_Node_allocator().max_size(); }
 
And in MSVC12,
 
size_type max_size() const _NOEXCEPT
{ // return maximum possible length of sequence
return (this->_Getal().max_size());
}
 
In my case the std::list::max_size() function returns 1, which I believe is wrong. Is this a bug in the implementation, or am I missing something obvious?
 
Thanks,
Saliya.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 15 02:56PM +0100

On 11/15/2015 2:18 PM, Saliya Hamparawa wrote:
> }
 
> In my case the std::list::max_size() function returns 1, which I believe is wrong. Is
> this a bug in the implementation, or am I missing something obvious?
 
Sounds like a bug to me. The maximum array size the allocator can handle
has no relation to the maximum size of a linked list.
 
 
Cheers,
 
- Alf
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 15 06:32PM

On 15/11/2015 13:56, Alf P. Steinbach wrote:
>> this a bug in the implementation, or am I missing something obvious?
 
> Sounds like a bug to me. The maximum array size the allocator can handle
> has no relation to the maximum size of a linked list.
 
I had this issue several years ago and brought the problem up with
Microsoft and P. J. Plauger but didn't get anywhere.
 
/Flibble
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)