Posts by mike_2000_17

I would imagine (since there is not enough code to tell), that the error is due to "originalTree" not being NULL, yet being invalid (either a pointer that has been deleted or a garbage address (uninitialized value)). Make sure that there is no way that either root, left or right pointers can be invalid (i.e. point to nowhere) and still have a non-NULL value. If the problem persists, post more code (like the insert method and the default constructor of myTreeNode).

@nezachem: True. I was just putting things in Lay-man's terms and trying not to open the flood-gates to explaining everything.

The library to use is <fstream> for file I/O. You can do simple input of a number or line (string) as follows:

#include <fstream>
#include <string>

int main() {
  std::ifstream in_file("my_list.txt");  //opens the file "my_list.txt"
  int code;  //declare variable for the integer code
  std::string name; //declare a variable for the name
  in_file >> code; //read the code from the file
  std::getline(in_file, name); //read the name from the file (remaining characters on the line).
  return 0;
};

You can also verify that the file stream has not reached the end-of-file by a simply using the file stream in an if-statement. This allows you to do a loop like this:

#include <fstream>
#include <iostream>

int main() {
  std::ifstream in_file("my_list.txt");
  int code;
  while(in_file >> code) { //this reads the code and checks that it did not reach end-of-file.
    std::cout << "A code is " << code << std::endl;
  };
  return 0;
};

With the above, you should be able to solve your problem. Giving any more hints would be cheating.

Both a DLL and an EXE are called "modules". When code gets compiled, you get a bunch of functions compiled to executable code and collected together in a module. In the case of an executable, there is one special function (the "main()" function) which is called the "entry-point" because when you run the program, that function gets called and that starts the execution of your program. In a DLL, there is no such function (well, there is, but let's not get into that). In that sense, a DLL is just an executable without an entry-point, thus, it cannot be executed directly. However, an executable program can use a DLL and call the compiled functions that are contained in it. DLLs are called either "shared libraries" or "Dynamic Link Libraries" which emphasizes two different characteristics that they have. They are shared because you can group many functions that could be useful to many different applications into one DLL and then different applications can share that DLL and its set of functions without the need for recompilation from source. It is dynamically linked which means that the linking (similar to what happens when you compile different "translation units" and _link_ them together to form an executable) is performed at run-time, either by loading the DLL when the executable starts (called static loading) or by loading it manually in the code of the application (via some system call like LoadLibrary()) at whichever point you like to load it (called dynamic loading). Creating and …

Are you sure that calling path.append("file1") does not change the string stored in "path"? I would bet that is the problem, in fact, I know.

Try using this instead:

// switch statement to changed filename
        switch(j){

        case 1: fileName = path + "file1";
            break;
        case 2: fileName = path + "file2";
            break;
        case 3: fileName = path + "file3";
            break;
        case 4: fileName = path + "file4";
            break;
                 }

How you would need to do it is as follows (explanation will follow):

//header.h
#ifndef HEADER_H
#define HEADER_H

void test();

#endif

//main.cpp
#include <iostream>
#include "header.h"   //to find the test() function.

int main()
{
  test();

  return 0;
}

//declerations.cpp
#include "header.h"

#include <iostream> //for using std::cout.

void test()
{
  std::cout << "This is from the function test in declerations.cpp";
}

Each cpp file is what we formally call a "translation unit". They are compiled separately and then linked together. So, since each cpp is compiled separately, they need to #include all the headers that they need for the compilation to work (thus the #include <iostream> and "header.h" in both the main.cpp and declarations.cpp).

Since cpp files are compiled separately and alone, they will never be "included" twice in one compilation run (in one "translation unit"). So, the header-guards (i.e. the #ifndef HEADER_H) are not required for cpp files because their content are guaranteed to appear only once. For header files, this is not the case, and header-guards are needed. Imagine this simple situation:

//in header1.h
int global_value = 10;

//in header2.h
#include "header1.h"

//in main.cpp:
#include "header1.h"
#include "header2.h"    //which will, in turn, include "header1.h" a second time.

int main() {
  return global_value; //ERROR: Which "global_value" should be used? there are two declarations of the same variable, this will not compile due to the One-Definition-Rule in C/C++.
};

Because headers are meant to be included by different files (other headers or cpp files) there is …

You just need to enclose everything in the namespace. As so:

/**
 * lib1.h
 */
#ifndef LIB1_H
#define LIB1_H

#include <iostream>
#include <fstream>
#include <vector>

namespace MyLib {

class Lib1 {
public:
    Lib1();
    ~Lib1();

    int some_lib1_function(int foo);

private:
    Lib1 *lib1;

};

}; //end of namespace MyLib

#endif

/**
 * lib1.cpp
 */
#include "lib1.h"

using namespace std;

namespace MyLib {

Lib1::Lib1() : lib1(new Lib1) // this will, btw, cause an infinite loop.
{

}

Lib1::~Lib1()
{

}

int Lib1::some_lib1_function(int foo)
{
    // do stuff with foo
    return foo;
}

}; //end of namespace MyLib

You have to post more code. And also the compilation error you get.

>>By the way, just curious .. you guys getting paid doing this? :OP

No. This is purely voluntary. There are different reasons for spending some time here and there to answer a few questions (e.g. helping people, promoting good values, strengthening your own understanding, having interesting discussions and sharing knowledge, ego-tripping!, etc.), but none involve money. So, voluntary means we can choose to answer, but we can choose to ignore. Questions which are short, unexplicative, or sound like "I don't get this! please explain!", can get ignored fairly often (and voted down), just like they would in real life (i.e. if your friend came up to you and said "I can't understand this homework! do it for me!", you wouldn't respond and probably told him to do his own bloody homework, but if he comes up and says "I've been working all day on this problem! This is how far I got.. but I'm stuck, what am I missing?", you would be much more inclined to answer).

Your terminology is wrong, that is why your internet searches on the subject fails to yield anything. The correct term is "passed-by-value" and "passed-by-reference", i.e. "passed" not "call". Call-by-value makes no sense (those who use this terminology do so incorrectly).

In lay terms (similar to GaidinDaishan):
Imagine you are one worker ("function") and your friend is another worker ("function"). Your friend wants you to do something ("call" upon you), but you need a password to accomplish your task (a "parameter" needs to be "passed"). Your friend has the password written on a piece of paper ("variable"). Now, there are two options:

Pass-by-value: You could have your own piece of paper ("local variable") for your friend to write the password on ("copy" its "value"). In this case, you can accomplish your task and your friend preserves the original, unaltered and, more importantly, unalterable.

Pass-by-reference: Your friend could simply pass-on the piece of paper to you. This is cheaper since no-one has to waste time writing a copy. But, now, you hold the original paper with the password, and you can do whatever you like with it (which can be useful, or not). This can be useful if you happen to change the password, then you can just erase the old password on the paper and replace it by the new one, and when you are finished, you hand the paper back to your friend and thus informing him of the new password. This is, however, not useful …

The error is in lines 144 and 155. In the first case, you are accessing the Left node, but the checked condition involved a logical OR expression, which means if Right node is valid (not NIL) then you proceed to access the Left node which may or may not be valid. Vice versa on line 155. Take out the check of the Right node on line 144 and take out the check of the Left node on line 155. That should help.

For the answer to your question, please refer to section 8.5 and 12.1/5-6-7-8 of the C++ standard (1998).

And, yes, it is irritating when posting on several forums. Different forums have different feels to them, and some do indeed participate in many.

>>are there any real techniques for drawing shapes?

Of course there are. But what "shapes" are you talking about? When it comes to shapes made of polygons, we usually talk about a mesh. Typically people use 3D design programs (like 3D studio max, or Blender3D, or Milkshape), and create 3D models (with animations) and load and draw them into their programs. But then, there are several other techniques to draw other kinds of objects. For example, heightmaps can be used to create land-scapes. This is pretty easy, you can create a grey-scale bitmap in your image editor of choice (GIMP or Paint), then load the image in your program with your image loading library of choice (FreeImage, OpenCV, or GLUT) and treat each pixel grey value as the height (hence, a "heightmap") and then draw a quad between each 4 neighbouring pixels (and apply some grass texture or some blend of different textures). Another important technique is so-called "procedural generation" of meshes (and other things). Techniques like "Perlin Noise" can be used to general natural looking artifacts (including dynamic ones) such as random (but natural looking) landscapes, dynamic cloud formations, dynamic water surfaces, and even natural looking random textures (like wood-grain, or grass). Finally, for very nice "shapes" you can also use built-in interpolation algorithms, like Non-Uniform Rational B-Splines (NURBS) curves and surfaces. These allow you to prescribe the general shape of an object with few points and let OpenGL general a smooth surface with high point-density (hence, the …

Narue is right. I would classify the ID data under "implementation details", i.e., stuff that should be encapsulated and hidden from the user (maybe accessible through a get function). I probably would go as far as not even providing a constructor that takes an ID, just ones that take high-level objects (a constructor from process name, a copy-constructor, and possibly some conversion or transfer of ownership kind of constructors between your different classes that handle a process ID, so that they can hand it over to each other while hiding it from the user).

Well, from your comments, y is the step size and ref is the reference voltage, they both should be floating-point values, then, the integer division won't apply anymore, even if divide remains an __int64 (which I can't tell because I have no idea what "divide" is supposed to represent).

You are calling it wrong (the __int64 should not be there). However, when dealing with higher numbers like this, you can't trust functions like abs(), they could very easily convert implicitly the operand to a lover type of int and then you loose everything. Don't use it. Use unsigned integers, not signed integers! You will avoid the use of this abs function altogether. There is no reason why a signed integer should appear anywhere in your code.

EDIT: I just tested your code. It doesn't work. It has huge percent errors at the end. And, it is also way, way longer than it needs to be (I rewrote it, and my implementation is less than 8 lines total, except for the I/O stuff).

Several observations:

1) remove the semi-colons after the include statements.
2) #include <cstdio> instead of <stdio.h> (in fact, I don't think you need it at all)
3) If you just removed the "feature" of outputting text in different colors, this program could run on Linux just as easily (removing the #include <windows.h>, of course).
4) Lines 40, 47, and 54, when you need a while-loop, use a while-loop.
5) If you are going to use the bits of the integer, use an "unsigned int" or, better, use fixed-length integer types, like uint64_t (from #include <stdint.h>) for a fixed-length 64bit unsigned integer type.
6) Don't use the pow() function for shifting bits. All calls like pow(2,bit); are equivalent to 1 << bit; using the bitshift operator, the latter is much better than pow().
7) don't use a string to store the result, it is just wasteful as hell.

Finally, your code is a bit too messy and un-indented that it is hard to reason about it. But, from the looks of it, you didn't implement a successive approximation ADC. My guess is that it doesn't work about 30 bits because you are using a signed integer which has at least one bit less than the unsigned integer (because it has to represent all negative numbers too!).

@awie10007
Yeah, I'm pretty sure the OP is talking about either a hobbyist's robot, or some research-grade robot (mobile, or manip, or other), or high-level control on industrial-grade robots (like feeding in joint-space trajectories in real-time to the controller). In which case, C++ is probably the best bet in terms of a suitable programming language. But, of course, for simple operation of industrial robots, there is no C/C++ involved, it's all proprietary CNC-like programming languages (i.e. a DSL) (like KRC/RSI for Kuka), but the capabilities are very limited (but totally sufficient for most of what is done in industrial automation).

>>how would you differentiate between the 'base' call to copy and the iterating call to copy

Of course you can't use overloading for this purpose, but why would you? The point of overloading is not to have a helper function while not needing to come up with some alternative name. When you define a helper function, which is only meant to be called by the "real" function, then what you really want is to "hide" that helper function away from user-access (out of your interface). For that exact purpose (which comes up a lot) there are three wide-spread methods/conventions. The first, which is preferred if your function has its own translation unit (not a header-only library), is to use a mechanism built into C++, namely: unnamed namespaces. As so:

namespace {
  int length_recursive(const char* str){
    if(*str)
      return 1 + length_recursive(++str);
    else
      return 0;
  }
}

int length(const char* str) {
  if(str)
    return length_recursive(str);
  else
    return 0;
};

The second is to use a "detail" namespace. This is a convention to collect in one sub-namespace all the things you don't intend "outsiders" to use:

namespace detail {
  int length(const char* str){
    if(*str)
      return 1 + length(++str);
    else
      return 0;
  }
}

int length(const char* str) {
  if(str)
    return detail::length(str);
  else
    return 0;
};

Finally, if you are in C or namespaces are not usable for some reason, the good-old convention is to append the name _impl at the end. Most programmers, if they see _impl after a function …

>>how do you feel about letting a 15 year old do your homework (if it is homework)
I guess the OP should feel some shame in that. But, you should too (a bit). It is generally not helpful to the OP to simply post finished work.

@OP:
You should not need to pass an integer to do the recursion. Basically, you are using the integer to mark the current character that is being looked at. You can just as easily achieve this by moving the pointer (incrementing the pointer instead of calling with index + 1). I'll rewrite your length function to show how that can be done, you can then do the same for the copy function.

int length(const char* str){
  if(str && *str)                //or just: if(*str)  for more efficiency
    return 1 + length(++str);
  else
    return 0;
}

>>Can you give me a few tips about that?
code, code, then code some more. Do it until your fingers or brains are numb (whichever occurs first), then rest, then repeat. Find a project you like, and get cracking. Make sure the project is within your grasp, but does challenge you (i.e. the perfect project is one that has high interest for you and for which you can already tell, roughly, how it should be done, but with several (big) holes, these are the parts from which you will learn the most). Program it incrementally, doing unit-testing will save you a world of trouble at debugging.

>>What books should I read
Read this thread.

>>what websites should I hang out
Daniweb! I guess you can also browse sourceforge for some project ideas and maybe join one, or build a project upon some existing open-source library. Open-source software is a great resource to expose you to both very well programmed software (e.g. Boost) and very poorly written code (e.g. like 90% or so of open-source software). Learning to deal with other peoples code and interfacing with external libraries is a crucial part of programming experience (i.e. learning to weight the cost of rolling your own code for something versus doing contortions to interface an external library, and being able to do so), and there are no books that can teach you that.

C++ is the language of choice in Robotics. C is also needed very often when dealing with drivers or small micro-controllers that don't provide any better option.

As far as I know, Assembly is not needed in robotics. But you could encounter some domain-specific languages (DSL) depending on the application, and often they are extremely low-level (or very high-level, depending on how you look at it). For example, if you deal with industrial manipulators, then they usually are programmed with a DSL that allows simple point-to-point or path-following commands, they are inspired from CNC machine tools. But, typically, if you deal with such a system you can interface the controller with an external PC with DAQ card and you are free to program it which ever way you like, i.e., using C++.

If you look in the AI department, you will find a lot of stuff in Java (like the various agent-based software platforms). But when you look in the "running robots" department, it is overwhelmed with C++ code (ROS, CLARAty, MaCI, Player/Stage, and many others, including my own). That's the divide between academics and pragmatists.

Frankly, in robotics, the programming language should be the least of your worries to start from. You need to start by designing the system architecture in a language agnostic, hardware agnostic and OS agnostic manner. Then, find hardware that matches your design requirements. Evaluate your software choices and programming language choices, and select. Very often, the programming language will turn out …

Recursion?

I don't think this will always work. If you look at the synopsis of min_element, you will see that it starts by using the first element as the lowest one. If the first element has really small distance but does not satisfy the predicate, you will be in trouble. You could probably find the first element that satisfies the predicate and start the min_element from there. But, in this case, I think it is easier to just make your own version of min_element that finds the min_distance or something like that. It will also be less wasteful in terms of distance computations.

>>don't want to use boost or AfxBeginThread().

Good luck. So, I'm guessing that if you don't want to use AfxBeginThread() which is just a thin wrapper around CreateThread, then you don't want to use CreateThread either. And if you don't want to use Boost.Thread, then you probably won't want to use any other library solution for multi-threading in C++, since Boost is by far the best, fastest, easiest and most robust implementation for multi-threading in C++ (in fact, it will become part of the C++ standard library before the end of this year, that's how good it is).

You have asked a question, but you also ruled out all the possible answers, from the lowest-level functions (i.e. CreateThread from the win32 API), to the most user-friendly high-level library solution (i.e. Boost). What do you expect?

The only other solution I can think of is a parallel processing solution, that is, OpenMP or Intel's TBB. But that can easily be overkill, and won't be very easy to use (it is professional stuff).

Maybe you should give more details as to why you reject Boost or AfxBeginThread, and what you are looking for in a solution for multi-threading.

>>Oh, and it works in /MD[d], /MD, MFX.
Don't worry about that, they all will work fine with those (if fact, you need /MD, it is not optional if you want to do multi-threading).

For Line 3 (the last param of the function), here is a detailed explanation:

First, consider the following simple statement:

Foo Bar::*attr;

This statement declares a pointer-to-data-member. In the above, it declares a pointer with name 'attr', which points to a data member of 'Bar' which is of type 'Foo'. Here are a few declarations of the same kind of syntax that you may be more familiar with:

//A function pointer:
int (*fptr)(int, double); //fptr points to a function taking (int,double) -> int.
//A function pointer type:
typedef int (*fptr_t)(int, double); //fptr_t is the type of functions pointers (int,double) -> int.
//A member-function pointer (or pointer-to-member-function):
//mfptr points to a function taking (int,double) -> int, and which is a non-static member of class MyClass:
int (MyClass::*mfptr)(int, double);
//similarly, as a type:
typedef int (MyClass::*mfptr_t)(int,double); //type of mfptr (above).

//then, a pointer-to-data-member:
int MyClass::*mdptr; //mdptr is a pointer to a member of MyClass, with type int.
//similarly for the type:
typedef int MyClass::*mdptr_t; //type of mdptr (above).

So, by substitution, in your example, attr is a pointer-to-data-member to a member of class std::iterator_traits<ForwardIter>::value_type , which is of type T.

Now, for the std::iterator_traits<ForwardIter>::value_type . I guess you understand that this will be the class that your iterators will dereference to (i.e. your Voice class). By now, you should also understand its place and function in the declaration of the pointer-to-data-member (see above). So, all that remains is the std::iterator_traits business. This is just the standard way, in …

Another simple solution to not cluttering your main install directory, and I believe this solution is pretty frequent, is to put your "real" executables and DLLs in a subfolder (like "bin") and then write a simple "launcher" executable to put in the main install directory, that launcher just starts the "real" executables found in the subfolder. This way you hide the ugly stuff and you don't pollute the client's system32 directory.

As for turning a _Dynamic Link Library_ into a static library, I have doubts that this is even possible (maybe it is, but I wouldn't know how). Normally, under Windows, the .dll is paired with a .lib static library, and the .lib is used just to associate the symbols for loading the DLL (i.e. it won't put the content of the .dll inside the .exe, you will still need the .dll to execute the program).

If you have the source for the DLL(s), then I suggest you compile those sources as static library instead, then, all the code will get bundled in the executable, dependence-free, but larger .exe file.

To get the normal out of a vertex on the edge of a 2D polygon, you take the vector that goes from the point just before to the point just after, and then you rotate that vector by 90 degrees ccw (right-hand rule). You can do that by swaping (x,y) with (-y,x). That's all! (it's actually the same as taking the cross-product, in 3D, with a vector pointing directly out of the 2D plane).

>>I can move getAtribDim to an ancestor class

Don't. This is a very clear case in which you should be using a free function, not a class member function. It is more scalable that way (like all standard <algorithm> functions).

I suggest you just make it a free function:

template <typename ForwardIter, typename T>
std::multiset<T> getAttribSet(ForwardIter first, ForwardIter last, 
                              T (typename std::iterator_traits<ForwardIter>::value_type)::*attr) {
  std::multiset<T> result;
  std::copy(first, last, std::inserter(result,result.end()));
  return result;
};

Definitely, Code::Blocks is recommended. It's the easiest one to download-install-setup-use with gcc (you should be able to pretty much compile and run a hello-world program within the minute following the install).

As for GCC, the stable recent versions are good. I think the current release of CodeBlocks comes with GCC 4.4, but the latest stable release is 4.5.2. I think that 4.4 should do fine if you are not doing heavy work or playing around with C++0x. If you are doing heavy work, it might be worth the trouble installing the latest MinGW (with GCC 4.5.2) separately from CodeBlocks (the version not packaged with MinGW), this is because there are significant compilation speed improvements between 4.4 and 4.5. Finally, if you are playing around with C++0x, then you would have to pretty much get the latest possible compiler there is (i.e. 4.6.0 or 4.7.0 (exp)) and compile from source (but they are not very stable, so you have to keep an earlier, stable version too for production code).

>>Am i wrong?

You are totally right. firstPerson's solution is not at all scalable. If you had more than one animation there would have to be a bunch of cases for each combination of simultaneous animations, or only one animation would run at a given time.

The only scalable solution is to reverse firstPerson's pattern, as you and I have suggested in our previous posts. In a simple object oriented design for a computer game, the rendering loop would look something like this:

void Game::Render() {
  double dt = /* calculate time since last frame */;

  ClearScreen(); //e.g. glClear(GL_COLOR_BUFFER | GL_DEPTH_BUFFER);

  //update the motion of camera and apply model-view and projection matrices. 
  mCamera->Render( dt ); 

  //iterate through visible objects and render them:
  for(std::vector<VisibleObject*>::iterator it = mObjList.begin(); it != mObjList.end(); ++it) 
    (*it)->Render( dt );

  SwapBuffer(hDC); //or similar.   
};

The above lets each object take care of tracking its own animation frames, this is scalable and decoupled, and thus, is the preferred option, instead of trying to manage all animations is some sort of centralized fashion, like firstPerson implied by his suggestion.

>>Can I build such a template?

You cannot. The reason this is a problem (and the reason for the errors) is because your function template, when instantiated with int, has to compile, all of it has to compile, including the parts that will not be executed (i.e. parts which insert elements that are not of type T). The compiler tries to compile it but it can't.

There are a few options.

First, you can specialize the function template for each type. As so:

class Voice
{
  public:
    template <typename T>
    std::multiset<T> getAtribDim(const std::vector<Voice>& v, std::string attr);
    int air_time;				// 115
    double charged_amount;			// 864
    std::string id_cell;			// "cell a"
};

template <>
std::multiset<int> Voice::getAtribDim<int>(const std::vector<Voice>& v, std::string attr);
{
  std::multiset<int> satrib;		//multiset
  for (std::vector<Voice>::const_iterator ci = v.begin(); ci != v.end(); ++ci) {
    if (attr == "air_time") {
      satrib.insert(ci->air_time);		//int member name
    } else if(//... for any other int-type attributes..
  }
  return satrib;
}


template <>
std::multiset<std::string> Voice::getAtribDim<std::string>(const std::vector<Voice>& v, std::string attr);
{
  std::multiset<std::string> satrib;		//multiset
  for (std::vector<Voice>::const_iterator ci = v.begin(); ci != v.end(); ++ci) {
    if (attr == "id_cell") {
      satrib.insert(ci->id_cell);		//string member name
    } else if(//... for any other string-type attributes..
  }
  return satrib;
}

//similarly for double and whatever else you have.

When you "call" the function template, it will instantiate only the appropriate specialization, and won't have trouble compiling it because all your inserts are of consistent type.

The other solution, which I think is much better, is to use a pointer …

If you are writing an FPS game, you are going to need some way of executing animations (i.e. things that move as a function of real-time), like for bullets, clouds, non-static objects, etc.. Once you integrate a means to do that, it shouldn't be a problem to implement a smooth crouching and standing (like a linear interpolation between the starting height (at starting time) to final height (at starting time + time for the animation), you can always make it more fancy, but this should do).

To integrate animations, I found that a very easy way to do it is to pass the current time (or delta-time) to the update() or render() functions of your visible objects (which I presume your first-person camera is, as it should be). You could have some interface or base-class to represent animations and some special code to deal with them, but I find that just passing a time parameter is the easiest (and more maintainable too). Static objects can just be rendered by ignoring this time parameter with minimal overhead, dynamic objects can be driven by the time parameter to create either animations or physical simulated motion, and user-controlled objects can use it when needed for some smooth transition animations.

The reason why the code keeps repeating the first value all the time is because the first value "9" is the largest one, so it will be moving up the array as you are traversing it.

If you want to print the original array, make a separate loop for that. Then, repeat the loop after the sorting to see the result.

The solution I posted does work. Here is the code:

#include <iostream>
#include <iomanip>

using namespace std;

int main() {

  double d = 1.23456;

  cout << "Default format: " << d << endl;
  cout << "Fixed format: " << fixed << d << endl;
  cout << "Fixed prec3 format: " << setprecision(3) << d << endl;
  cout.unsetf(ios_base::floatfield);
  cout << "Default format: " << setprecision(10) << d << endl;

  return 0;
};

//OUTPUT:
// Default format: 1.23456
// Fixed format: 1.234560
// Fixed prec3 format: 1.235
// Default format: 1.23456

You can use Boost.Tokenizer. It has nicer functions for extracting tokens from strings. You can, for instance, specify a list of characters that should be ignored and that mark the separation of tokens. This is the canonical example:

// char_sep_example_1.cpp
#include <iostream>
#include <boost/tokenizer.hpp>
#include <string>

int main()
{
  std::string str = ";;Hello|world||-foo--bar;yow;baz|";
  typedef boost::tokenizer<boost::char_separator<char> > tokenizer;
  tokenizer tokens(str, boost::char_separator<char>("-;|"));
  for (tokenizer::iterator tok_iter = tokens.begin();
       tok_iter != tokens.end(); ++tok_iter)
    std::cout << "<" << *tok_iter << "> ";
  std::cout << "\n";
  return 0;
}

There are also a few other nice features. For more complicated stuff, you can use Regex, but it might be overkill if you are just doing simple tokenizing.

Actually, setprecision() affects the stream, not just the next output. See this

Yeah, my bad. I confused it with setw(). That's what I get for being a smart*ss.

I think, however, that since setprecision will only give an upper-bound. If you don't use "fixed", then resetting precision to a large number (like 15), it should bring it back to a somewhat default behaviour.

NB: You can unset the "fixed" format by calling cout.unsetf(ios_base::floatfield); .

Compiler development is second only to operating system development as far as difficulty goes, in my opinion.

I concur.

Syntactically, they are very similar. But, I would say, the important differences are the things that are hidden in Java and for which you are responsible in C++. That includes:

- Cleaning up: C++ is not garbage collected. This means everything that you allocate with new has to eventually be deleted explicitly (with delete) when the memory is no longer needed (although experienced C++ programmers have much better tricks to manage memory which is typically far better than the vanilla solution of garbage collection in Java).

- Value-semantics: All variables, including objects, have value-semantics in C++. In Java, all objects just look like they are objects when really they are pointers to objects, but Java hides that fact from you (that is one of the things I hated the most when having to write Java code). In C++, if you want "reference-semantics", you have to do so explicitly in the code (by using references and pointers, and handling those correctly).

Then, of course, one of the major differences is the standard library. Be sure to explore this reference site to see the tools available in C++.

>>i will use c++ language ..

stick to a very simplified version of C. Don't even dream of using the C++ language as the language that your "compiler" will interpret (C++ is essentially the hardest major programming language to parse, very few good parsers for it exists and most C++ compilers are based the few that work).

Go with the simple calculator idea.

By the way, you have a memory leak in this queue class. I understand the garbage collector takes that responsibility off your back when in Java, but in C++, you are responsible for cleaning up your own mess, like grown-ups do. So, in the remove function, you need to delete the old head pointer sometime before you return from the function. As so:

void Queue::remove()
{
  if(size == 0) {
    cout << "Queue is empty \n";
  } else {
    DNode* garbage = head; //store the old head pointer. 
    if(size == 1)
      head = tail = 0;
    else
      head = head->getNext();
    --size;
    delete garbage; //delete the old head pointer.
  }
}

Also, line 31 and 37 are inverted. What you want is to set tail to be a pointer to the new node "n" not the other way around. N.B.: Be sure you understand the difference between reference-semantics that Java uses and value-semantics that C++ uses. In Java, these lines might have the behaviour you expect, but not in C++, because of value-semantics.

At line 39, you should just have "else" not an else-if.

Line 41 should disappear.

After line 55, you should have break; statement to get out of the loop, otherwise the new node will get inserted ad infinitum and the loop will never end.

That's all I can see. If you really want to move to C++, learn to use STL containers and algorithms instead. A priority queue is available there, btw (and …

It surely is legal. In fact, you need to have exactly one function named main() when you build an executable. So, if you have a main function in several cpp files, you are in trouble. Usually, cpp files which are associated with a class or a set of utility functions that you wrote, will not have a main function (unless it is a unit-test harness that is conditionally compiled only).

So, in order to be able to make an executable, the compiler will compile all those cpp files independently (called translation units) into object files (.o or .obj) and then put them all together (called linking). At the end of this process, it basically has one big chunk of compiled code linked together. It then looks through that chunk of code of a main() function to use as the "entry-point" of the executable. If it does not find one and exactly one main() function, it will give an error.

The typical setup is to have the main function in its own cpp file and do as ravenous laid out, compile a list of cpp files that includes the "library" cpp files and the one "application" cpp file (main.cpp or something like that).

For unit-testing, it is typical to add a main function at the end of each cpp file that is a simple test program that calls and tests every function in your cpp file. But, in this case, you have to enclose it in a #ifdef …

You should start by defining the language that you will be "compiling".

You need to define the types that you will use.

Then, define the operators (+ - = * / etc.).

And then, define some standard functions like print and scan.

I would suggest you use a simple subset of C.

Then, start by writing a parser that will look for the different tokens (type names, operator symbols, standard functions names, etc.). Try to identify the tokens and see how well it does by taking a simple code in your programming language and printing out the list of tokens you find it in, with their identification as a variable, operation, function call, etc.

then....

If you are just interested in visualising a graph, why not use graphviz? It's a library dedicated to that very purpose. It will probably be easier to just shoot your graph structure into the graphviz functions and get some image files out, instead of using a full GUI tool.

Either that code is _very_ incomplete, or it is not valid C++ code (i.e. just a guideline example that doesn't really work or compile, but just gives an idea of the process).

No doubt, the easiest language to write a compiler for is Brainf*ck. Writing an interpreter for this language is probably gonna require less lines of code that the "Hello World" program in Brainf*ck.

I doubt very much that your teacher is really expecting you to write a "real" compiler in the sense that is produces machine code, because that requires much more than a theoretical idea of the inner workings of a compiler, it requires to know very low-level details about how to set up application loading and entry points and things like that. I'm guessing he is expecting you to right a kind of virtual machine that interprets and executes a simple program.

You should start incrementally. I would suggest you restrict the domain of your language. For example, if you restrict the domain to simple numerical computing, then you can basically just write a glorified calculator.

I would suggest you start by writing a simple calculator that can parse and compute mathematical expressions (a = b + 4 * c) or something like that. Then add mathematical functions (sin, cos, pow, etc.). I would probably recommend that you use implicit types, this way you can assume all types are floating-point values (and round them if they ought to be integers).

When that is done, you can add things like arrays and loops. if-statements shouldn't be so hard either.

You should also make your "standard library" as simple as possible, just a few functions like "getUserInput(a)" to fill the variable "a" with some user input and similarly a "print(b)" to print the value of b to the console.

Your "compiler" should probably just parse / tokenize the …

@AD>>..C++ programs are pretty much operating system specific.
What on Earth are you talking about? There are robust cross-platform libraries for everything in C++ (you just have to stay clear of anything that bares the name Microsoft or Apple). The amount of platforms you can target with platform-independent code in C++ far exceeds anything found with Java. Not to mention that massively multi-threaded or parallel programming in C++ has far more powerful frameworks and better speed (e.g. TBB, OpenMP, OpenCL, CUDA, and to some extent C++0x).

@OP:
I have to admit, I never really understood the need for frameworks specifically targeted for ABM. It's so trivial to implement from scratch in C++ (or any other proper language), when you have the proper skills. I have done it a few times. But I did look around a bit and found EcoLab that is free and seems reasonable. Not surprisingly, the code-base is small (25k lines of code) (as I said, it is pretty trivial to implement). My guess as to why there are vastly more Java implementations is because ABM is more of an academic topic and academics (even though I am one) seem to cling to toy-languages like Java (sorry for the ranting.. couldn't help it).

EcoLab: Seems pretty good, it's C++ and TLC, and seems fairly recently maintained (2010).

line 56 is a simple typo. You declared and set a variable named checkWaitResult a few lines before but then use dwWaitResult. You just need have the same name in both uses.

line 139 is reversed. When you use = sign, it stores whatever is on the right into the variable on the left. You have the statement reversed, your abc_output should be on the left and the function call on the right.

It seems like you are pretty much done, you just have to fix lines 60 and 61 to:

cout << "Driver: "; driver->print();
cout << "Owner: "; owner->print();