Posts by Narue

MyChar is an array of char. a is a single char. The two types are completely incompatible. MyChar[i] = a[i] would work. At least until i gets incremented past 1, then you're accessing a out of bounds.

GetData and GetSize are called on objects that are qualified as const. In such a case the compiler has to assume that both of those functions modify the state of the object, so it disallows the call. You can fix it by qualifying the two member functions as const since they don't actually modify the state:

unsigned GetSize() const
{
	return n;
}

void* GetData() const
{
	return v;
}

>I am not certain where to start.
Then you should consider switching your major. "I don't know where to start" is equivalent to "I'm not cut out for programming".

>1. Write a C program that only lists all files in the current
>directory and all files in subsequent sub directories.
This is a simple program. Do a man for opendir, readdir, and closedir, and stat. You can recursively go through the directory tree.

>2. Write a C program to print the lines of a file which contain a
>word given as the program argument (a simple version of grep
>UNIX utility).
This can be written using standard C (no Unix-specific code). Do a man for strstr. Presumably you know how to read lines from a file. :icon_rolleyes:

>3. Write a C program to emulate the ls -l UNIX command that
>prints all files in a current directory and lists access privileges etc.
Do a man for stat.

>4. Write a C program that gives the user the opportunity to
>remove any or all of the files in a current working directory.
This can be done in standard C too. Do a man for remove.

>First you did not change the while as narue said
>while ( getline ( plainText, plainLine ) ) {
>instead of
>while (getline(plainText, plainLine)){
Um...what? Do you really think a few extra spaces will make any significant difference?

>Second should try
>string plainLine, inputPath, outputPath;//all in one
I would argue otherwise, but matters of style are very subjective.

>No ios::in nor ios::out... I belive your stream does nothing
And I believe you don't know what you're talking about. ofstream is derived from fstream and defaults to ios_base::out for the second constructor argument.

>here is what i have so far (it won't compile)
So what do you want us to do? Finish it up for you, tie it up with a pretty little bow, and send it to your teacher with your name on it? Why don't you try posting what errors you're getting, explain what you did to solve them, what you learned along the way, and ask a specific question so that we don't treat you like a homework cheating leech.

kthxbye

>notice that the argv that i enter exists in the txt.....
Yes, but is it the same string you're comparing against? Remember that fgets does not strip the newline character. If you're comparing "test" against "test\n", strcmp will never return 0. You might be better off with strstr instead of strcmp.

>could u write a litle program for me?
Uh, no.

>if(strcmp(caracter,argv[1]))
strcmp returns a comparison, not a boolean. In other words, 0 is a match and non-zero is a failure to match. Thus, your if statement is reversed. You print the line when it doesn't match argv[1]. This should work better:

if ( strcmp ( caracter, argv[1] ) == 0 )
  puts ( caracter );
else
  puts ( "NOT FOUND" );

>is their any body tell me the Difference between int* a; and int *a; ?
From a language standpoint there's no difference. However, placing the asterisk by the variable makes more sense when you have multiple variables in a declaration:

int *p, *q;

The reason this makes more sense is because when the asterisk is paired with the type, it's easy to forget that it only applies to the first variable:

int* p, q; // q should be a pointer, but it's not

And of course, when you fix that error, it just looks funny:

int* p, *q;

If you only have a single variable per declaration, it's not an issue and you can do whatever you think makes more sense. The problems only show up with multiple variables per declaration.

The >> operator is default delimited by whitespace. If your strings need to contain whitespace, use getline instead.

FYI:

>ifstream plainText(inputPath.c_str());
>ofstream cipherText(outputPath.c_str());
This won't do jack because inputPath and outputPath are presently empty strings. You need to open the file after figuring out what the path is. :icon_rolleyes:

>while (!plainText.eof()){
This is a bad idea. The eof member function only returns true after reading past end-of-file. In other words, your loop will probably run once more than expected. Because getline returns a stream reference, and stream references have a conversion for the stream state, you can do this to fix the problem:

while ( getline ( plainText, plainLine ) ) {
  // ...
}

If you don't expect the first character to actually be whitespace, you can use "%*s". Otherwise, because %s ignores leading whitespace, you would need to use an exclusion scanset of whitespace:

fscanf ( in, "%*[^ \n\t\r\f\v]" );

>my questiion would be
Ooh, let's see.

>can some one tell me what to do next
That's not a question, that's a request for hand holding. By specific question, I mean specific question. Not "I'm clueless, tell me what to do!".

>if yu have a conversion into C++ cod can i see it
That's not a question either, it's a request for us to do your research for you. As you may have guessed by now, that's not how it works.

>I'm trying to learn on my own and need a little demo to look at.
No, you need to learn enough about Java to understand the code you're trying to convert. Then you need to learn enough about C++ to understand how to write code that does the same thing as the code you're trying to convert. C++ and Java are similar enough, especially with this trivial program, that I'm not going to cut you any slack. Common sense will take even the greenest of beginners through most of the exercise.

>Think about the relationship described by inheritance,
>and why what you're doing isn't possible
And yet it is possible. What the OP wants to do is called downcasting. It's not recommended for the obvious reasons, but it's a feature that C++ supports using dynamic_cast because it's sometimes necessary:

#include <iostream>
#include <string>

class PersonClass {
public:
  virtual ~PersonClass() {}
};

class LawyerClass: public PersonClass {
public:
  virtual ~LawyerClass() {}
};

void test ( PersonClass *p )
{
  if ( dynamic_cast<LawyerClass*> ( p ) != 0 )
    std::cout<<"It's a lawyer! Run!\n";
  else
    std::cout<<"It's a person!\n";
}

int main()
{
  PersonClass *p = new PersonClass();
  PersonClass *q = new LawyerClass();

  test ( p );
  test ( q );

  delete p;
  delete q;
}

>myarray.clear(); //Doesnt deallocate the memory
Correct. Clearing the array only changes the size.

>myarray.reserve(0); //Doesnt deallocate memory
Correct. Reserving space only causes reallocation if the new size is greater than the current capacity.

>myarray.swap(myarray);//Doesnt deallocate memory
This isn't required to shrink-wrap the capacity. You might have better luck with a different object, but that isn't guaranteed either:

vector<vector<CString> >( myarray.begin(), myarray.end() ).swap ( myarray );

It's called an initialization list. The code is roughly equivalent to this:

foo ( int limit, void (*action)() )
{
  _i = 0;
  _limit = limit;
  _action = action;
}

It looks like you're on the right track. Do you have a specific question?

Just use a pointer to a function for the callback:

#include <iostream>

class foo {
  int _i;
  int _limit;
  void (*_action)();
public:
  foo ( int limit, void (*action)() )
    : _i ( 0 ), _limit ( limit ), _action ( action )
  {}

  bool done();
};

bool foo::done()
{
  if ( _i++ < _limit )
    return false;

  _action();

  return true;
}

void my_action()
{
  std::cout<<"boop!\n";
}

int main()
{
  foo bar ( 10, my_action );

  while ( !bar.done() )
    std::cout<<"Working...\n";
}

>I have tried everything you have suggested
Did you try this?

std::wcout<< cs.GetBuffer() << '\n'; // cs is the CString object

>However the following line of code works:
Well, DUH! That line uses a narrow string literal with a narrow stream object. You didn't exactly (or at all) reproduce the problem in that case, and I would be utterly shocked if it failed to work as expected.

>Use a database.
Use your brain. This guy is clearly a beginner, and you want him to struggle with a database API on top of basic C++ for a trivial problem?

>I've tried so hard,but so far i still cant figure out what is the actual way to do this....
You already store the IDs for each product in an array. The problem now is matching the name of the product with the ID after the IDs have all been entered. You started something along those lines with your switch statement, but it should be in a loop and check the current ID at all times. Something like this:

for ( int index = 0; index < i; index++ ) {
  switch ( product[index].id ) {
  case 1001 :
    product[index].item = "shirt";
    break;
  case 1002 :
    product[index].item = "book";
    break;
  default:
    product[index].item = "(unknown)";
    break;
  }
}

Also note the default case. You should always use one, especially when the value being tested is based on user input.

Mixing C++/CLI and standard C++ can be troublesome. Try sticking to one or the other unless you have good reason not to:

label2->Text = Convert::ToString ( a );

You're working with uninitialized pointers. Pass the matrices as references:

void generate(int**&, int, int);
void fill(int**&, int, int);
int** compute(int**& ,int**&, int, int, int, int);
void dellocate(int**& val, int x, int y);
void display(int**& val, int x, int y);

Match that in the definitions, and that's the only change you need to make.

>Hmm, That's very odd!
Not especially, though it can be surprising. This is the underlying problem:

#include <iostream>

#define UNICODE
#include <windows.h>

int main()
{
  TCHAR *s = L"test";

  std::cout<< s <<'\n';
}

My crystal ball says the UNICODE macro is defined, which causes CString to resolve to an actual type of CStringW. The implicit conversion ends up actually being CStringW to wchar_t*, which cout (the narrow stream object) isn't built to handle. Two simple options are to undefine UNICODE (if you don't need Unicode in the project), or use wcout instead of cout.

I'm intrigued. Please post a complete (small!) program that exhibits the problem.

>Anybody?
Probably not, seeing as you appear to have ignored the previous replies to the same question in another thread. We're generally hostile toward people who waste our time.

p.s. Don't bump your threads. It's extremely rude and antisocial.

>but many books have this specifier.
I hate to break it to you, but many books are written by people who know little more about C than you do. The lesson about %lf is that printf is not a mirror image of scanf in terms of format specifiers.

>where can i find the information related to the format specifiers.
A good book will cover them accurately. A good reference will cover them. And of course, you can refer to the standard itself, though it's a bit harder to glean useful information until you learn how to decipher the legalese.

>Ｉ’ｍ ｕｓｉｎｇ ｄｅｖ ｃ＋＋ ｗｉｔｈ ｔｈｅ ｄｅｆａｕｌｔ ｇｃｃ／ｇ＋＋ ｃｏｍｐｉｌｅｒ，
>ａｎｄ ｔｈｉｓ ｅｘａｃｔ ｃｏｄｅ ｗｏｒｋｓ ｆｉｎｅ ｆｏｒ ｍｅ
There's nothing to stop a compiler from including standard headers in other standard headers. In your case, <iostream> includes <string> somewhere along the line. However, it's extremely poor practice to rely on this kind of behavior.

>what do you mean by "there are still issues"?
Cleaning up the output, checking user input for success/failure...that kind of thing. It's not a huge deal at this point in time, so I didn't mention those things.

>If you expect your IDE to come fully featured then it won't be lightweight....
The very definition of IDE implies a text editor, a compiler, a debugger, and build tools. vim is a text editor, not an IDE. That's why developers work with several individual tools such as vim, gdb, gcc, and make when working without an IDE.

Two replies (one from a mod), and both are horrid. You both completely missed the fact that the <string> header wasn't included, which means any use of the std::string try (qualified or no) will fail miserably.

*sigh*

Here is the corrected[1] code. I added the <string> header and qualified the types because the OP was using explicit qualification for cout and cin:

#include <iostream>
#include <string>

int main()
{
  std::string firstName;
  std::string lastName;
  int salary;

  std::cout << "Enter First Name, Last Name, Salary";
  std::cin >> firstName >> lastName >> salary;

  std::cout << "\nFirst Name is " << firstName;
  std::cout << "\nLast Name is " << lastName;
  std::cout << "\nSalary is " << salary;

  return 0;
}

[1] There are still issues, but the immediate problem has been fixed.

>i read that the precision of float is 6 digits and double is 10.
No, the precision of float is FLT_DIG and double is DBL_DIG, where both of those macros are defined in <float.h>.

>but it is showing only 6 for both.
Yes, that's the correct behavior. If you print a floating-point value using printf and no precision specification, the precision is assumed to be 6. You can find this as a stated requirement in the standard for the %f specifier.

>float f = 34.34567832;
You'll most likely get a warning about precision loss here. float constants are suffixed with f or cast to float:

float f = 34.34567832f;

>printf("%lf\n",d);
There's no such thing as thing as %lf. You've invoked undefined behavior by using a length modifier that doesn't apply to the type specifier. %f is for double and %Lf is for long double. Because printf is a variable argument function, all of the variable arguments follow the regular type promotions, which means that float gets promoted to double. Therefore there's no specifier for float in printf.

Try this instead:

#include <stdio.h>
#include <float.h>

int main ( void )
{
  printf ( "Float precision:  %d\n", FLT_DIG );
  printf ( "double precision: %d\n", DBL_DIG );

  printf ( "float value:  %.*f\n", FLT_DIG, 34.34567832f );
  printf ( "double value: %.*f\n", DBL_DIG, 34.3456783221 );

  return 0;
}

>int nulls=atoi(argv[2]);
>int arry[nulls];
Nope, sorry. C++ doesn't allow an array size that isn't a compile-time constant.

>const int nulls=atoi(argv[2]);
>int arry[nulls];
Bzzt! Wrong! nulls is still not a compile-time constant despite being qualified as const. This is because to be truly compile-time, the variable needs to be qualified as const (oxymoron?), and the value being assigned must be a compile-time constant as well. atoi is a function that produces a result at runtime, so the value being assigned to nulls is not a compile-time constant, and nulls is also not a compile-time constant because it's incomplete until the initialization value is generated. Therefore, nulls cannot be used to declare an array size.

>It works for me.
This is the mating call of mediocre programmers. Just because it works for you doesn't mean it works for everyone. You're relying on the extended behavior of your compiler, which means that your code only works on your compiler (and possibly even that specific version of your compiler). Moving to a different compiler and/or version means your code could likely stop working for you.

Now for the correct answer. Option 1 is to use a vector:

#include <cstdio>
#include <cstdlib>
#include <vector>

int main ( int argc, char *argv[] )
{
  if ( argc < 3 )
    return EXIT_FAILURE;

  std::vector<int> a ( atoi ( argv[2] ) );

  //...
}

This is the recommended solution. Vectors are safer and easier to use than the next …

>So is there really nothing i can do to the findMax function to fix the problem?
No. In keeping with the spirit of the function as well as the question, the solution is to make pToMax a pointer to a pointer. Most of the changes for that are made in findMax, but you still need to make at least one change in main (passing the address of ptr), or the solution won't work. To be a robust solution, main should also initialize ptr to NULL and check for NULL as a failure state.

All in all this is a bogus exercise because it's unsolvable with the given restrictions.

>I cannot change the main function
Sucks for you then, because the error is in main and can't be fixed from findMax. You have an uninitialized pointer.

>pToMax = &arr[0];
>//should be
>pToMax = &arr;
No, that changes the the meaning of the expression and introduces a type mismatch. It should be either pToMax = &arr[0] or pToMax = arr .

>It seems that your function fails to check the ends of the arrays.
>Please revise your code.
That doesn't look like a compiler error. Did your teacher tell you this?

<psychic_debugging>
I'm willing to bet that you copied the code from that site without adding the necessary scaffolding. For example, executable (as opposed to declarative) code needs to be wrapped in a function:

#include <windows.h> // Assuming this for Sleep
#include "libwmp3.h"

int main()
{
  /* create class instance */
  CWMp3* mp3 = CreateCWMp3();

  /* open file from disk */
  mp3->OpenFile("mysong.mp3",800, 0, 0);
  mp3->Play();

  /* ... wait here in some loop */
  MP3_STATUS status;

  mp3->GetStatus(&status);

  while(status.fPlay)
  {
      Sleep(200);
      mp3->GetStatus(&status);
  }

  /* destroy class instance */
  mp3->Release();
}

</psychic_debugging>

inline: Similar to C++'s inline keyword. It gives you the option of telling the compiler that you want inline expansion rather than real function object code. Inline functions are a safer and easier to use alternative to function macros:

static inline swap ( int *a, int *b )
{
  int save = *a;
  *a = *b;
  *b = save;
}

I'd recommend avoiding this feature. Not only are the rules somewhat tricky, the compiler isn't required to honor a hint for inlining. Further, if the compiler does honor the hint, it could be counter-productive and actually hurt performance instead of help it by increasing the memory footprint and causing thrashing.

_Bool: C99's boolean type. Using _Bool directly is only recommended if you're maintaining legacy code that already defines macros for bool, true, or false. Otherwise, those macros are standardized in the <stdbool.h> header. Include that header and you can use bool just like you would in C++.

#include <stdio.h>
#include <stdbool.h>

int main ( void )
{
  bool b = true;

  if ( b )
    printf ( "Yes\n" );
  else
    printf ( "No\n" );

  return 0;
}

restrict: The restrict keyword is an optimization hint. It says that a pointer is not aliased in the current scope, which means the underlying object is not accessed by another pointer. This hint gives the compiler extra leeway in making assumptions about the pointer and can result in better object code. I'd recommend avoiding this feature too. A lot of …

If you want to be able to roll back changes, store the contents of the vector in a backup vector before making the changes. Alternatively, you could reverse your algorithm to obtain the original values, but the backup vector is easier and faster (at the cost of extra memory usage).

If you know how to use arrays, and you know how to use FILE pointers, you know how to use arrays of FILE pointers. There's really nothing tricky about it except for the number of files you can have open at any given time. The FOPEN_MAX macro in stdio.h tells you how many streams are guaranteed to be open simultaneously. Note that this number includes the standard streams that are already open. Size your array accordingly.

>I believe the problem lies in the fact that when the instance
>of the function ends so does any local variables within it.
Are you a complete idiot? I told you exactly what the problem was: you don't have a suitable copy constructor. The default copy constructor does not make a copy of dynamic memory, only pointers to said memory. When you return a copy of the polynomial object, the copy points to the original memory, which is deleted when the original object is destroyed. So why don't you fix that before digging any deeper into the mystery, Sherlock.

>You can also do this: <snip conio.h crap>
You can do that...but don't teach it to others. Using conio.h is like bumping uglies with a fat chick. A lot of guys might do it, but they don't talk about it. Such is the way with bad programming practices.

Your polynomial class has a pointer member and a destructor, but no user-defined copy constructor. Sounds like a one-way ticket to the exact error you're describing.

There's nothing wrong with it per se, but it's generally wiser not to confuse your readers with frivolous includes that aren't used in the file.

>no help at all...but thanks anyway.
Your capacity for patience is staggering. I mean, you couldn't even wait a full hour when it's either SUNDAY, or the wee hours of Monday all over the world. Good luck passing your class, and succeeding at a programming career, because you'll clearly need it. :icon_rolleyes:

Amazing. You took the time to add underscores so that your formatting wasn't lost and didn't bother to look for some kind of forum tag that would preserve it for you?

>PLEASE help pps!!
Here's a hint: realloc only works on memory that was previously returned by malloc, calloc, or realloc.

>Is there a way to write a program in c++ that get a decimal number
>and convert it to its equivalent in hexadecimal without using arrays ?
Why yes, there is indeed a way.

>A bit guidance please ....
I'm guessing that you refused to search the forum before posting a new thread, because I can guarantee that this question has been asked and answered at least half a million times since Daniweb went live.

The C# and C++ IDEs are written by separate teams and do not correspond in supported features. In other words, if you can't find that feature in the same place as you would find it for the C# IDE, you're SOL. However, you can still do a selection format by selecting the part of your code you want formatted and using the Ctrl+K+F combination (or Edit->Advanced->Format Selection). In my experience that works across the board.

>I'm relatively comfortable with C++ and am taking a class in C for the
>first time. I'm finding it difficult and frustrating to adapt to the new
>language. It's kind of like trying to box with a hand tied behind my back.
If you're used to C++ and the benefits of such things as the more powerful standard library, templates, and RAII (those are the things I miss most when I use C), then C can certainly feel restrictive.

>Is C a subset of C++? Do they share libraries? Are
>there libraries that are specific to C or C++?
C is not a subset of C++, but C++ does implement the C libraries as they were before C99 (C++0x should include more of C99). C does not share any of C++'s libraries.

>Additionally, are there any websites that you can point me to for general information on C?
Honestly, the best place to get your questions answered would be forums like this (or cprogramming.com) where there are people knowledgeable about C. Otherwise, just google different combinations of keywords until you find matches. Searching for C is more difficult than C++ as you've already discovered. Not for lack of resources, of course. Also, keep in mind that C and C++ of often similar enough that the low level C++ answer is also the C answer with a few minor changes.

>http://www.cprogramming.com/ seems to have some of the information …

Just out of curiosity, why are you trying to circumvent the access mechanism? Those members are private for a reason, and if you need to access them from outside of the class without a field, something isn't right.

However, if you really want to use a pointer to a member, have a public member function return that pointer:

#include <iostream>

class Angry_Dude
{
private:
    int health;
    int attack;
public:
    typedef int Angry_Dude::*health_ptr_t;

    health_ptr_t health_ptr() const
    {
        return &Angry_Dude::health;
    }
};

int main()
{
    Angry_Dude ad;
    Angry_Dude::health_ptr_t p = ad.health_ptr();

    ad.*p = 12345;
    std::cout<< ad.*p <<'\n';
}

I don't recommend this method because it's both obscure and questionable class design. You'd be better off re-evaluating your class interface to account for the apparent need to have unrestricted access to private members.

>Would it make sense to add a new forum to separate it?
Frankly, I don't think it makes sense. But if it did then it would also make sense to add a new forum for C++/CLI, and for Qt because it seems to be a favorite recommendation for pretty pictures, and DirectX/Direct3D as well because you know someone will bitch about a Qt forum but no DirectX forum. Oh, and since we're breaking up the forum based on things that by some arbitrary estimation aren't "pure" C++, we need a separate forum for each and every compiler in common use as well because most of the OPs use features specific to their compiler.

One big problem with adding new forums is that it's a slippery slope. If Dani adds one forum based on a recommendation like this, tons of others will push to get their own pet forum added and use that first one as a precedent.

We worked hard to remove and merge forums a few years ago because Daniweb was turning into the site of a million forums, and I suspect that Dani is going to be hesitant to add new ones at this point. To successfully get a new forum, you need to prove that there's a significant benefit to it (enough to justify the many headaches that a new forum will create), especially when everyone will think you're asking for it because "I just started learning this kewl thing and it would be …

>When printing output to a terminal in C++, should i use "\n", or "endl"???
I recommend using '\n'. For the most part, the stream is flushed in the right places by default, so explicitly flushing it yourself is just an extra unnecessary step.

>Is one lighter, faster, or industry standard?
These two statements are directly equivalent:

cout<<"Hello, world!"<<endl;

cout<<"Hello, world!\n"<<flush;

endl prints a newline character and then forces a flush of the stream. So just printing '\n' is lighter and faster because the flush isn't performed.

>Incr.Add(1);
You use the arrow operator to access members of managed references:

Incr->Add(1);

On current implementations, you'll probably find that the stdio library is faster than the iostream library. The usual recommendation is to try both and use the one that's fastest on your setup, if all you care about is execution performance.