Re: Where's the beef?

On 9/1/05 8:29, in article
102E3388-8481-49AB-A779-1822EC518114@xxxxxxxxxxxxx, "AVee"
<AVee@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

> I posted this question on 8-23, and await a "managed" response:
>
> Is it possible to define a macro substitution in the C++ preprocessor so
> that it will be replaced "as if" it were defined within the source code?
>
> In other words, I would like the preprocessor to expand this:
>
> #include "..\_MYPATH_\myfile.h"
>
> to this:
>
> #include "..\MySpecificPath\myfile.h"
>
> without having to include this line of code in each file
>
> #define _MYPATH_ MySpecificPath
>
> The reason that this is so important to me is because our company has become
> heavily invested in MFC, and certain capabilities (Class Wizard & Browser
> features) essential to efficiently maintain large MFC projects have been
> dropped in VS.NET - AND, once project files are converted to VS.NET, they are
> no longer usable under previous development systems. Also, it is impossible
> to turn off deprecated warning C4996 - making portability harder yet to
> manage ... and suggested replacements for deprecated functions are not easily
> linked into the older development system (VC6).
>
> Since portability to VS.NET has proved to be extensive, we need to maintain
> production source files under VC++ during the process. The only method that I
> see is viable is by accommodating the compiler differences in compiler
> dependent headers, and calling the appropriate header by means of a
> predefined macro in the project.
>
> So - in order to reliably port large amounts of (tested and reliable) code,
> I need to be able to call in different header files depending on the version
> of compiler that I am using - at least until Microsoft reintroduces MFC
> maintenance features that were dropped. I am hoping NOT to have to introduce
> gazillions of #ifdef's, only needing to remove them once porting is complete.
>
> And by the way - it's my opinion that developers would be MORE inclined to
> migrate to newer MS technologies (managed code) if MFC support were enhanced,
> not diminished (so as to force our hand). On what basis can developers be
> assured that their investment in the new technology will be preserved?
>
> Anyway - when I purchased MSDN I was assured of 48 hour managed response.
> It's been eight days now. Can someone answer my simple question? "Can macro
> substitutions be made by the project's preprocessor or not?". If not - fine,
> #ifdef's it is. If so, how?
>
> - otherwise please suggest or point me to information on the "suggested"
> method of maintaining large MFC projects while porting to emerging MS
> development systems.
>
Don't get me wrong, please, but I don't think newsgroups is the place where
you can expect "managed" response :-). I don't think our PSS monitors them,
newsgroups are mostly for peer help and sometimes you can also meet some
Microsoft developers here, but it is really a community service :-). If you
want timed response, please contact PSS directly either my phone or e-mail.
I am not in a tech support, for example, I am actually a developer in the VS
HTML editor team and typing this response from home.

Anyway, back you your question. Since you use different versions of the
compiler I assume you are using external make files. In this case you can
change you code to simply

#include "myfile.h"

And specify location of the header files using -include compiler option. If
you prefer to have include statement unchanged, you can define MYPATH in the
compiler options using -DMYPATH=whatever. This way you don't have to specify
MYPATH in sources. Yet another way is to specify MYPATH in a single header
that you include in the beginning of all the file. This way you only have to
change a single file between different versions of the compiler.

Thanks
Mikhail Arkhipov (Microsoft)
-- This post is provided 'AS IS' with no warranties and confers no rights



.

Relevant Pages

  • Re: "a book on c" Kelly & Pohl (4e)
    ... A preprocessor is built into the C compiler. ... This header file is provided by the C system. ... in the "usual place," which is system dependent. ...
    (comp.lang.c)
  • Re: namespace and c++ headers in wince
    ... You suggested using MFC as framework..but i actually set out to do an MFC ... I have used an external header and cpp file which uses namespace std ... Namespaces are fine with the compiler and your code is ...
    (microsoft.public.windowsce.app.development)
  • Re: Rob Pikes simple Include rule
    ... > The GNU C preprocessor is programmed to notice when a header file ... > it's time to shop around for a better C compiler. ...
    (comp.lang.c)
  • Re: Newbie questions (four of them)
    ... > C much more difficult than I did the first semester of Java. ... if you're using an interpreter rather than a compiler - ... Think of the preprocessor as a separate "compiler" which mungs the source ... and make sure that header is included. ...
    (comp.lang.c)
  • Re: Header Files and Interfaces Yet Again
    ... compiler is not allowed to read them. ... illustrate the difference of header file and fake header. ... fake headers can not serve as sufficient information to the ... > something but it appears to me the Standard Library is not designed ...
    (comp.lang.cpp)
Loading