Welcome, Guest. Please login or register.

Author Topic: #line directive debugging vs boost preprocessor library...  (Read 1803 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline JoseTopic starter

  • Hero Member
  • *****
  • Join Date: Feb 2002
  • Posts: 2869
    • Show only replies by Jose
I was reading through the boost library docs about their preprocessor library and it seems that the only valuable argument they present for people to use it over building their own custom code generator is that users would have to integrate it in their development environment and there would have to be various builds for various platforms, contrarily to the preprocessor wich already exists and should work in most C compliant preprocessors, given enouph care.

But the other day I was debugging some of my own macros and checking the preprocessor output from some compilers when all of a sudden it got me. A custom made code that would interpret custom keywords in the source (custom macro preprocessor) could be integrated simply using the #line directive wich seems to have been tailored specifically to this task!! Using it would allow line numbers to appear correctly on compiler messges.
My C book actually mentions that the #line directive is intended for debugging purposes. Must be the same use here: some utility that analised a source could actually use the #line and #error directives to make the compiler display errors regarding any line it wanted.

SO now I'm left with a big doubt. Surely there must be some advantages to using the boost preprocessor library (and preprocessor macros in general) otherwise the boost devs wouldn't have gone through all the trouble of creating it ? Or is it just that if there's an alternative way to do things, some people will try it anyway, even if it's worse ?

:pint:
\\"We made Amiga, they {bleep}ed it up\\"
 

Offline Karlos

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16867
  • Country: gb
  • Thanked: 4 times
    • Show only replies by Karlos
Re: #line directive debugging vs boost preprocessor library...
« Reply #1 on: May 26, 2007, 08:57:08 AM »
My dear Jose. You've tamed C, don't let yourself get tied down into bad habits and worrying about things for which far cleaner solutins exist. It's time to postincrement ;-)
int p; // A
 

Offline JoseTopic starter

  • Hero Member
  • *****
  • Join Date: Feb 2002
  • Posts: 2869
    • Show only replies by Jose
Re: #line directive debugging vs boost preprocessor library...
« Reply #2 on: May 26, 2007, 03:00:23 PM »
Who would've wrote that  ;-) I actually don't regret having pushed it a bit more on this one, as I've found the boost preprocessor is used among C++ coders too for metaprograming. Apparently templates don't solve all problems.
I'd also face the problem that the C++ library is more bulky and would make my code slower and bigger (AFAIK), at least for smaller projects.
\\"We made Amiga, they {bleep}ed it up\\"
 

Offline Karlos

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16867
  • Country: gb
  • Thanked: 4 times
    • Show only replies by Karlos
Re: #line directive debugging vs boost preprocessor library...
« Reply #3 on: May 26, 2007, 06:49:36 PM »
Quote
Apparently templates don't solve all problems.


Agreed, templates have their uses and they don't solve every problem of course.

However, seemingly a lot of the stuff you've worked on in C that have relied heavily on macro usage do have more immediate and safer solutions in C++, be they via templates or just basic OO.

Quote
I'd also face the problem that the C++ library is more bulky and would make my code slower and bigger (AFAIK), at least for smaller projects.


Yeah, you got me there. GCC 2.95.x in particular can produce serious bloat if you aren't careful. However I've found ways around most of its problems and thankfully many of those are solved in later versions anyway.

There's no immediate reason why a C++ program will be significantly larger if all it uses are C library functions and doesn't heavily rely on RTTI, templates, exceptions etc.

I always use C++ even for projects readily implementable in C. In that regard, you can just regard it as a safer version of C.
int p; // A