I'll second the have some kind of container (vector, list) of objects which are derived from a base class which has a pure virtual
method which returns true if the achievement is satisfied, so it can be removed from the container after it has been completed.
But what you don't want is each achievement to be a separate class derived from the base class - most achievements are similar (kill enemy X, collect X items, kill X enemies of type Y, etc.), so you want to have the different types of achievements as classes which take parameters on construction (or a separate initialisation step) which provides the details.
You can still have really complicated achievement types to have a class of their own, but these should be an exception rather than the norm. Also consider compound achievements which can have several subtasks (such as kill X goblins and collect Y golden nostrils), you can have a compound achievement class which checks for both (so will contain 2 or more instances of concrete achievement classes as members) which only returns true from SatisifiedAchievement when both tasks are complete.
If you are using C, you can do the same with function pointers.