What framework should aspiring c++ mechanical engineers learn
closed account (E8A4Nwbp)
Hello,
It is highly advised to learn c++, should you wish to enrol in a mechanical engineering career. However, what framework should you learn at the very least?
It is highly advised to learn c++, should you wish to enrol in a mechanical engineering career. However, what framework should you learn at the very least?
framework means nothing to me.
I might consider learning some math libraries for calc, linear algebra, and equation parsing though, possibly CFD. You might consider, if you go for a minor or more classes in programming, taking a scientific path rather than 'IT' path. You may want a numerical methods class. My degree was the scientific applications approach and I had to take enough math to get a minor, had to take engineering statistics, calc based physics, 2 chemistry, data structures and algorithms, discrete math, numerical methods … to name a few things. All of those were very useful as I worked side by side with mechanical (aerospace actually) engineers.
That is a lot to pile onto your already tough degree, but those are the things I needed most to write programs to express what the engineers were telling me to do.
I would take this mess with a grain of salt and just focus on learning the core language well enough that you can write some programs and getting your primary degree. You can pursue the extras if you have free electives or even after you get a job, on your own time as needed or as interested, or on the side if you go for a masters.
you may also find some enlightenment in buying some hardware and programming a motor or other devices, simple controllers, etc.
I might consider learning some math libraries for calc, linear algebra, and equation parsing though, possibly CFD. You might consider, if you go for a minor or more classes in programming, taking a scientific path rather than 'IT' path. You may want a numerical methods class. My degree was the scientific applications approach and I had to take enough math to get a minor, had to take engineering statistics, calc based physics, 2 chemistry, data structures and algorithms, discrete math, numerical methods … to name a few things. All of those were very useful as I worked side by side with mechanical (aerospace actually) engineers.
That is a lot to pile onto your already tough degree, but those are the things I needed most to write programs to express what the engineers were telling me to do.
I would take this mess with a grain of salt and just focus on learning the core language well enough that you can write some programs and getting your primary degree. You can pursue the extras if you have free electives or even after you get a job, on your own time as needed or as interested, or on the side if you go for a masters.
you may also find some enlightenment in buying some hardware and programming a motor or other devices, simple controllers, etc.
Last edited on
I'm in agreement with @jonnin on this one, with a few notions of extension.
For example, as @jonnin mentions some math libraries, I might suggest you examine Eigen, a linear algebra library. I'd also suggest you familiarize yourself with Boost, as I've found a few libraries relative to various fields, including robotics, which rely upon Boost.
The main theme in my view is to simply to be familiar with how various libraries are consumed, because it is likely that whatever you already might know, you will be faced with a requirement for a library you've never seen before, and you'll want to be familiar with how they are acquired, built and used.
I'd also point out there are "plugins" built for various tools engineering consumes, like Pro/E or AutoDesk Inventor. So, you may want to obtain the SDK for some such tool and see how they work.
Depending on what fields you address, visualization may be a substantial part of it. There are a number of rendering libraries, like Ogre3D, which are used for various visualization requirements attached to such work, if they are not plugins for existing tools like Pro/E or Inventor (or what have you).
To that end, too, some game engines serve reasonably well as visualization tools. Unity, for example, is used for architectural visualization products.
You may also want to try some embedded projects, as they are related to the kind of computer control applied to a great many engineering targets.
You would also be well served by experimenting with robotics.
All touch various targets relevant to engineering.
For example, as @jonnin mentions some math libraries, I might suggest you examine Eigen, a linear algebra library. I'd also suggest you familiarize yourself with Boost, as I've found a few libraries relative to various fields, including robotics, which rely upon Boost.
The main theme in my view is to simply to be familiar with how various libraries are consumed, because it is likely that whatever you already might know, you will be faced with a requirement for a library you've never seen before, and you'll want to be familiar with how they are acquired, built and used.
I'd also point out there are "plugins" built for various tools engineering consumes, like Pro/E or AutoDesk Inventor. So, you may want to obtain the SDK for some such tool and see how they work.
Depending on what fields you address, visualization may be a substantial part of it. There are a number of rendering libraries, like Ogre3D, which are used for various visualization requirements attached to such work, if they are not plugins for existing tools like Pro/E or Inventor (or what have you).
To that end, too, some game engines serve reasonably well as visualization tools. Unity, for example, is used for architectural visualization products.
You may also want to try some embedded projects, as they are related to the kind of computer control applied to a great many engineering targets.
You would also be well served by experimenting with robotics.
All touch various targets relevant to engineering.
for visualization ... the 'big' stuff, your tools on your job likely provide this (eg animation of your system in your cad program, I think they all do that now?).
What you often find you want is a quick way to do graphs (x/y plots, not the data structure).
I glossed over that for the most part in my early days by exporting CSV files and letting excel plot it for me. A little clunky, but a system("excel filename.csv") made it less painless.
Later on I did start graphing 2-d plots with directdraw. I had a cool program that would take a message from the network and plot up to 10 variables in 10 different colors and let me take screenshots. It was handy .. I could watch the driver's commands vs the vehicle's responses in real time, for example .. they say full left and then a few blips after that command the vehicle is turned full left... and it was generic, anything we did could use it and it could do around 100 points/sec (pretty good back then).
So yes ... being able to draw even crude things is very useful. Our primary aerospace engineer could tell everything he wanted to know in one screen's worth of plots that his stuff generated.
Tool plug-ins is also huge. 90% of what I do in C++ right now is just small functions that are called by our main tool, either for a performance lift of something it could do but poorly or something it could not do at all. I cut one process' time in half (30 min to 15) with a couple of these recently.
What you often find you want is a quick way to do graphs (x/y plots, not the data structure).
I glossed over that for the most part in my early days by exporting CSV files and letting excel plot it for me. A little clunky, but a system("excel filename.csv") made it less painless.
Later on I did start graphing 2-d plots with directdraw. I had a cool program that would take a message from the network and plot up to 10 variables in 10 different colors and let me take screenshots. It was handy .. I could watch the driver's commands vs the vehicle's responses in real time, for example .. they say full left and then a few blips after that command the vehicle is turned full left... and it was generic, anything we did could use it and it could do around 100 points/sec (pretty good back then).
So yes ... being able to draw even crude things is very useful. Our primary aerospace engineer could tell everything he wanted to know in one screen's worth of plots that his stuff generated.
Tool plug-ins is also huge. 90% of what I do in C++ right now is just small functions that are called by our main tool, either for a performance lift of something it could do but poorly or something it could not do at all. I cut one process' time in half (30 min to 15) with a couple of these recently.
Last edited on
Topic archived. No new replies allowed.