Author Topic: something about M_PI  (Read 2505 times)

Offline coutnut

  • Single posting newcomer
  • *
  • Posts: 1
something about M_PI
« on: September 07, 2021, 11:04:16 am »
Hi! Guys, nice to meet u all here.
     I am really new to CBs. and I am learning programing in the structure of OpenCASCADE. Typically, I should use VS2019. However my computer is a little bit old, if I use the VS2019,  sometimes it'll crash. So I aim to program with CBs, language is cpp.

    Here is the problem. I got a gp_Dir2d.lxx which uses M_PI.
    I defineed ||#define D_USE_MATH_DEFINES   || and ||  #define _USE_MATH_DEFINES || ,||   #include <math.h> ||   but error came out  : 'M_PI' was not declared in this scope.

    I am really confused. What should I do to fix it? (PS:this works in VS2019,BUT I really need a lighter IDE!)

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7190
    • My Best Post
Re: something about M_PI
« Reply #1 on: September 07, 2021, 05:49:02 pm »
Sounds like an Compiler and Code::Blocks (C::B) configuration related issue.

Therefore the Compiler Toolchain info is needed.  NOTE: C::B is not an Compiler.

Operating System (OS) including 64 or 32 bit might also be needed.

Example info expected is:

Compiler: GCC (Rev5, Built by MSYS2 project) 10.3.0
C::B Version: svn-r12452
OS Info: Microsoft Windows 7 64 bit

From C::B Help -> About (Information Tab)

Code
Name                    : Code::Blocks
Version                 : svn-r12452
SDK Version             : 2.9.0
Scintilla Version       : 3.7.5
Author                  : The Code::Blocks Team
E-mail                  : info@codeblocks.org
Website                 : http://www.codeblocks.org
OS                      : Windows 7 (build 7601, Service Pack 1), 64-bit edition
Scaling factor          : 1.000000
Detected scaling factor : 1.000000
Display PPI             : 96x96
Display count           : 1
Display 0 (\\.\DISPLAY1): XY=[0,0]; Size=[1366,768]; Primary

wxWidgets Library (wxMSW port)
Version 3.1.5 (Unicode: wchar_t, debug level: 1),
compiled at Apr 25 2021 09:56:34

Runtime version of toolkit used is 6.1.

I am 80 percent sure the problem is caused by using GCC with a non standard file extension of "lxx".

But, I have no idea about how to fix the problem.

Posting the build log might help an expert to help you. NOTE: Build Log not Build messages

Edit: Add example build log
Code
-------------- Build: Debug in testpi (compiler: GNU GCC Compiler)---------------

x86_64-w64-mingw32-g++.exe -Wall -fexceptions -pedantic -std=c++17 -g  -c C:/Users/stahta01/test/testpi/main.cpp -o obj/Debug/main.o
x86_64-w64-mingw32-g++.exe  -o bin/Debug/testpi.exe obj/Debug/main.o   
Output file is bin\Debug\testpi.exe with size 143.26 KB
Process terminated with status 0 (0 minute(s), 5 second(s))
0 error(s), 0 warning(s) (0 minute(s), 5 second(s))
 

Tim S.

« Last Edit: September 07, 2021, 05:51:42 pm by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7190
    • My Best Post
Re: something about M_PI
« Reply #2 on: September 07, 2021, 11:45:49 pm »
The file "gp_Dir2d.lxx" that I found in opencascade project was never meant to be treated as a source file as in being compiled.
Instead it should be treated as a header file and the compiling and linking turned off for the file.

So, the file extension of "lxx" should not be a problem. Still waiting for a build log!

Tim S.
 
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline sodev

  • Regular
  • ***
  • Posts: 446
Re: something about M_PI
« Reply #3 on: September 08, 2021, 04:30:47 pm »
M_PI is not part of the C standard but part of POSIX. Most probably the OP is using GCC and that one is more strict regarding the standard. Using a C standard with GNU extensions does help in that case, e.g. instead of using --std=c11 use --std=gnu11.