Best way to use enum with classes

[JiiPee]

This one I have been pondering that what is the best way. Say we have a
class and we use it like this:
################
class SpecialVehicle
{
public:
enum Direction { North, East, South, West };

void setDirection(Direction dir) { m_curDirection = dir; }
private:
Direction m_curDirection;
};

int main()
{
SpecialVehicle veh;
veh.setDirection(SpecialVehicle::East);
return 0;
}
###############
Now enum can be implemented in 3 different ways:
1) (above):
class SpecialVehicle
{
public:
enum Direction { North, East, South, West };
...
with a call:
veh.setDirection(SpecialVehicle::East);

2) (new enum)
class SpecialVehicle
{
public:
enum class Direction { North, East, South, West };
...
with a call:
veh.setDirection(SpecialVehicle::Direction::East);

3) (new enum outside the class)
enum class Direction { North, East, South, West };
class SpecialVehicle
{
public:
...
with a call:
veh.setDirection(Direction::East);

So which is the best practise?
They all have their advantages:
- 1) is bundled inside the class (+) , has short call (+) but is not so
safe (old enum) (-)
- 2) is bundled inside the class (+) , has long call (-) and is safe
(new enum) (+)
- 3) is not bundled inside the class (-) , has short call (+) and is
safe (new enum) (+)

[Jerry Stuckle]

What data members and methods would class Direction have? Do you have
another Direction class with something else (i.e. Northeast, Southeast,
etc.)? Is Direction used in any other class?

Take by itself there is no "best practice". It depends on the program
as a whole.

--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================

[JiiPee]

On 14/10/2016 02:08, Jerry Stuckle wrote:
> What data members and methods would class Direction have? Do you have
> another Direction class with something else (i.e. Northeast, Southeast,
> etc.)? Is Direction used in any other class?

Direction is not a class.. its an enum...

[Jerry Stuckle]

No, it's another option I supplied.

But you didn't answer my questions.

[JiiPee]

On 14/10/2016 02:49, Jerry Stuckle wrote:
> No, it's another option I supplied.

I still dont quite understand. I have a class:


class SpecialVehicle

which uses Direction enum.

Can you type an example what you mean?

[Jerry Stuckle]

You might have a class Direction which has appropriate members and use
that instead of your enum. There can be advantages to that, like being
able to increment the direction around the compass.

But forget the class and answer my other questions. You can't look at
something by itself; you have to know how it fits in with the rest of
the program.

[Paavo Helde]

4) Put the enum in a namespace outside of the class:

namespace SpecialVehicleConstants {

enum class Direction { North, East, South, West };
}

Then the code can choose if it wants to use longer or shorter names
(with 'using namespace' or namespace aliases).


Yes, new class-style enums are safer and should be usually preferred.
Apart of this technical detail, use the form which most clearly
expresses the intent. If it is really specific to the class, define it
in the class. If the enum also makes sense without the class, define it
outside. Especially, if the enum is used by other functions or classes
which do not otherwise require definition of class SpecialVehicle, then
define it outside of the class in a separate header which can be
included without including SpecialVehicle.h. This reduces dependencies
and increases modularity.

If the names are too long, just use shorter names:

SpecVehicle::Dir::East;

Too long names reduce readability (the same holds for too short names as
well, of course). The '::' separators make long names a bit easier to
read, but not infinitely.

hth
Paavo

[4ndre4]

On 14/10/2016 02:00, JiiPee wrote:

[...]

> public:
> enum Direction { North, East, South, West };

The concept of direction is a general and generic one, not
class-specific. It may be needed in other contexts as well. You should
define it outside the class.

--
4ndre4

[JiiPee]

On 14/10/2016 04:21, Jerry Stuckle wrote:
> You might have a class Direction which has appropriate members and use
> that instead of your enum. There can be advantages to that, like being
> able to increment the direction around the compass.

oh *instead* of using enum using class. But I was only thinking of using
enum this time...

For example: enum Month {Jan, Feb, March} ... then I dont think there is
any reason to use class there. So enum is many times best.

[JiiPee]

On 14/10/2016 02:08, Jerry Stuckle wrote:

> What data members and methods would class Direction have? Do you have
> another Direction class with something else (i.e. Northeast, Southeast,
> etc.)? Is Direction used in any other class?

No, lets say we dont have any other directions... it can only ever move
to 4 directions. Like moving in a grid.

Its possible another kind of Direction enum would be in another class in
the future, yes. That option must be left open.

[JiiPee]

On 14/10/2016 06:49, Paavo Helde wrote:
> 4) Put the enum in a namespace outside of the class:
>
> namespace SpecialVehicleConstants {
> enum class Direction { North, East, South, West };
> }
>
> Then the code can choose if it wants to use longer or shorter names
> (with 'using namespace' or namespace aliases).

sure

>
>
> Yes, new class-style enums are safer and should be usually preferred.

even if we need to then type longer names? like
SpecialVehicle::Dir::East ? So we should never think about the shortness
of names used in the code? Becouse thats why I used the old style this
time (so that I can only write SpecialVehicle::East ) ... as it was
inside the class and also used outside the class.

> Apart of this technical detail, use the form which most clearly
> expresses the intent. If it is really specific to the class, define it
> in the class. If the enum also makes sense without the class, define
> it outside.

ok, this makes sense. Although sometimes difficult to know if its only
specific for the class and not outside world.

> Especially, if the enum is used by other functions or classes which do
> not otherwise require definition of class SpecialVehicle, then define
> it outside of the class in a separate header which can be included
> without including SpecialVehicle.h. This reduces dependencies and
> increases modularity.

ok, this was a good point and good to know.

>
> If the names are too long, just use shorter names:
>
> SpecVehicle::Dir::East;

In this case I am just a bit scared somebody would confuse Dir with
"Directory" :)

[JiiPee]

Yes I think you right here. But what if it is specific to the class
only? Would you always use the latest class-type enum and would you put
it inside the class or outside?

[JiiPee]

if its a generic , like:

enum class Direction { North, East, South, West };

should this always (automatically) be put into some global space becouse
its not specific for any class? So Direction should never be put inside
a class, but rather in its own file? Thats what 4ndere4 said.

Should all generic type of enums be put to global space? Like: enum
Month {Jan, Feb...}? Is there a situation you would put Month inside a
class (in a case lets say Month is always fixed and has those 12 months
only)?

>

[Öö Tiib]

On Friday, 14 October 2016 04:00:57 UTC+3, JiiPee wrote:
> This one I have been pondering that what is the best way.

Usually, when they say that then they actually search what is
the universal, "silver bullet" way. It does not exist.

Seems that here are two questions mixed. One is about nested or not
nested types. I use nested type when it is specific to the nesting
class only. Otherwise I use external types. With 'using' or 'typedef'
I can bring alias of external type into scope of class.

Other question seems to be about if to use 'enum' or 'enum class'. That
is matter of taste. I prefer the 'enum class' unless I need to interface
with C. Also I do not define enum like you did. I define enum like that:

enum Direction
{
Direction_North,
Direction_East,
Direction_South,
Direction_West
};

I define enum class like that:

[JiiPee]

On 14/10/2016 12:12, Öö Tiib wrote:
> I use nested type when it is specific to the nesting
> class only.

so becouse Direction is not specific only for a class you would put it
outside the class?

[4ndre4]

On Friday, 14 October 2016 12:12:13 UTC+1, Öö Tiib wrote:

[...]

> enum Direction
> {
> Direction_North,
> Direction_East,
> Direction_South,
> Direction_West
> };

With all due respect, this is horrible :)

[Jerry Stuckle]

Yes, it can be best. But that depends on the needs of the rest of your
program, not just one small piece.

[Jerry Stuckle]

In that case you should have it as a global enum or possibly a class itself.

[4ndre4]

On Friday, 14 October 2016 11:21:02 UTC+1, JiiPee wrote:

[...]

> Yes I think you right here. But what if it is specific to the class
> only?

It's a matter of scope:

- does it need to be known outside the class? Yes -> outside. No -> inside.

[JiiPee]

On 14/10/2016 13:18, Jerry Stuckle wrote:
> On 10/14/2016 6:10 AM, JiiPee wrote:
>> On 14/10/2016 02:08, Jerry Stuckle wrote:
>>> What data members and methods would class Direction have? Do you have
>>> another Direction class with something else (i.e. Northeast, Southeast,
>>> etc.)? Is Direction used in any other class?
>>
>> No, lets say we dont have any other directions... it can only ever move
>> to 4 directions. Like moving in a grid.
>>
>> Its possible another kind of Direction enum would be in another class in
>> the future, yes. That option must be left open.
>>
> In that case you should have it as a global enum or possibly a class itself.
>

So your logic is here that is the class is the only one who use the enum
then put it inside the class.. otherwise outside the class (if somebody
outside the class needs to use it)?

[JiiPee]

class SpecialVehicle
{

public:
enum Direction { North, East, South, West };

########

Ok so if I have:

SpecialVehicle veh1;

and use it (outside the class SpecialVehicle , like in main()):

veh1.move(SpecialVehicle::North);


Then , becouse we call the enum from outside, this should better be:

veh1.move(Direction ::North);


and Direction is defined outside class SpecialVehicle.

?

[JiiPee]

I used to do similar thing (befofe class-enum), ... but I would do:

enum Direction
{
DIR_NORTH,
DIR_EAST
};

but I am not really doing that anymore :).

[JiiPee]

On 14/10/2016 02:00, JiiPee wrote:
>

> 3) (new enum outside the class)
> enum class Direction { North, East, South, West };
> class SpecialVehicle
> {
> public:
> ...

The problem I have with this approach (which people seem to suggest is
the best) is that if I use enum as an array index:

int arr[North];

with enum class this does not work but i have to do:

int arr[static_cast<int>(Direction::North)];

So I have to put that staticcast to everywhere where I use it as an
index. Dont you agree that this:
int arr[North];
is much more readable? So if I intend to use enum a lot as an index,
then is it better to just use the old enum?

[Hergen Lehmann]

Am 14.10.2016 um 14:26 schrieb JiiPee:

> Ok so if I have:
>
> SpecialVehicle veh1;
>
> and use it (outside the class SpecialVehicle , like in main()):
>
> veh1.move(SpecialVehicle::North);

I would consider this as "inside", because the enum is only used when
making calls to SpecialVehicle.

Hence
- enum only used in conjunction with a specific class
=> put it inside that class to illustrate its purpose.
- enum may be of use elsewhere
=> put it outside.

When the enum is outside of a class, you should always use "enum class"
to ensure type safety and avoid name collisions.

When the enum is inside a class, it's a matter of taste. Personally, i
prefer using "enum class" whenever possible. It provides better type
safety and allows the use of natural value names without having to fear
collisions. This becomes all the more important, if the enum has more
than just a few values.

Hergen

[JiiPee]

On 14/10/2016 13:51, Hergen Lehmann wrote:
> When the enum is inside a class, it's a matter of taste. Personally, i
> prefer using "enum class" whenever possible. It

In my case i use enum a lot as an index, so enum class would make it
more difficult to use it as an index

[Cholo Lennon]

On 10/14/2016 09:28 AM, JiiPee wrote:
> On 14/10/2016 13:15, 4ndre4 wrote:
>> On Friday, 14 October 2016 12:12:13 UTC+1, Öö Tiib wrote:
>>
>> [...]
>>> enum Direction
>>> {
>>> Direction_North,
>>> Direction_East,
>>> Direction_South,
>>> Direction_West
>>> };
>> With all due respect, this is horrible :)
>
>
> I used to do similar thing (befofe class-enum), ... but I would do:
>
> enum Direction
> {
> DIR_NORTH,
> DIR_EAST
> };
>

Well, it's a matter of taste and surely not all here are going to agree
with me, but names with all capital letters are generally recommended
for macros only. In my case I'd write dirNorth, dirEast, etc

> but I am not really doing that anymore :).
>

--
Cholo Lennon
Bs.As.
ARG

[JiiPee]

On 14/10/2016 13:51, Hergen Lehmann wrote:

> When the enum is inside a class, it's a matter of taste. Personally, i
> 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....

[JiiPee]

On 14/10/2016 14:08, Cholo Lennon 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

[Hergen Lehmann]

Am 14.10.2016 um 14:46 schrieb JiiPee:

> The problem I have with this approach (which people seem to suggest is
> the best) is that if I use enum as an array index:
>
> int arr[North];

Using an enum as an array index is very bad practice anyway, because
there is no guarantee, that the enum stays within the array limits.
Someone might add an additional value later, and everything goes into
pieces.
You should use at least std::vector, which provides bounds checking...

> with enum class this does not work but i have to do:
>
> int arr[static_cast<int>(Direction::North)];

... or probably even std::map, which also solves having to cast an "enum
class" index.

Hergen

[Paavo Helde]

No. Using static_cast reduces readability and can potentially also hide
bugs when code changes. So using it more often than needed is not good.

Alternatively, yoy could wrap the array in your own class and provide
operator[] taking your enum class, and do the static_cast once only in
the operator[]. This has the extra benefit that it forces the caller to
use enums uniformly.

Cheers
Paavo

[Alf P. Steinbach]

On 14.10.2016 03:00, JiiPee wrote:
> This one I have been pondering that what is the best way. Say we have a

> class and we use it like this:
> ################
> class SpecialVehicle
> {
> public:
> enum Direction { North, East, South, West };
>
> void setDirection(Direction dir) { m_curDirection = dir; }
> private:
> Direction m_curDirection;
> };
>

Well, I usually define an old-fashioned conversion-happy enum inside a
struct, like this:

struct Direction
{
enum Enum { north, east, south, west, _ };
static constexpr int n_values = _;
};

Then you can say things like

int blah[Direction::n_values] = {};

and

void foo( Direction::Enum const d )
{
if( d == Direction::south ) {}
}

and in Special_vehicle you can avoid having to qualify those values,

class Special_vehicle
: private ::Direction // enum values directly available
{
public:
};

The C++11 enum variants also provide the ability to qualify names of
values, which is necessary when two or more enums have the same value
names, but it comes at the cost of no implicit conversion to integer.

Your comments about “safety” seem to indicate that you don't want that
implicit conversion.

However, I find that things generally get impractical without it. ;-)


Cheers & hth.,

- Alf

[JiiPee]

On 14/10/2016 14:41, Paavo Helde wrote:
> On 14.10.2016 16:09, JiiPee wrote:
>> On 14/10/2016 13:51, Hergen Lehmann wrote:
>>> When the enum is inside a class, it's a matter of taste. Personally, i
>>> 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....
>
>
>
> No. Using static_cast reduces readability and can potentially also
> hide bugs when code changes. So using it more often than needed is not
> good.

yes, I agree.... its looks too ugly in too many places.

>
> Alternatively, yoy could wrap the array in your own class and provide
> operator[] taking your enum class, and do the static_cast once only in
> the operator[]. This has the extra benefit that it forces the caller
> to use enums uniformly.
>
>

hmmm, good suggestion... i ll check this

>
>
>

[JiiPee]

On 14/10/2016 14:10, Hergen Lehmann wrote:
>> int arr[static_cast<int>(Direction::North)];
>
> ... or probably even std::map, which also solves having to cast an
> "enum class" index.

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)?

[Öö Tiib]

Good. Then the 'Direction::North' achieved by enum class (that I prefer to
enum) is one character more gruesome. :D

[Öö Tiib]

On Friday, 14 October 2016 15:46:39 UTC+3, JiiPee wrote:
> On 14/10/2016 02:00, JiiPee wrote:
> >
> > 3) (new enum outside the class)
> > enum class Direction { North, East, South, West };
> > class SpecialVehicle
> > {
> > public:
> > ...
>
> The problem I have with this approach (which people seem to suggest is
> the best) is that if I use enum as an array index:
>
> int arr[North];

You use that 'North' as dimension of raw array? That is hard to understand
why you need array with 'North' elements.

>
> with enum class this does not work but i have to do:
>
> int arr[static_cast<int>(Direction::North)];

Yes, but may be you did not want to write it.

>
> So I have to put that staticcast to everywhere where I use it as an
> index. Dont you agree that this:
> int arr[North];
> is much more readable? So if I intend to use enum a lot as an index,
> then is it better to just use the old enum?

No. The 'int arr[North];' is short. However it is not readable. I still
don't understand why you needed to declare such array there. The term
"readable" means that I can quickly understand what it does; about
'int arr[North];' I have pondered now some time and am about 95%
certain that its author (you) made a programming defect because it does
not make sense.

[David Brown]

While you cannot put methods in an enum class, you can use it for
defining other functions, such as an "ord" function:

enum class Direction {
north, south, east, west
};
int ord(Direction d) {
return static_cast<int>(d);
}


You can also use it for variable templates (C++14):

template<typename T> constexpr const int enumSize;

template<> constexpr const int enumSize<Direction> = 4;


This lets you write code like this:

std::array<int, enumSize<Direction>> coords;

void t1(void) {
coords[ord(Direction::south)] = 3;
}

[Paavo Helde]

AFAIK this style is often used in C for emulating missing scope
(namespace/class/enum class) names.

[Jerry Stuckle]

Which is one reason you might want to consider a class surrounding the
enum. You can create methods (often inline) to handle integer values.

[Jerry Stuckle]

True. If it is specific to that one class, then put it inside the
class. However, if it is general to more than one class, then it should
be outside the class.

[JiiPee]

On 14/10/2016 15:31, Öö Tiib wrote:
> On Friday, 14 October 2016 15:46:39 UTC+3, JiiPee wrote:
>> On 14/10/2016 02:00, JiiPee wrote:
>>> 3) (new enum outside the class)
>>> enum class Direction { North, East, South, West };
>>> class SpecialVehicle
>>> {
>>> public:
>>> ...
>> The problem I have with this approach (which people seem to suggest is
>> the best) is that if I use enum as an array index:
>>
>> int arr[North];
> You use that 'North' as dimension of raw array? That is hard to understand
> why you need array with 'North' elements.

no sorry, i mean as an index:

arr[North]

[JiiPee]

On 14/10/2016 15:33, David Brown wrote:
> void t1(void) {
> coords[ord(Direction::south)] = 3;
> }

yes i saw this on the internet. Is this a good idea?

[JiiPee]

On 14/10/2016 16:59, Jerry Stuckle wrote:
> On 10/14/2016 8:46 AM, JiiPee wrote:
>> On 14/10/2016 02:00, JiiPee wrote:
>>> 3) (new enum outside the class)
>>> enum class Direction { North, East, South, West };
>>> class SpecialVehicle
>>> {
>>> public:
>>> ...
>> The problem I have with this approach (which people seem to suggest is
>> the best) is that if I use enum as an array index:
>>
>> int arr[North];
>>
>> with enum class this does not work but i have to do:
>>
>> int arr[static_cast<int>(Direction::North)];
>>
>> So I have to put that staticcast to everywhere where I use it as an
>> index. Dont you agree that this:
>> int arr[North];
>> is much more readable? So if I intend to use enum a lot as an index,
>> then is it better to just use the old enum?
>>
>>
>>
> Which is one reason you might want to consider a class surrounding the
> enum. You can create methods (often inline) to handle integer values.
>

yes, am looking into this

[JiiPee]

But sometimes we dont know about the future. Like for example Direction
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?

[Hergen Lehmann]

Am 14.10.2016 um 15:55 schrieb JiiPee:

>> ... or probably even std::map, which also solves having to cast an
>> "enum class" index.
>
> 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]

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

[Öö Tiib]

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]

On 14.10.2016 19:18, JiiPee wrote:
>
> But sometimes we dont know about the future. Like for example Direction
> 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]

On 14/10/2016 17:50, Öö Tiib wrote:
> I thought we*never* know about future.

hehe

Well, God knows....

[David Brown]

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]

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]

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]

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)

> 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+:

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]

Am 14.10.16 um 15:09 schrieb JiiPee:

> On 14/10/2016 13:51, Hergen Lehmann wrote:
>> When the enum is inside a class, it's a matter of taste. Personally, i
>> 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]

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]

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 :)

[Jerry Stuckle]

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.

[4ndre4]

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]

On Friday, 14 October 2016 21:03:52 UTC+3, JiiPee wrote:
> 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.

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.

>
> Although I think its a bit more readable to have:
>
> square[North] (the north side of the square)
>
> > 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+:
>
> 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.

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]

On 14/10/2016 22:11, Öö Tiib wrote:
> On Friday, 14 October 2016 21:03:52 UTC+3, JiiPee wrote:
>> 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.
> 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

>
>> Although I think its a bit more readable to have:
>>
>> square[North] (the north side of the square)
>>
>>> 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+:
>> 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.
> 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.

I want to eat the cake and keep the cake at the same time :)

>
>

[JiiPee]

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

[Jerry Stuckle]

Agile methodologies are good for small programs, but they don't work
when you have 50 or more programmers working on a project for a year or
two. Even projects with 3 or 4 programmers going on for a couple of
months suffer without a decent design up front.

[Jerry Stuckle]

On 10/14/2016 3:08 PM, 4ndre4 wrote:

Agile methodologies work for small projects, but don't do at all well
when you have fifty or more programmers working a year or longer on a
project. Even 3 or 4 programmers working for a couple of months don't
do well without an initial design.

And agile methodologies are not conducive to code reuse.

Agile has its place. But it is overused, IMHO. This leads to lots of
code rewriting, poor test methodologies, and overall, more bugs.

[Jerry Stuckle]

Not only in this project - but code reuse is most profitable when you
can reuse the same code in other projects.

[4ndre4]

On Saturday, 15 October 2016 00:29:39 UTC+1, Jerry Stuckle wrote:

[...]

> Agile methodologies are good for small programs, but they don't work
> when you have 50 or more programmers working on a project for a year or
> two. Even projects with 3 or 4 programmers going on for a couple of
> months suffer without a decent design up front.

You couldn't be more wrong. Either you don't know how Agile is implemented, or you don't know companies that use it. Agile methodologies have by now proven to be effective in large organisations and for large projects. I work in a multinational company with dozens of Scrum teams who've been working on very large projects for many years now. We have just estimated 2 years of work on a new project. Poor test methodologies? More bugs? Seriously, you couldn't be more wrong.

[4ndre4]

On Friday, 14 October 2016 23:09:29 UTC+1, JiiPee wrote:

[...]

> yes you have a point. Although in this current program I do not see any
> other use for that direction right now.

Do not follow his suggestion. Focus on what you need in the immediate.

[JiiPee]

I guess in these advises many times people are partly correct :). So in
some situations what they say is valid... so maybe its good to know
everybodys views. Yes might be this advice does not suit to this
project, but maybe in other projects?

[Jerry Stuckle]

Oh, I DO know how Agile is implemented, and I've seen it used in several
projects - both to success and failure. And even IBM (whom I used to
work for and has been one of my clients) has used Agile. But they have
found it does not work well on large projects. The same with many of my
clients - most of which are on the Fortune 500 list.

It has its place. But the mistake is in thinking it is the best way for
every project. That is the thinking of someone who has never worked
with a proper design and project management.

[Jerry Stuckle]

Says someone who has never reused code before. You'd better go back to
school. You know little about multiple projects - except how to design
on the fly.

[Jerry Stuckle]

Very possibly in other projects. Anytime I create code - be it in C,
C++, Java or other languages, I consider is this code potentially
reusable, and if so, how.

A lot of the time I find it's too specialized and is not. Other times,
I can reuse a lot of code. I've had projects with well over 50% code
reuse from other projects. It has saved a huge amount of time coding,
and since the code is already debugged, the result is less test time and
fewer bugs. Overall, a huge cost savings.

[Öö Tiib]

What "not at all"? What is called "reusable code"? Does it predict future?
When someone writes something that he does not see as being needed right
now but thinks "may be it is needed in future" then he is usually wrong.

>
> 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.

I do not see where I suggested to reinvent wheels.

[Jerry Stuckle]

It's not at all pointless to make something compatible in the future.
I've been doing it for over 30 years. So have a lot of great
programmers I know - in fact, all of the best programmers I know do it.

It comes with experience and planning. No, I'm not always right.
Sometimes I think something is reusable in the future but never use it.
Other times I don't plan for reuse, but find later I can reuse something.

I've built a huge library of code over the years. And most of it is
reusable.

But then do you reinvent the C++ libraries with every program? Those
were planned with reuse in mind and millions of programmers reuse them
every day.

But according to you, they need to write all of the library code from
the scratch, with every program.

>>
>> 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.
>
> I do not see where I suggested to reinvent wheels.
>

That's exactly what you're doing when you have to write code from
scratch with every project.

[4ndre4]

On Saturday, 15 October 2016 01:46:11 UTC+1, Jerry Stuckle wrote:

[...]

> Oh, I DO know how Agile is implemented,

You clearly don't. If you say that Agile cannot be used on large projects, you don't know what you're talking about. As said, there's plenty of companies (mine included) out there using Agile on many large projects (see Microsoft Team Foundations Group with 3000 people). And you might want to look at these:

http://www.slideshare.net/alankan1/how-does-ibm-do-agile
http://agilescout.com/video-agile-scrum-at-facebook/

All big names out there use Agile.

As usual, you end up belittling others' experience in designing and developing software systems just because you have no real arguments. The problem is that many company DON'T know how to implement Agile. That's another problem.

[4ndre4]

On Saturday, 15 October 2016 01:47:19 UTC+1, Jerry Stuckle wrote:

[...]

LOL :) Stuckle, your aggressive reactions are a clear sign of your lack of confidence and real arguments. Keep your opinions. I am not trying to persuade thick numskulls like you. I have worked on a good number of very large projects in my life, for very large companies, and I am working on a new large project right now. You don't know what I know so you'd better shut up ;)

[4ndre4]

On Saturday, 15 October 2016 01:30:04 UTC+1, JiiPee wrote:

[...]

> I guess in these advises many times people are partly correct :)

Planning for code reuse is VERY expensive. In the must-read book Mythical Man Month, Fred Brooks explains that reusable code costs three times as much to develop as single use code. There is a lot of fuss around reusable code, especially from old-school people (like Stuckle), but that's actually a myth. The way software is developed today has greatly changed. There's plenty of information around about this. I am not saying that writing parts of your code so they can be reused is bad; *planning* for code reuse has proven to be a bad idea.

[4ndre4]

On Saturday, 15 October 2016 01:51:09 UTC+1, Jerry Stuckle wrote:

[...]

> Very possibly in other projects.

You do not justify the code of code development by saying "I might reuse it in other projects".

[4ndre4]

On Saturday, 15 October 2016 00:32:46 UTC+1, Jerry Stuckle wrote:

[...]

By the way, look at this, Stuckle:

https://www.linkedin.com/jobs/view/196601961?refId=abd4186e-7e31-4c74-8910-555e9a4ef7ea&recommendedFlavor=SCHOOL_RECRUIT&trk=jobshomev2_jymbii

You'll like it.

[Jerry Stuckle]

On 10/15/2016 2:52 AM, 4ndre4 wrote:
> On Saturday, 15 October 2016 01:46:11 UTC+1, Jerry Stuckle wrote:
>
> [...]
>> Oh, I DO know how Agile is implemented,
>
> You clearly don't. If you say that Agile cannot be used on large projects, you don't know what you're talking about. As said, there's plenty of companies (mine included) out there using Agile on many large projects (see Microsoft Team Foundations Group with 3000 people). And you might want to look at these:
>

Using Agile is quite similar to building without a blueprint. You can
do it with a dog house or a chicken coop - but it doesn't work well for
a ten story combination commercial/residential building.

> http://www.slideshare.net/alankan1/how-does-ibm-do-agile
> http://agilescout.com/video-agile-scrum-at-facebook/
>
> All big names out there use Agile.
>

Oh, so you know every big name out there, and know they use Agile?

> As usual, you end up belittling others' experience in designing and developing software systems just because you have no real arguments. The problem is that many company DON'T know how to implement Agile. That's another problem.
>

No, you're the one who started with "You don't know what you're talking
about". But like all idiots and trolls, you try to shift the blame.

People who claim Agile is good for every project have never been on a
project with a proper design and test environment.

[Jerry Stuckle]

So? What do I care what a stoopid troll posts? And that's exactly what
you've shown yourself to be.

But than that's exactly what I expect from someone who posts with a fake
name from a gmail account. You have zero credibility. I suspect you're
still in your 20's and only been programming professionally for 4-5
years max. Probably not even that long.

And it is MR. Stuckle to you, troll.

[Jerry Stuckle]

Once again you show you don't know how to build reliable, reusable code.
But then that's not something Agile developers do. They reinvent the
wheel with every project.

I have a library hundreds of megabytes of code I've developed over the
last 30 years. No, I haven't reused all of it. But if I hadn't planned
on reuse, I couldn't have reused ANY of it.

For instance, I had linked lists, dynamic arrays, strings and other
class libraries long before STL came along. And I used them in a lot of
projects (especially strings).

But then I guess you don't use the C++ libraries or templates, either.

[Jerry Stuckle]

In the short run, it is a BIT more expensive - but not three times.
Maybe 25% more. However, the first time you reuse the code, you have
saved 100% of the cost.

And yes, I claim this from around 50 years of programming experience,
including almost 30 in C++ and 26 years as a consultant, mostly to
Fortune 500 companies.

It's all in the planning. Good design and it's cheap to do it. But
with Agile development it very well could be three times the cost.

Code reuse is called a myth by those who can't do it. It is a very
useful and cost savings measure when implemented by competent programmers.

You could learn something from us "old timers" if you opened your mind.
But then I don't expect much from a troll who uses a pseudonym from a
gmail account.

[Jerry Stuckle]

Not at all aggressive. Just calling a stoopid troll exactly what you
are.

I guess you never use any of the C++ libraries, do you? You create
everything from scratch with every project.

Or maybe you are just unwilling to admit you are competent enough to
design reusable code. So you try to tell someone with much more
experience that he doesn't know what he's talking about

But that's what I expect from someone using a pseudonym from a gmail
account - not even brave enough to use your real name or a real account.

And it's MR. Stuckle to you, troll.

[Öö Tiib]

How do you know what *is* in future? You seemingly conflate writing
reusable code with predicting future! No one can predict future.

Code can be reused in several places regardless if it was predicted to.
Only thing needed is that it is useful in those several places. If we
don't have such places then we have code that is useful in one place.
So we can indeed waste lot of time to make it "reusable" there and build
a whole "framework" of single application. What is the point? Nothing
else to do?

> I've been doing it for over 30 years. So have a lot of great
> programmers I know - in fact, all of the best programmers I know do it.

What widely reused thing you made during those 30 years? Nothing.

>
> It comes with experience and planning. No, I'm not always right.
> Sometimes I think something is reusable in the future but never use it.
> Other times I don't plan for reuse, but find later I can reuse something.
>
> I've built a huge library of code over the years. And most of it is
> reusable.

What I dislike is that you make it sound like I was arguing that code can
not be reused. I nowhere wrote such thing. I wrote that future can't be
known. Also if something is not needed right now then YAGNI, most often
*you* *aren't* *gonna* *need* *it* ever.

>
> But then do you reinvent the C++ libraries with every program? Those
> were planned with reuse in mind and millions of programmers reuse them
> every day.
>
> But according to you, they need to write all of the library code from
> the scratch, with every program.

Where did I claim that? What in C++ libraries contradicts with what
I actually wrote? Or are you now claiming that something of C++ standard
library is your invention? What it is? What has ever predicted future in
standard library? Most futuristic thing in C++ library was 'std::auto_ptr'
and now it is gone, deprecated.

>
> >>
> >> 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.
> >
> > I do not see where I suggested to reinvent wheels.
> >
>
> That's exactly what you're doing when you have to write code from
> scratch with every project.

Yes and I do not see where I suggested that.

[Öö Tiib]

On Saturday, 15 October 2016 17:01:41 UTC+3, Jerry Stuckle wrote:
>
> I have a library hundreds of megabytes of code I've developed over the
> last 30 years.

That was pathetic. Writing 200 megabytes of source code with 30 man
years means about 30 000 bytes of source code per day. :D
You can go tell such fairy tales to ignorant people.

[Jerry Stuckle]

Its called experience. After enough years of programming, a good
programmer can make intelligent decisions on what might be reusable and
what might. You don't need to know the future; you only need to learn
from the past.

> Code can be reused in several places regardless if it was predicted to.
> Only thing needed is that it is useful in those several places. If we
> don't have such places then we have code that is useful in one place.
> So we can indeed waste lot of time to make it "reusable" there and build
> a whole "framework" of single application. What is the point? Nothing
> else to do?
>

Sure, it can be reused in a lot of places. But your fallacy is that it
'wastes a lot of time" to make it reusable. Properly designed, it takes
very little time.

And nothing said it had to be an entire framework of a single
application. It can be as little as one class.

>> I've been doing it for over 30 years. So have a lot of great
>> programmers I know - in fact, all of the best programmers I know do it.
>
> What widely reused thing you made during those 30 years? Nothing.
>

Well, I had string, linked list, resizable arrays and associative arrays
long before STL came out. And used them in a lot of cases. I have
database classes which are independent of the underlying database. I
have other classes like person, employee and customer. And all kinds of
support classes. The list is way too long to discuss - it probably
totals over 100MB of source code by now.

>>
>> It comes with experience and planning. No, I'm not always right.
>> Sometimes I think something is reusable in the future but never use it.
>> Other times I don't plan for reuse, but find later I can reuse something.
>>
>> I've built a huge library of code over the years. And most of it is
>> reusable.
>
> What I dislike is that you make it sound like I was arguing that code can
> not be reused. I nowhere wrote such thing. I wrote that future can't be
> known. Also if something is not needed right now then YAGNI, most often
> *you* *aren't* *gonna* *need* *it* ever.
>

You're the one who have argued that it's not worth designing code for
reuse - as you did once again here. I'm just disputing that.

>>
>> But then do you reinvent the C++ libraries with every program? Those
>> were planned with reuse in mind and millions of programmers reuse them
>> every day.
>>
>> But according to you, they need to write all of the library code from
>> the scratch, with every program.
>
> Where did I claim that? What in C++ libraries contradicts with what
> I actually wrote? Or are you now claiming that something of C++ standard
> library is your invention? What it is? What has ever predicted future in
> standard library? Most futuristic thing in C++ library was 'std::auto_ptr'
> and now it is gone, deprecated.
>

You're the one who claimed it's not worth designing code for reuse.
Just like you did again here.

>>
>>>>
>>>> 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.
>>>
>>> I do not see where I suggested to reinvent wheels.
>>>
>>
>> That's exactly what you're doing when you have to write code from
>> scratch with every project.
>
> Yes and I do not see where I suggested that.
>

You're the one who claimed it's not worth designing code for reuse.
Just like you did again here.

[Jerry Stuckle]

First of all, I never said I was the only one who wrote the code. I've
led many multiple-programmer projects, and kept rights to use the code I
designed over that time. Second of all, even your math is off. It's
nowhere near 30KB per day.

And BTW - all of that code is heavily commented. I didn't say it was
all code; there are comments in the code, also.

Sorry, your show your ignorance.

[Öö Tiib]

On Saturday, 15 October 2016 23:59:24 UTC+3, Jerry Stuckle wrote:
> On 10/15/2016 11:12 AM, Öö Tiib wrote:
> > On Saturday, 15 October 2016 17:01:41 UTC+3, Jerry Stuckle wrote:
> >>
> >> I have a library hundreds of megabytes of code I've developed over the
> >> last 30 years.
> >
> > That was pathetic. Writing 200 megabytes of source code with 30 man
> > years means about 30 000 bytes of source code per day. :D
> > You can go tell such fairy tales to ignorant people.
> >
>
> First of all, I never said I was the only one who wrote the code. I've
> led many multiple-programmer projects, and kept rights to use the code I
> designed over that time.

In United States of America? Other programmers wrote it, company got
the executable but source code became yours. :D I knew its worth to
talk with you for more jokes.

> Second of all, even your math is off. It's
> nowhere near 30KB per day.

My math seems Ok. Right here was a good place of you to show "correct
math". What is the correct number "nowhere near 30000"?

>
> And BTW - all of that code is heavily commented. I didn't say it was
> all code; there are comments in the code, also.
>
> Sorry, your show your ignorance.

What percentage was comments? :D When you are in such a sad hole then
stop digging.

[Ian Collins]

The joke of it is the arse doesn't realise agile development practices
(especially XP) naturally produce reusable code. You do have to
remember that jerryworld is stuck somewhere in the 90s.

--
Ian

[Jerry Stuckle]

Wrong again, Ian. Even the other trolls here claim that Agile
development doesn't allow for reusable code.

But then you're is exactly the type of comment I would expect from
someone who claims to have 10GB in their office - with 100GB coming.

You are even more clueless than the typical troll.

[Jerry Stuckle]

On 10/15/2016 7:22 PM, Öö Tiib wrote:
> On Saturday, 15 October 2016 23:59:24 UTC+3, Jerry Stuckle wrote:
>> On 10/15/2016 11:12 AM, Öö Tiib wrote:
>>> On Saturday, 15 October 2016 17:01:41 UTC+3, Jerry Stuckle wrote:
>>>>
>>>> I have a library hundreds of megabytes of code I've developed over the
>>>> last 30 years.
>>>
>>> That was pathetic. Writing 200 megabytes of source code with 30 man
>>> years means about 30 000 bytes of source code per day. :D
>>> You can go tell such fairy tales to ignorant people.
>>>
>>
>> First of all, I never said I was the only one who wrote the code. I've
>> led many multiple-programmer projects, and kept rights to use the code I
>> designed over that time.
>
> In United States of America? Other programmers wrote it, company got
> the executable but source code became yours. :D I knew its worth to
> talk with you for more jokes.
>

Once again you show you have no idea what copyright law is - in the
United States or otherwise. Fortunately, i do.

>> Second of all, even your math is off. It's
>> nowhere near 30KB per day.
>
> My math seems Ok. Right here was a good place of you to show "correct
> math". What is the correct number "nowhere near 30000"?
>

Much less than 1/2 of that. And that is bytes, not LOC. But once again
you don't seem to know the difference.

>>
>> And BTW - all of that code is heavily commented. I didn't say it was
>> all code; there are comments in the code, also.
>>
>> Sorry, your show your ignorance.
>
> What percentage was comments? :D When you are in such a sad hole then
> stop digging.
>

Enough to make the code clear.

You're right. You've gone past the bottom. You should have stopped
digging long ago.

[Ian Collins]

On 10/16/16 03:52 PM, Jerry Stuckle wrote:
> On 10/15/2016 9:12 PM, Ian Collins wrote:
>> On 10/16/16 03:38 AM, Öö Tiib wrote:
>>> On Saturday, 15 October 2016 06:03:06 UTC+3, Jerry Stuckle wrote:
>>>> On 10/14/2016 9:06 PM, Öö Tiib wrote:
>>>>>
>>>>> I do not see where I suggested to reinvent wheels.
>>>>>
>>>>
>>>> That's exactly what you're doing when you have to write code from
>>>> scratch with every project.
>>>
>>> Yes and I do not see where I suggested that.
>>
>> The joke of it is the arse doesn't realise agile development practices
>> (especially XP) naturally produce reusable code. You do have to
>> remember that jerryworld is stuck somewhere in the 90s.
>>
>
> Wrong again, Ian. Even the other trolls here claim that Agile
> development doesn't allow for reusable code.

Citation please, no one using an agile methodology would make such a claim.

> But then you're is exactly the type of comment I would expect from
> someone who claims to have 10GB in their office - with 100GB coming.

Why do you find that such a hard concept to grasp?

[root@kvmhost (Home) /]# dladm show-phys
LINK MEDIA STATE SPEED DUPLEX DEVICE
rge0 Ethernet up 1000 full rge0
e1000g0 Ethernet up 1000 full e1000g0
ixgbe0 Ethernet up 10000 full ixgbe0
ixgbe1 Ethernet up 10000 full ixgbe1

--
Ian

[Jerry Stuckle]

On 10/16/2016 12:05 AM, Ian Collins wrote:
> On 10/16/16 03:52 PM, Jerry Stuckle wrote:
>> On 10/15/2016 9:12 PM, Ian Collins wrote:
>>> On 10/16/16 03:38 AM, Öö Tiib wrote:
>>>> On Saturday, 15 October 2016 06:03:06 UTC+3, Jerry Stuckle wrote:
>>>>> On 10/14/2016 9:06 PM, Öö Tiib wrote:
>>>>>>
>>>>>> I do not see where I suggested to reinvent wheels.
>>>>>>
>>>>>
>>>>> That's exactly what you're doing when you have to write code from
>>>>> scratch with every project.
>>>>
>>>> Yes and I do not see where I suggested that.
>>>
>>> The joke of it is the arse doesn't realise agile development practices
>>> (especially XP) naturally produce reusable code. You do have to
>>> remember that jerryworld is stuck somewhere in the 90s.
>>>
>>
>> Wrong again, Ian. Even the other trolls here claim that Agile
>> development doesn't allow for reusable code.
>
> Citation please, no one using an agile methodology would make such a claim.
>

Read the messages in this thread.

>> But then you're is exactly the type of comment I would expect from
>> someone who claims to have 10GB in their office - with 100GB coming.
>
> Why do you find that such a hard concept to grasp?
>
> [root@kvmhost (Home) /]# dladm show-phys
> LINK MEDIA STATE SPEED DUPLEX DEVICE
> rge0 Ethernet up 1000 full rge0
> e1000g0 Ethernet up 1000 full e1000g0
> ixgbe0 Ethernet up 10000 full ixgbe0
> ixgbe1 Ethernet up 10000 full ixgbe1
>

ROFLMAO! Stoopid is as stoopid does! That is NOT 10G ethernet - much
less 100G! You wouldn't know the difference between that and a 1200
baud modem.

[Öö Tiib]

On Sunday, 16 October 2016 05:54:40 UTC+3, Jerry Stuckle wrote:
> On 10/15/2016 7:22 PM, Öö Tiib wrote:
> > On Saturday, 15 October 2016 23:59:24 UTC+3, Jerry Stuckle wrote:
> >> On 10/15/2016 11:12 AM, Öö Tiib wrote:
> >>> On Saturday, 15 October 2016 17:01:41 UTC+3, Jerry Stuckle wrote:
> >>>>
> >>>> I have a library hundreds of megabytes of code I've developed over the
> >>>> last 30 years.
> >>>
> >>> That was pathetic. Writing 200 megabytes of source code with 30 man
> >>> years means about 30 000 bytes of source code per day. :D
> >>> You can go tell such fairy tales to ignorant people.
> >>>
> >>
> >> First of all, I never said I was the only one who wrote the code. I've
> >> led many multiple-programmer projects, and kept rights to use the code I
> >> designed over that time.
> >
> > In United States of America? Other programmers wrote it, company got
> > the executable but source code became yours. :D I knew its worth to
> > talk with you for more jokes.
> >
>
> Once again you show you have no idea what copyright law is - in the
> United States or otherwise. Fortunately, i do.

Me? I did never contract you. :D My company is small, nowhere fortune
500. These were "fortune 500" companies that contracted you but did
not know laws. Each have huge legal department but still agreed with
contract where all source code, even that other people wrote for them
is yours to reuse forever anywhere. It was because your brillant
knowledge of copyright laws trumped them. :D

>
> >> Second of all, even your math is off. It's
> >> nowhere near 30KB per day.
> >
> > My math seems Ok. Right here was a good place of you to show "correct
> > math". What is the correct number "nowhere near 30000"?
> >
>
> Much less than 1/2 of that. And that is bytes, not LOC. But once again
> you don't seem to know the difference.

Ok, lets try with that. Since you give no numbers I have to calculate with
most favorable to you extremes. So ... "1/2" of 30 000 that I claimed
is 15 000 bytes per day. "Much less" is lets say as extreme 5 less
so 15 000 - 5 is 14 995 bytes per day.

You as extreme do not have weekends, vacations, sick leaves nor national
holidays so as 365 days per year you write 14 995 * 365 is 5 473 175 bytes
per year.

"30 years" you claimed makes 30 * 5 473 175 what is 164 195 250 bytes per
30 years.

Smallest from the "hundreds of megabytes" you claimed is as extreme 2 hundreds
megabytes that is 209 715 200 bytes. So however favorably I try to calculate
there are 45 519 950 bytes missing. That is more than 43 megabytes missing.

You can't calculate, mate, sorry. I don't know what "software designer" you
are, but sounds funny. :D

>
> >>
> >> And BTW - all of that code is heavily commented. I didn't say it was
> >> all code; there are comments in the code, also.
> >>
> >> Sorry, your show your ignorance.
> >
> > What percentage was comments? :D When you are in such a sad hole then
> > stop digging.
> >
>
> Enough to make the code clear.
>
> You're right. You've gone past the bottom. You should have stopped
> digging long ago.

Oh you can't tell any numbers. That indicates that the weird code-base
resides within your fantasies.

[Jerry Stuckle]

You're the one who claims to know everything about United States
copyright law. That's the law that rules here. And you know even less
about United States contract law. But you claim it is a joke. The only
joke here is you.

>>
>>>> Second of all, even your math is off. It's
>>>> nowhere near 30KB per day.
>>>
>>> My math seems Ok. Right here was a good place of you to show "correct
>>> math". What is the correct number "nowhere near 30000"?
>>>
>>
>> Much less than 1/2 of that. And that is bytes, not LOC. But once again
>> you don't seem to know the difference.
>
> Ok, lets try with that. Since you give no numbers I have to calculate with
> most favorable to you extremes. So ... "1/2" of 30 000 that I claimed
> is 15 000 bytes per day. "Much less" is lets say as extreme 5 less
> so 15 000 - 5 is 14 995 bytes per day.
>

And now you've just proven you can't even do simple arithmetic. What do
they teach in your schools?

> You as extreme do not have weekends, vacations, sick leaves nor national
> holidays so as 365 days per year you write 14 995 * 365 is 5 473 175 bytes
> per year.
>
> "30 years" you claimed makes 30 * 5 473 175 what is 164 195 250 bytes per
> 30 years.
>

Ah, you do know arithmetic. And that is about 64% more than 100MB. Can
you compute that?

> Smallest from the "hundreds of megabytes" you claimed is as extreme 2 hundreds
> megabytes that is 209 715 200 bytes. So however favorably I try to calculate
> there are 45 519 950 bytes missing. That is more than 43 megabytes missing.
>

Yes, and much of that is also code I haven't written personally - but
have rights to from the contracts I've worked on.

> You can't calculate, mate, sorry. I don't know what "software designer" you
> are, but sounds funny. :D
>

You have zero clue, that's obvious. You should try working on larger
projects. For instance, when you have > 100 programmers on a project,
you get a LOT of code written every day. Multiple megabytes every week,
in fact. Properly designed, much of that code is reusable.

And I have rights to use all of that code that I designed, even when
others wrote the code. It's in my contracts.

But you also know everything about U.S. Copyright and contract laws, so
I know you'll just blow that off, too.

>>
>>>>
>>>> And BTW - all of that code is heavily commented. I didn't say it was
>>>> all code; there are comments in the code, also.
>>>>
>>>> Sorry, your show your ignorance.
>>>
>>> What percentage was comments? :D When you are in such a sad hole then
>>> stop digging.
>>>
>>
>> Enough to make the code clear.
>>
>> You're right. You've gone past the bottom. You should have stopped
>> digging long ago.
>
> Oh you can't tell any numbers. That indicates that the weird code-base
> resides within your fantasies.
>

The only fantasy here is your concept of the real world.

[Öö Tiib]

I claim only that you are clowning. Rest is your own nonsense bragging
and fantasies.

>
> >>
> >>>> Second of all, even your math is off. It's
> >>>> nowhere near 30KB per day.
> >>>
> >>> My math seems Ok. Right here was a good place of you to show "correct
> >>> math". What is the correct number "nowhere near 30000"?
> >>>
> >>
> >> Much less than 1/2 of that. And that is bytes, not LOC. But once again
> >> you don't seem to know the difference.
> >
> > Ok, lets try with that. Since you give no numbers I have to calculate with
> > most favorable to you extremes. So ... "1/2" of 30 000 that I claimed
> > is 15 000 bytes per day. "Much less" is lets say as extreme 5 less
> > so 15 000 - 5 is 14 995 bytes per day.
> >
>
> And now you've just proven you can't even do simple arithmetic. What do
> they teach in your schools?

Right here was good place again to show the ways you calculate. Unfortunately
no. You only talk groundless patronizing noise and it is uninteresting. :(

>
> > You as extreme do not have weekends, vacations, sick leaves nor national
> > holidays so as 365 days per year you write 14 995 * 365 is 5 473 175 bytes
> > per year.
> >
> > "30 years" you claimed makes 30 * 5 473 175 what is 164 195 250 bytes per
> > 30 years.
> >
>
> Ah, you do know arithmetic. And that is about 64% more than 100MB. Can
> you compute that?

You swallowed 365 day work-years without a blink? :D

No, I can't compute what you claim. Your "library hundreds of megabytes of
code" is still quoted above. 100MB is "hundred of megabytes" so at least
2 times less than that. Also I can not imagine how you reached 64% unless
you claim 56.59% being "about 64% in your universe". 164 195 250 bytes
is 156.59% of 100MB so it is about 57% more than 100MB.

>
> > Smallest from the "hundreds of megabytes" you claimed is as extreme 2 hundreds
> > megabytes that is 209 715 200 bytes. So however favorably I try to calculate
> > there are 45 519 950 bytes missing. That is more than 43 megabytes missing.
> >
>
> Yes, and much of that is also code I haven't written personally - but
> have rights to from the contracts I've worked on.

You are again claiming how you trumped your fortune 500 companies with
your wicked contracts. Such empty claims are out of proportions
uninteresting.

... snip rest of bragging.

Sorry, you are getting repetitive and uninteresting.

[Ian Collins]

On 10/17/16 01:24 AM, Jerry Stuckle wrote:
> On 10/16/2016 12:05 AM, Ian Collins wrote:
>> On 10/16/16 03:52 PM, Jerry Stuckle wrote:
>>> On 10/15/2016 9:12 PM, Ian Collins wrote:
>>>> On 10/16/16 03:38 AM, Öö Tiib wrote:
>>>>> On Saturday, 15 October 2016 06:03:06 UTC+3, Jerry Stuckle wrote:
>>>>>> On 10/14/2016 9:06 PM, Öö Tiib wrote:
>>>>>>>
>>>>>>> I do not see where I suggested to reinvent wheels.
>>>>>>>
>>>>>>
>>>>>> That's exactly what you're doing when you have to write code from
>>>>>> scratch with every project.
>>>>>
>>>>> Yes and I do not see where I suggested that.
>>>>
>>>> The joke of it is the arse doesn't realise agile development practices
>>>> (especially XP) naturally produce reusable code. You do have to
>>>> remember that jerryworld is stuck somewhere in the 90s.
>>>>
>>>
>>> Wrong again, Ian. Even the other trolls here claim that Agile
>>> development doesn't allow for reusable code.
>>
>> Citation please, no one using an agile methodology would make such a claim.
>>
>
> Read the messages in this thread.

I have and no one has made such a claim.

>>> But then you're is exactly the type of comment I would expect from
>>> someone who claims to have 10GB in their office - with 100GB coming.
>>
>> Why do you find that such a hard concept to grasp?
>>
>> [root@kvmhost (Home) /]# dladm show-phys
>> LINK MEDIA STATE SPEED DUPLEX DEVICE
>> rge0 Ethernet up 1000 full rge0
>> e1000g0 Ethernet up 1000 full e1000g0
>> ixgbe0 Ethernet up 10000 full ixgbe0
>> ixgbe1 Ethernet up 10000 full ixgbe1
>>
>
> ROFLMAO! Stoopid is as stoopid does! That is NOT 10G ethernet - much
> less 100G!

Let's see:

# man ixgbe

NAME
ixgbe - Intel 10Gb PCI Express NIC Driver

So you disagree with Intel as well now?

--
Ian

[Jerry Stuckle]

On 10/16/2016 2:33 PM, Ian Collins wrote:
> On 10/17/16 01:24 AM, Jerry Stuckle wrote:
>> On 10/16/2016 12:05 AM, Ian Collins wrote:
>>> On 10/16/16 03:52 PM, Jerry Stuckle wrote:
>>>> On 10/15/2016 9:12 PM, Ian Collins wrote:
>>>>> On 10/16/16 03:38 AM, Öö Tiib wrote:
>>>>>> On Saturday, 15 October 2016 06:03:06 UTC+3, Jerry Stuckle wrote:
>>>>>>> On 10/14/2016 9:06 PM, Öö Tiib wrote:
>>>>>>>>
>>>>>>>> I do not see where I suggested to reinvent wheels.
>>>>>>>>
>>>>>>>
>>>>>>> That's exactly what you're doing when you have to write code from
>>>>>>> scratch with every project.
>>>>>>
>>>>>> Yes and I do not see where I suggested that.
>>>>>
>>>>> The joke of it is the arse doesn't realise agile development practices
>>>>> (especially XP) naturally produce reusable code. You do have to
>>>>> remember that jerryworld is stuck somewhere in the 90s.
>>>>>
>>>>
>>>> Wrong again, Ian. Even the other trolls here claim that Agile
>>>> development doesn't allow for reusable code.
>>>
>>> Citation please, no one using an agile methodology would make such a
>>> claim.
>>>
>>
>> Read the messages in this thread.
>
> I have and no one has made such a claim.
>

You don't read very well, do you?

>>>> But then you're is exactly the type of comment I would expect from
>>>> someone who claims to have 10GB in their office - with 100GB coming.
>>>
>>> Why do you find that such a hard concept to grasp?
>>>
>>> [root@kvmhost (Home) /]# dladm show-phys
>>> LINK MEDIA STATE SPEED DUPLEX DEVICE
>>> rge0 Ethernet up 1000 full rge0
>>> e1000g0 Ethernet up 1000 full e1000g0
>>> ixgbe0 Ethernet up 10000 full ixgbe0
>>> ixgbe1 Ethernet up 10000 full ixgbe1
>>>
>>
>> ROFLMAO! Stoopid is as stoopid does! That is NOT 10G ethernet - much
>> less 100G!
>
> Let's see:
>
> # man ixgbe
>
> NAME
> ixgbe - Intel 10Gb PCI Express NIC Driver
>
> So you disagree with Intel as well now?
>

Fine - that's a NIC driver. It says nothing about your LAN/WAN
connection. I have set up a lot of 1G LANs for clients - even though
they only have 100MB connectivity.

But you don't know the difference. You've already proven that.

[Jerry Stuckle]

Nope, you claimed a lot more. But I know you won't own up to it.

>>
>>>>
>>>>>> Second of all, even your math is off. It's
>>>>>> nowhere near 30KB per day.
>>>>>
>>>>> My math seems Ok. Right here was a good place of you to show "correct
>>>>> math". What is the correct number "nowhere near 30000"?
>>>>>
>>>>
>>>> Much less than 1/2 of that. And that is bytes, not LOC. But once again
>>>> you don't seem to know the difference.
>>>
>>> Ok, lets try with that. Since you give no numbers I have to calculate with
>>> most favorable to you extremes. So ... "1/2" of 30 000 that I claimed
>>> is 15 000 bytes per day. "Much less" is lets say as extreme 5 less
>>> so 15 000 - 5 is 14 995 bytes per day.
>>>
>>
>> And now you've just proven you can't even do simple arithmetic. What do
>> they teach in your schools?
>
> Right here was good place again to show the ways you calculate. Unfortunately
> no. You only talk groundless patronizing noise and it is uninteresting. :(
>

I don't need to show how wrong your basic arithmetic is.

>>
>>> You as extreme do not have weekends, vacations, sick leaves nor national
>>> holidays so as 365 days per year you write 14 995 * 365 is 5 473 175 bytes
>>> per year.
>>>
>>> "30 years" you claimed makes 30 * 5 473 175 what is 164 195 250 bytes per
>>> 30 years.
>>>
>>
>> Ah, you do know arithmetic. And that is about 64% more than 100MB. Can
>> you compute that?
>
> You swallowed 365 day work-years without a blink? :D
>

I never said anything of the sort. But you're so stoopid that you can't
even see how out of range your ideas are.

> No, I can't compute what you claim. Your "library hundreds of megabytes of
> code" is still quoted above. 100MB is "hundred of megabytes" so at least
> 2 times less than that. Also I can not imagine how you reached 64% unless
> you claim 56.59% being "about 64% in your universe". 164 195 250 bytes
> is 156.59% of 100MB so it is about 57% more than 100MB.
>

Ah, now you're back to trolling. And you don't even know how much 100MB
is. It has been 100,000,000 bytes for most people ever since hard disks
> 10MB came out in the middle 80's (when disk manufacturers vied as to
who had the largest disk). 164,195,250 bytes is 64.195250% greater.

>>
>>> Smallest from the "hundreds of megabytes" you claimed is as extreme 2 hundreds
>>> megabytes that is 209 715 200 bytes. So however favorably I try to calculate
>>> there are 45 519 950 bytes missing. That is more than 43 megabytes missing.
>>>
>>
>> Yes, and much of that is also code I haven't written personally - but
>> have rights to from the contracts I've worked on.
>
> You are again claiming how you trumped your fortune 500 companies with
> your wicked contracts. Such empty claims are out of proportions
> uninteresting.
>
> ... snip rest of bragging.
>
> Sorry, you are getting repetitive and uninteresting.
>

No "trumping" and no "wicked contracts". Pure business - and they know
it, also. But you know nothing about business, either.

In the United States, smart businesses keep control of code and license
its use. Microsoft is a great example.

[Ian Collins]

On 10/17/16 08:56 AM, Jerry Stuckle wrote:
> On 10/16/2016 2:33 PM, Ian Collins wrote:
>> On 10/17/16 01:24 AM, Jerry Stuckle wrote:
>>> On 10/16/2016 12:05 AM, Ian Collins wrote:
>>>> On 10/16/16 03:52 PM, Jerry Stuckle wrote:
>>>>> On 10/15/2016 9:12 PM, Ian Collins wrote:
>>>>>> On 10/16/16 03:38 AM, Öö Tiib wrote:
>>>>>>> On Saturday, 15 October 2016 06:03:06 UTC+3, Jerry Stuckle wrote:
>>>>>>>> On 10/14/2016 9:06 PM, Öö Tiib wrote:
>>>>>>>>>
>>>>>>>>> I do not see where I suggested to reinvent wheels.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That's exactly what you're doing when you have to write code from
>>>>>>>> scratch with every project.
>>>>>>>
>>>>>>> Yes and I do not see where I suggested that.
>>>>>>
>>>>>> The joke of it is the arse doesn't realise agile development practices
>>>>>> (especially XP) naturally produce reusable code. You do have to
>>>>>> remember that jerryworld is stuck somewhere in the 90s.
>>>>>>
>>>>>
>>>>> Wrong again, Ian. Even the other trolls here claim that Agile
>>>>> development doesn't allow for reusable code.
>>>>
>>>> Citation please, no one using an agile methodology would make such a
>>>> claim.
>>>>
>>>
>>> Read the messages in this thread.
>>
>> I have and no one has made such a claim.
>>
>
> You don't read very well, do you?

Prove it with a quote (I know you won't, but what the hell).

>>>>> But then you're is exactly the type of comment I would expect from
>>>>> someone who claims to have 10GB in their office - with 100GB coming.
>>>>
>>>> Why do you find that such a hard concept to grasp?
>>>>
>>>> [root@kvmhost (Home) /]# dladm show-phys
>>>> LINK MEDIA STATE SPEED DUPLEX DEVICE
>>>> rge0 Ethernet up 1000 full rge0
>>>> e1000g0 Ethernet up 1000 full e1000g0
>>>> ixgbe0 Ethernet up 10000 full ixgbe0
>>>> ixgbe1 Ethernet up 10000 full ixgbe1
>>>>
>>>
>>> ROFLMAO! Stoopid is as stoopid does! That is NOT 10G ethernet - much
>>> less 100G!
>>
>> Let's see:
>>
>> # man ixgbe
>>
>> NAME
>> ixgbe - Intel 10Gb PCI Express NIC Driver
>>
>> So you disagree with Intel as well now?
>
> Fine - that's a NIC driver. It says nothing about your LAN/WAN
> connection.

If you had half a clue you would see that it does. Hint: SPEED 10000.

I find it truly bizarre that you can't accept that people use 10G
networks, they aren't as esoteric ans you appear to believe.

--
Ian

[Chris M. Thomasson]

FWIW, this one works fairly nice:

https://business.spectrum.com/content/fiber-internet

[David Brown]

I don't think Ian was claiming to have a 10G /internet/ connection. He
has 10G local network connections. As far as I understand it (Ian can
correct me if I'm wrong), he has these because his job is development on
equipment that has high-speed network connections.

To me, this sounds entirely reasonable, and I can't figure out why Jerry
does not believe him. It's true that there are few people who need a
10G connection on their workstations - it's mostly something you have
between servers, or trunk lines in a network. But if your job involves
development work on that sort of network equipment, then you want those
interfaces on your workstation. (And I'm sure there are many other
use-cases where 10G on a workstation is worth the cost.)


But perhaps the only use Jerry knows of networks is to connect to
Usenet, and maybe do a little browsing - so he is simply can't imagine
that you might want local networks that are faster than your internet
connection.