Suggestions for things to study

Hello everyone,

At my current job, my employer offers us bonuses based on our performance above and beyond the specifications of our work. Things like learning COM, or MSI technology, or Showing the team how to use VisualAssistX, etc. Anyway, I have seem to come to a road block in that I ran out of ideas for these bonuses. I literally Don't know what to research next.

I was wondering if the good members of Cboard could offer some ideas. Things like new technologies pertaining to either C++ or Win32 (or derivative - such as ATL or MFC, which I already learned) programming. Or even plugins to visual studio that can make life easier. I want to stay away from other languages since we don't use them in the shop (Although this may change in the future). We are a Windows based shop so all of our programming is done on Windows, using the API (Hence why I posted in this forum).

Things that I have learned/presented already:
- MFC & ATL
- cppUnit (and general unit testing)
- MSI technology
- x86 Assembly
- VissualAssistX
- Design Patterns
- COM
- WinPE
- SVN vs CVS

Any suggestions are greatly appreciated and it doesn't matter how outlandish they may be. Thanks in advance.


EDIT: I should also say that this is not limited to Research. I can do coding projects as well (such as building a wrapper library for the team).

As I see you have already looked into x86 assembly, you could also consider looking into drivers. :)

How about some generally useful things:
- How to optimize code (and I don't mean "how to write it 20% faster in Assembler", but rather general things like: Identify bottlenecks, improve algorithms, etc)
- How to write good code (checking return values and such things, but also for example how to make sure that C++ classes are binary compatible from one development cycle to another).
- How to avoid Undefined behaviour traps.

--
Mats

Quote:

---

As I see you have already looked into x86 assembly, you could also consider looking into drivers.

---

Good suggestions, I will definitely look into this and run it by my manager.

Quote:

---

- How to optimize code (and I don't mean "how to write it 20% faster in Assembler", but rather general things like: Identify bottlenecks, improve algorithms, etc)

---

I sort of started doing this on the side just to increase my general knowledge of things. Might be a good idea. Thanks.

Quote:

---

- How to write good code (checking return values and such things, but also for example how to make sure that C++ classes are binary compatible from one development cycle to another).

---

We have processes at work for all this stuff. Might be good to go over it again and see if there might be improvements.

Quote:

---

- How to avoid Undefined behaviour traps.

---

We had a big debate about unit testing and exceptions last week. So I think this has been discussed enough internally. Either way, we have a standard to follow that forces us to avoid and check for behaviour. QA does the rest, I guess.

Quote:

---

Originally Posted by Mastadex

We had a big debate about unit testing and exceptions last week. So I think this has been discussed enough internally. Either way, we have a standard to follow that forces us to avoid and check for behaviour. QA does the rest, I guess.

---

Interesting. So I presume you have some sort of parser that detects things like "a = i++ * i++;"? How about f0(f1(), f2()) - if f1 or f2 depends on something happening in the other function, then you may find that f1 is called in the other order at some point [I had such a bug in some code I wrote many years back].

--
Mats

Quote:

---

Originally Posted by matsp

Interesting. So I presume you have some sort of parser that detects things like "a = i++ * i++;"? How about f0(f1(), f2()) - if f1 or f2 depends on something happening in the other function, then you may find that f1 is called in the other order at some point [I had such a bug in some code I wrote many years back].

--
Mats

---

That was actually added into our coding standard. It had some 280 rules, most of which are common sense but some are like the above quoted. If someone gets caught using such logic, our lead would bust a gasket. Also, we do use the code analyzer that comes with VisualStudio and also we have a 3rd party analyzer that does it all at compile time on our build server. Also a 3rd one that does analysis at run time. I know it wont catch all errors, but we do have some safeguards against it, preemptive or otherwise.

I would love to look into some other tools that do code analysis, so that could be one research topic.