Welcome to the Lounge

2-Sep-19 4:18

kmoorevs wrote:
was a cheapo ralink that had quit working after the first year

It never ceases to amaze me that one can somehow make solid state silicon etched circuits so cheap that they actually degrade over the course of a year.

If you would have asked me, before I'd known it was possible I wouldn't have believed it. Poke tongue | ;-P

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

Re: This isn't good...

honey the codewitch1-Sep-19 8:05

A Programming Philosophy Question

1-Sep-19 8:05

that sounds like a hardware problem if its intermittent. Maybe a hard drive issue that cropped up after being used intensively to wipe and reimage.

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

Richard Andrew x6431-Aug-19 13:31

Richard Andrew x64

31-Aug-19 13:31

So I'm perusing through an STL cookbook. I never learned the C++ STL, so I thought I'd like to try.

So I'm expecting to see good OO design principles in play here. But I find that to sort a vector, you don't simply call a Sort() method on the vector, you need to call a stand-alone function and pass it the vector, sort(begin(v), end(v)).

As a matter of fact, a whole cadre of things you would want to do with STL objects are accomplished by calling these external, stand-alone functions.

What kind of design is this? This feels a lot more like C than C++.

Why was it designed this kooky way?

The difficult we do right away...
...the impossible takes slightly longer.

Maximilien31-Aug-19 14:30

Maximilien

31-Aug-19 14:30

C++ is not only classes and hierarchy and encapsulation; and in the case of STL, a lot of it is generic and templated stuff (STL)

From STL FAQ: A Few Questions and Answers :

"The STL exemplifies generic programming rather than object-oriented programming, and derives its power and flexibility from the use of templates, rather than inheritance and polymorphism. It also avoids new and delete for memory management in favor of allocators for storage allocation and deallocation. The STL also provides performance guarantees, i.e., its specification requires that the containers and algorithms be implemented in such a way that a user can be confident of optimal runtime performance independent of the STL implementation being used."

Anecdotal: The more I use C++ the less I use strict pure OO design (something like the idealistic Smalltalk) .

I'd rather be phishing!

Richard Andrew x6431-Aug-19 14:53

Richard Andrew x64

31-Aug-19 14:53

Well, this is a terrific answer. Thank you! Thumbs Up | :thumbsup:

The difficult we do right away...
...the impossible takes slightly longer.

Amarnath S31-Aug-19 15:21

Amarnath S

31-Aug-19 15:21

This implies that OO does not necessarily guarantee performance, doesn't i?

KateAshman1-Sep-19 22:21

KateAshman

1-Sep-19 22:21

You can safely ignore the performance aspect of OO design.

In ye olden times, OO was considered default-bad for writing algorithms, because objects are generally bigger than base-types, which is mathematically bad for performance if you have to cycle through 100 million of them.

Today, it just doesn't matter, because developers don't really have to do math anymore.
We include a package or library or header to implement the proven best version of the algorithm we need. And that's it.

15~20 years ago, C++ developers got paid to write custom data structures and algorithms because performance was a thing, code sharing was uncommon and hardware was slow.
Nowadays, most of the C++ work is deleting all of that old custom stuff while replacing it with standardized parts, because maintaining custom code is bad for everything, including performance ironically.

obermd2-Sep-19 5:42

obermd

2-Sep-19 5:42

OO was never about performance. It was about finding a better way to model a problem domain so that it would be easier to maintain a codebase.

Whether or not it succeeded at this is very dependent on the skills of the original designer and how well the OO model actually fit the problem domain.

Gary Wheeler3-Sep-19 1:17

Gary Wheeler

3-Sep-19 1:17

obermd wrote:
Whether or not it succeeded at this is very dependent on the skills of the original designer and how well the OO model actually fit the problem domain

Excellent answer, and very much on point. OOP is not a magic bullet, just like functional programming and other models aren't. They are tools, useful in some cases and problematic in others.

Software Zen: delete this;

honey the codewitch31-Aug-19 17:45

31-Aug-19 17:45

C++ is NOT OO
not OO
not OO

what you're seeing is generic programming.

You need the book Accelerated C++ by Andrew Koenig and Barbara Moo.

Best $15-$20 USD you will ever spend.

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

User 26235231-Aug-19 23:02

User 262352

31-Aug-19 23:02

C++ is multi paradigm.

C^hris L^osinger1-Sep-19 3:34

C^hris L^osinger

1-Sep-19 3:34

it's sort(v.begin(), v.end())

but this does allow you to sort a range within the container.

KateAshman1-Sep-19 21:39

KateAshman

1-Sep-19 21:39

Because even though OO design was considered the norm for C++, it still had clearly defined use cases, and STL algorithms were never considered one of them.

I could get theoretical about it, but just stating the practical difference is easier:
- OO design is for helping humans to deal with abstract concepts.
- Functional design is for writing fast algorithms with low coupling.

Basically, STL containers are OO because it makes sense to modify, expand and build on top of them.
STL algorithms are functional, because they perform time-critical individual tasks and you're not encouraged to mess with them.

All in all, it's proper design, because you shouldn't use OO design for algorithms.

Richard Andrew x642-Sep-19 4:07

Richard Andrew x64

2-Sep-19 4:07

Very good answer, thank you!

The difficult we do right away...
...the impossible takes slightly longer.

User 5838522-Sep-19 19:18

User 583852

2-Sep-19 19:18

It's just a different abstraction where the iterator idea forms the interface. I find it far easier to work with than c# and linq tbh

Happy coding.

honey the codewitch31-Aug-19 12:28

31-Aug-19 12:28

When an object model you didn't design with caching in mind can implement intelligent caching with very little code changes.

I backed all my objects with normalized json - basically an object is represented by a Dictionary and an array is represented by a List

each property already did localized caching for individual fiels

public string Title 
{ 
  get {
    return GetCachedProperty("title",(string)null);
  }
}

and has a public Json property that contains the root for that object.

All I do is create a larger Json object and root each object in that. When an instance is created, the first thing it does is root itself in the larger cache document. Like so

void _InitializeCache()
{
	// Json is a new object with our key(s) in it.
	var networks = Tmdb.GetProperty("networks", (IDictionary<string, object>)null);
	if (null == networks)
	{
		networks = new JsonObject();
		Tmdb.Cache.Add("networks", networks);
	}
	object o;
	if (networks.TryGetValue(Id.ToString(), out o))
	{
		var oj = Json;
		var d = o as IDictionary<string, object>;
		if (null != d)
		{
			// found our network:
			// 1. take any existing data and merge it with the cache
			// 2. set our Json pointer to the cache for it
			JsonObject.MergeReplace(oj, d); // merges one tree with another
			Json = d;
		}
	}
	else
		networks.Add(Id.ToString(), Json);
}

Since the Json graph is all objects, it keeps references intact so you can reference the same branch from multiple places and there will only be one copy, even though if you serialize the JSON out each reference will be written out (so N copies)

Anyway, what's cool is you can check the cache simply by calling

Console.WriteLine(Tmdb.Cache); // basically an IDictionary object with an overloaded ToString method.

or clear it by calling Tmdb.Cache.Clear();

or traverse it as lists and dictionaries.

And it can easily be serialized and deserialized (as long as your cross references don't hose it too badly)

It's pretty cool overall.

I just designed it to back The Movie Database's JSON/REST api but in doing so I made the caching completely automatic without even changing much of my code.

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

Seems about right

Jörgen Andersson31-Aug-19 9:54

Jörgen Andersson

31-Aug-19 9:54

Wumo 31. Aug 2019 | Wumo[^]

Wrong is evil and must be defeated. - Jeff Ello

OriginalGriff31-Aug-19 19:49

OriginalGriff

31-Aug-19 19:49

I'm sure his funeral will be well attended - remember, "where there's a Will, there's a bunch of vultures". Big Grin | :-D

Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!

Jörgen Andersson31-Aug-19 21:42

Jörgen Andersson

31-Aug-19 21:42

But those aren't friends are they?

Wrong is evil and must be defeated. - Jeff Ello

OriginalGriff31-Aug-19 21:57

OriginalGriff

31-Aug-19 21:57

They were when they thought he might give them something! Laugh | :laugh:

Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!

Jörgen Andersson31-Aug-19 22:13

Jörgen Andersson

31-Aug-19 22:13

Ah, but those aren't Friends, they are "friends".

Wrong is evil and must be defeated. - Jeff Ello

OriginalGriff31-Aug-19 22:42

OriginalGriff

31-Aug-19 22:42

There's a difference with Farcebok? OMG | :OMG:

Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!

Sander Rossel31-Aug-19 23:01

Sander Rossel

31-Aug-19 23:01

I'm pretty sure he'll be disassembled.
Some parts might still be usable Unsure | :~

Best,
Sander

sanderrossel.com
Continuous Integration, Delivery, and Deployment
arrgh.js - Bringing LINQ to JavaScript
Object-Oriented Programming in C# Succinctly