Posts by Narue

>So when i declare a local variable inside a function,
>it will be disposed from the memory automatically?
Yes.

>And i should dispose it myself if i create it using malloc?
Yes.

You only need to explicitly free resources that you explicitly ask for. For example, a FILE* given to you by fopen needs to be closed, and a pointer given to you by malloc needs to be freed.

>If you have to use array notation, also consider
>using a static variable instead of a parameter
That's a horrible suggestion. You've managed with one change to ruin the function's flexibility, potential error handling, actual error handling, and thread safety. Congratulations, this gets my vote for the most damaging minor change of the week award.

p.s. Your code is broken, so I mentally changed it to this:

void enter(int *p_arr)
{
  static int i = 0;
  int insert;
  printf("\nplease enter the number:");
  scanf("%d", &insert);
  p_arr[i++]=insert;
}

>depends on the pass if its the first pass then 0, if second then 1, e.c.t...
Bzzt! Wrong. The correct answer is "I don't know". Though I would have accepted "indeterminate" as well. Technically you don't need i at all in that function because you pass the address of the correct array element:

void enter(int *p_arr)
{
  int insert;
  printf("\nplease enter the number:");
  scanf("%d", &insert);
  *p_arr=insert;
}

However, because you use p_arr where i is indeterminate (usually this means a large number), then you're pretty sure to index the array well out of its bounds.

If you want to continue using array notation, this will solve the problem immediately (though it's technically identical to my previous fix):

void enter(int *p_arr)
{
  int i = 0;
  int insert;
  printf("\nplease enter the number:");
  scanf("%d", &insert);
  p_arr[i]=insert;
}

Note that i is always 0, because p_arr always points to the element you want to initialize. You can also change your logic as Aia suggested such that the index actually makes sense:

int main()
{
  int arr[5];
  int i;

  for ( i = 0; i < COUNT; i++ )
    enter ( arr, i );

  report ( arr, COUNT );

  return 0;
}   

void enter ( int *p_arr, int i )
{
  int insert;

  printf ( "\nplease enter the number:" );
  scanf ( "%d", &insert );
  p_arr[i] = insert;
}

There are two forms of getline that concern you in this case. The first is a member function of cin:

char buffer[BUFSIZE];

cin.getline ( buffer, sizeof buffer );

Note that the argument is an array of char, and the maximum number of characters you want to fill it with. The second is a non-member function for the std::string class:

string bufferl

getline ( cin, buffer );

You're mixing those two up by passing a std::string object to the member function, but no such overload for std::string exists. Thus, you need to use the non-member function if you want to continue using the std::string class:

bool enterPlans(RememberPlans& nds)
{
    cout << "This program creates lesson plan documents.\nType export to view and export the the plans.\n\n";
    cout << "Enter subject: ";
    getline(cin, nds.subject);

    if(nds.subject == "export" || nds.subject == "EXPORT")
    {
        return false;
    }

    cout << "\nEnter date: ";
    getline(cin, nds.date);

    cout << "\nEnter resources (seperate with '-'): ";
    getline(cin, nds.resources);

    cout << "\nEnter a brief descrition: ";
    getline(cin, nds.description);	

    cout << "\n";
    system("CLS");

    return true;
}

>p_arr=insert;
Tell me the value of i in this line of code.

I assume you're using system ( "PAUSE" ) . My first inclination is to say that this solution is a bad idea anyway, and if it doesn't do exactly what you want, that's all the better for convincing you not to use it. :D

The usual recommendation for pausing a program from an IDE that terminates the hosting console when the program ends is to ask for input. For example, the following code won't terminate until you press the Enter key:

#include <iostream>

int main()
{
  std::cout<<"Hello, world!\n";
  std::cin.get();
}

You'll eventually have problems with existing data in the stream causing this not to work, but we have a sticky on this forum that teaches you how to deal with that.

>Is there something wrong in my understanding.
Probably. You're still doing the same thing as your first program. The value of out comes from vector::operator==, not is_equal. Compare:

#include <iostream>
#include <vector>

int main ()
{
  const int init1[] = {1000, 1, 0, 0};
  const int init2[] = {1000, 1};

  std::vector<int> vector1 ( init1, init1 + 4 );
  std::vector<int> vector2 ( init2, init2 + 2 );
  bool is_equal = false;

  if ( vector1.size() < vector2.size() )
    is_equal = std::equal ( vector1.begin(), vector1.end(), vector2.begin() );
  else
    is_equal = std::equal ( vector2.begin(), vector2.end(), vector1.begin() );

  std::cout<<"operator==: "<< ( vector1 == vector2 ) <<'\n';
  std::cout<<"std::equal: "<< is_equal <<'\n';
}

strcmp and friends already do a case sensitive comparison. It's easy to write a function that does a case insensitive comparison; it's just the same algorithm but with tolower or toupper matching the case:

int nocase_strcmp ( const char *a, const char *b )
{
  while ( tolower ( *a ) == tolower ( *b ) ) {
    if ( *a == '\0' )
      break;

    ++a;
    ++b;
  }

  return *a - *b;
}

So you want them to compare equal based on the length of the shorter vector? std::vector's operator== basically uses a test to see if the lengths match, then calls std::equal. You can manually call std::equal and skip the length check:

bool is_equal = false;

if ( vector1.size() < vector2.size() )
  is_equal = std::equal ( vector1.begin(), vector1.end(), vector2.begin() );
else
  is_equal = std::equal ( vector2.begin(), vector2.end(), vector1.begin() );

I'm not sure I understand what you want to do, but even more so I don't understand why you want to do it. Can you be more specific? I'm guessing you're trying to solve a non-issue.

>I'm not sure why you would number them
I probably wouldn't number them, but you were entering into a disturbing pattern where I would end up listing them constantly:

You: "Can you tell me where pointers are useful?"
Me: "Linked data structures."
You: "You can tell me another place where pointers are useful?"

Clearly that would go on and on until you were satisfied, at the cost of my sanity.

>I just didn't know if the implementation of classes and object
>oriented programming in C++ made them obsolete.
Wrapping something in a class doesn't make it go away. You can have a linked list class, but it's still a linked list and quite likely will use pointers in the implementation. A class is there for notational convenience, it doesn't change how things work under the hood.

The only real difference between a linked list class and a C-style linked list library is how client code uses it, so suggesting that classes and object oriented programming make linked lists obsolete is nonsensical.

>Also, I'm moving from VB and assembly to C++, so obviously a lot
>of the concepts are going to be hard to grasp at first
Feh, if you know assembly then pointers should be a breeze. The instruction pointer and stack pointer are both prime examples of an address pointer and pointer arithmetic. You also know about indirection through effective addressing to offset a base address. Unless …

Most of the functions in the stdio library will take a pointer to FILE. scanf and printf assume stdin and stdout, respectively, so you might not have had cause to jump to something like fscanf and fprintf. The idea is to open the file and close the file, but in between use it just as you would stdin, stdout, or stderr:

#include <stdio.h>

int main ( void )
{
  FILE *out = fopen("myfile", "w");

  /* fopen returns NULL if it can't open the file */
  if ( out != NULL ) {
    char buffer[BUFSIZ];

    /* Read from stdin and write to out */
    while ( fgets ( buffer, sizeof buffer, stdin ) != NULL )
      fputs ( buffer, out );
    
    /* Always close the file! */
    fclose ( out );
  }

  return 0;
}

>For implementing run time polymorphism you use pointers .
Or references, but in reality references are just restricted pointers with a more convenient syntax.

Since I'm so nice (but not as nice as I used to be), I'll also mention that pointers are so useful, the concept has been adopted by iterators, which are used practically everywhere in the standard library of algorithms and containers.

I'll also link to this page, which is more of a what and how rather than where and when, but it might offer some insights you haven't reached yet.

Finally, I'm of the opinion that pointers are an intuitive thing, and if you don't have that intuition, you'll have a great deal more trouble with C and C++ than someone who intuitively "gets it". That's not to say that you should drop the language and start using Python or some other language that hides these details from you, rather that you'll have to work harder to achieve the same level of proficiency that those who naturally understand pointers.

Of course, it could also be that you've been brainwashed by the masses who insist that pointers are difficult. The concept is simple and the practice is simple. Any difficulty comes from the programmer thinking too hard and making it more difficult than it really is. In a way, a lot of people sabotage themselves by believing that something is difficult before learning enough to realize it's dead easy.

Don't repeat the static keyword in the definition of getWindowCount.

I'm not going to enumerate every possible use I can think of. If you're having trouble thinking of ways that pointers are useful then either you don't understand them as well as you think, or you don't have enough experience programming to fully grasp the uses even if I do list them.

And yes, you can use linked lists in C++ too. :icon_rolleyes:

Do a google search for linked data structures (ie. linked lists, binary trees) and you'll discover a good use for pointers.

>How can I exchange 2 variables values without using any 3rd temporary variable.
Most likely your teacher is expecting this:

a ^= b;
b ^= a;
a ^= b;

But I'd recommend you find a new teacher because your current one is likely too focused on archaic trivialities and bad practices to teach you anything worthwhile.

>and my problem is that which one is better or more useful.
If one were better or more useful (all of the time, since you didn't specify your needs) then there wouldn't be two to choose from, would there?

I'm still trying to convince Dani to put me on the Daniweb payroll.

>There's a hell of a lot more to it than simply being able to recite a language reference manual.
However, you can probably go for quite a while on book knowledge if your only goal is to look smart on forums and newsgroups if you're clever about it. ;)

It doesn't matter how the size is defined, you can't initialize an array member arbitrarily like you can with local arrays. You can default initialize it, but that's about as good as it gets, and with a const array, it's not terribly useful:

template<int s>
class something {
  const int array[s];
public:
  something(): array() {}
};

Might I recommend the std::vector class instead of an array? Or remove the const qualifier and use assignment in the constructor as a poor man's initialization.

Choose the one you like the most. :icon_rolleyes:

By the way, if you want to learn a language "completely" you'll likely end up learning nothing else. For example, there's probably not a human on this planet who can claim complete knowledge of C++.

I'm assuming you mean a buffer in the context of a stream.

A stream is a sequential list of items where (in the simplest sense), the source places a single item at a time onto the stream and the destination extracts a single item in the order of insertion. In other words, a stream is one concrete implementation of a FIFO queue.

A buffered stream is a stream with a buffer (obviously!), but what's the point? Consider something like an input file stream, where physically moving to the correct record on your hard drive and loading data into memory is relatively slow. If you have a character stream and each request for a character has to go back to the hardware, you're going to see some serious latency.

The solution is to read as much as possible when you go back to the hardware and store that data in a temporary location that's quicker to access. This is the buffer. Then when a character is requested, if the buffer isn't empty then it will satisfy the request instead of going to the hardware. The only time you need to go back to the hardware is to refill the buffer when it becomes empty.

The end result is that the input file stream is drastically faster because instead of (for example) one million hardware accesses to read one million characters, a buffer of ten thousand drops the number of hardware accesses to one hundred. Most of the …

Clearly the same message is used for both good and bad rep, which means somebody didn't think very hard about the implications before trying to be all warm and fuzzy to users. ;)

Initialized the pointer to 0 if you aren't allocating memory. You can safely delete a null pointer and it will effectively be a no-op.

>On the other hand a simple addition to tm_mday may produce
>wrong dates and the real implementation (VC++ 2008) returns a
>very strange results after mktime of that "new date".
Granted I don't do a lot of date/time work, but I have yet to see what you've described as a glaring bug in Visual C++'s implementation.

>For example, for 2009-02-28 (109,2,28 in tm) we have (109,2,42) in
>tm and have 2009-02-11 after conversion this funny 2009-02-42 date.
Could you post a full program that exhibits this problem. Does it occur in older versions of Visual C++ as well?

You probably forgot to terminate the last class defined in InputHandler.h with a semicolon.

>How you can use cin.ignore to ignore every character
>up to and including a specified character
I'd start by reading my reference manual and seeing that the second argument to ignore is a delimiter.

>I have written a program but it does not work the way I would like to?
Then you're doing it wrong, obviously. Post your code so we can do more than tell you that you're doing it wrong.

>there's no way to either go to the top of the page
The Home key on my keyboard is sufficient for that task.

>I declare a pointer ptr (int *ptr; ) and then define ptr
>as 5 by saying *ptr=5; what adress is ptr pointing at
The precise answer depends on where you've declared the pointer, but the short answer is "nowhere you can dereference". Therefore your code exhibits undefined behavior. A pointer must be assigned to an address that you own before it can be dereferenced.

>a temporary variable?
If you want temporary magic that does what you wanted and not what you said, I recommend a much higher level language than C++.

>_TCHAR* tmp = new _TCHAR( i+1 );
This looks like a bug to me. You want to simulate a dynamic array, but you're using the wrong syntax:

_TCHAR* tmp = new _TCHAR[i + 1];

>why?
Because when you use void main, your code is no longer guaranteed to compile or run. The C standard specifies two definitions of main, and you should use one of those unless you have a very good reason not to:

/* When expecting no command line arguments */
int main ( void )
{
  /* ... */
}

/* When expecting command line arguments */
int main ( int argc, char *argv[] )
{
  /* ... */
}

Further, there are only three predictable return values from main. Deviating from them means your code may not behave as expected on termination:

/* Return a success code */
return 0;

/* EXIT_SUCCESS defined in <stdlib.h>, return a success code */
return EXIT_SUCCESS;

/* EXIT_FAILURE defined in <stdlib.h>, return a failure code */
return EXIT_FAILURE;

The point of these rules is to make your code portable to every compiler on every machine that supports standard C. If you don't follow them, you lose that flexibility to the point where your code is only portable to the exact version of the compiler and machine you initially wrote your code on.

>But how to do it?
Did you not read the answers you've been given? Both of them told you to use the strstr function.

More code please. Preferably a complete program that exhibits the problem so we can play with it.

There's a sticky How do I flush the input stream? that explains your problem and provides several solutions.

Thanks for searching before posting...not! :icon_rolleyes:

>mybutton1->BackgroundImage = NULL;
*sigh*

>so what do you suggest for me to do?
I thought it was obvious:

Open file for writing.
Write to file.
Close file.
Open file for reading.
Read from file.
Close file.

Set the same property to null?

In my experience you save yourself a lot of headaches by avoiding both sharing (working with the same file through two streams simultaneously) and read-write access (being able to read from and write to the file through a single stream).

>how did the linker or compiler find the path to that IO library when all i do is only header inclusion?
Compiling and linking are two separate stages. The header is only relevant during compilation because declarations for the names you use must be present before you use them or the compiler will fail with a syntax error. When you link, you specify which libraries you want to link with (certain standard libraries may be linked automatically). The linker then searches these libraries for the names you used in the translation unit and matches them to the definitions from one of those libraries; it throws a link error if no definition can be found.

To answer your question, the linker finds the path to the library because either the library is among the standard libraries that it searches automatically, or the path was provided as an argument when calling the linker.

>how it is logical to get this to work?
C++ takes an expression and evaluates it in a boolean context, but the expression itself doesn't have to evaluate to the bool type. a = 0 evaluates to the value of a, which is 0, which when treated in a boolean context is false. The condition of the if statement is thus false, and the else clause is executed. If you set a to anything other than 0, the opposite will happen because non-zero in a boolean context is true.

>whereas in c#
C++ is not C#. You'd do well to realize that making comparisons between two completely different languages serves little purpose.

>you can not do something like below
Because C# requires the expression to have a boolean type.

>for (o=n; o>0; o--)
Each row of the second triangle is based on n, and n doesn't change throughout your program. I believe you want to set o to m instead.

>it doesn't stop on 13
Clearly not, because you don't tell it to stop when the user enters "13". Both loops run exactly 13 times, and they'll do this without fail unless you break from the loop:

for ( i = 0; i < 13; i++ ) {
  /* ... */
  if ( some_value == 13 )
    break;
}

>This is wrong, isn't it?
If the value of argc really is changing (sometimes debuggers can be misleading) then looking for overflow would be my first task. It's entirely possible for memory overflow to spill into other variables and corrupt your data.

>vector<T> :: iterator ptr;
Change this to:

typename vector<T> :: iterator ptr;

Dependent types need explicit qualification with typename because C++ assumes they're not types and they can't be used in a declaration.

>if its not in a class look at memset()
Using memset is unsafe even for some built-in types, and if you don't know why, you should refrain from working with memory at such a low level. Consider these two statements for a variable declared as double d; :

d = 0; // Set d to the value of 0
memset ( d, 0, sizeof d ); // ???

The first statement is well-defined and correct. The second statement, which you probably believe to be equivalent, is neither well-defined nor correct because the internal representation of 0 for double is not required to be all bits zero (which is what this memset call does).

Try std::fill instead.

You're in luck. If you don't initialize all of the items in your array in the initialization list, the ones you didn't specify will be set to the equivalent of 0 for that type:

double U[N]={0}; // Completely filled with 0
double g[N][M]={0}; // Completely filled with 0

>so the default constructed object of string class does not take storage?
It's an empty string, for whatever that means on your system. Most likely that means the base size for the object and no wasted dynamic memory.

>when I pop an element out of the Stack, I don't
>want that element to still take memory storage.
My advice is not to worry about it. But setting the item to T() is the most portable way to hopefully do what you want, if you're lucky. Will it work? Maybe, maybe not, depending on the type of T and how much extra dynamic memory it uses for the default construction. Will it hurt? Maybe, maybe not, also depending on the type of T and how it handles memory.

There's just so much involved that unless you've done this before and have a good idea of how things will work, my advice once again is not to worry about it.

>template<class Tpl, unsigned int iSize>
>void AddData(CClient& c, CArray<Tpl,MAX_SIZE>& ar)
Change MAX_SIZE to iSize. Since you didn't have iSize anywhere in the parameter list or as an explicit list in the instantiation, your compiler couldn't figure out what it was supposed to be.