Comments by merano99 (Top 200 by date)

Since it converts the number 88 into a string and passes the result to a function, I assumed more than one character. I think that a char* is needed. The prototype of the function would help here, but unfortunately, as so often, important details are missing.

He probably doesn't know how to convert the result into a const char*.

Even as a newcomer, you can't avoid reading the documentation, e.g. on strings. The string object “charge” contains the text “88”, correct, but your function seems to require an old (non-constant) char pointer. It would be much easier if you could change the function to const char*, but this way there is a type conflict that my code tries to work around. Of course you can use the code inside a loop. If you know the maximum length it would also be possible to request the memory only once with new and release it again at the end.

If “C:\SFML-2.0\include\SFML” is currently listed under “Additional include directories”, “C:\SFML-2.0\include” would probably be appropriate here.

The assumption that something is wrong with the path is obviously correct, but the subdirectory “SFML” under “C:\SFML-2.0\include” would be there if you have not renamed it or moved files. What surprises me more is the outdated SMFL version from 2013, which may not fit well with current compilers.

Changes to the non-client area, i.e. title bar and menu bar, are not trivial. I would be interested in the functional owner drawn menu. It would probably be best to open a new question and post the already working code there first.

The initial size is known exactly with MenuInfo.cch and is also used by you when reserving the wstring. The TCHAR is compatible for both variants (A+W) of the system calls, which is not the case with wstring. Only the fact that the memory is automatically released with wstring speaks in favor of string objects. I hope that the original question has been completely answered by my contribution. If yes, please mark as solution ...

The claim that "the whole stack is allocated when the process is created and cannot be increased after that." is not entirely correct in this form. Under Linux, the stack size of a process can be changed with the ulimit command, for example. If the stack is set to "unlimited", this means that the stack theoretically no longer has a fixed upper limit. The process can use as much memory for the stack as the system can provide without being restricted by an artificially set limit.

This has nothing to do with C, but rather with the compiler or its settings. The errors are already reported in Visual-Studio without any special settings. If you use gcc, you usually have to set a lot of flags so that it notices something.

Yes, please create a new thread with a suitable heading if you have further problems.

what about "lattice[site] == EMPTY;" - makes no sense

Please use the improve link above to describe exactly which functionality is required. I can't do anything with the comment.

It's nicely packaged, but does it really solve the problem? I suspect that the suspended message processing is causing additional problems due to the long OP. The window is not updated and the mouse pointer is probably not displayed.

You are right that a cursor with an instance handle would have to come from the application's resources, while NULL would use a system cursor. I suspect that the suspended message processing is causing additional problems due to the long OP. The window is not updated and the mouse pointer is probably not displayed. I have further suggestions, see my solution.

+5

+5, looks good

The comments that fgets() requires the specification of the maximum buffer size and not the length of an uninitialized string are correct, but do not answer the question of why the result is 4 and not 3 when entering "abc".

Exactly. I would also like to add that the missing end of the string becomes a problem for all entries with 100 or more characters. In addition, one could also think about what should happen with the rest of the line.

Thanks for the hint, since the previous solution was fresh I had probably overlooked the date of the question. I'll delete the solution so as not to confuse others.

Undeclared functions and identifiers: displayDescription, levelInfo, transitions, handItem, endGame.

+5, I also see the problem with insecure data types that are also accessed globally.
Especially with the announcement that it could possibly also be used by other developers with multithreading, I would save the length, copy the data and possibly also make the original data type checkable.

I did not see a download option for the compiled file, but I was able to create it without any significant effort. As I had already set up the WSL2, only three simple steps were necessary. Download with wget, unpack and call "do". If it helps I could provide the result.
Although I have not tested it with these files, Visual Studio can also be used to conveniently edit Linux-based programs remotely. But in the end, programs are created that are based on the Linux API.

Thank you very much! Unfortunately I have to withdraw my answer. Although the 4 jumps did not cause a crash for me, they require a presumably segmented solution.

It would probably be better if you discussed your problem based on your current source code, e.g. a link. Without knowing exactly how your data is currently displayed, but based on the requirement that it should be based on Win32, the article Custom Controls in Win32 API: Scrolling by Martin Mitáš would be a possible starting point. There is the "Advanced scrolling example".

In your proposed solution, you are already assuming that k is positive. The search starts asymmetrically at 0.
Usually, however, the solution is not known and I would read the (poorly implemented) approach of the questioner with the asymmetric loop in such a way that the solution could actually also be negative.
Your approach would also not find any negative solutions.

Another point is that the extremely frequent summation or subtraction in the floating point range can generate high errors.

Starting from a symmetrical loop with for ( i = -310000; i < 310000; i++) the result would be with your approach with k += kInc;

i = -10000
formula = 2.2370993946196904e-12
k = 3.0000000000111862

If you do not add up, but multiply by the loop index, the result looks like this with k = i*kInc:

i = 300001
formula = 0.0000000000000000
k = 3.0000000000000004

Please bear in mind that my proposed solution covers a much larger area, which would have led to the following result with your solution:

i = 300000
formula	= 4.6054271507500744e-12
k = 3.0000000000230274

Since the questioner knows that the result 3.0 is correct, he should have told us his constants and the start value.
I have thought about why the loop starts at -10000 and come to the conclusion that it is better to calculate k with the loop index i. k = offset + k_step*i
If you were to add Rick's and my solutions to your approach, you would have to check (fabs(formula) > epsilon), calculate k with the loop index and, as you correctly described, increase the range of the loop to such an extent that the supposedly correct result 3.0 has a chance.
I'll wait and see if my comment has any effect on your suggestion before voting.

You are absolutely right, and on closer inspection several problems overlap here.

I consider the finding that the step size or the loop range was selected far too small to be valid. However, I consider the direct comparison of two float numbers to be fundamentally wrong, regardless of which values are being compared. Especially if the incremental part cannot be represented smoothly and even if the error increases due to continuous addition.
Since the solution is not completely correct, full points cannot be expected.
Unfortunately, the correct and important findings were not posted as a solution, but as a comment on the completely different solution, why?

There are so many mistakes, you have a free choice.

Thx!Your comment that all variables should be float or double is important. I would have assumed that.

+5, exactly that should help

Successful implementation would require good C or C++ knowledge and an understanding of Windows system calls. In other words, knowledge of how to connect an input field and the proposed function to the required program.

Apart from the fact that the answer may not reach the questioner 13 years late, there are a few problems with the code in VS.

1. the include file "zss.cmnlib.h" is missing. Therefore some declarations are missing.

2. the macro "DEFINE_GUID" has more arguments and the compiler generates warning C4003.

3. in C++ mode Visual-Studio generates error C2440 at char* sendbuf = "AT+BTVER?\r"; with the hint that a const char[] supposedly cannot be converted to char*. The error is not displayed in C mode.

This seems to be another explanation to the original question with a requirement to be considered. It would therefore be better to delete the text here and add "Improve question" to the original question above.

In fact, he wrote: "as the player moves through them."

The point that Alan is not offering a solution, but is helping to narrow down the problem is correct. My comment was not meant as criticism. I was interested in whether the code actually behaves differently under Win11 than under Win10.
To find the responsible window handle, I would suggest testing whether you could follow the process hierarchy. The process that you have started yourself is known and you might be able to find the child that starts it. This may be time-critical, as the original process could end prematurely.

I have tested the code with VS under Win10. The Calc app is started in the background and the string title is empty. The launched app Calculator is located in the directory "C:\Program Files\WindowsApps\Microsoft.WindowsCalculator_11.2311...." and thus corresponds to what Alan N describes. So far, this suggestion does not fulfill the wish to determine the title of the started app.

As already mentioned, I would expect a Windows exe to start with the bytes 4D 5A. I would not store the data as a string, but as a binary array to save space. I can't comment on the implementation under VB. The specified data does not look like a valid Win32 exe file. As a test, it should be possible to write the data to a binary file to see if the original exe file comes out and if it can be started without errors.
By the way: The DOS header could also be omitted, as it is skipped anyway. The function would only have to be changed slightly.
I would suggest the conversion byte by byte, e.g. with this program https://github.com/LucaBarile/HexFileConverter.

It may be that the examples under "Flicker Free Drawing In MFC" worked back then. Current compilers can no longer cope with this without major changes.

What is the declaration of list_array?

The restriction with divisor = 10000 could be avoided. See my suggestion in Solution 2.

With a 16 - bit integer as used in the union (int16_t), the worst - case estimate would be a five - digit negative number such as - 32768. Including the sign, the resulting string requires a minimum of 7 characters.

I have copied the declarations from the comment to the question as it is relevant for meaningful answers.

I am pleased that I was able to contribute to the solution. Please don't forget to award the stars and mark my suggestion as solution so that the question is displayed as solved.

I have no idea what Gandalf has to do with the problem. The description of the task lacks information on what exactly should happen with a full stop or a comma, for example.
I have expanded my solution a little and assume that you can now do the rest yourself.

I have improved your original question for you with this post. Please do not post a solution as the questioner, but update the original question if you want to add additional details, or your final solution at the end. Please delete this post.

Since my answer has helped, it would be nice if you could mark my answer as a solution. Otherwise it could give the impression that there is no solution yet. Points would also be appreciated.

It's nice that my suggestion was able to contribute to solving the question. It would be customary to mark helpful suggestions as solutions. Then the question will also be displayed as solved. An own (final) solution could better be written as an additional paragraph with "improve question" instead of as an own solution.

"read up on EXIF" was my suggestion, it is strange that the questioner posts a solution on this basis, which then also gets points, while my suggestion is neither marked as a solution nor gets points.

The source code is identical to the posted question, so it cannot be the solution. If the source code is not the solution, it should be deleted here.

Have you tried to write the program? Please show the attempt here and ask a specific question. If someone were to write the program for you, you would hardly make any progress.

I'm delighted, congratulations!

This function is far from what it should be. Please open a new question for this. Also use the prototype I suggested, otherwise it won't work.

For performance optimization, you could perhaps also use std::transform.
transform(values.begin(), values.end(), back_inserter(averages),
[](const Value &v) { return (v[0] + v[1]) / 2.0; });

After I added the missing parts, the solution seems to work. I had tested it, of course. What exactly is not working yet?

The amount of data to be transmitted is already known. It would be unnecessary to send this additionally. The MPI_Recv was already running, now it should work asynchronously in exactly the same way. If necessary, ask another question for this new version.

isn't!
Why not MPI_Waitall? You need 2 requests for two requests per process, no more.

Then my suggestion for improvement would be:
MPI_Request request[2];
MPI_Irecv(A, ...);
MPI_Irecv(C, ...);
MPI_Waitall(2, request, MPI_STATUSES_IGNORE);

The above code is error-free and fulfills all the conditions we have been informed of here. Without further information, I cannot contribute anything more.

I am wonder why no one else has contributed to your questions. My suggestion is to ask the teacher if MPI_Gather is the feature you are looking for, or alternatively implement your program with it and submit it. It could be that the teacher expects something like this. If you have any questions, please start a new quest with a suitable heading.

I had pointed out to you several times that Hungarian special characters do not fit well in a char-string.

But the problems and my answers to them are the same. To be honest, I am shocked that the source code has regressed compared to the previous 3 versions. The source code is not even compilable. Instead of the discussed function for reading the (Hungarian) CSV file, fscanf is still used.
In addition, Kerdesek (Questions) was unnecessarily renamed to Adatok (Data). At least under Windows, reading the Hungarian CSV file with char strings does not work. Strings are unnecessarily copied several times without checking the length. In addition, there are many sprintf(), although you could simply copy strings with strncpy(). I had already noted that Hungarian special characters will probably not fit well in a char-string, but this is still being tried.

You will have to revise the hozzafuz() function so that it can fulfill its function. If necessary, please open a new question, copy the current source code (with translation) to the question and describe what the problem is. PS: Thanks for rating.

It makes no sense to send me your work, if you have given all the relevant information here, you would have to find out for yourself what the problem is with the code. It would be possible to upload documents and code to github and post the link. Maybe someone else here has a suggestion on what to do differently.
In addition to Scatter and Reduce, Gather could also be considered instead of the for loop. Maybe that is an option that works?

I don't like the for loop to collect the results either, but MPI_Reduce wasn't wanted either. Are there any alternatives that can be found in the documentation?

What exactly did he say? Are there any other general conditions that have not been mentioned here so far? Did you submit the uncommented code above in exactly the same way?

MPI_Isend is supposed to run in parallel? Yes, it allows the calling process to continue directly and carry out its own activities before checking whether sending has been completed. The time between MPI_Isend and MPI_Waitall can therefore be used ...

Looks OK now. Now answer the teacher's question correctly and it's finally finished. Comments in the source code would of course be helpful.

It would be necessary to think about the location of MPI_Waitall. With some certainty exactly the point that the teacher meant. I would also declare and use the variables requestA and requestC only for process 0, as no other process needs them.

I have answered your original questions several times in the meantime and the hints have not yet been accepted as a solution. If you keep changing the requirements for the original question, it is very unsatisfactory. It would be better to leave the original question for review and reward the solutions with stars first. Then you can post a new question and ask it again under the changed conditions. Simply replacing your original code with my solution so that my answer looks funny is not a sensible approach.

see above.
Note: It would be better to add code changes to the top of the question instead of as a comment. Please move the source text to the top and delete it here.

Please look at your line: char *token = strtok(line, ",");
Note: It would be better to add code changes to the top of the question instead of as a comment. Please move the source text to the top and delete it here.

It seems to work for now, but there are still shortcomings, here are some examples:
1. When declaring the MPI_Request variables, memory and effort should be reduced.
2. The calculation of globalMin should be implemented in such a way that time is not wasted.
3. Many comments are missing that could improve understanding.
4. Almost all evaluations of return values are missing

And also remember to confirm all solutions that were useful, unfortunately this has been forgotten so far.

"UPD: the teacher said that there should be only one check if(rank==0) - is it realistic to do so?"
To implement an MPI program with only one check if(rank==0), you could execute the same code in both the if and else branches. I think this is (gross) nonsense, but of course it would work.
The program will be longer, more confusing and probably more difficult to maintain, but if there is a good grade for it, I wouldn't argue with him.
Of course, it could also be that the teacher wants to see if you can do it yourself, because no one will do that for you.

I have added an extended program framework to get further here.

I would not assume that it works now, because the calculation if (rank < hvost) { pSize++; } still does not calculate an individual size for each process. I would also not let (size - 1) processes calculate, but let process 0 participate in the calculation. This would also work if there is only one process. We are still missing concrete questions or at least your description of what does not work from your point of view.

The linked article deals with C++ threads, but the questioner uses MPI, i.e. (distributed) processes - not threads.

What exactly is the question?

In the task description no restrictions of the MPI functions are required. Instead of MPI_Reduce, MPI_Send can be used again at this point if necessary. This does not change the basic proposed structure of my proposal. It would only change the comment suggestion in the last line. My suggestion would significantly improve the above program and also shorten it greatly.

yes, that's right, I read it wrong.

You wanted to say cos(x)/sin(x) = tan(x)?

Yes, of course. Thanks for the addition!

Are you sure you meant to say physical address?

That the HANDLE of each resource must be different, so that the OS can manage them was clear. Calling GetModuleHandle(NULL) always gives me the same value, no matter if in the exe or in the dll. According to the documentation this is the module handle for the specified module, here the exe file.
For the above question, however, neither HMODULE nor HINSTANCE seems to need to be bent in any way. Everything runs in the same address space and in the same thread, and that is essential.
I'm deleting the comments about HMODULE and HINSTANCE because they are not part of the problem for me.

The point is, that the exe and the dll run in the adresspace. I'm not sure if any of your suggestions help to solve the above, so I won't say anything about it. Somewhere there is a showstopper in codewitch code, I could not find it.
The linked documentation clearly states: "Each process has its own window class list". DLL and exe are the same process and here even the same thread.

The text is translated with a translator into hopefully correct English. I could still offer my original to translate yourself. I even took the trouble to reproduce codewitch's problem, however my test program runs as I would have expected. Don't understand why you devalue me.

Two comments:
1. thread change times below 16ms are hardly feasible in the default setting under Windows, as far as I know. Working out messages with shorter spacing could cause problems.
2. it is not seen with pleasure, if questioners post their answer as Solutions. If you have solved the problem, it will be gladly accepted above as an extension under the asked question. Then everyone will see it, and you can ask questions about the solution you found.

+5, According to my knowledge, thread change times below 16ms were not possible under Windows, at least in the environment I tested. Even if the PerformanceTimer resolves more precisely, the processing of a message could probably also require this minimum time.

If there is already a dialog, then there should be a header in which it is declared. Usually this is a dialog class directed by CDialog. The files belonging to the dialog must be added to the project. Then the header should be included with #include. The call can then be made with DoModal if it should be a modal dialog.

The header seems to be included, otherwise it would not know the constructor CStatisToDayDlg(class CWnd *). If the dialog is available as .cpp it must be included in the project. If it should be a library, this would have to be communicated to the linker. There are many details missing and so this becomes a guessing game.

A CWnd object is a C++ window object, this applies to almost all under Windows. Here as basis a CDialog would be more appropriate.The error "unresolved external symbol" means something is missing or cant be found.

If I understood correctly, my linked solution attempt was not accepted as a solution because it did not find its way into the brain? I hope that it was not due to an incorrect translation. It would have been clearly better if you had posted corrected code than to ask the same nonsense again as a new question.

I would like to point out my remark that the compiler here ( pt->a + pt->b + pt->c ) sees the danger of an arithmetic overflow. A typecast to double would be necessary.

thx

I have seen it, meanwhile several have tried to help. I give you 5 for your attempt, but have considerable doubt that this time it is useful.

I already tried to correct the code in his previous post with the same problem. see there.

Top! Yes, that's exactly how it is. I'll remember that saying. You get +5

It gets worse ...
Apparently, the questioner does not read the answers, or not correctly. I had already here
https://www.codeproject.com/Questions/5368041/How-to-fix-item-declaration-problem
written the following:
"ItemType cannot be the type and the name of a variable at the same time."

yes :-)

Unfortunately, I can currently change the height and width with the program under Windows 10, but the position of the taskbar does not change yet. Also SHAppBarMessage(ABM_SETPOS, ..) does not seem to work. At the moment I can only change the position with the mouse and via taskbar settings. There must be a solution with C, but at the moment I can't find one.
Moving is allowed via a registry key, that could be set here: [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced] "TaskbarSizeMove"=dword:00000001

Thanks! It should not be a problem to compile the code with VS2013. There is nothing special included that will cause problems with a MS compiler. I would recommend creating a new Win32 console project and copying the source code into it. Note: The project linked on Github seems kind of weird, I had problems with it too.

It works, but aren't WMSZ_TOP and WMSZ_BOTTOM reversed?

I have tested the program on a Win10 system with a screen resolution of 1920 x 1080. The result is the following size of the taskbar:

1 lines: 1920 x 40
2 lines: 1920 x 81
3 lines: 1920 x 122

With -b 80 nothing happens, with -b 90 it switches to 2 lines with a height of 81. A specification in pixels does not seem to make much sense.
In fact, it does not seem possible to switch directly from 1 to 3 lines. However, this could be solved easily, since the old size is determined at the beginning and it is therefore foreseeable.

With Win10, as expected, the win32 (x86) version also works under X64.

I find it somewhat strange that the parameters -b -t -r -l occupy in each case own variables and besides can be used at the same time. Here ONE enum with the 4 possibilities would be perhaps better.

If you multiplex the 8 output data bits with the 4 outputs of the control register two simple latches would be enough. The circumstance with the shift register seems to be due to the the special task. Technically this does not seem to make sense for the time being.

With two simple latches, like e.g. 74HCT573, the programming would be much easier.

Thx!

Without the code, no one here can guess why the expected result is not coming out. The code posted as a Solution does not seem to take into account several things.
Please move your own Solution to the question and comment on what exactly is wrong.
The definition of neighbors is not symmetric and would declare a single diagonal connection as a neighbor, but only in one direction.
This seems neither reasonable nor correct. If you define the neighbors above, below, right and left as usual and also apply the DFS as in my Solution 3, the result for the example is exactly 6.

It is better to use fgets() to limit the maximum length.

You also learn a programming language through practice and feedback. I didn't want to let it fail here because of the feedback :- )

Thanks for the comment. The memory interface is now wide enough to handle 64-bit in parallel, I had that in mind as well.
I listed it under the desired aspect "effort for conversions" anyway. Whether or how this affects performance would have to be investigated separately and would probably also be system-dependent. To get along with less cache could perhaps have a positive effect.

"Int64 is the native integer length and can be done in a single instruction."
Sure, but that says nothing about performance. We agree that you have to put work into it to make comparisons and optimize the algorithm. With C and C++ the native integer length remained on the systems known to me with 32Bit. But that can change quickly and is also system dependent.

If I understand it correctly, it is sent every 10 sec, but the connection setup as well as receiving the data takes almost 1 minute?

If you can not send and receive at least so fast that the data can be processed, it comes to data congestion.

I would copy the incoming packets to larger packets and send them only from a minimum size.

If this is not possible you have to work asynchronous and parallel (multithreaded). What kind of data is this?
Some questions run through my head: Do the data packets contain a date or a numbering? Is the order, as well as the runtime critical?

Note: 1 minute is an eternity in the IT world. Is there no way to speed it up?

Using mutltithreading under Linux with C would amount to thread generation (possibly Posix library) as well as synchronization with mutexes.

Is it possible that the very long time when filling the buffer only occurs because a timeout is waited for here?

Here a solution would be to work with a fixed packet length and not to wait until nothing more is received.
It would also help if the total packet length was included in the first received bytes.

It would be useful to add all helpful information to your problem above in the original question, so it can be found by all. Alternatively, create a new question with all the parameters.

Thanks. Ok, overlooked that someone woke up a dead body. I delete my belated post it then just now.

thanks for the tip, I do not notice such things :- ), and thanks for 5

It doesn't work that way for me. My compiler expects the data type size_t as index and does not handle larger data types. For the code to work cross-platform and correctly it is recommended to use size_t. If the data type for the index is larger than size_t, more memory is required and overflow problems can occur.
The calls vm.resize(u + 1, 0) and vm[u] generate the following warning with me: warning C4244: "Argument": conversion of "unsigned __int64" to "const unsigned int", possible data loss.
With a custom template, the solution works, so +5.

Your function works with my suggestion. Have you tested it? You can get the TEB with gs:[00000030h].

I assume that it is not enough to submit a program. To be able to explain it, one will have to deal with it. Anyone can use the AI anyway. Schools are now also adapting to this.

Why do you tag the code as C++ when it is 100% C code?

5+ Thus, everything is actually said.

The usleep() function causes an EINVAL error if usec is greater than or equal to 1000000, and nanosleep() also provides a higher resolution. So it is actually clear which one should be used.

Thanks for the tip. I overlooked, since someone had brought it up.Then I better delete it again.

Glad to hear that it now works as desired and you have learned something from which you will benefit in the future. That's the way it should be! Thanks for accepted solution and the stars.

Are you sure you really want to recommend scanf("%s", stringVariable);?

5+; very nice, thanks for mentioning

Since you can't specify the buffer size with gets() too long user input would quickly overwrite something, I would suggest fgets().
https://cplusplus.com/reference/cstdio/fgets/

In addition, the gets() function is no longer supported by current compilers for these reasons as well. [NOTE: This function is no longer available in C or C++ (as of C11 & C++14)]

If my post was helpful, I would appreciate rating it and marking it as a solution.

+5, I come to the same conclusion here.

I had written it exactly the same way, right? " ...already done with the merge() function."

nothing to add, 5+

The alternative to a vector would be to wrap even a concatenated list in a class. But that would be unnecessary in C++ and not recommended. Rick's suggestion to use an array and reallocate memory each time would mean that everything would have to be copied multiple times. If you don't use a C++ container you have to take care of memory yourself and release it at the end.

+5

First of all, you can do the math: 40 x 40 x 4 bytes = 6.25 kByte
As long as the know-how for dynamic memory management is not enough you can (if necessary) leave it like this. As soon as the grids get bigger, you need more than one or recursion is desired it will not work well anymore.

The grid is defined by the decalation and also initialized by the assignment with empty. The code that assigns all elements with consecutive numbers should probably just be deleted. From my point of view there is no additional problem here.
If you want to keep the grid variable and also use very large grids it would be recommended to get memory from the heap with calloc(). However, this would be much more complex and requires some experience.

I had overlooked that the number of calls of the "operation" are counted, not the number of necessary swap operations.
If the "operation" is really only allowed to always replace each existing letter a in str1 with a (freely selectable) letter ß, one would have to call the operation several times and do additional work. A lookup table would also be helpful here. More runs would then be necessary when the problem occurs and additional characters would have to be managed in it.

I had noted errors that probably change the flow completely. It would be necessary to take these remarks into account in the code and adjust it. Where at the run tested by me still an error occurs I did not experience.
Instead of writing another new output here as a comment it would surely be much better to write an example output at the top of the question and explain exactly where something goes wrong, what the calculation base should be and what output is actually expected.
Since the source code is long and confusing, also because of the gotos, a further limitation in the source code would be helpful. Usually one writes subroutines and avoids gotos.

thanks!

str1="bacd"; str2="abcd"; // 3 changes ??
There are only 2 changes here. Introducing an additional letter does not seem to make sense and would significantly complicate the task. Would that really be part of the task? It would mean that no letters may be exchanged directly, which already occur. One would then have to introduce new letters, remember which places would still have to be changed in further runs.

The question is answered completely. How to write comparisons and assignments in C or C++ should also be easy to read in tutorials and books.

He didn't address the aspect that the application should be able to continuously output during execution and also receive on commands, did he?

As I said before, cross-process synchronization is not (easily) possible with pure C++. Since neither the operating system nor the compiler are known, several variants would have to be discussed here. It would be good if you could narrow down the framework.

+5. The messages disappear as soon as the functions are declared with "dllexport".

Thanks for the tip, it was right at the top - someone must have resurrected the part. I better delete the entry again.

Did you have it compiled as x64?

How does the program to be modified in b) differ from the first?

For which input does it not work and what is the result? Are you perhaps calling the subroutine incorrectly?

I had tested it, of course. What exactly is wrong?

The task is to add several lines up to the next blank line and assign the sum of the calories to one elf each. However, as Richard has already correctly pointed out, none of this happens in this program and is therefore not a valid solution.

Often there are several ways to solve tasks. A simple easy to understand solution would be Solution 4.

I would agree with you if the solution was complete. Without own contribution at the places where TODO is written it will not work. To complete the solution, you will have to understand the rest of the program. The multiplication is also completely missing here.

Thx

Why do you use Min/MaxInt here at all? You can simply set the start value to the first value and then omit it in the for loop. If you already use it, then from <limits.h>. You can never tell for sure how big an Int is or will be at some time.

The 8 should set the highest bit and that would give the largest negative value. If one assumes an int with 4 bytes, there should be a total of 8 hexadecimal digits. So here a 0 would be missing on the right side. If one already assumes that the numbers could be negative I would not output these also with %u.
The reason why the program of OriginalGriff had worked at all was that "accidentally" had used a very large number.

I'm sure you don't have to explain to CPallini what a cast does.

I cannot find the function RegCreateAddSetString(). Google is also at a loss.

You can use CreateProcess(). See update.

+5

Unfortunately, you have ignored all the solutions suggested here and come up with a solution that is even worse that the original code. Also, it is not desired that you answer your own question here. It would be better if you marked the new code as an update and attached it to the question above.
The code is not only wrong, but makes complete nonsense. Moreover, it cannot even be compiled.
After improving the incorrect brackets you would get the answer 1 if you enter e.g. 100.

OK. I guess I had forgotten about this version. Makes sense, of course. Have improved it.

You're right, according to the documentary, count is fine without -1. With std::string you would have to ensure the capacity and write it directly into the buffer. And then you would have to specify this length. Methods that could automatically increase the string are not used with getline(), in my opinion. I would not want to read multiple lines here.

Please do not post a solution to your question here yourself. Better would be to add to the question above already found solutions with appropriate reference.
Maybe it would be better to mark the helpful solutions here as a solution and give an appropriate rating. Then ask a follow-up question with new questions

I don't know what problem is meant by "the problem exists". I have extended my solution again.

+5

Please do not post questions as answers, but directly under the solution to which are questions. Alternatively, you could expand your original text above. See also Solution 3.

You never will see 21 at the end.

+5

my 5

my 5

Thx

+5

You propose yourself a solution? If yes, you should explain it, if no it belongs rather above under "What I have tried".

The function mygetline() reads individual characters until either the end of the line is reached or the end of the buffer. For this the loop for (int k = 0; (k <= len); ) with the index k is run through. If the line is finished and not empty it is terminated with break. A line that has not been read completely is then deleted up to the end of line character. If the line was read completely, 0 is returned otherwise 1. It makes sense to look at the whole thing line by line with a debugger.

I needed almost no special knowledge for this and I wonder how to comment "learned all this". For C, the book by Kerninghan & Ritchie (second edition) is enough to start with. However, it doesn't deal with the brand new features of C, but you can learn them later. In addition, you get experience by programming yourself and reading in forums ... I don't know the book "Absolute Beginner's Guide to C by Greg Perry", but if you can't do anything with loops and termination conditions after 2/3 of the book, I would find it questionable.

I can't use it with Visual-Studio and the doc says it's gone.
https://learn.microsoft.com/en-us/cpp/c-runtime-library/gets-getws
With problem I meant the not limitable length.

See Solution 4 for my version.

Unfortunately gets() has been removed in the meantime for a good reason. It has the same problems as scanf() with %s. there are alternatives like fgets() or better C++ and getline().

+5

You should not fill the buffer completely with fgets() and hope that strlen() finds an end of string. I would recommend to keep the last byte free for a 0.

Never use scanf with %s, because buffer overflows are not preventable.
My suggestion would be fgets, even if it is not a 100% replacement.
NOTE: The function gets() is no longer available in C or C++ (as of C11 & C++14)
Alternatives are discussed e.g. here
https://stackoverflow.com/questions/43174201/alternative-to-gets

For me the tags indicate what it should be or what solution is desired. If something completely different appears under "What I have tried:" I assume that the questioner has problems to implement it in the desired environment or is not even aware that his approach does not fit. With C and C++ there is however as well known a large intersection.
I am not sure if it would be acceptable to simply delete or ignore the possibly wrong tags. I would only do that if it is obviously wrong or incorrect.

+5, really inefficient way - exactly that

Firstly, the answer has nothing to do with question "Convert Python to C code", and secondly, the question is already 2 years old.

Visual Studio analyzes the string argument of printf very precisely, both the number and the variable type are checked. I am rather surprised that this did not always work with every compiler. At runtime, on the other hand, nothing is checked, then the bytes are displayed that are on the stack, or otherwise in the expected places. The output is then either random, or with %s it can also crash.

When calculating the days and derived quantities, it would probably be useful to consider leap years as well.

According to the table above, it should be 1/16. Other entries in the table are probably nonsense.

yes should be printed if it is NOT a prime ? With you it is currently exactly the other way around (which would also be usual). A recursion without return is also rather unusual.

yes, +5 (some code, like IPC commands like mutex; see my suggestion)

yes, +5

"3. When the value of the Analog signal increases above 1.6 volts on all the LEDs" ???
With incomplete sentences we would have to guess how to proceed.
So there is an unknown hardware here with a two-digit 7-segment display on which an average value of a data series is to be displayed?

If there is already program code, what is wrong with it? Unfortunately, you have neither described if there are problems nor asked any questions. So what do you need exactly?

+5