Posts by Dogtree

bjam "-sTOOLS=borland" install

How is that weird? cin's >> operator is overloaded for plenty of different types. If you include <string>, that includes the std::string class.

>thats the latest 1 available
That's funny, Borland offers their 5.5 compiler for free download. And if you're willing to pay money, you can get the newer versions. ;)

Did you recently switch to a new operating system? Like from DOS to Windows XP? :rolleyes: A bunch of people try to use old ass versions of a C++ compiler and wonder why they don't work well with a latest-and-greatest OS. I think Borland's C++ compiler is up to version 10, so you're just a smidge behind the times and it's no surprise that you're having issues. I'm sorry to be the bearer of bad news, but what you should do is upgrade your compiler and update your programs so that they work properly on your platform.

>> I thought cin.get() didn't work with strings... or am I wrong?
What kind of strings are you talking about? C++ supports two types of strings: the C-style string that's just an array of char terminated by '\0', and the std::string class. You're correct if you mean the std::string class, otherwise you're wrong. cin.get() is overloaded with the same signature and functionality as cin.getline(), with the one obvious difference that cin.get() does not extract the delimiter character from the stream while cin.getline() does.

An access violation means your code is broken. Post the relevant parts of your attempt and we can probably help you fix the problem.

>> I tried using the sizeof operator as suggested above.
Don't bother, it won't work.

>> Pls tell me how can I get the number of elements stored in a dynamic array using them?
The only way to get the size of a dynamic array is to save the size when you allocate memory. The only way to get the size of an array parameter is to pass the size as another parameter:

// Get the size of a dynamic array
char *p = new char[10];
int sz = 10; // Save the size!

// Get the size of an array parameter
void foo(char array[], int size); // Pass the size!

>> I donot know the usage of std::vector or boost::array.
That's not a good excuse. ;) If you don't know the usage of a feature but you clearly need it, then it's time to learn. It's almost always better to use a container class than it is to use arrays anyway. Arrays are error prone while container classes work hard to protect you from those potential errors.

>> Is it?
String is not, unless you define it yourself, std::string is a class in the standard library.

>Moron!
I'm not the one who came to a programming help forum asking other programmers to work for free.

>I came to this place for help and to learn obviously noone wants to help.
We don't offer the kind of help you want here. There's nothing I can do about that. So instead of calling me names because you don't like the answer you got, take my suggestion and go hire someone. You'll probably get a better program out of it. If you want to continue hanging around here insulting us, I'll consider you a troll and recommend that you be banned.

Have a nice day.

This is a forum for programming help, not for hiring programmers. If you want someone to write this for you then you can get someone cheap at www.rentacoder.com. It's pretty clear that you have no intention of learning to program to get this working, so your thread is off-topic.

No offense, though it will seem that way, but if you're incapable of even starting this then you probably haven't been paying attention in class. Why should we work to help you when all you seem to want is a handout?

http://msdn.microsoft.com/

>> Just make it this and it will work (i think)
No offense, but when you're guessing, you're not helping. Most of the time a guess is either grievously wrong, or has subtle problems.

>> so stop criticizing people
It's called constructive criticism. If you don't want to learn then don't bother trying to help because you'll just give bad advice. If you think you know everything then don't bother trying to help because you'll probably give bad advice and then turn the thread into a flame war when someone who knows better corrects you.

>> The easiest way to get the length of a dynamic array is this
Is it? Forget about the 'array' part and look closely at the 'dynamic' part. A dynamic array is not an array, it's a pointer to a block of memory that can be subscripted like an array:

#include <iostream>

#define length(x) (sizeof(x) / sizeof(*(x)))

void foo(int a[])
{
  std::cout << "From foo(): " << length(a) << '\n';
}

int main()
{
  int *a = new int[10];
  int b[10];

  std::cout << "From main(): " << length(a) << '\n';
  foo(b);
}

So the sizeof trick just breaks silently when you use it on a dynamic array, or an array passed as a function parameter. Templates are a better solution because they complain when you pass a pointer and not an array:

#include <iostream>

template <typename T, int sz>
char (&array(T(&)[sz]))[sz];

void foo(int a[])
{
  std::cout << "From foo(): " << sizeof array(a) << '\n';
}

int main()
{
  int *a = new int[10];
  int b[10];

  std::cout << "From main(): " << sizeof array(a) << '\n';
  foo(b);
}

The rule of thumb is that if you want the size of a dynamic array, you save it! If you want the size of an array parameter, you pass it! Anyone who doesn't know these rules or isn't comfortable with them would be better off using a smart container like std::vector or boost::array.

Look slick, I was very politely helping you out. If you want to get all insulted over nothing and turn it into a flame war then I'll be happy to rip you a new one. Despite how lamers like you think, not everyone is out to get you. And WTF is this about sarcastic comments? If I'm being sarcastic, you'll know it, because it will be obvious, scathing, and meant to make you feel like the ignorant noob that you are. I'm not subtle when I get mean, so go crawl back into your hole and don't return until you can take polite, helpful advice in the spirit that it was given. You think I take time out of my busy day to listen to people like you bitch about imagined insults? No, I'm here to help, and if you can't understand that, or if you're looking for a fight, go somewhere else. I don't have time to listen to your ignorant and unsophisticated flames of a post that wasn't provocative in the slightest.

If you think I was being insulting in my last post then your frail constitution won't be able to handle most of the posters out there, so you might as well just turn around and go away until you can handle it.

Basically, yea. :) But you don't have to use a string representation, you can use whatever you want as long as it's POD.

As far as I know, the only way to get a 64-bit time_t on Solaris would be to use a 64-bit version of Solaris. As for third party libraries, I don't know of any without a thorough web search, but I would be surprised if sourceforge and friends didn't provide one. boost::date_time can handle what you want, but that's kind of like using std::string to handle the work for your own String class, no? ;)

The diagnosis is accurate for the most part. Shared memory can't handle non-POD types. You could write a special purpose allocator for your standard containers, and unshared proxy objects that refer to a reasonable representation of the data in shared memory for everything else. I don't have a lot of experience with shared memory, so I won't try to give you code because it would be hopelessly broken. But this is a good problem to solve with threads rather than IPC and processes. ;)

I imagine that the proxy solution would be the easiest for you. You can serialize the data into, say, a C-style string representation for storage in shared memory, and the proxy class would be able to represent it as whatever object you need when you need it for a minor conversion cost. Here's a crude example for std::string:

class string_proxy {
  std::string _str;
  char *_mem;
public:
  std::string_proxy(char *addr): _mem(addr) {}
  std::string& get() { _str.assign(_mem); }
  void serialize()
  {
    memcpy(_mem, _str.c_str(), _str.size() + 1);
  }
};

With std::string and other standard containers you can write a custom allocator that knows about the shared memory and doesn't make your system cry when you use it. But that's harder, and depends heavily on knowing what you're doing with the shared memory library, which I don't, so I won't show you code. ;)

If you really need dates beyond 2038, you have no choice but to avoid time_t and the standard functions, which means either hand coding the algorithms or using a third party library. That's the solution that people use when they need very old dates (where they discover the "Satan's armpit" of pre-gregorian calendar dates) or long predictions of the future. But for most uses of dates, you can play the wait game and the problem with fix itself when your implementation converts to 64-bit time_t's or your application stops being used. ;)

You're calling the default constructor, not the two argument constructor:

#include <iostream>
#include <string>

using namespace std;

class baseType
{
public:

  void decToBase(int num, int base);
  void print();
  baseType(int b, int d);
  baseType();

private:

  int decimalNum;
  int base;
};

int main()
{
  int d;
  int b;

  cout << "Enter number in decimal and the Base to Convert: ";
  cin >> d >> b;
  baseType myBase(b, d);
  cout << endl;
  myBase.decToBase(d, b);
  myBase.print();

  return 0;
}

void baseType::print()
{
  cout << "Decimal " << decimalNum << " = ";
  //	decToBase(decimalNum, base);
  cout << " in Base " << base << endl;
}

void baseType::decToBase(int num, int base)
{
  if (num > 0)
  {
    string digit="0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";
    decToBase(num / base, base);
    cout << digit[num % base];
  }
}

baseType::baseType(int b, int d)
{
  base = b;
  decimalNum = d;
}

baseType::baseType()
{
  decimalNum = 0;
  base = 0;
}

PM me with the threads you're talking about and I'll see what I can do.

>> My thought is that if they didn't want me to close it, they would have made the close function private or protected.
So you always use the open function too even though the constructor provides that functionality?

std::fstream file;

file.open(filename);

// ...

file.close();

If they didn't want you to open the file then they wouldn't have made it public. Since you're adding redundant code for no reason, you might as well make it explicitly symmetrical. ;)

Yes, I'm mocking you. No, it's not personal. No, it's not a flame or an insult, so don't take it as such.

I agree, but only if the fstream object doesn't go out of scope before opening another. There's no need to close the stream if this is your code:

int main(int argc, char **argv)
{
  for (int i = 1; i < argc; i++) {
    fstream file(argv[i]);

    if (!file) continue;

    // Process the file
  }
}

There's no way that you can have more than one stream open at the same time because the destructor is called after each iteration of the loop. The destructor will flush unwritten output and close the stream properly. The only reason you would have for calling close explicitly is if you reuse the fstream object for another file, have enough fstream objects to reach an implementation limit of open files, or the fstream object will be unused, but still in scope for a while after processing the file.

But if you like the extra typing and redundant code, who am I to stop you? Some people prefer to close their file streams explicitly as a matter of style.

>> while ( ! file.eof() )
You shouldn't use <stream>.eof() as a loop condition. Because the eofbit is only set after a request for input has failed, you'll increment the counter once more than necessary if the last line contains the search string. A better way to read input is to use the return value of your input function:

while (getline(file, buffer)) {
  if (buffer.find(string1) != string::npos)
    ++counter;
}

>> if ( buffer.find( string1 ) != -1)
Okay, this is a subtle error. string::npos is defined as (size_t)-1, which is not the same as -1. Your test may or may not work as written, so you should use string::npos directly for tests such as this one.

>> file.close();
There's no need to close an fstream explicitly if the destructor is going to be called. Just FYI.

>> I guess this would be helpful
No, not a bit. Your code is wrong.

>> for (n=0;inp[n];n++)
Assuming that n was defined somewhere, the test for imp[n] against 0 is dngerous because imp is uninitialized. There could be a null character straight away, or 5000 characters later. You're really risking an access violation with this loop.

>> char *arr = new char [sizeof(char)];
This alloctes memory for one char. sizeof(char) is guaranteed to return 1, everywhere, without fail. That's one of the few absolutes when it comes to type sizes in C++.

>> for (n=0;arr[n];n++)
You have the same problem here as the previous loop.

Yes, your idea is valid assuming there's some sentinel value at the end of the array to stop the loop on. With the original question that's difficult because any string object is valid in the general case. That's probably why you took it upon yourself to change the example to char so that you could use a null character as the sentinel.

The best solution is to avoid using arrays in the first place because they're unsafe and most people don't understand them well enough to avoid the pitfalls, as displayed by your flawed example. The std::vector class provides a good container that grows dynamically.

Think about it like this. Base 2 has two digits, 0 and 1. Base 8 has eight digits, 0 through 7. Base 10 has 0 through 9, and base 16 has 0 through 10 including the first six letters of the alphabet. In other words, the number of digits matches the base. If you want base 36, take note that there are 26 letters in the latin alphabet, and ten decimal digits. The total is 36, so at the very least you need to add that to your function to represent base 36.

>> what must be added to convert between 2 and 36?
How about using all letters of the latin alphabet rather than just the first 6?

All the more reason to read the forum titles carefully. For example, a good first stop for your question would be under the Hardware forum. There you might see a Peripherals forum which further specializes the category that you should post under to get a quick and knowledgeable answer to your question. I don't imagine that the DVD-R experts will be looking under Daniweb News and Feedback for DVD-R questions, just like I don't go to the Community Introductions forum looking for C++ questions.

Maybe it's just me, but it seems like everyone is trying to post in the forum that is least topical to their question.

typedef struct Dictionary* DictionaryRef;
I don't like hiding pointers with typedef. It's confusing to readers and maintenance programmers. You would be better off just using Dictionary *.

void delete(DictionaryRef D, int k);
Deletion in a hash table isn't trivial unless you use separate chaining. However, your comment suggests that you're supposed to use some variation of linear probing, so I'll assume that's what you want and show you deletion using a DELETED status.

lookup is just taking a hash of the key and checking that location to see if it's empty. If not, you go to the next location and do the same test. Repeat until you get back to where you started, in which case the key isn't found:

int lookup(Dictionary *dict, int key)
{
  unsigned start = hash(key);

  if (dict->dict[start].status == FULL && key == dict->dict[start].key)
    return dict->dict[start].value;
  else {
    /* Linear probe until found or back at start */
    unsigned probe = start == DICT_SIZE - 1 ? 0 : start + 1;

    while (probe != start) {
      if (dict->dict[probe].status == FULL && key == dict->dict[probe].key)
        return dict->dict[probe].value;
      if (++probe == DICT_SIZE) probe = 0;
    }

    return UNDEF;
  }
}

The tricky part is making sure that you don't go around and around in an infinite loop. Deletion is just a variant of lookup where instead of returning the value, you mark the status as DELETED so that it won't effect future insertions, but still won't be treated as …

>> i cant clearly get to ur point
That's probably because the answer was assuming C++ when you clearly stated C. Arrays are just a bunch of blocks of memory strung together; you can fake a multidimensional array using a single dimensional array easily:

#include <stdio.h>
#include <string.h>

int main(void)
{
  char a[60] = "hello";

  strcat(a, " welcome");
  strcat(a, " goodnite");

  puts(a);

  return 0;
}

Or, instead of doing it all manually, you could write a function do to it for you:

#include <stdio.h>
#include <stdarg.h>
#include <string.h>

/* addstr assumes dst points to enough memory
   and the vararg list ends with NULL */
char *addstr(char *dst, ...)
{
  va_list args;
  char *p;

  va_start(args, dst);

  while ((p = va_arg(args, char *)) != NULL)
    strcat(dst, p);

  va_end(args);

  return dst;
}

int main(void)
{
  char a[60] = "";

  addstr(a, "hello", " welcome", " goodnite", NULL);
  puts(a);

  return 0;
}

And of course, if you think you might forget to tag NULL on the end of every call to addstr, you can change it to use an explicit size:

#include <stdio.h>
#include <stdarg.h>
#include <string.h>

char *addstr(char *dst, int n, ...)
{
  va_list args;

  va_start(args, n);

  while (--n >= 0)
    strcat(dst, va_arg(args, char *));

  va_end(args);

  return dst;
}

int main(void)
{
  char a[60] = "";

  addstr(a, 3, "hello", " welcome", " goodnite");
  puts(a);

  return 0;
}

And of course, error checking is a good thing to add, especially for a function with such high risk of buffer overflow:

>> Theres not much diff between the 2.
Only if you limit yourself to a tiny subset of C++ and use poor style in C. When used correctly and to their fullest, there's a huge difference between C and C++.

>> plus what u use in c can be easily implemented in c++
Most of what you write in C++ can be more easily implemented in Java, or C#, or Perl, or Python, or just about any other language suited to general purpose use. However, none of those languages, including C++, can be used for some systems. For example, there are embedded architectures that lack the resources for a C++ compiler and have no choice but to rely on C or end up using assembly. Such programs are not easily implemented in C++.

>> and c is dated ... so might as well keep c with c++...
That's not a logical argument, dude. If C is dated then it should go in the Legacy Languages forum, not lumped together with C++. And what about C++? It's not any less dated, approaching 30 years. But dated doesn't mean useless or unused. Look at FORTRAN, or COBOL. They're "dead" languages, but still used a lot if you know where to look. The C community is thriving, almost as much as the C++ community. If you don't believe that then look at the activity on the comp.lang.c, comp.lang.c.moderated, and comp.std.c newsgroups. They're active post for post with comp.lang.c++, …

<iostream.h> is not standard, and therefore is becoming increasingly less supported by compilers as standard C++ matures. This isn't a theoretical difference, by the way. My compiler will refuse to compile <iostream.h>.

>> Why?
Why not? It's concievable that there would be a default precision for the stream, one that would be valid everywhere so that it could be portable. It just so happens that that's the case. The default is 6:

#include <iostream>

int main()
{
  double d = 123.4567890123;

  std::cout << "Precision: " << std::cout.precision() << '\n';
  std::cout << "Value: " << d << '\n';
  std::cout.precision(4);
  std::cout << "Value: " << d << '\n';
}

>> i want it to be say for example 8 or 10 decimal places
Assuming your system is capable of holding an accurate precision to 10 digits past the radix including an arbitrary number of digits before the radix, you would do it like this:

#include <iostream>

int main()
{
  double x = 2.3767553235;

  std::cout.precision(11);
  std::cout << x << '\n';
}

However, because the precision is all digits in the number, to get an exact precision of 10 for any whole value, you would need a way to determine the number of digits before the radix. An easy to understand solution is to make a string and take its length:

#include <iostream>
#include <sstream>

namespace jrd {
  int digits(double val)
  {
    std::ostringstream oss;

    oss << static_cast<int>(val);

    return oss.str().length();
  }
}

int main()
{
  double x = 2.3767553235;

  std::cout.precision(10 + jrd::digits(x));
  std::cout << x << '\n';
}

>> Randomize(); //Required in Borland C++
How about srand instead? That's available everywhere:

#include <cstdlib>
#include <ctime>
#include <iostream>

int main()
{
  std::srand(static_cast<unsigned>(std::time(0)));

  // Generate 10 rolls of a 6 sided die
  for (int i = 0; i < 10; i++)
    std::cout << std::rand() % 6 + 1 << '\n';
}

On some older compilers, using modulus with rand will give you horrible sequences unless the value comes close to RAND_MAX, in this case 6 isn't even close to close. ;) So you'll see this trick as a workaround:

#include <cstdlib>
#include <ctime>
#include <iostream>

int main()
{
  std::srand(static_cast<unsigned>(std::time(0)));

  // Generate 10 rolls of a 6 sided die
  for (int i = 0; i < 10; i++) {
    int r = int((double(std::rand()) / RAND_MAX) * 6 + 1);
    std::cout << r << '\n';
  }
}

Post some complete code that breaks under Dev-C++. It looks like you wrote what you think is the same thing as the relevant parts of the program, but since the code you posted won't compile even after removing the .... parts and adding necessary headers.

And rule #1 when your code works on one compiler but not another: It's almost always your fault. You would do better to assume that your code is wrong rather than an inherent problem with the compiler.

By its definition, the postfix increment operator has to use temporary storage so that it can return the pre-incremented value. You can think of it like this:

operator++
  temp = self;
  self = self + 1;
  return temp;

Optimizations can make it close to atomic for all cases of built-in types, or atomic for some cases of some built-in types, but in the general case, it's not gonna happen. :)

In general, no.

I've noticed two strange things with my sound card when it comes to using a microphone. Using multiple microphones, they work, but the result is very very quiet. Also, the plugs are are very loose when seated in the microphone socket. Without going into detailed troubleshooting, has anyone seen these two problems before? :)

>> For the timmer try writting TSR's.
A TSR is only relevant for DOS and other single-tasking operating systems. In a modern OS you would use either threads or separate processes.

>> can anyone tell me what are the real time applications of C.?
Take a look at any application you use. Chances are good that it's written in C, written in a language implemented in C, or written in a language derived from C.

>> Why do I need to specify the datatype?
It's a definition. Any valid definition is also a valid declaration, and standard C++ disallows implicit int declarations.

>> The syntax looks to me as if it is supposed to return an int rather than that it IS an int..
How does an object return anything? It might evaluate to something, but only after its definition during use.

>> Also, why do I not need to on Solaris Workshop compiler?
It's either pre-standard implicit int, where if a type is needed, int is assumed, or it's a compiler extension. I would guess the former.

You forgot the type:

int CommandLineArg::longestDescr=0;

A list of filenames is very different from an array of file contents. The former is very easy and becomes harder as you get lower level. A vector of strings is best:

#include <string>
#include <vector>

std::vector<std::string> v;

v.push_back("doit.dsp");
v.push_back("doit2.dsw");
v.push_back("doit3.cpp");

Followed by a boost array of strings:

#include <string>
#include <boost/array.hpp>

boost::array<std::string, 3> a;

a[0] = "doit.dsp";
a[1] = "doit.dsw";
a[2] = "doit.cpp";

Then an array of strings:

#include <string>

std::string a[3];

a[0] = "doit.dsp";
a[1] = "doit.dsw";
a[2] = "doit.cpp";

Then an array of arrays of char:

#include <cstring>

char a[3][9];

strcpy(a[0], "doit.dsp");
strcpy(a[1], "doit.dsw");
strcpy(a[2], "doit.cpp");

Then lastly, an array of pointers to char:

#include <cstring>

char *a[3];

a[0] = new char*[9];
strcpy(a[0], "doit.dsp");
a[1] = new char*[9];
strcpy(a[1], "doit.dsw");
a[2] = new char*[9];
strcpy(a[2], "doit.cpp");

// ...

delete [] a[2];
delete [] a[1];
delete [] a[0];

Is that what you're trying to do? Because I'm getting mixed messages. ;)

You have to be careful since .dsp and .dsw files are binary if I remember right. That limits you to a container of unsigned char and unformatted binary input:

std::vector<unsigned char> v;
unsigned char c;

std::ifstream s1("doit.dsp", std::ios::binary);

while (s1.get(c))
  v.push_back(c);

Anything else risks undefined behavior or unwanted character conversions. Can you be more specific about what you're trying to do?

There's really no way I could have hinted how to define the operators and call sort that would be useful without giving code. Don't worry, if possible I try not to solve other people's problems. ;) I also didn't give it to you on a silver platter. There are multiple ways to do something, some better than others, and you would still have to piece it all together even if you did use the exact code I gave.

>> Why do people like you, Narue, Dave,... make it all look so simple
We make it look simple because we worked really hard to learn it, just like you're doing now.

>> Define a class "point" with two datamembers, x and y.

struct point {
  int x, y;
};

>> Use the STL-container vector to stack a row of point-objects.

#include <vector>

std::vector<point> points;

>> Enter them by using the keyboard by two(pairs), x and y.
>> Use a non numeric character to stop the input of the (pairs) x and y.

while (std::cin.peek() != 'q') {
  point item;
  int x, y;

  if (!(std::cin >> x >> y))
    break;

  item.x = x;
  item.y = y;

  points.push_back(item);
}

>> Define the operators == and < for two point-objects

bool operator==(const point& a, const point& b)
{
  return a.x == b.x && a.y == b.y;
}

bool operator<(const point& a, const point& b)
{
  return a.x < b.x || (a.x == b.x && a.y < b.y);
}

>> Use the STL-algorithm 'sort' to sort the previous entered (pairs) x and y
>> by using the defined order operator <.
std::sort uses operator< by default, so you can simply do this:

std::sort(points.begin(), points.end());

You can omit the array size for the first dimension because array names are almost always converted to a pointer to the first element, so any size information is lost. That feature only applies to the first dimension, so you have to provide size information for the second dimension because the conversion to a pointer makes it a pointer to an array of N. These two function declarations are equivalent:

void foo(int a[][10]);
void bar(int (*a)[10]);

To avoid those errors, you can always provide sizes for all dimensions until you're comfortable with the rules. However, for arbitrary sizes in all dimensions, you have no choice but to use a dynamic array:

void foo(int **a, int m, int n);

int main()
{
  int **a = new int*[5];

  for (int i = 0; i < 5; i++)
    a[i] = new int[5];

  foo(a, 5, 5);

  for (int i = 0; i < 5; i++)
    delete [] a[i];
  delete [] a;
}

Of course, that's assuming you don't have libraries to work with. The standard vector class is well suited to this:

#include <vector>

void foo(std::vector<std::vector<int> > a);

The boost library also supports a multi_array class.

>> while (cin>> x >>" ">> y, !cin.fail())
Since you already know what the problem was, I'll tell you why it's a problem, just to be thorough. cin >> is strictly for formatted input. It doesn't accept formatting strings and it already skips whitespace by default. If you want to skip precise strings then you can do this (nonportable):

#include <iostream>

namespace std {
  template <typename CharT, typename Traits>
  basic_istream<CharT, Traits>&
    operator>>(basic_istream<CharT, Traits>& in, const char *fmt)
  {
    while (in.good() && *fmt != '\0') {
      if (in.get() != *fmt++)
        in.setstate(ios::failbit);
    }

    return in;
  }
}

int main()
{
  int a, b;

  std::cout << "Enter two numbers separated by =-=: ";
  std::cin >> a >> "=-=" >> b;
  std::cout << "a: " << a << '\n' << "b: " << b << '\n';
}

It's not portable because you technically aren't allowed to add stuff to the std namespace. You can do it portably by writing a manipulator:

#include <iostream>

class skip {
  const char *_fmt;
public:
  skip(const char *fmt): _fmt(fmt) {}

  template <typename CharT, typename Traits>
  friend std::basic_istream<CharT, Traits>&
    operator>>(std::basic_istream<CharT, Traits>& in, const skip& sk)
  {
    const char *tmp = sk._fmt;

    while (in.good() && *tmp != '\0') {
      if (in.get() != *tmp++)
        in.setstate(std::ios::failbit);
    }

    return in;
  }
};

int main()
{
  int a, b;

  std::cout << "Enter two numbers separated by =-=: ";
  std::cin >> a >> skip("=-=") >> b;
  std::cout << "a: " << a << '\n' << "b: " << b << '\n';
}

But …

You know, these statements are easier to believe when you can write coherent English and provide objective arguments. You haven't done either, so you can only expect to be treated as a troll.

NORTH, NORTHEAST, SOUTH, and SOUTHEAST are all integral values, probably members of an enum, possibly #define's. The switch is keyed on the getSrcDir() member of path, which returns one of those integral values. It's basically an abstracted version of this:

int dir;

// ...

switch (dir) {
  case 0: /* Do north */ break;
  case 1: /* Do NE     */ break;
  case 2: /* Do south */ break;
  case 3: /* Do SE     */ break;
}