Click here to Skip to main content
12,631,923 members (30,252 online)

Comments by David O'Neil (Top 28 by date)

David O'Neil 1-Dec-16 20:22pm View
   
I like the the simplicity of your COBOL solution! I can see a C++ STL equivalent in my head that would be a little longer, but keep your simplicity. Out of curiosity, can you determine how fast your routine compares to Graeme's output for Solution 10 on your machine? I'm just curious how efficient intrinsics are - I've never played with them.

Your "REPLACING "poo" BEFORE INITIAL "p**"" comment triggered my new approach to solving that part of the problem - without recursion! Thanks!
David O'Neil 1-Dec-16 11:28am View
   
Deleted
My code is ~11.5x as fast as Graeme's revised code on my machine, instead of 13x.
David O'Neil 3-May-16 15:02pm View
   
Doh! Thanks for catching that. It is working. Don't know why the original stopped in VS2015, but have other things to do that are more important than spending more time on it.
David O'Neil 2-May-16 22:26pm View
   
Thanks for the reply. That makes sense, but may not solve the const problem, because the error was on the lambda function line.
David O'Neil 2-May-16 18:43pm View
   
Bling's proposed solution resulted in a fix that runs without issues, so it is highly doubtful that other code is responsible. It appears to be a 'const' issue as I touch upon in my response to him. But if I have a chance, I will work up a minimal project that exhibits the issue.

Thanks for the response.
David O'Neil 2-May-16 18:38pm View
   
Entering the following gives a clue as to what is happening:

wString toUpper(const wString & str) {
wString c;
c=str;
for (auto & c: str) c=std::toupper(c); //ERROR HERE
return c;
}

That gives "... error C3892: 'c': you cannot assign to a variable that is const", so somehow it is turning const.

Rewriting it like the following threw an error about function body redefinition:

wString toUpper(const wString & str) {
wString c(str);
wString::iterator it;
for (it=c.begin(); it!=c.end(); ++it) {
*it = std::toupper(*it);
}
return c;
}

Moving the body into the CPP file instead of the header fixed it.

If you can answer why Visual Studio 2015 is being more aggressive at making things const, I'll mark yours as the solution because it resulted in a method that works.

Thanks much for the pointer, even though I still don't understand why the earlier code didn't simply recompile in 2015 without execution issues, as before.
David O'Neil 2-May-16 9:42am View
   
It will be a std::string or a std::wstring, depending on the definition of UNICODE.
David O'Neil 2-May-16 9:26am View
   
I just tried _totupper, and there is no difference in release: the program crashes. Weird. Thanks for the thought, though.
David O'Neil 2-May-16 8:48am View
   
Checking the address of a heap variable around that point in the code, I get 19EA79 in release mode, so it isn't that far from the address space, but you could be right. The fact that my workaround seems to have eliminated the problem, and everything is running, indicates the 'toUpper' call really is the issue. While debugging, I placed a MessageBox before and after the call, and it passed the first MessageBox before crashing.
David O'Neil 2-May-16 8:41am View
   
Thanks. It is puzzling!, and has made for far too long of a day already.
David O'Neil 2-May-16 8:08am View
   
I've updated the question with error code info. As you will see, it is simply refusing to let my program rewrite the memory locations in the std::transform call in release mode.

Thanks for your help.
David O'Neil 28-Sep-14 9:28am View
   
5-d and Accepted. For clarity, the specific subpage is http://msdn.microsoft.com/en-us/library/aa381033.aspx, where it says (paraphrased) "'#define' in a Resource Compiler file defines a specified name by assigning it a given value." It continues on to say,

"RC treats files with the .c and .h extensions in a special manner. It assumes that a file with one of these extensions does not contain resources. If a file has the .c or .h file name extension, RC ignores all lines in the file except the preprocessor directives."

Thanks for pointing my in the right direction!
David O'Neil 28-Sep-14 5:43am View
   
So it is only for the resource compiler itself? That compiler is constrained to using #defines, and somehow maps '103', or whatever number is used to something different than a const int or other declaration, and then the MAKEINTRESOURCE gets hung up on that difference? I'd like to understand that better if you know of any links... (Googling "microsoft resource compiler requires defines" isn't very helpful.) Thanks.
David O'Neil 21-Aug-14 12:10pm View
   
I would rather have an explicitly stated function call than an implicit conversion occur. I've been bitten by things I can't see, therefore I will shy away from the conversion operator now that I know about it.

Thanks for helping me.
David O'Neil 20-Aug-14 15:31pm View
   
Are you sure you added the CSettings unit to your non-test project properly? Are the include directories correct?

PS - I edited your question to use a code block. Please use them in the future. It makes it much easier on us.
David O'Neil 20-Aug-14 14:09pm View
   
Thanks. It isn't under 'operator()' like I expected, but 'implicit' in Stroustrup revealed the location. It is filed under 11.4: conversion operators. Your link was far from being clear to me!

To use the first one: if surrounding class is 'MyDC' and the object instantiation is 'dc': just "dc()" will retrieve the dcC. Or if it is a pointer, "(*dc)()". To be clearer, "someMethodThatRequiresAplainDeviceContext((*dc)());"
David O'Neil 23-Jun-14 11:31am View
   
You now have CFileDialog set up correctly to use wchar_t under the hood for your Unicode build, but you (or someone else) has programmed ParseFile to use a char array instead of a wchar_t array for the filename passed to it. The proper way to solve that would be to change ParseFile to take 'TCHAR *' for its argument, not 'char *', and then modify ParseFile appropriately. The link given by Sergey should help you understand what is going on under the hood better, but basically if you are building a Unicode build, TCHAR is a macro that expands to wchar_t, and if you do a Multi-byte build, TCHAR expands to char. If you use TCHAR everywhere, your program can be built for Unicode or Multi-byte without any problems (usually).
David O'Neil 13-Jun-14 5:27am View
   
The report went through and MS has confirmed the buggy behavior. Time for some sleep!

Interestingly, the unit that this reared its head on now refuses to have any in-header initializations in it without buggy behavior. Made for a rather long initializer list (25 members) - yuck!
David O'Neil 13-Jul-13 17:34pm View
   
>> You just have to find the most acceptable solution when you face a problem like this. Unfortunately its not always as clean as in this case.

And it sure is frustrating when what you had worked in an earlier compiler! But things like this are those which give insights into the craft. Again, thanks to you, as well as everyone else.
David O'Neil 13-Jul-13 14:42pm View
   
Thanks for the reminder. It has been a while since I've delved this deep into this stuff. And as far as the buggy code - for an example I won't say a thing! And since you caught it, the chance of getting to production is slim!
David O'Neil 13-Jul-13 13:55pm View
   
Yes, since I had the MyModalWindow throughout the d = call. But I was too tired to realize that, and the inline idea was fixed in my mind... Again, thanks!
David O'Neil 13-Jul-13 13:48pm View
   
That is the solution! It was simply in the "d = ... assignment that I needed to make certain everything referred to MyModalWindow, which, if you review the previous code snips, weren't the cases. Doing that, the virtual method ISN'T NEEDED - it can be a regular class function!

For clarity, here's the working code for the initial method:

class DwlWinObject {
};

template <class T>
class DwlDelegate {
public:
typedef void (T::*FuncPtr)(DwlWinObject*);
protected:
FuncPtr ptrC;
public:
int junk;
static DwlDelegate create(T* object_ptr, DwlWinObject * arg, FuncPtr ptr) {
DwlDelegate d;
d.junk = 12;
return d;
}
};

class ModalBaseWindow : public DwlWinObject {
protected:
int a;
void accept(DwlWinObject*) {
int a=0;
}
};

class MyModalWindow : public ModalBaseWindow {
public:
MyModalWindow() {
DwlDelegate<MyModalWindow> d = DwlDelegate<MyModalWindow>::create(this, this,
&MyModalWindow::accept);
int test = d.junk;
d.junk = 15;
}
};

void main() {
MyModalWindow win;
}

Of course, that means more rework than making everything public, but that's OK! Thank you very much!
David O'Neil 13-Jul-13 12:06pm View
   
I will make it so, and yes it is. Thank you very much for your time and knowledge!
David O'Neil 13-Jul-13 11:46am View
   
By changing the other places appropriately (the typedef and such), it will compile. But you lose the ability to do anything interesting in the accept function unless you resort to static member variables as well.

A full-blown solution is to go to the std::function approach I outline in this article, but I'm not ready to take that plunge at this stage. [EDIT] - Now that I think about it, even that probably won't work, because of the same issue - I'm getting tired.[/EDIT] Another, to overcome the static problem, is the one I hinted at in the question:

class DwlWinObject {
};

template <class T>
class DwlDelegate {
public:
typedef void (T::*FuncPtr)(DwlWinObject*);
protected:
FuncPtr ptrC;
public:
int junk;
static DwlDelegate create(T* object_ptr, DwlWinObject * arg, FuncPtr ptr) {
DwlDelegate d;
d.junk = 12;
return d;
}
};

class ModalBaseWindow : public DwlWinObject {
protected:
int a;
virtual void accept(DwlWinObject*) {
int a=0;
}
};

class MyModalWindow : public ModalBaseWindow {
public:
MyModalWindow() {
DwlDelegate<MyModalWindow> d = DwlDelegate<MyModalWindow>::create(this, this,
&MyModalWindow::accept);
int test = d.junk;
d.junk = 15;
}
inline void accept(DwlWinObject * ptr) {
return ModalBaseWindow::accept(ptr);
}
};

void main() {
MyModalWindow win;
}

I suspect the compiler shouldn't be allowing me to specify inline on the accept override, and will really ignore it, and a similar function has to be added to every other derived unit. But at least now I know my options.
David O'Neil 13-Jul-13 11:33am View
   
Not even that works. Same error.
David O'Neil 13-Jul-13 10:08am View
   
Thank you for the feedback. Yes, I get the same error regardless of the approach. Even the following gives the exact same thing, whether or not I cast in the d = line. I don't have another compiler installed, and even though it would be fun to play and see, I'm going to skip on that for now.

class DwlWinObject {
};

template <class T>
class DwlDelegate {
public:
typedef void (T::*FuncPtr)(DwlWinObject*);
protected:
FuncPtr ptrC;
public:
int junk;
static DwlDelegate create(T* object_ptr, DwlWinObject * arg, FuncPtr ptr) {
DwlDelegate d;
d.junk = 12;
return d;
}
};

class ModalBaseWindow : public DwlWinObject {
friend class DwlDelegate<ModalBaseWindow>;
protected:
int a;
void accept(DwlWinObject*) {
a=0;
}
};

class MyModalWindow : public ModalBaseWindow {
public:
MyModalWindow() {
accept(this); //2008: No problem accessing 'accept'
//But VS2012 gives C2248 compile error on the next line.
//C2248 is 'cannot access protected member'
//VS2008 has no problems with it, and executes as expected.
DwlDelegate<modalbasewindow> d = DwlDelegate<modalbasewindow>::create(this, this,
(DwlDelegate<modalbasewindow>::FuncPtr)(&ModalBaseWindow::accept));
int test = d.junk;
d.junk = 15;
}
};

void main() {
MyModalWindow win;
}

(And don't ask me why a copy/paste results in ModalBaseWindow loosing its capitalization when inside < >)
David O'Neil 13-Jul-13 9:17am View
   
You mean something like this?

class DwlWinObject {
};

class ModalBaseWindow;

template <class t>
class DwlDelegate {
typedef void (T::*FuncPtr)(DwlWinObject*);
protected:
FuncPtr ptrC;
public:
int junk;
static DwlDelegate create(T* object_ptr, DwlWinObject * arg, FuncPtr ptr) {
DwlDelegate d;
d.junk = 12;
return d;
}

};

class ModalBaseWindow : public DwlWinObject {
protected:
int a;
void accept(DwlWinObject*) {
a=0;
}
};

class MyModalWindow : public ModalBaseWindow {
public:
MyModalWindow() {
accept(this); //2008: No problem accessing 'accept'
//But VS2012 gives C2248 compile error on the next line.
//C2248 is 'cannot access protected member'
//VS2008 has no problems with it, and executes as expected.
DwlDelegate<mymodalwindow> d = DwlDelegate<mymodalwindow>::create(this, this, &ModalBaseWindow::accept);
int test = d.junk;
d.junk = 15;
}
};

void main() {
MyModalWindow win;
}

If so, that's also a no-go. I was surprised it took the 'd = line. [edit - I mean that it didn't barf up a template error instead of the 'can't access' error!] Templates make my head hurt!

Thanks,
David
David O'Neil 13-Jul-13 8:06am View
   
Seldom used this before, so didn't see how to comment. But deleted my other reply now that it is abundantly obvious!

Unfortunately, friending it doesn't work. I'm seriously thinking about the public route to save time. Thanks for the input!

Advertise | Privacy | Mobile
Web02 | 2.8.161205.3 | Last Updated 1 Jan 1900
Copyright © CodeProject, 1999-2016
All Rights Reserved. Terms of Service
Layout: fixed | fluid