> gcc -c dtio.h dtio.c
> g++ screen.h screen.cpp dtio.o testMain.cpp -o testM
You DON'T compile header files!
gcc -c dtio.c
g++ -o testM dtio.o screen.cpp testMain.cpp
> gcc -c dtio.h dtio.c
> g++ screen.h screen.cpp dtio.o testMain.cpp -o testM
You DON'T compile header files!
gcc -c dtio.c
g++ -o testM dtio.o screen.cpp testMain.cpp
> then tells the OS to return back to the called procedure.
The OS isn't involved in such things.
> to be set or always set?
Not at all.
The compiler just outputs the code such that it's tagged with the right section name.
It's the linker and linker configuration script which set the properties of each section of memory.
As for checking say that a particular code section has the 'x' bit set say, before calling it, I've no idea.
No, because a->b requires you to actually run some code along the lines of
a->b = new B;
or something.
It's like a linked list, which points to itself.
Whereas this is an alternating pair of types.
> Class A uses class B. (object class)
> Class B uses class A. (object class)
One of these will have to contain only a POINTER to the other one.
class A {
B b;
};
class B {
A a;
};
You just end up with a.b.a.b.a.b.a.b.a.b.a.b.a.b and so on filling up the universe.
Making one of them a pointer to the other breaks the cycle.
class B; // class forward declaration
class A {
B *b;
};
class B {
A a;
};
> Also when compiling the compiler frequently shows
That's because the program is still running when you try to rebuild it (or you're still debugging it)
> I Tried that but the program crashes even before reaching there.It usually crashes at the dynamic allocation of in
Like I said, check them all.
> unsigned long insize=ULfilesize-2-4-(8*dicsize);
Because your first for loop reads 1 too many dic entries, the rest of the calculations for the rest of the file are also off.
Post your latest code.
> dic=new dicv [dicsize];
> for(unsigned long i=0;i<=dicsize;++i)
First problem, this runs off the end of the array.
Better check your other array subscripts as well.
So what's with all the smoke about "infinity" then?
You have n sorted integers.
Is he dumb enough to
- not call any kind of tech support
- not figure out that some malware is now on his machine
- not figure out it was you that put it there (you visit, WoW stops working, mmmm)
- not call YOU for help
I just see this back-firing in so many bad ways.
> have you ever tried telling your older brother he needs to see a counsellor
But you at least should consult with one to explain your collective concerns (and situation). That is, someone who is competent to deal with addiction (which I'm not, and probably, neither are you).
And needless to say, you'd better make sure the rest of the family are in on this plan.
Then what?
I very much doubt that he'll simply "snap out of it" just because of a failure to connect. What's your plan for phase 2?
If he's that deeply addicted to it, you're going to need a counsellor, and probably some other services as well. Research your total solution, don't just pull the plug and hope everything will be well.
Your (and his) problems are sociological, not technical.
As it's a CRT, have you tried pressing the degauss button recently (or at all?)
> Is MinGW not an advanced compiler? Or is it just because they aren't developping Dev-C++ anymore...
1. separate the compiler from the IDE. You can normally upgrade one without the other.
2. dev-C++ is not being developed; it also has a fair number of bugs
http://en.wikipedia.org/wiki/Comparison_of_integrated_development_environments
http://en.wikipedia.org/wiki/List_of_source_code_editors
Choose your own pair of shoes which feel most comfortable to you.
Everything else is just opinion, that's why there's so much choice out there. In the end, it's you that's got to live with your choice, not us.
> testptr[5] = 203;
Still an array overrun.
Perhaps the error message is correct.
Actually, almost every line of your program is wrong. It's quite a surprise that it gets that far.
> int * testptr = new int[1];
OK so far.
> testptr[1] = 23;
Oops, you stepped off the end. You only allocated 1 int, so the only valid subscript is zero.
> cout << testptr[1] << endl;
It prints what you stored, but it's stored in someone else's memory. Maybe they'll want it back soon...
> redim(testptr, 5); // change the dimension
Look up call by value and call by reference.
Sure you can free the memory (you have a copy of the pointer), but you can't change the pointer HERE (you don't have a reference to it).
Anything you do AFTER this point in the code with testptr is really bad news. Even if everything else was fixed, the subscript would still be out of bounds (see earlier comment).
> delete[] testptr;
The function freed it.
But you didn't get back a new pointer, so you try and free the old one again (this is a bad thing).
> ptr_to_data = new int[newdim];
And now the line with the error message.
ptr_to_data at this point is just a local variable. Changing it here doesn't change anything in the caller.
So you allocate some memory, then immediately lose the pointer to it when the function returns (and …
http://bashdb.sourceforge.net/bashdb-man.html
By convention, a -- option turns off all further option processing, and treats the rest of the command line as parameters.
Post-it notes and a whiteboard would be my suggestion.
If you're still in the dark as to what the nature of the problem really is, then hacking code is the last thing you should be doing.
What you're tying to do is create one of these
http://en.wikipedia.org/wiki/Entity-relationship_model
Some of the more outlandish designs you come up with can be dismissed in a few minutes. But it might take you a week of coding to come to the same conclusion with your existing approach.
But each failure tells you more about the problem, so don't look on this as anything negative.
When you have something which seems to do what you want, and you have some kind of API (insert, delete, find, traverse etc), then simulate some runs to see how it all hangs together.
If that passes muster, then try and implement it.
For wiping all the free space on a disk, this was mentioned recently.
http://www.killdisk.com/
There are also many tools which act like a "shredder" for your desktop wastebasket.
http://www.filetransit.com/files.php?name=Secure_File_Delete
http://www.snapfiles.com/freeware/security/fwerase.html
No specific recommendation, just somewhere to look
> It moves along the vertical axis, but never on the horizontal axis
By itself, or when you scroll a page or a window or ...
Case matters.
Get != get
Line 42: while (msgIn)
You're at the end of the file when you call your size function.
So it returns immediately.
Make sure the file location pointer is reset back to the start of the file, and the eof() state has been cleared.
> so can I get source code of socket.h(I mean the definition file)
> from them and probably compile it with MinGW?
You might, but I'm pretty sure you'll find an OS in the way before you get down to the wires.
Then you'll be back in the same spot you're in at the moment, only at a lower level.
I found this - http://www.libsdl.org/projects/SDL_net/
I've no idea if it does what you want, but it seems to run on what you want.
There are tools like partition magic (and others - http://en.wikipedia.org/wiki/List_of_disk_partitioning_software) which should do the job.
> and D about 20 gb. Due to (my music) collection growing now to 80 gb
Even if you absorb the whole of D into C, you're only extending your collection space by 25%. How long will that last?
If you've got all the original install disks (and downloaded all the latest drivers for your machine and burnt them to CD), then spend the money you might spend on a s/w licence you're only going to use once or twice, on the biggest HD you can afford (you'll probably double the space on what you have now).
Plus your system will benefit from being a nice clean install with no accumulated crud.
Plus your old disk is handy for backups, or experiments with other operating systems, or just generally as a big data disk for all your collection.
> Can I just copy paste my /sys/socket.h from my Linux Box and paste it on the /sys/ of MInGW directory
Nope, not at all.
You also need the .lib. Since that's compiled for a different architecture and OS, chances are it wouldn't even link, and has much less chance of running.
> But personally, I prefer MinGW because it gives me freedom to use without depending from any run-time DLL.
But you also sacrifice the comfortable magic which cygwin offers to give you an environment which is far more unix-like.
It's a choice, but you need to decide on your priority.
> but I would prefer to use sys/socket.h since I don't wanna go in WSA() thing.
Unfortunately, if you want to avoid too many dependencies, there's no real getting away from having to deal with the real thing at the bottom of the call hierarchy.
> But I dont want to use that since it will have me do a lot of conditional compiling(to make my app,
> platform independent) which I don't like.
If you implement a wrapper class, then only ONE file should contain all the WSA stuff, and conditional code.
Capturing your interfaces at the right level can really make or break your portability efforts. Done well, it's a breeze. Done badly, and it's a disaster.
And what about the for loop?
You just described classes and operator overloading.
class myLongInt;
Then later
myLongInt a, b, c;
With suitable initialisation, and an appropriate method or two, you can do
c = a + b;
> a simply is a pointer. That's what an array name is, a constant pointer to the first element.
No it isn't.
Read Narue's answer.
Then read this as well.
http://c-faq.com/aryptr/index.html
> so I can compare them to user input from another page
You encrypt the input using the same steps you did to store the encrypted password in the first place.
You then compare two encrypted results.
If they match, they're in!.
Dunno, it's been 15+ years since I last did any 68K work.
But the essence of arrays is to load the address of an array into an 'a' register, and load the subscript into a 'd' register.
Then look for the various indexed addressing modes, something like
move.b d1, a0(d0)
There might even be auto-incrementing modes, like
move.b d1, a0(d0+)
It makes no difference to where "hello world" is stored.
> would I have to variable2[0]='h'; etc to send the characters to the heap memory?
Yes, or use strcpy() to do the whole string for you.
> what if it's in main()? Or declared outside of main(), as a global variable?
Makes no difference.
Well /2 is commonly achieved by doing >>1 (aka ASR in assembly).
Only the compiler probably knows a few more tricks than that.
Like I said, you're pitting your knowledge against the distilled experience of MANY experienced programmers.
> I was going to try doing simple things like my cross/dot products and stuff with asm to see if that makes any difference.
First thing you need to do is make sure this is in fact a hot-spot by doing some profiling.
Then figure out if there is a better way of working the problem which involves less calls to the hot function. The biggest optimisation is to simply not call it; so if you can identify useless calls, then that's a big win.
Rewriting in ASM is the absolute last resort when you've exhausted all other avenues.
Finally, if you're going to do it in asm, you need one hell of a crafty approach to the problem to make it worth-while.
Simply writing out instructions which you imagine a really stupid compiler would generate, then trying to squeeze out a bit of dead code will mean you'll always lose. Write your code, then look at the asm, and see if you can figure any of it out when the optimiser is turned on. There's all sorts of stuff you'd never think of going on in there.
Your compiler is NOT a programmable calculator which takes every character you write literally and …
> will strMain become the reference for the block of memory allocated in the cc function as retVal?
> If I delete[] strMain, will that be the same as freeing the memory I allocated in cc()?
Yes and yes.
Though you need to add a \0 to make it a string inside cc().
> char* variable="hello world!";
variable is wherever you declare it (on the stack if this is inside a function). The string "hello world" is stored in the programs constant data. It always exists for the life of the program.
> char* variable2;
As above, but not initialised
> variable2=new char[13];
Now initialised, pointing to 13 chars on the heap.
> variable2="hello world!";
Bad news!
The heap memory you had has now leaked (you lost your last pointer to it).
Too easy.
Just send out 6 random numbers to every schmuck who signs up. Just occasionally, some of the numbers will win enough for the schmuck to write some glowing piece of puff which'll go right up on the web page as "proof".
Like it says "can".
Every other combination of 6 numbers "can" as well.
If you want to pay $19 for someone else to think of 6 numbers for you, then that's your problem.
That compilers are smarter than you perhaps?
> I literally picked up asm today.
Whereas the combined asm experience of all the people who wrote the compiler is probably in the 1000+ YEAR category. My bet is that they've figured out some stuff that you haven't.
In particular
1. 11/5 is a constant. Seeing that, the compiler will do the work at compile time rather than literally emitting the code (like you did) to calculate the result (num = 2 in other words).
2. You don't use the num result, so it might not even do that much.
3. Having eliminated step 2, it sees the loop is empty, and gets rid of that as well.
> and figured out doing things directly would be faster
How?
By guessing that you could (the wrong approach)
Or by using a profiler to find out where the real hot spots are.
> else if(postqueue.front() == '+' || '-' || '*' || '/' || '^')
Nope, try again.
Yes it's valid code, but it sure doesn't do what you want it to do.
1. you need to cout i and n
2. you need to reset n each time around
Simple question - why do you have nearly 700 posts, and haven't figured out how to use google yet?
It looks like an enhanced strtok() you might find in something like python or ruby, or some other scripting language.
> sprintf(str,"%s%c",str,isciistream);
1. Almost all C library functions have undefined behaviour when the source and destination overlap. You're reading from the string you're printing into.
2. QString temp=str;
> const char *foo = temp.ascii();
If you print out the bytes of str before this, are they OK?
Perhaps QString defaults to a wide char on F8
Well I guess you'll just have to post your real code, and not just random bits of pseudo-code.
Something like FILE.open ("data.txt",ios::app);
So you append, rather than rewrite.
Also, opening the file before the loop, then closing it when you're done would help.
Your two if statements are always false and true in that for loop.
And did you assign the result of fopen ?
And please learn how to use code tags.
> for(B = 1; B < C; B++)
Perhaps your code is broken, because C is uninitialised the first time around.
Perhaps < A ?
There were others, which have now gone.
Because strcmp() is C.
You're already half-way there with line 9, so just carry on using == to compare two std::string variables.
Like I said, at what point in your compilation steps did the compiler generate the code for swap<voter>
Was it when it compiled salarycompare.cpp - doubtful, it doesn't know what a voter is.
Was it when it compiled main.cpp - again no, the actual template code isn't in view (only the class in the .h file).
Judging from the way the code colouring goes completely out of whack at about line 20, I'd say that you're missing a " on a previous line to end a string.