|
Nowadays it's not nearly as bad as it used to be. The biggest culprit was and still is the UI, and in fact any graphics or sound functionality, simply because there are no C++ standard libraries for that. However, there are OS independend libraries around for that purpose.
Everything that is in the C++ standard libraries, including STL and BOOST, should work out of the box on any OS without changing the code, unless the compiler you're using is not adhering to the standard (in which case you should consult your compilers compatibility documentation).
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Because STL containers are much better than the MFC ones.
|
|
|
|
|
_Flaviu wrote: ... if this member has a lot of elements
Just to make a point: the elements of a container do not affect how the container itself looks like, or how it should be allocated. This is true for all STL containers, and also for CStringList.
Containers are typically designed like this: one central data structure to store the basic info about the container, and maybe it's state, and some kind of reference (or two) to the data structure(s) containing the elements. The container will take care about allocating memory for the elements on the heap. But the central structure will never need to be reallocated, nor is it very large. Therefore it is no problem at all to allocate a container on the stack.
That said, if you pass a container to a function, you should normally pass it by reference. If you don't, the container will be copied as a whole, including all the elements!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Thank you for your explanation !
|
|
|
|
|
Hi,
MFC app using CRecordset to transfer data to a SQL Server database.
Uses the RFX_Date mechanism mapping to SQL Server "datetime" data types, previously using the old "SQL Server" odbc driver and all was well. Trying to update to the more recent "ODBC Driver 13 for SQL Server" (TLS 1.2 support) and when attempting to write to the SQL Database I'm seeing the following exception :-
"Datetime field overflow. Fractional second precision exceeds the scale specified in the parameter binding."
Have found the following article which identifies the issue as related to the updated drivers (since SQL Server 2008) being unable to infer the precision of the parameter if not explictly detailed so throws the exception.
I tried changing the datatype on the Server to datetime2 with various precisions e.g. datetime2(0), datetime2(3) and datetime2(7), none of which worked.
I have subsequently read (here) that this issue cannot be resolved by server sides changes and is a breaking change for older clients :-<
It states there that Quote: I think the application change is just a matter of specifying a scale of 3.
I'm not sure what that means in terms of using the RFX_Date approach, will I have to write an RFX_Date2 replacement or is there one out here already?
If anyone has had a similar issue I'd appreciate hearing their suggestions on how to resolve this (preferably without having to do an update to the client app if possible).
|
|
|
|
|
Do you seriously need that precision for seconds?
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Can you split the seconds field, which is currently some floating-point type, up into two integer fields, one for seconds and the other for fractions of a second?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
|
good point, should have mentioned that, it's
Quote: void AFXAPI RFX_Date(CFieldExchange* pFX, LPCTSTR szName, TIMESTAMP_STRUCT& value);
|
|
|
|
|
Well, that really does not explain what is happening. Perhaps if you showed (in your original question) the actual code and the values that cause the problem ...
|
|
|
|
|
In visual Studio, I can change the DPI Awareness in the Manifest Settings (Manifest Tool -> Input and Output )
Is it the same thing as setting it in the manifest file ?
Thanks.
I'd rather be phishing!
|
|
|
|
|
Yes, add the following lines just below the root (<assembly>) node:
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>true</dpiAware>
</asmv3:windowsSettings>
</asmv3:application>
|
|
|
|
|
That's what I am doing.
Thanks.
I'd rather be phishing!
|
|
|
|
|
My task is to input individual characters , terminate the input with "space" or "ESC" and then retrieve / save the characters entered.
getchar and its variety waits in loop (?) and outputs to stdout until "enter" key is pressed.
putchar outputs ( to stdout) EACH character entered in do { ...} while loop - runs the loop.
Questions
1. Is there a way to terminate getchar other than entering "enter "?
2. How does putchar "runs" in do { .. } while loop ignoring getchar?
3. How can I "retrieve" characters in WHAT buffer for additional processing AFTER the do{} while loop is terminated ?
char next;
do
{
next = getchar(); putchar(next); }
while (next != '\n');
|
|
|
|
|
Vaclav_ wrote: getchar and its variety waits in loop (?) and outputs to stdout until "enter" key is pressed.
No, getchar merely reads the next character entered at the terminal. If the terminal is in (normal) echo mode then it displays the character as typed. The putchar function merely displays a character, it has no knowledge of the loop or anything else.
1. Yes, you can terminate on anything, just inspect the character as entered and compare it to your terminator.
2. As above, putchar does nothing beyond displaying a single character.
3. Save them somewhere.
|
|
|
|
|
I am seeing this
char next;
do
{
next = getchar(); cout << "text entered " << endl;
putchar(next); }
while (next != '\n');
qwerty
text entered
qtext entered
wtext entered
etext entered
rtext entered
ttext entered
ytext entered
|
|
|
|
|
you need to turn off canonical mode on input. man termios, and look for ICANON. As a quick test without recompiling:
$ myprog
qwerty
text entered
qtext entered
wtext entered
etext entered
rtext entered
ttext entered
ytext entered
$ stty -icanon
$ myprog
qtext entered
qwtext entered
wetext entered
ertext entered
rttext entered
tytext entered
y
text entered
$ stty icanon
See: [FAQ - Cprogramming.com](https://faq.cprogramming.com/cgi-bin/smartfaq.cgi?answer=1045691686&id=1043284392)
|
|
|
|
|
It seems that reading characters one at a time is no longer possible (on Windows). While getchar returns the characters one at a time, the system does not present them until after the enter key was pressed. So although you are trying to read single characters, they are still streamed internally.
[edit]
Same result on Ubuntu.
[/edit]
modified 16-Jun-19 13:01pm.
|
|
|
|
|
It has nothing to do with windows 
Whoever writes the C/C++ library determines how it works, you are making a C/C++ standard call not a windows call and if they don't do the standard then it is hardly a fault of windows.
On windows really the easy way is to hook the WM_CHAR and/or WM_SYSCHAR messages because the message queue is available even in console apps since windows XP service pack 2.
In vino veritas
|
|
|
|
|
I know that, I was merely pointing out its behaviour on Windows as opposed to Linux.
|
|
|
|
|
Richard MacCutchan wrote: the system does not present them until after the enter key was pressed.
Not quite true, or at least not complete: if there is something in the input buffer already, getchar will immediately return with the next char it finds in that buffer. It will only wait if the input buffer is empty. AFAIK this is not dependend on the OS.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Well that is exactly what happened in my tests, none of the characters were retrieved until the enter key was pressed.
|
|
|
|
|
No it doesn't always it depends on the canonical mode of your input, this was covered above.
The C standard doesn't cover how the underlying system is operating and it cant present what it doesn't yet have.
Richard simply has an OS that is in canonical mode.
In vino veritas
|
|
|
|
|
Well it always worked as I described for me. But I admit I haven't heard of the canonical mode before, so I'm going to trust you on this.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Hi,
There are icon for Maximize and Restore Down on Wondow Title.
Can I change Maximize icon to Restore down on button click?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
