Heidelberg

Heidelberg probably has the most picturesque old town in the entire Germany. Out of all the views I’ve seen in Germany, this is one of the best.

The view is from the ruins of a castle that was destroyed during the Thirty Years War (17th century). I believe the old town is mostly in the Baroque style.

For breakfast, we had a very traditional German pastry, known as a Berliner. It’s similar to a doughnut, but without the hole, and it has a jam filling on the inside and powdered sugar on top. They’re super delicious and not insanely sweet like a lot of American doughnuts.

For lunch, we had more traditional German street foods. The top of the bottom image is currywurst, cut up sausage with curry ketchup on top. The flavour is a very savoury sausage with a slight sweet and spicy zing of curry. The bottom of the image is a bratwurst in a breadroll with mustard. Everything about this is better than the American hot dog. Better sausage to bun ratio, better bread, better sausage, and better mustard. And of course, fries are seasoned with mayonnaise instead of ketchup.

After lunch, we drove up the hill across the river from the old town and visited an old ampitheatre. Why is this amptitheatre interesting, you might ask? It’s actually a relic of the Nazi period for holding propaganda performances.

The main allure of Heidelberg itself is its picturesque views both in the old town and up on Heidelberg castle. Visitors can easily enjoy this by strolling through the old town and making their way up to the castle (there is also a tram), which are main attractions of the city.

Zweibrücken

From Heidelberg, we drove to Zweibrücken. It was a slight detour from Luxembourg, where we were actually trying to go, but we had read about a cool observatory decorated like R2D2, so we thought we’d check it out! It would have been cool to look through the telescope – after all the sky was completely clear of any clouds.

Driving to the place was super scenic! Nice rolling countryside hills with towering wind turbines.

From there we continued our drive to Luxembourg.

Luxembourg

We crossed the border into Luxembourg at dusk and stopped by the town of Schengen. This is the place where the Schengen Agreement was signed – the agreement that removed the hard borders between its European member states.

Normally, it’s possible to walk across to the island to see the small exhibit that discusses the Schengen Agreement, but we were super surprised to see the river at such a high tide (it did rain a lot the past couple of days). On the right of the picture, there’s a little shrub, street signs and flagpoles poking out of the water.

By the time we reach Luxembourg City, it was nighttime. To our surprise, the city looked deserted even though it was only 19:00. People walking on the street appeared drunk. There was even a guy taking a leak in the street without even trying to do it in an alley!

We walked around a bit to check out the town, but otherwise, there wasn’t much to do at that hour on a weekday.

We didn’t stay too long in Luxembourg, and we continued our drive to Bastogne, where we’d stay the night.

Photos:

• Heidelberg
• Zweibrücken
• Luxembourg

Unlike Shinto shrines in other places, these ones are quite simple in their architecture.

These people were trying to “listen” to the tree. I thought stethoscopes were needed to do that. Anyway, that tree trunk was huge.

Random chicken on the road. Doesn’t seem to be afraid of people.

And of course, lunch! Ise is famous for its udon, so that’s what we had at a restaurant called Ise Udon Okunoya. My lunch also came with a rice bowl with sashimi from local fish.

And I also had one piece of sushi that costed ¥1,000 (~$10). The main ingredient: Matsuzaka beef, a kind of beef that rivals even Kobe beef in quality. The beef is very soft and tender. When I put it in my mouth, I felt it melting apart by itself. $10 well spent.

Oharaimachi is a street with many traditional buildings and restaurants. There also lots of shops that sell different types of sake, and local foods for tourists.

Played this game where I shot a gun that shot out a small cork at towers of candies. Whatever I knocked down, I got to keep. Went home with a bag of candy

Links to photo albums: here

“Korea DMZ” by Rishabh Tatiraju is licensed under CC BY-SA 3.0

Joint Security Area at Panmunjom

The most worthwhile part of the trip was to be able to visit the Joint Security Area in Panmunjom or the so-called “Truce Village”. This is the part of the DMZ where people from the North and South can see each other face-to-face. Travelling here allowed me to see a piece of history that I was already interested in.

Before going in everyone had to sign an agreement, where one passage says, “The visit to the Joint Security Area at Panmunjom will entail entry into a hostile area and possibility of injury or death as a direct result of enemy action.” Luckily, the US soldier informed us that it was “highly unlikely for anything to happen”. We were also told to not make any gestures toward the North Korean guards or any tourists on the other side.

The blue buildings are conference buildings where meetings with both sides take place. They are placed such that half of the building lies on each side of the border. The gray/white building is the Panmungak, a North Korean building. On the first door on the left, a North Korean soldier stands on guard. Concrete slabs show the separation between the two sides. I guess this means I’ve technically been to North Korea – at least for a few minutes.

Third Infiltration Tunnel

Another destination we went to was the Third Infiltration Tunnel, which had the potential of being used to attack the South and its location was revealed by North Korean defector. This was known because there were clear signs of holes drilled in the rock for the next blast, and the holes were aimed toward the South side.

To prevent injury, everyone had to wear hard hats – which was a really, really, really good idea since there was a low ceiling and I hit my head at least a dozen times. Unfortunately, we weren’t allowed to take any photographs underground.

“Third Tunnel of Aggression” by Josh Berglund is licensed under CC-BY-2.0

Dora Observatory Post

This is a place where one can look toward North Korea from afar – but photos are not allowed past the yellow line for fear of being mistaken for sniper scopes. It’s pretty barren on that side. If only my camera could take a shot like the image I found on Wikipedia!

“The view of North Korea from Dora Observatory” by Josh Berglund is licensed under CC-BY-2.0

Dorasan Station

Dorasan Station is one of the few places one can actually go to Pyeongyang, at least before 2008. Our tour guide happened to be named Dora, so when we got to Dora Mountain she said, in her accented English, something like, “Look! This is my mountain!”

Lunch!

Lunch was a delicious mushroom and beef hotpot with kimchi, salad, and other delicious goodies on the side (if only I knew what I was eating)!

Outdoor Military Vehicle Display in Imginjak

Nothing much to say here – just a showcase of various military vehicles.

Back to Seoul

The tour lasted the full day. It began in Imginjak and ended at the Joint Security Area. We had dinner (more on that very “special” dinner in another post) in Myeongdong and spent the rest of the night walking around there.

Link to more photos: here

Print Volume

This is the amount volume that the printer is able to print in.  Generally, the measurement is given by the three dimensions of a rectangular prism.  The thing to watch out for here is that just because a printer has a large print volume, it does not mean the printer can reliably print in all of it.  Say the design calls for a thin flat plate.  If the plate is too wide, then the edges of the plate will peel/warp during the print and the flat shape that was intended will be slightly curved.  To visualize what warping is, imagine a flat plate lying on the print bed as it is being printed.  Warping is when the corners of the plate start peeling off the base during a print.  Warping will be explained in a little more detail later on.

Resolution

This describes the accuracy of the nozzle’s positioning.  It is usually measured in microns or inches.  Clearly a smaller value means that the printer will be more accurate in its position.

Layer Thickness

Because the printer works by extruding layers of plastic, thinner layers allow for more fine details.  However, more layers means that the part will take longer to print (all other things being equal).

Print Speed

3D printing is generally a slow process, but a faster print speed could definitely help offset that.

Nozzle Diameter

A small nozzle diameter means that the extruded plastic will be narrow and thus allow for fine details.  It also improves the smoothness of the printed object.

Ease of Removing Parts off the Platform

Because during a print, the base of the part (ideally) should be firmly adhered to the print bed, one must take care when removing the part from the print bed.  In some cases, removing a part requires a little bit of force to pry the part off the print bed.  This application of force may affect the alignment of the print bed relative to the nozzle.  In lower quality printers this can permanently affect the alignment or require frequent re-calibration   Seeing how “rigid” the print bed assembly can help assess how the machine accuracy can be affect during part removal.  For example, if the print bed is mounted on really large support structure, then the affect of misalignment is less of a problem than a machine where the print bed is mounted in a smaller support.

Enclosure

Some printers enclose the part to be printed in a box and some don’t.  The reason an enclosure exists is so that the machine is able to prevent the part being printed from losing too much heat during print.  Loss of heat during a print negatively affects the adhesion of the printed plastic.  Also a larger temperature difference means the part will warp more.  Without an enclosure, heat is able to freely transfer to the ambient.  High quality printers generally have an enclosure.

Variety of Printed Materials

A common material to print with is ABS.  Other materials such as PLA can be printed as well.  The use of the particular material can be quite dependent on the application of the printed part.  The cost of material also differs.  It is worthwhile to determine what material will be printed.  In many cases, ABS should be sufficient.

Warping

This is probably one of the biggest limitations of 3D printing.  Because of the use of heat during print, it is natural for the part to shrink as it cools down.  The problem is that the shrinkage is not uniform.  Some parts of the model shrink more than others and most of the time it is very unpredictable.  While there are some general guidelines that designers can follow to reduce warping, there are definitely some machine features that are good to have to help reduce warping even further.  Because the nature of the way the printer prints is that plastic is extruded layer by layer, the plastic layer at the very bottom is the first to cool down.  Cooling down means shrinkage.  This also means that as the bottom of the model shrinks, the printer is still printing on top of a slightly shrunken part.  Sometimes the shrinkage can be so bad that the part pulls itself off the print bed.  When the part is no longer securely adhered to the print bed, the part may slide around and ruin the entire print.  Warping is the enemy of 3D printing.

Below are some qualities of a machine that help reduce shrinkage:

• Heated print bed – a heated print bed keeps the plastic hot during the print and does not let the base cool down as much as if there were no heated print bed
• Enclosure – described above

There are more ways to reduce warping that the designer can do, but that is outside the scope of this article.

Number of Nozzles

A lot of printers just have the one print nozzle, but there are some with multiple.  This allows printing with multiple colours or in some cases printing with a water soluble support material.  Generally, support material has to be manually removed from the printed part, but if the support material is water soluble, this saves a lot of the manual labor involved in cleaning up the model.

Nozzle Maintenance

Through extended use, the nozzle can become quite dirty, that is black gunk starts building up on the surface of the nozzle.  If one is not careful, this can clog the print nozzle.  It is worthwhile to find out how often the nozzle needs to be replaced.  There are also other factors that may result in the need to replace a nozzle.  This is a recurring cost of maintaining the printer.  Some nozzles are cheaper and more common than others and it is worth it to see how often the nozzle needs to be replaced and how much it will cost each time.  Machines may come with extra nozzles.

Lubrication

Over time, moving parts may have to be lubricated.  Printers should come with a maintenance manual to help instruct the user how to do this.  It is also helpful to know the cost of the lubricant and how often it will be required.

Machine Lifetime Cost

Aside from the cost of the machine, operating a 3D printer can also incur the following costs:

• Shipping
• Insurance
• Brokerage fees
• Tools for removing support material
• Currency conversion
• Sales tax
• Print material (recurring)
• Replacement nozzles (recurring)
• Lubricants for moving parts (recurring)

As it can be seen, the extra costs can be quite significant.

Conclusion

Hopefully this has given a good general overview of some of the considerations in buying a 3D printer.  Different people will value different things in the printer and hopefully this subset of possible considerations for buying a 3D printer helps people make a decision as to what to look for in a printer.

Beginning of the Competition

On the first day of the competition, there was a work day for all the teams to use to get their robots ready again after a long flight to Canada.  As the current mechanical team lead for the Thunderbots, I too had to get our own robots ready to play.  The mechanical systems had already been completed some weeks ago, but unfortunately, even now, the electrical board testing and firmware coding still had not been completed yet and some parts that we needed were still not in.  For the next day and a half, the team was scrambling to get everything finished in preparation for the first game on Sunday.  Because, the only critical tasks remaining were the electrical testing and coding, only the electrical team had the know-how to tackle those tasks.  The mechanical and software teams could only wait for results.  As the electrical team worked, everybody else on the team became more and more stressed.  We all kept wondering whether the team would have working robots for the first game.  We were all helpless in this situation.  The electrical team worked throughout the day and night trying to finish.  Some of the other team members stayed in anticipation while others went home to rest hoping for results in the morning.

Throughout this work day, the Chinese team continued testing their robots on the field.  They seemed like the most ready team.  The German team however, had lots of work to do as well.  Their flight to London from Germany was delayed and as a result, they missed their flight from London to Vancouver.  They arrived in Vancouver on Saturday night.  They  had even less time than we did to get their robots working.  When each team set up their work space, they each made sure to put up their mascots.  For the Chinese team, they had a panda plush of about 1.5 ft tall and the Germans had a full size German flag.

Game Days

On the game day, I woke at up 5:30 AM and arrived bright and early on campus at 8 AM.  When I arrived, the electrical team was still at it and seemingly not even close to finishing.  This led to a change in the team’s strategy to the competition.  We would try to repair the electrical boards from last year’s robots.  These old boards had a different size than the new ones and had different mounting holes, but luckily, somebody on the team had the great idea of including mounting holes for these old boards for this year’s robots.  Otherwise, we would have had a really hard time hacking that together.  Given only the few hours we had to hack this set up together, the mech team and I worked as fast as we could to finish.  We each probably ran up and down the stairs at the UBC Engineering Design Center about 20 times that day looking for tools and delivering robots.

The first game was supposed to be at 9:30 AM, but my team certainly was not ready.  It seemed like the other teams weren’t completely ready either, so the game was postponed until the afternoon.  The Thunderbots was supposed to play the first game, but due to our lack of readiness, China and Germany played each other instead.  When it became our turn we play, we managed to get three robots out of six on the field.  None of these robots had a working break beam sensor (the sensor on the robot that is designed to detect ball possession).  Without break beams, the robots did not know they could kick the ball, since it would never know if it had ball possession.  The robots did not have a controller that worked well either (the controller determines how much voltage to apply to each of the motors such that the robot can move smoothly from A to B).  A controller that didn’t work well meant the robots drove about on the field seemingly confused.  “Derp” is probably the best word to describe it.  Despite the shortcomings of these three robots, they played their best against ZJUNLIct from China and the Thunderbots were defeated 10-0.

On the following few days, the mech team tried to help the electrical team the best they could with tasks such as building extra connectors.  We also tried to get the old break beam sensors working again.  It was something that had to be on the robot if it were to ever kick the ball properly.  After toiling for a few hours, we managed to get two out of three of them working.  We probably could have gotten more if we knew more about the electrical design.  There was little to go on in terms of the wiring schematic and spare parts.  It was also hard to troubleshoot since ambient lighting largely affected the sensor.  If it worked upstairs in our work space, it wouldn’t work downstairs on the playing field.  It took us a while to figure that out.

In our second game, we played against ER-Force from Deutschland.  For this game, we still only had three robots, but this time they were a little bit better equipped.  Even then, the robots still had trouble kicking because the lights being used on the field emitted too much infrared light, which obstructed the break beam sensors.  It was very frustrating to see the robots not knowing when to kick even though they were handling the ball perfectly. But somehow, we still managed to score a goal.  In the end we lost the game 6 to 1.

In the final game between China’s ZJUNLict and Germany’s ER-Force, the Chinese team was victorious.  Both teams had a full fleet of robots to play six on six.  A modest crowd of spectators also watched the whole game being played and in general people were quite impressed at this engineering feat.

Team Social

To allow the teams to better know one another, there was a social event planned by the organizers of the North American Open.  There, I met a lot of the members of the German and Chinese teams.  It was nice that that I could talk to each team in their native languages.  Although my German wasn’t that good to keep up a conversation for a long time, it was enough to get the Germans wondering how I knew it at all.  The last thing they’d expect is for a Chinese guy to start speaking German to them.  My Mandarin was at a level that I could talk to people in it, but there were still some occasions where I didn’t understand what they said.  It was probably because of me not having a lot of practice with Mandarin (I speak Cantonese normally) and them having an accent from their region that I didn’t recognize.

Press Conference

The organizers made sure to invite as much of the press as they could.  More publicity meant that the team could potentially get more money in sponsorship.  More money means better robots.  The administrative members of the team were in the spotlight and talked to most of the people from the press, while the technical members of the team continued to do their work.  The team leads from mech, software and electrical also had a brief interview with the 24 Hours Vancouver newspaper.  The team was also featured in the Ubbyssey here and on MacLean’s magazine here.

The Chinese team also put on a show for the press by putting all 12 of their robots on the field so they could they play against themselves six on six.  The performance went quite smoothly as there were not random break downs and the press were very impressed.

Engineering Failures

As with these student projects, an accident was bound to happen.  This one was with a battery.  There was have been a defective battery that the Chinese team unknowingly brought and when they charged it, the battery started puffing up – not a good sign for a battery.  One of our team members was quick to notice and instantly dunked it in soap water and disposed of it.

For our team, we had problems where the solenoid kicker would get stuck after being used repetitively.  Heat from the power dissipation in the solenoid windings would heat up the whole assembly and cause the solenoid housing to permanently deform.  The solenoid was produced out of stacked layers of poly-carbonate sheets.  This stacking of layers allowed each layer to deform individually.  To fix this problem, we printed out new housings made of ABS plastic.  By having one solid solenoid housing, it was more difficult for it to deform.

The German team had some problems with the turf getting dug out of the carpet and getting everywhere inside the problem and also with their robot shells not staying on properly.  The turf inside the robot meant that gears could get stuck intermittently and could also get in the way of other mechanical components.  Their solution solution for now was to clean it all out every game.  During games, the shells of the robot would pop out randomly whenever there was an intense impact with a ball or another robot.

Getting Ready for Mexico

On the Friday before all three teams left for Mexico City, everybody had to pack up all of their things.  The German and Chinese teams could pack everything easily since they had packed everything once before when they had to fly to Vancouver.  For us, our tools were scattered all over the place.  It took us about 4 hours to find all tools to pack into the the luggage containers.  The approach to packing was that we would pack any tool that was ours and was already lying out on the table.  This is because if we took it out of the tool closet, it meant that the team used it for something.  Naturally all of the hex keys, screw drivers and the like were packed.  All spare parts were packed.  Every tool that we had sitting around was packed.  Even electrical equipment like a power supply and an oscilloscope was packed.  We had everything we needed for RoboCup 2012 in Mexico City.  Even though not everything was done in time for this competition, everybody was confident that things would be better in the competition in Mexico.

More photos here

Team Formation

I think this is where a lot of students struggle when things go wrong.  It’s always possible to get a teammate that is hard to work with.  While it is no fault of either person, the two personalities (either in values, cultural background, style of working, way of thinking, etc.) are different enough to cause disagreements.  At times, the disagreements can become so heated that the team’s progress in the project is hindered.

I realized that there were communication issues among each other in the group, which delayed progress in the early stages of the project.  These issues came about in the form of misunderstandings of what people said during team meetings.  I found myself in the position where I was expressing my own interpretation of what people said in the hopes that everyone would reach a common understanding.  As the project went on, family issues prevented one member from continuing this project further.  In a way, this eased our communication problems since communication between three people was a lot easier than between four people, based on what I experienced in the project.  Afterward, our team became a lot more efficient and progressed at a faster rate than before.

One of the things that the mechanical engineering curriculum at UBC teaches is team dynamics.  After learning a lot of theory as to how to work best with teams, doing projects with other people puts that knowledge to the test.  Some people don’t really manage working with others and feel set in their ways.  Differences among people exist and I realize that adjustments in the way I work with them is required in order to promote a healthy functioning group.

Project Scope

In retrospect, I would have advocated reducing the project scope since; I feel that the hours we put in were beyond what the course asked for.  I estimate that each member put in over 300 hours on the project.  Since a large part of this course is about design justification, time is very realistic constraint that can limit project scope.  At the same time, there are other courses to worry about.  By spending extra time on 45X, less time is available for other courses.

In the beginning of the project, I couldn’t predict well how long things would take.  Therefore, time for “messing up” or “unforeseen consequences” should be budgeted for.  Many people say things like “I can finish this in about 2 hours”, but in reality, it will take him two days.

Documentation

Very often I found myself referring to old dossier documents to find out information that I needed to know. For example, if I forgot how much something cost, I looked back on the dossier to find out.  If I forgot one of the project requirements, back to the dossier I looked.  At times, it is a bit of a pain to write some sections of the dossier since I couldn’t make sense of the some of the wording.  To deal with it, I had to ask the project supervisor during team meetings.

Project Logistics

I booked as much machine shop time as we could ahead of time knowing that we would need it.  The team would have liked to send in parts for the waterjet or have the technicians work on them, but we were way too late for that.  With a simpler project scope, we could have designed our parts faster and could have been further ahead in those manufacturing lineups to decrease the lead time.  My teammates and I spent quite a bit of time in the machine shop to get as much as we could ready for the design review.  At the same time, I had to look at when ordered parts arrived such that things would arrive in time so that we had everything prepared while building the prototype.

Time Management

While doing 45X, I was also working on New Venture Design and Thunderbots at the same time, which also took up a lot of my time.  As with design projects, they take up the most time relative to other courses.  For me, I had to juggle these three for the entire year.  This gave me a lot of stress at times, but it taught me to be more productive.  For example, on the way home, I would be responding to e-mails that I received during the day so I would have more time to work on the project when I got home.  Since my commute to campus is 1.5 hours just to get to campus (one direction), I had to learn how to make use of this time.

Project Management

I took up the role of “project manager” in the beginning of the project and this role showed me a lot of the logistics that had to be considered in a project.  Very often I found myself asking for progress on certain tasks and pushing teammates to finish faster.  Different issues often came to my head that I had to find an answer for such as “are our parts going to arrive in time for machining” or “do we need to have another meeting with the client”.

For Future 45X Students

Don’t wait until the last minute to do something.  There is always something that needs to be done in this course from beginning to end.  Mech students like to aim high, which is good, but 99% of the time there is not enough time to accomplish the “perfect” design that they always aim for.  This leads to a lot of sleepless nights or worse, a prototype that isn’t ready to be handed in.  Be ready to bite the bullet and make compromises like cutting features to make work less for the team and to meet deadlines.  No design will be “perfect” at the end of the course and this fact, however brutal it may be, must be accepted.

The eerie music played continuously in the background.  I don’t remember what the music was, but reading more about it, it is the source of an urban legend surrounding the “Lavender Town Syndrome”.  Apparently, there was a brief peak in suicides among 7-12 year old kids shortly after the release of Pokémon Red and Green in Japan.  I don’t remember being that frightened by the ghosts when I was little.

I also remember talking to the old man in Viridian City who taught the player how to catch Pokémon and then using him as an exploit to get to MIssingNo off the coast of Cinnabar Island.

All sorts of weird stuff happened like seeing level 100+ Pokémon and the massive replication of items in the sixth inventory slot (that’s a lot of Masterballs and Rare Candies).

And then there was Gary, who was probably the biggest jerk ever encountered.  At every step of the game, he’d ALWAYS be one step ahead of the player.  In the beginning, he purposely picks the Pokémon that is your pick’s weakness.  And later in the game, after the player gets all the Gym Badges, it turns out Gary got them all before the player.  And he still remains ahead even after fighting the Elite 4.

At least, at the end, there is a great feeling of satisfaction after beating him.  If I remember correctly, according to Professor Oak, he didn’t give his Pokémon “trust and love”.  Gary was a bit of an ass, so I guess he deserved it.

asm (seldom used)

• Used to insert assembly language commands directly into the code. This function is very tricky to use even for professional programmers and can cause portability issues.
  

  asm(“instruction”);

auto

• Used to declare local variables but is purely optional.
  

  auto int i = 5;

  The previous declaration thus has identical meaning to the following declaration.

  int i = 5;

bool (C++ only)

• Used to declare a Boolean logic variable; a variable that can have the value true or false. This variable type is normally 8 bits (1 byte) long.
  

  bool t = true;

break

• Used to break out of a loop independant of the loop condition. Also, used to finish a switch statement, keeping the program from “falling through” to the next case in the code.
  

  while(x < 100)
  {
      if(x < 0)
           break;
      cout << x << endl;
      x++;
  }
  

case

• Used as a label to declare a single test in a switch statement.
  

  case 1: command1;
          command2;
          break;
  

catch (C++ only)

• Used to handle exceptions generated by a throw statement.
  

  catch(const char* e)
  {
      //handle exception
  }
  

char

• Used to declare character variables. This variable type is normally 8 bits (1 byte) long.
  

  char c = ‘h’;

class (C++ only)

• Used to define a new class. Members of the class are private by default unless listed under the protected or public labels.
  

  class class-name : inheritance-list
  {
      public:
          public-members-list;
      protected:
          protected-members-list;
      private:
          private-members-list;
  } object-list;
  

  • class-name is the name of the class that is being created.
  • inheritance-list is the optional list of classes inherited by the new class.
  • public-members-list is the list of public members of the class.
  • protected-members-list is the list of protected members of the class.
  • private-members-list is the list of private members of the class.
  • object-list is an optional list used to immediately instantiate 1 or more instances of the class.

  class Date
  {
  public:
      void display();
  
  private:
      int day;
      int month;
      int year;
  }
  

const (C++ only)

• Used to tell the compiler that a certain object should not be modified once it has been initialized.
  

  const int i = 5;

• Used to declare a pointer so that the value of the pointer (the memory location to which it points) can be modified, but the data in the memory location cannot be changed.
  

  const int* j = new int(3);

• Used to declare a pointer so the that value of the pointer (the memory location to which it points) cannot be modified, but the data in that memory location can be changed.
  

  int* const j = new int(3);

• Used to declare a member function that does not modify the object’s state, meaning that it should be used for methods like print so that data in the object cannot be changed accidentally. If and attempt is made to modify the object in any way, a compilation error will be triggered.
  

  void print(bool verbose) const;

const_cast (C++ only, seldom used)

• Used to remove the const protection on a variable as long as the original variable was not declared as a const. The target type must be the same as the original type.
  

  const_cast<target_type> (object);

continue

• Used to jump to the next iteration of a loop. The following example will print out all of the numbers from 1 to 20 except for 10.
  

  for(int i = 0; i < 21; i++)
  {
      if(i == 10)
          continue;
      cout << i << endl;
  }
  

default

• Used as a label to declare the default case of a switch statement.
  

  case 1:  command1;
           command2;
           break;
  
  default: command1;
           command2;
           break;
  

delete (C++ only)

• Used to free memory allocated for a pointer back to the heap. The argument should have been allocated through a call to new. To delete an array, use the following form of delete: delete[]
  

  delete p;
  delete[] pArray;

do

• Used to create a loop that is executed at least once. The terminating condition is tested at the end of the loop.
  

  do
  {
      cout << "hello worldn";
      i++;
  } while(i < 5)
  

double

• Used to declare a double-precision floating-point type variable. This variable type is normally 64 bits (8 bytes) long.
  

  double d = 12.55;

dynamic_cast (C++ only, seldom used)

• Used to cast from one type to another with a check performed at runtime. If the cast types are incompatible, NULL is returned.
  

  dynamic_cast<target_type> (object);

else

• Used for an alternative condition in an if statement.
  

  if(i == 1)
  {
      // do something
  }
  else
  {
      // do something else
  }
  

enum

• Used to define an enumerated type. Each of the names in the name-list are given a distinct value. This should be used in place of defining variables using “magic numbers” (eg. int Monday = 0, int Tuesday = 1, etc).
  

  enum name {name-list};

  • name is the name of the enumerated type that was created
  • name-list is the list of names of the elements

  enum weekdays {Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday};

explicit (C++ only)

• Used to make sure that a constructoor is only used for the creation of new values and not used for the implicit conversion between two different types. It will only be be used if the initialization exactly matches the call to that constructor. This keyword is only needed with one-argument constructors.
  

  class vector
  {
      ...
      explicit vector(int v);
      ...
  }
  

  Using this keyword, some mysterious errors can be caught by the compiler like the following:

  vector<int> v(10);
  v = 5; // error, meant to write v[0] = 5
  

  The problem in this code if the explicit keyword was not specified is that the v = 5 statement would invoke the constructor, creating a new vector of size 5 and destroying the old one.

export (C++ only, seldom used)

• Used to export a template to other modules. Most compilers require template definitions to be explicitly specified in the header file since the Comeau C++ compiler seems to be the only compiler that supports this keyword.
  

  // In MyTemplateFunction.h
  template
  void myTemplateFunction(const T &t1);
  
  // In MyTemplateFunction.cpp
  export template
  void myTemplateFunction(const T &t1)
  {
      ...
  }
  

extern

• Used to inform the compiler of variables and functions that are defined outside of the current scope or module. Variables defined as extern will not have space allocated for them since they are defined elsewhere.
  

  extern char* message;

false (C++ only)

• Used to represent the Boolean value false.
  

  bool b = false;

float

• Used to declare a single-precision floating-point type variable. This variable<br> type is normally 32 bits (4 bytes) long.
  

  float f = 3.5;

for

• Used to create a loop that is meant to initialize, test and update a variable.
  

  for(int i = 0; i < 10; i++)
  {
      cout << "i is " << i << endl;
  }
  

friend (C++ only)

• Used to allow another class or function to have access to the private features of that class.
  

  friend void print(bool verbose);
  friend class Vector;

goto (seldom used)

• Used to jump to another location in a function specified by a label. This is generally considered harmful and should not be used unless necessary.
  

  goto labelA;
  ...
  labelA:

if

• Used to create a conditional branch statement so that different code can be executed under different conditions. The conditions are evaluated in the order that they appear in the code.
  

  if (i < 0)
  {
      cout << "i is negative";
  }
  else if(i == 0)
  {
      cout << "i is 0n";
  }
  else
  {
      cout << "i is posativen";
  }
  

inline (C++ only)

• Used to tell the compiler that the function an its body are inserted into the calling code meaning that it has to expand the function in-place instead of just insert a call to the function. Functions that have static data, loops, switches or recursive calls cannot be inlined.
  

  inline int test(int A)
  {
      ...
  }
  

int

• Used to declare an integer type variable. This variable type is normally 32 bits (4 bytes) long.
  

  int i = 3;

long

• Used as a data type modifier for the int and double types to indicate that they may have more bytes then the type has available. This variable type is normally 32 or 64 bits (4 or 8 bytes) long.
  

  long int i = 100000;

mutable (C++ only)

• Used to specify that it is a data field that can be modified even if another part of the data is declared const.

namespace (C++ only)

• Used to create a new scope. Once created, the namespace must be refered to either directly or with the using keyword.
  

     namespace CartoonNameSpace
      {
          int HomersAge;
  
          void incrementHomersAge()
          {
              HomersAge++;
          }
      }
      int main() {
          ...
          CartoonNameSpace::HomersAge = 39;
          CartoonNameSpace::incrementHomersAge();
          cout << CartoonNameSpace::HomersAge << endl;
          ...
      }
  

new (C++ only)

• Used to allocate a new block of memory for the given type from the heap, and return a pointer to that block of memory. Allocating arrays can be done by providing the size of the array in square brackets.
  

  pointer = new type;
  pointer = new type( initializer );
  pointer = new type[size];

  • pointer is a pointer to the type that you want to allocate the memory for
  • type is the type of the item that is to be stored in the memory that is allocated
  • initializer is the optional information for the constructor
  • size is the size of the array to create

operator (C++ only)

• Used to specify that you are overloading an operator.
  

     return-type class-name::operator#(parameter-list)
      {
          ...
      }
  

  • return-type is the return type for the function
  • class-name is the name of the class that the operator is a part of. If it is not part of a class, this can be left out along with the ‘::‘.
  • # is the operator that is to be overloaded, such as ‘++’. You cannot overload the #, ##, ., :, .*, or ? tokens.
  • parameter-list is the list of parameters that the operator will take. For unary operators, parameter-list should be empty, and for binary operators, parameter-list should contain the operand on the right side of the operator (the operand on the left side is passed as this).
• There are special conventions for some operators, such as the unary ++ and — operators.
  • The unary ++ operator has both prefix (++object and postfix (object++) versions.

  •    return-type class-name::operator++()
        {
            ...
        }
    

    overloads the prefix version (the value returned is the value of the object after it is incremented, so this is also known as the pre-increment version because the increment takes place before the value is returned). There is no parameter specified because ++ is a unary operator.

  •    return-type class-name::operator++( int )
        {
            ...
        }
    

    overloads the postfix version (the value returned is the value of the object before it is incremented, so this is also known as the post-increment version because the increment takes place after the value is returned). The parameter int is not really a parameter (++ is still a unary operator) but is there soley to differentiate the prefix and postfix versions.

private (C++ only)

• Used within a class declaration to specify features of that class that can only be accessed by itself and its friends.
  

  class Date
  {
  public:
      void display();
  
  private:
      int day;
      int month;
      int year;
  }

• Used to inherit a base class privately, which causes all public and protected members of the base class to become private members of the derived class.
  

  class AlarmClock : private Clock
  {
  public:
      void display();
  
  }

protected (C++ only)

• Used within a class declaration to specify features of that class that are private to its own class, but can be inherited by a derived class.
  

  class Date
  {
  public:
      void display();
  protected:
      int day;
      int month;
      int year;
  }

• Used to inherit a base class, which causes all public and protected members of the base class to become protected members of the derived class.
  

  class AlarmClock : protected Clock
  {
  public:
      void display()
  }

public (C++ only)

• Used within a class declaration to specify features of that class that are accessable to everyone.
  

  class Date
  {
  public:
      void display();
  protected:
      int day;
      int month;
      int year;
  }

• Used to inherit a base class publically, which causes all public and protected members of the base class to become public and protected members of the derived class.
  

  class AlarmClock : public Clock
  {
  public:
      void display()
  }

register

• Used to reccommend that a varibale be placed into a processor register so that it is optimized for speed but the compiler is not obliged to do so. This keyword is rarely used anymore since compilers have become better than programmers at optimizing code.

reinterpret_cast (C++ only), seldom used

• Used to change one data type in a non-portable way. It is normally used to cast between incompatible pointer types.
  

  reinterpret_cast<target_type> (object);

return

• Used to cause the execution to jump from the current function back to the one that called it. An optional value can be returned but the function must specify the type that it will return.
  

  return;
  return 5;

short

• Used as a data type modifier for the int type to indicate that there may be less bytes then the type has available. This variable type is normally 16or 32bits (2 or 4bytes) long.
  

  short int i = 5;

signed

• Used to specify that the number type provided could potentially be negative, so it must be stored in a different format. This is the default representation that is chosen by most compilers if either signed or unsigned is not specified.
  

  signed int i = -12;

sizeof

• Used to return the size of the object (in bytes) that is passed to it.
  

  int i = 5;
  int size = sizeof( i );

static

• Used outside any function or class as a qualifier to a variable declaration makes the scope of the variable the file in which the variable is declared, and the extent is permanent (i.e., it is in the static segment).
  

  static int i;

• Used inside a function as a qualifier to a variable declaration makes the scope of the variable the function in which the variable is declared, and the extent is permanent (i.e., it is in the static segment).
  

  void foo()
  {
      static int i;
  }

• Used inside a class as a qualifier to a variable declaration makes the scope of the variable the class in which the variable is declared, and the extent is permanent (i.e., it is in the static segment).
  

  class bar
  {
      static int i;
  }

• Used outside any class as a qualifier to a function declaration makes the scope of the function the file in which the function is declared. As with all functions, the instructions for the function are in the code segment.
  

  static void foo()
  {
  }

• Used inside a class as a qualifier to a function (method) declaration makes the scope of the function the class in which the function is declared (as with all methods), and the instructions for the method are in the code segment (as for all functions). What is different is that a static method is invoked without requiring an object, using the qualifier syntax class::staticMethod( parameters ), although it can also be invoked on an object in the class in the usual way. Because no object is associated with a static method, only static member variables and other static member functions can be invoked by a static method.
  

  class bar
  {
      static void foo();
  }

  Note: A method in a class cannot be both “static” and “virtual”. The reason for this is that virtual functions have to know the object to which they apply (because of polymorphism) but static methods are not applied to an object.

static_cast (C++ only, seldom used)

• Used for a normal conversion between types. No runtime checking is performed.
  

  static_cast<target_type> (object);

struct

• Used to create a structure like a class, but the members are public by default instead of private. In C, structs can only contain data, cannot have inheritance and cannot have data with different visibilities.
  

  struct struct-name : inheritance-list
  {
          public-members-list;
      protected:
          protected-members-list;
      private:
          private-members-list;
  } object-list;

  • struct-name is the name of the struct that is being created.
  • inheritance-list is the optional list of structs inherited by the new struct.
  • public-members-list is the list of public members of the struct.
  • protected-members-list is the list of protected members of the struct.
  • private-members-list is the list of private members of the struct.
  • object-list is an optional list used to immediately instantiate 1 or more instances of the struct.

  struct Date
  {
      int day;
      int month;
      int year;
  }

switch

• Used to test an expression of an integer value against many constant integer values and is commonly used to replace large if()…else if()… statements. Break statements are required between each case statement, otherwise execution will “fall-through” to the next case statement. The default case is optional. If provided, it will match any case not explicitly covered by the preceding cases in the switch statement.
  

  char keystroke = getch();
  switch( keystroke )
  {
      case 'a':
      case 'b':
      case 'c':
      case 'd':
          KeyABCDPressed();
          break;
      case 'e':
          KeyEPressed();
          break;
      default:
          UnknownKeyPressed();
          break;
  }
  

template (C++ only)

• Used to create generic functions and can operate on data without knowing the nature of that data. They accomplish this by using a placeholder data-type for which many other data types can be substituted.
  

  template void genericSwap( X &a, X &b )
  {
      X tmp;
  
      tmp = a;
      a = b;
      b = tmp;
  }
  

this (C++ only)

• Used as a pointer to the current object. All member functions of a class have this pointer.
  

  this.print();

throw (C++ only)

• Used together with try and catch statements to create an exception handling system. Throw is used to generate an exception.
  

  try
  {
      cout << "Before throwing exception"<< endl;
      throw 42;
      cout << "Shouldn't ever see this"<< endl;
  }
  catch( int error )
  {
      cout << "Error: caught exception " << error << endl;
  }
  

true (C++ only)

• Used to represent the Boolean value true.
  

  bool b = true;

try (C++ only)

• Used to attempt to execute exception-generating code.
  

  try
  {
      cout << "Before throwing exception" << endl;
      throw 42;
      cout << "Shouldn't ever see this" << endl;
  }
  catch( int error )
  {
      cout << "Error: caught exception " << error << endl;
  }

typedef

• Used to create a new type from an existing type.
  

  typedef int seconds;

typeid (C++ only, seldom used)

• Used to get a reference to a type_info object that describes the object it was passed.
  

  typeid(object);

typename (C++ only)

• Used to describe an undefined type or in place of the class keyword in a template declaration.

union

Used to create multiple data fields that will occupy the same memory location.

union Data
{
    int i;
    char c;
};

unsigned

• Used to specify that the int or char provided can only be posative and can therefore contain a larger number since there is no need to worry about representation of negative numbers.
  

  signed int i = -12;

using (C++ only)

• Used to import a namespace into the current scope.
  

  using namespace std;

virtual (C++ only)

• Used to create virtual functions that can be overridden by derived functions.
  • A virtual function indicates that a function can be overridden in a subclass, and that the overridden function will actually be used.
  • When a base object pointer points to a derived object that contains a virual function, the decision about which version of that function to call is based on the type of object pointed to by the pointer, and this process happens at runtime.
  • A base object can point to different derived objects and have different versions of the virual function run.

  virtual void print();

• Used to create a pure virtual function which is a virtual function that must be overriden by some derived class.
  

  virtual void print() = 0;

• Note: A method in a class cannot be both “virtual” and “static”.

void

• Used to denote functions that return no value.
  

  void print()
  {
      cout << "printn";
  }
  

• Used to create generic variables which can point to any type of data.
  

  void *p = 5;
  

• Used to declare an empty parameter list.
  

  void print( void )
  {
      cout << "printn";
  }

volatile

• Used to inform the compiler that the variables value can change in unexpected ways (i.e. through an interrupt), which could conflict with optimizations that the compiler might perform, so therefore the compiler will not optimize these variables.
  

  volatile Date d;

wchar_t

• Used to declare a wide character variable. This variable type is normally 16 bits (2 bytes) long.
  

  wchar_t c = ‘c’;

while

• Used as a looping construct that will evaluate a list of statements as long as the condition is true. Note: if the condition starts off as false, the list of statements will never be executed. (You can use a do loop to guarantee that the list of statements will be executed at least once.)
  

  bool done = false;
  while( !done )
  {
      ProcessData();
      if( StopLooping() )
      {
          done = true;
      }
  }

Copyright (C) 2000-2005, The University of British Columbia

Conditional – decides which set of actions that the program will perform depending on a programmer specified condition

Constant – a special kind of variable whose value cannot change during program execution

Control structure – refers to the order in which the individual statements, instructions, or function calls of an imperative or a declarative program are executed or evaluated

Data structure – ways that data can be organized within a program

Data type – different varieties that data can be represented within a program

Directive – used to describe how the parts of a program are to be used to built a complete program

Identifier – programmer-specified name; a sequence of characters associated with and used to access a variable, particular object, class or struct, or function. Every identifier has a scope

Iteration – a single execution of a set of instructions that are to be repeated; “the solution took hundreds of iterations”

Keyword – a word that has particular meaning to the programming language and describes how a program is to work

Literal – a notation for representing a fixed value in source code. For example, the literal 12 represents the integer value “twelve”, “Morning” represents the character string value “Morning” and true represents the Boolean value true. They describe the type of value data has

Naming structure – rules for how data values, variables, operators, and other language constructs are referred to within the language

Operator – special symbols that specify how data is to be manipulated. For example, a ++ is an operator

Pragma – data embedded in source code by programmers to indicate some intention to the compiler

Sequential execution – execution by a computer if instructions in a program, performed in the sequence established by a programmer

Subprogram – a part of the code that is reused in various parts of the program

Variable – remembers data values for use within a program

Variable declaration – defining a variable’s type and name (identifier)