Thread: Is it not learning C++ shooting myself in the foot?

Hello All,

I wanna be a programmer for a living and I really, really wanna do meshing.

Even now, I've got a tetrahedral triangulation code written and it works pretty sexily. I link faces, I don't collide or anything weird and I'm trying to optimize it by scanning it and replace certain tetrahedrons with others.

I'm trying to build a Voronoi mesh, for those who are curious.

But I was talking to this Swiss company and they rejected me. Mostly because getting a work visa (I'm an American) is a hassle, especially just for an intern.

But they ragged on me for not writing it in C++. They told me that their company uses "high level OO principles" and that I needed Visual Studio experience, whatever Visual Studio is. It's like a Microsoft IDE, right?

Honestly this isn't a rant thread, I swear. I'm just wondering why C++ is 'better' or more employable than C is.

Just looking at the flow of my code, I fail to see how an object would do anything differently. The C and C++ versions would be logically equivalent.

I also don't see why putting a function pointer in a structure redefines programming as a paradigm.

So, am I fool for only wanting to learn C and CUDA? I figured there's little point in learning all 3 languages. C++ isn't that different while CUDA is actually useful because of it's ability to grant you 10,000 threads while C++ is still CPU-bound.

Sorry to cry but I really wanted the job.

You're right though, phantom. I should learn enough C++ to make myself marketable.

But C++ better be worth it! CUDA took my skills with addresses and pointers and like tripled them just by trying to build a linked list on the GPU.

If anything, using C++ seems like it'll make me a worse​ programmer!

Man, whatever happened to using Gedit and a Makefile with the compiler set to super noisy?

Fair enough.

I'm re-writing my code in C++ though I'm not sure how I can benefit the most from an OO approach.

For example, should I just dump all my previously used functions into the class that's relevant? That doesn't really seem to do much.

I'ma keep toying with it and see how useful C++ can be but I've yet to come up with any brilliant ideas.

Any important new aspects of C++ I should look out for if I'm a C programmer?

You may want to look through this tutorial C++ tutorial for C users as a start. There is also a similarly titled book.

Jim

Originally Posted by MutantJohn

Any important new aspects of C++ I should look out for if I'm a C programmer?

Yes: the paradigm.

The way a C programmer views a problem is different to how a C++ programmer views it.

It is not just the question of what kind of tool you have in your hand. (Like they say, if the only tool you have is a hammer, all problems look like nails.) It's more about how those tools interact, how much their use costs (initial time/effort, plus maintenance time/effort), and how much experience you have had with solutions to similar problems.

Many programmers do that quite instinctively, and some may even claim they don't do that at all. Those of us that have used a lot of different programming languages (and specifically different types of programming languages) tend to become a little more introspective, just because that helps a lot when learning a new programming language. Learning the paradigm takes much longer; typically things "click" only when you see beautiful solutions written in a way to best use the strengths of that language.

For a C programmer, I think that first learning GTK+ should be useful. It is a common GUI toolkit used in Linux (and also available on other OSes) which heavily relies on the object-oriented paradigm. It is also not too ugly; I consider it a good example of how to do OO in C. It should be a good introduction to the paradigm.

Then, if you compare GTK+ in C to say Qt in C++, you can see that the approach and the objective are just about the same, only the implementation differs. I think this realization (or more specifically, experiencing that realization), is necessary for you to actually start to see the differences in the paradigm.

After that, you can learn a lot by simply reading well-done C++ projects, to see how they solve problems you've seen before. Even reading criticism about existing projects, if supported by suggested fixes or alternative approaches, will then give you a better picture of how C++ is best applied.

Obviously, none of this is specific to C and C++; you can say the absolute same thing about any two languages with different paradigms but with similarities in syntax.

I personally absolutely hate it when people conflate C and C++. Not just because they are different languages, but because they have such different paradigms. It's like saying "axe, saw; same thing: both cut wood". (Not to mention those idiots who insist on asking "why on earth would you ever use an axe, when motorized saws are available?".)

Okay then.

Can I use you guys to bounce ideas around???

I'm just curious how I should construct my code to maximize the use and efficiency of OOP.

Okay, I allocate a base particle set which I will use as vertices for my triangulation. I don't think this needs the use of any in-line members or functions as it's too specific. I'm not writing a generic allocation routine, I'm allocating a Cartesian distribution with positions (0, 0, 0) to (7, 7, 7) for 512 points.

I build a root tetrahedron for the insertion algorithm.

I figure one good use of objects is in my tetrahedron structure.

Code:

struct tetra {

    struct particle *p[4]; // 4 vertices per tetrahedron

    struct tetra *ngb[4]; //4 neighbouring tetrahedra

   double a[4], b[4], c[4], d[4]; // half-plane data (stored for the sake of point location performance)

   void mallocTetra(struct tetra *t); //allocate memory for a non-local address (I should do this, right?)

   int allocTetra(struct tetra *t, struct particle *p0, struct particle *p1, struct particle *p2, struct particle *p3) /* take a non-local address to a tetrahedron and assign points, half-plane data and initialize neighbours to NULL */
};

Granted, I still need to add to this but this is the general idea of an OO approach, right? Sorry if this all seems to nooby, never done this before.

Perhaps the C++ forum would be more appropriate place for advice on C++ implementation?

One of the big design questions is which things to describe using a class, and which things to keep as an implementation detail. For example, whether you use a class to describe the tetrahedral mesh, or if you want individual classes for the tetrahedra.

Personally, I would not create a vertex class, but a vertex list class would be useful: since your vertices are in a regular grid, you can just generate them on demand, instead of storing them in memory in an array or similar. Similarly, a class to describe and provide access to the tetrahedral mesh makes sense to me; I see no harm in leaving the individual tetrahedra as implementation details not directly accessible from outside the class.

Just because something is logically an object, does not mean the best option is to encapsulate it in a class. It is important to choose the level of abstraction. The main reason is it lets the programmers/developers brains concentrate on the overall algorithms. (A minor reason is that the abstractions usually come with a runtime cost. In most cases this is irrelevant, though.)

As an example of bad choice of abstaction: In a molecular dynamics simulation, it "makes sense" to create a class to describe each individual particle. Unfortunately, in non-quantum-mechanical simulations, the overhead of method calls (indirect function calls) over millions of particles per time step becomes significant, causing such a simulation to be slow. While throwing more hardware at it will solve the slowness, such code tends to also become overly complex when new features (multiple particle types, more complex interactions) are added.

However, if you use a class to describe a set of particles, say all particles in a rectangular region in space, you avoid those overheads, and the resulting code will be much more straightforward and readable. One reason for this is that MD simulations do not model individual particles, they model the interactions in a set of particles. The description of each particle is just an implementation detail that depends on the interaction model used, and therefore does not need their own class at all. The proper level of abstraction -- I posit -- is the interaction model instead, with the particles and their properties just internal state in the model.

Originally Posted by grumpy

Personally, I consider people who are limited in that way to be beginners. Fortunately, the main barrier affecting ability of anyone to move beyond that beginner status is their own effort.

I am a beginner to programming in the sense that I graduated with a degree from University last year and have only been working for this software company for 9 months - but I still appreciate the merit in learning any new language,ethos or paradigm! Since beginning Uni 5 years ago i've been learning Java javascript,prologue,HLSL,C,C# and C++ and ALL of them have new things to teach me everyday! My advice although it may not mean very much is to Learn as much as possible buddy! I saw someones user quote on here once - went something like "If you know what your doing, you're not learning!" - Loved it!

Lol thanks for the support, everyone!

So, I started porting my code to C++ and so far, I'm actually really liking it.

The use of objects is fun and I like organizing my code by namespaces because wow, I was really running out of variable names. Literally, I was using band names for variables and that is like 3x more confusing than using a namespace.

Also, you're right, the use of std::vector and std::array probably does what I'm used to doing myself and it's nice to just have a routine that works. I've also heard there's stacks and stuff, right? That std namespace, omg.

I used to know Java...

There was actually a time when I used to love learning new computer science stuff so I'm not sure what happened to me along the way... I think it's what happens when you bash your head on a wall with a project for long enough.

But you guys, omg, I think I know how to actually implement a Delaunay tree! And I finally found out the name instead of what I was calling it before, a quadtree implementation of a Delaunay triangulation through incremental insertion. Yeah, two words is better than that mouthful, especially for a recruiter even though a real programmer would read that and be like, "Yeah, that's what it is."

So yes, objects are fun, so are namespaces, built-in routines for arrays and I gotta look up what this vector thing is all about.

So, I know the following then: Java, IDL, C, C++, CUDA and I mostly want to stick to scientific computing.

And actually, you guys, what's the best way for a BS in physics to be hired as a programmer in the first place? What can I do to convince a company that I am just as apt if not even moreso than a CS person?

I know CS != programming so I'm talking about programming skills, here.

The thing is, from what I've found, upper div CS is more about math than it is syntax of language. Like, the Delaunay papers I read are literally nothing but math. And as it turns out, 4/5 leading Delaunay codes are written in pure C while just one is written in C++ so there, take that, C++! I'm talking about ones like tess3 and cgal and etc.