Before going into windchill, try the experiment, you'd be surprised:
tC = f2c(t);
tF = c2f(tC);
cout << "t = " << t << "; tF = " << tF << endl;
The printed out values should be identical. They are not.
Before going into windchill, try the experiment, you'd be surprised:
tC = f2c(t);
tF = c2f(tC);
cout << "t = " << t << "; tF = " << tF << endl;
The printed out values should be identical. They are not.
Yes it is possible, although I'd recommend automation via make and a shell script. For example, add two targets to a makefile:
simulate: NEW_file
simulation command line here
NEW_file: binary_file
reader command line here
( simulate
target should be a default one).
If the simulation generates output, you may want to have that output file as another target.
I don't think that sum can help here. You may resort to functional style:
Stock_Value = functools.reduce(lambda x, y: x + y.getvalue(), stock_table, 0)
:~> g++ a1test.cpp ISBNPrefix.cpp ISBN.cpp
:~> a.out
I'd recommend:
:~> g++ -g a1test.cpp ISBNPrefix.cpp ISBN.cpp
:~> gdb a.out
(gdb) run
...
Segmentation fault
(gdb) where
...
Now you'd know exactly where the segfault happened, print out relevant variables.
PS: you are right that it is valid()
which segfaults.
What is there in your .profile? It usually defines and exports all the necessary environment variables. If it does not, add them there.
>> calling perror after i check if the file is null prints out "Invalid Argument"
i know that "w" is a valid mode.
Well, could it be a unicode string?
EINVAL after fopen does mean a bad mode after all.
>>i might try casting cmd.argv(1) to const char *
I doubt it would help. Non-constness may cause compile-time errors; you have a runtime one.
> BASH_ENV=profile
It is [B].[/B]profile
. The dot is rather hard to see, so it is dot-profile.
One problem with this code is that it can't match a literal '?'. Another is its complexity. I can't even try to understand how it works, let alone debug it.
This is how I would approach globbing:
#include "glob.h"
int globMatch(char * pattern, char * text)
{
while(*pattern && *text) {
char p = *pattern++;
switch(p) {
case '*':
while(*text) {
int rc = globMatch(pattern, text++);
if(rc != MATCH_FAIL)
return rc;
}
return MATCH_FAIL;
case '\\':
if((p = *pattern++) == 0)
return MATCH_ERROR;
if(p != *text++)
return MATCH_FAIL;
break;
case '?':
text++;
break;
default:
if(p != *text++)
return MATCH_FAIL;
}
}
return ((*pattern == 0) && (*text == 0))? MATCH_SUCCESS: MATCH_FAIL;
}
with an obvious glob.h:
#ifndef _GLOB_H_
#define _GLOB_H_
#define MATCH_ERROR -1
#define MATCH_SUCCESS 0
#define MATCH_FAIL 1
#ifdef cplusplus
extern "C" {
#endif
int globMatch(char * pattern, char * text);
#ifdef cplusplus
}
#endif
#endif
I don't get a segfault even with this sample. If you do, this would point to lines 57, 58, and 59. Switch to vectors, or at least use new int[z]
>> which exhibits the seg fault
Are you sure a segfault is reproducible with this set?
At the target machine, in the .ssh/environment add BASH_ENV=.profile (assuming bash as a default shell and the standard setup). Otherwise, many important variables, such as TERM, LD_LIBRARY_PATH, etc, etc would remain undefined.
perror after line 13 can give some useful information.
AD: OP tries to open the file for writing; it doesn't matter if the file already exists or not.
Can you provide some test data set (the smaller the better) which exhibits the seg fault?
> By logic /2 should mean half of sequence
Only if those halves are identical. What would be a result of
(0, 1, 2, 3) / 2
You never set done to True. Your do {} while(!done)
is a nice infinite loop. Of course it runs out of the string limits.
Something is wrong here, don't you think?
print "test_string:\t%.4f" % timeMethod([B]test_string[/B], 10, 1000000)
print "test_stringIO:\t%.4f" % timeMethod([B]test_string[/B], 10, 1000000)
print "test_cStringIO:\t%.4f" % timeMethod([B]test_string[/B], 10, 1000000)
Of course you can. They just don't have names. They are positional, and are referred as $1, $2, etc. The $1 used in a function is a first argument passed to it.
> since i cant find any information about
That's strange, because TFM clearly says:
When a function is executed, the arguments to the function become the positional parameters during its execution. The special parameter # is updated to reflect the change. Special parameter 0 is unchanged.
receivefunc()
{
echo $1
}
There are several problems with this code.
1. The producer locks the queue for much too long. The mutex can be safely released right after the queue entry is unlinked. In fact you make your producers to run sequentially, and since the file IO is a very time consuming operation, the consumers have more than enough time to do their job while another producer opens and reads its file. That's why you only get one slot used.
2. Semaphores are not enough. You need a mutex to protect the counter.
Notice parent 1
. Process with pid 1, aka init, besides other things, adopts every orphan. This means that by the time 6215 prints its message, 6214 is already dead.
> cat file1 file2 file3 > outputfile
I think you are missing the point. The script does not just cat files together. It creates another script, which serves as a primitive self-extracting archive. Let's see what happens when you invoke it as ./bundle.sh file1 file2>new.sh
As you said, line 3 just logs a progress message on a stderr, and new.sh gets written with
cat >file1 << End of file1
... body of file1 ...
End of file1
cat >file2 << End of file2
... body of file2 ...
End of file2
The <<
construct is a so called "here document". When new.sh is running, the data between matching strings (in this case, "End of file1") gets sent to stdin of the command (in this case, cat). That is, new.sh will write the body of file1 into file1, and the body of file2 into file2.
> The file is open
No, it just seem to be open. Your openfile function does open a file, but does not pass it back to main. The main's fp remains uninitialized.
> note: previous implicit declaration of ‘findEntry’...LINE 15
The error message means that by the moment the compiler sees the use of the function, it didn't see neither its prototype nor definition. In such situation the compiler must guess how it should be prototyped, and usually it guesses wrong (it will presume that the function returns int).
Put the prototype somewhere above main(), and the error would go away.
Using http://www.daniweb.com/forums/forum2.html as a starting point I can navigate forums at the tolerable level of discomfort. The out-of-style look of the page gives an impression that it is planned for deprecation. So, my first wish is please don't deprecate it.
Second, it would be much more comfortable, if its contents were filtered according to my preferences.
> I suppose it depends on your perspective. If not having to call free feels like a straight jacket then we can word it in a bad way. If not having to call free feels liberating then we can word it in a good way. What's your take on garbage collection?
The announced goal of the io_gets is to handle very long strings. Therefore it feels that the library must be prepared to the out-of-memory condition. Now, what can be done in that situation? The answer is, absolutely nothing. Me the user can't call free, or face some unpleasantness at the atexit time. So, even though the pointers to allocated memory aren't technically lost, the memory itself is unusable. It becomes a well-managed memory leak.
Which brings another point to consider. Correct me if I am wrong, but the memory will be deallocated at the program exit time anyway. The memory pool library -as written - just takes over the system job, nothing more. The pooling would make sense only if it lets the user manage itself.
That said, you already disclaimed that the library is not complete.
Just a few (very random) comments.
1. io_gets.c calls for #include <errno.h>
. I realize it gets included through one of the headers anyway, but let's be explicit. BTW, why bother with errno at all? In this particular case it doesn't add anything which would help in recovery.
Besides, I firmly (and humbly) believe that a library function may resort to errno only if it can't possibly flag an error in any other way.
2. > does not force the caller to free the resulting pointer
I'd say, it forces the caller not to free it. I don't think it is right. The library should at least provide a way to reclaim unneeded strings. That said, I seriously doubt the value of deallocation at exit time.
3. > Storing the newline is unnecessary
Again, can't agree with this. It destroys a very valuable piece of information, namely, did io_gets return due to a newline, or due to an allocation failure. The way the code handles it (via errno) forces the caller to check errno after every call to io_gets. I don't think it is right.
> Dev-C++
Missed that.
The linker does only one pass over the command line; it processes arguments in order they appear, and pulls objects from the libraries to resolve symbols which are currently unresolved. By the time it sees CPlib.a and gamelib.a (see line 30) there's no unresolved symbols yet. Change the order of files at line 30 to
SDLMain.cpp CPlib.a gamelib.a
PS: keep in mind that your makefile is rather unconventional.
> 'fork' undeclared (first use this function)
This is really surprising. Is it the only error message? Does it maybe complain about unistd.h not being found?
I don't see anything wrong with the line 9. Can you post an error message?
I do see however an error at line 10 - missing parameter for the second %d
so I know the issue is most likely not the makefile, but I could be wrong on that.
So can you post a makefile?
class polygon{ int n; point *points; public: polygon(int n){ point *points=new point[n]; this->n=n; };
At the line 6 you initialize a local variable points
. The member points
remains uninitialized.
Post your requirements. Until then, no advice is possible.
#define FERMATH #if[B]n[/B]def FERMATH class Fermat {...}
Your include guards are wrong. What happens here is that the code for class Fermat is only included if FERMATH is not defined (and of course it is!). Swap the directives at the beginning of the file.
He's comparing an int to a pointer at line 18. And assigning a pointer to an int at line 19.
Changing double quotes to single quotes (at line 18 and 19) would help.
You have to clear()
your stream.
When the line ends with the last number, a corresponding extract hits the end of string, and the stream is in end-of-file condition. Calling str() does not clear it.
Irrelevant parts snipped:
bool enque(QUE *que, void *data) { .... newNode->data = data; ... } int main() { ... char *data; .... for(i = 0; i < strlen(infix); i++) { token = infix[i]; *data = token; enque(que, data); } ... }
The main() passes the same pointer in each call to enqueue(). The enqueue() doesn't do anything with it, so each node points the same data. A simplest fix is to store not a pointer, but a value:
typedef struct QNODE
{
char data;
struct QNODE *next;
}QNODE;
bool enque(QUE *que, char data)
{
....
newNode->data = data;
...
}
....
enque(que, token);
....
memcpy()
comes to mind..
p is getting overwritten here how will we add that here.
if ( e % 2 == 0) { p = b*b; e/=2; }
Oh. I didn't realize you are doing that.
Back to the original:
while ( e ) { if ( e % 2 == 0) { p = b*b; e/=2; } else if ( e % 2 == 1 ) { p = b*p; } }
Let's say, e
is a power of 2, so the code never enters the else
clause. Can you tell what would be the result?
It is only copying the file buffer up to the null char into the http request.
sprintf(Post_Request, "%s%s\r\n", Post_Request, ReadBuffer);
Sure. What else would you expect from "%s"?
Probably, you want to print(value)
instead.
PS: note that subprocess.call returns the exit status, not the output. You may want to redirect stdout.
How about
else if ( e % 2 == 1 ) {
p = b*p;
e -= 1;
}
First of all, use code tags.
Second, it's not what I advised you.
for(i=1;i++;i<=10) { for(j=1;j++;j<=10) { T[i][j]= (T[i+1][j]+T[i-1][j]+T[i][j+1]+T[i][j-1])/4.0; if(i==5&&j==8){ T[i][j]=100; } temp[i][j]= T[i][j]; } }
is surely wrong. The whole point was to calculate temp based on T:
for(i=1;i++;i<=10) {
for(j=1;j++;j<=10) {
temp[i][j]= (T[i+1][j]+T[i-1][j]+T[i][j+1]+T[i][j-1])/4.0;
}
temp[3][8] = 100;
}
and then copy temp back to T.
Now, about loop conditions: i <= 10
is also wrong. Can you figure out why (hint: in C, indexing starts with 0, yet in this case i = 1
is surprisingly correct), and how to do it right?
PS: I intentionally omit one important step.
scanf ("%d", A[i][j]);
This is what is wrong (hint: scanf needs an address to scan into).
Is this a class for computer science, numerical analysis or math.phys.?
In any case, the way the assignment is written, you'll need 2 10x10 arrays. Iterate over the "first" storing new estimates in the "second". Compare the "second" values to the "first" using a proper metrics to find out if there's no progress anymore, and it's time to stop iterations. If another iteration is still necessary, copy the "second" values into the "first" and keep going. That's a CS approach.
Alternatively (MP approach), forget the initial conditions. Realize that what you have is a Laplace system of 63 equations with 63 unknowns. Just solve it.
PS:
average of the temperatures in all segments surrounding it; T[j]=(T[i+1][j] + T[j+1] + T[j-1])/4.0
There's surely a typo here. What happened to T[i-1][j]?
The value is just a pointer
... so it must oblige to the pointer alignment requirements. If the pointer is fetched correctly, the call would succeed. However, if it is stored at the odd boundary, chances are you'd fetch not what you expect.
This UB stems from the architectural issues indeed. On most IA32 based platforms you wouldn't notice anything strange. Still it is an UB and must be avoided.
*(unsigned int*)&recvline[0] = 11111; *(unsigned int*)&recvline[sizeof(unsigned int)] = 22222; /*this section*/ *(void(**)(void))&recvline[2 * sizeof(unsigned int)] = (void(*)(void))&myhello; /*this section*/
Casting is not for l-value. Only for r-value.
Correct, but not applicable. The result of cast, e.g. (int *) foo
, is not an lvalue, and cannot be assigned. (int *) foo = bar;
is incorrect. However, it can be indirected all right. * (int *) foo = baz;
is perfectly OK.
Regarding the original post, though well-formed, the code may invoke an undefined behaviour. The alignment of unsigned int (and a function pointer) is stronger than that of a char; a situation specifically mentioned in 6.3.2.3.7 paragraph of a Standard.
when you say "have nothing in common with other variables of the same name. " Are you talking about the lettercode and GPA? Am I opening the files incorrectly? Don't you have to use the same variables in the function? the lettercode and GPA never change they just get read from the file? This is horrible I feel so stupid right now.
Removing all irrelevant lines, the OpenFiles function boils down to the following:
void OpenFiles(char& lettercode, double& GPA) { ifstream input; input.open("ch7_ex4.txt"); ofstream output; output.open("GPAout"); }
It declares two local variables input
and output
, does some magic with them and returns. One very important thing you must realize is that once the function returns, its local variables are gone, as if they never existed. As coded above, the function has the same effect at the rest of the program as if it was
void OpenFiles(char& lettercode, double& GPA)
{
ifstream foo;
foo.open("ch7_ex4.txt");
ofstream bar;
bar.open("GPAout");
}
Later on, you try to use input
in
void Sum_GPA(char lettercode, double GPA, double& fgpa, double& mgpa, int& fcount, int& mcount) { ifstream input; input >> lettercode; input >> GPA;
and again, input
is a local variable. It does not relate in any sense to input
which was declared in OpenFiles
.
Hmm, I see.
Soo, I made the suggested corrections to the grammar (removed the unnecessary context_checks), but when I came to this part of your reply... I was confused. What do you mean "gen_code does not belong to the context_check"?
You have the context_check function which calls gen_code(). In my opinion this is wrong.
context_check( enum code_ops operation, char *sym_name ) { symrec *identifier; identifier = lookup( sym_name ); if( identifier == 0 ) { ... } else gen_code( operation, identifer->offset ); }
The said opinion is in part due to the functionality of context_check, which only validates the existence of the symbol. Really checking the context is much more involved (see below).
Can you clarify as to what direction I need to move towards to get my grammar looking more "sensible"? Other than removing the context_checks which were placed in error, I really didn't know where to progress from there.
The "sensible" related to the Pascal code being parsed. Speaking of direction, I'd concentrate efforts first on a symbol table. Right now you only store symbol names there. You need much more of course.
First of all, symbol types. I am not sure if your grammar supports any type system, but at least you have to somehow tell apart variables from procedures.
Second, local variables. Currently your symbol table is flat, which means that every symbol belongs to a global scope. Each procedure should have a private symbol table, and a proper name lookup discipline …
I only had a brief look at the grammar file.
One thing that strikes immediately is that you call context_check in the variable_decl rule. This is definitely wrong. The variable declaration introduces a new identifier, so you want to install it into a symbol table, rather than make sure it exists.
Another is that you do not need to (and in fact, cannot) context_check on expressions (as you do in the 2nd and 3rd choices in the statement rule. You are correctly checking at the IDENT choice, and that should be enough.
Regarding gen_code, in my opinion, it does not belong to the context_check. A check is a check, no more, no less. Code should be generated later, when you have a sensible piece of code (such as a statement) parsed into an AST. But, at the state the project is right now, I wouldn't worry about code generation at all.