Member Avatar for jhdobbins

Just curious how you feel about a few things...

First, how do you feel about operator overloading?
Our next project "can" involve it if we chose and I think it would be easier that way, but the TA's said some people think its a bad idea. I was just trying to get a prespective on it.

Second, I am thinking of buying Visual Studio 2003... I can get it at a
pretty good price and was just concerned if I should go thru with it or not.

Third, does anyone mess with open GL?

  • 3 Contributors
  • 3 Replies
  • 107 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by jhdobbins

Dani AI

Generated

Brief, practical notes tied to the thread: operator overloading, the tool choice, and OpenGL.

As and implied, operator overloading is a tool best used sparingly and where it reads like built-in types. Useful guardrails: keep operator semantics intuitive and side‑effect free (except for obvious mutating ops), prefer non‑member implementations for symmetric binary ops so conversions on either side work, make mutating operators return *this by reference for chaining, and mark single‑argument constructors explicit to avoid surprising implicit conversions. For types that manage resources, remember the special‑member rules (copy/move ctor, destructor, assignment) — mishandling these around overloaded assignment is a common source of bugs (operators reference, explicit keyword, ).

On the tool question raised by : modern development generally favors up‑to‑date compilers and IDEs because language support and diagnostics improve rapidly. For current hobbyist and student work, Visual Studio Community is a free, fully featured option; consider it over very old toolchains unless the course or legacy code specifically requires an ancient compiler (Visual Studio Community).

Regarding OpenGL: the API has shifted from the fixed‑function pipeline to a shader‑centric model. For current work, invest time in modern OpenGL (GLSL shaders, VAOs/VBOs) and use small helper libraries (GLFW for context/input, a loader like GLAD, and a math lib such as GLM). For tutorials and reference, the Khronos site and LearnOpenGL are practical starting points (Khronos/OpenGL, LearnOpenGL).

Final note: when collaborating (or when TAs express concern), prefer clarity over cleverness. Operator overloads that make intent clearer are fine; ones that hide behavior or introduce surprises are not.

Recommended Answers

All 3 Replies

Member Avatar for Narue

>First, how do you feel about operator overloading?
It's a frivolous feature that isn't really needed, but it sure is a convenient feature when used intelligently. For example, the iostream library certainly makes streams easier to use by overloading operator<< and operator>>. String comparisons are more intuitive by overloading the relational operators. For the most part you'll find that operator overloading isn't needed except in a few well understood cases. But those cases make your job as a programmer easier.

When I first learned C++, one of my pointed questions was concerning the need for operator overloading, and that was my conclusion. Much later. ;)

>I am thinking of buying Visual Studio 2003...
That would be a good choice if you can find a good deal. I haven't had any serious problems with the latest versions of Visual Studio. Visual Studio 6.0 sucked though. ;)

>Third, does anyone mess with open GL?
I would be surprised if nobody here did. Though I don't, my work doesn't enter the realm of graphics.

Member Avatar for prog-bman

First, how do you feel about operator overloading?

As Narue says it is handy sometimes but it really isn't necessary but I do use it ;)

Second, I am thinking of buying Visual Studio 2003... I can get it at a
pretty good price and was just concerned if I should go thru with it or not.

If it is a good deal then go for it.

Third, does anyone mess with open GL?

Negative on that one for me.

Member Avatar for jhdobbins

From through my engineering program at college, I can get VS 2003 for 14.99... plus 2.50 shipping... I figured that was a good deal? :mrgreen:

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.