How to output values of variables in JagPDF using C++

[ClobberXD]

I'm using JagPDF in C++, and can output normal text. However, the documentation doesn't specify a method to output variable values, which is what I need... Would you mind helping me with this? Thanks!

[Nineshadow]

What do you mean output variable values?

[ClobberXD]

2 minutes ago, Nineshadow said:

What do you mean output variable values?

If I've got an 'int number;', how do I output its value?

[Nineshadow]

1 minute ago, Anand_Geforce said:

If I've got an 'int number;', how do I output its value?

Output its value to what?

stdin/console?

a file?

[ClobberXD]

1 minute ago, Nineshadow said:

Output its value to what?

stdin/console?

a file?

To a PDF (obviously, as I've specifically mentioned using "JagPDF in C++" )

[Unimportant]

From what i can see at a quick glance at the JagPDF documentation, the text outputting functions take a "const char*" C-style string. You can use a stringstream to format your text and then extract the string from it and take it's char pointer as such:

 

#include <sstream>  //required for stringstream
  
  
//...
int x = 10;  //Example int to print.
std::stringstream sstr;  //stringstream
  
sstr << "Value of int x is: " << x;     //Format stringstream as you normally would printing to cout.
const char* Ptr = sstr.str().c_str();	//Extract string from stringstream with str() function and then...
					//...extract that string's char pointer with c_str().

//You can, off course, pass the pointer directly as well.
Canvas.text(sstr.str().c_str());

 

[ClobberXD]

10 minutes ago, Unimportant said:

From what i can see at a quick glance at the JagPDF documentation, the text outputting functions take a "const char*" C-style string. You can use a stringstream to format your text and then extract the string from it and take it's char pointer as such:

 

#include <sstream>  //required for stringstream
  
  
//...
int x = 10;  //Example int to print.
std::stringstream sstr;  //stringstream
  
sstr << "Value of int x is: " << x;     //Format stringstream as you normally would printing to cout.
const char* Ptr = sstr.str().c_str();	//Extract string from stringstream with str() function and then...
					//...extract that string's char pointer with c_str().

//You can, off course, pass the pointer directly as well.
Canvas.text(sstr.str().c_str());

 

Nice! But the compilation fails, as a header file (\jagpdf\detail\types.h) of the JagPDF has 3 'negative subscript' errors...

[Unimportant]

Post the full error message and the offending code plz.

[ClobberXD]

5 hours ago, Unimportant said:

Post the full error message and the offending code plz.

Quote

ERROR:

C2118    negative subscript    PDF_Project    \jagpdf\detail\types.h    lines 17, 52, and 150

Here are the lines:

// The define that is causing the problem...
#define JAG_STATIC_ASSERT_PUBLIC(expr, msg)  \
    typedef int msg[(expr) ? 1 : -1 ];

JAG_STATIC_ASSERT_PUBLIC(sizeof(void*) == JAG_SIZEOF_VOID_P, incompatible_address_models) // Line 17
JAG_STATIC_ASSERT_PUBLIC(sizeof(void*)==4, not_32bit_architecture) // Line 52
JAG_STATIC_ASSERT_PUBLIC(sizeof(void*)==4, jag_32_platform) // Line 150

 

[Unimportant]

I was thinking more in line of the lines of your code that trigger the error.

 

But looking at those macro's and the error message, it seems pointers are not 4 bytes long on your system. You don't have your compiler set to 64 bit by any chance ? It seems this library wants 32 bit.

[ClobberXD]

2 hours ago, Unimportant said:

I was thinking more in line of the lines of your code that trigger the error.

 

But looking at those macro's and the error message, it seems pointers are not 4 bytes long on your system. You don't have your compiler set to 64 bit by any chance ? It seems this library wants 32 bit.

I have! It won't work with 64-bit? How to make it?

[Unimportant]

I found the following in the JagPDF makefile:

 

# 64-bit check
if(CMAKE_SIZEOF_VOID_P EQUAL 8 )
  if (WIN32)
    message(FATAL_ERROR "\nJagPDF has not been ported to 64-bit Windows.")
  endif()
endif()

So there doe not seem to be a 64 bit port.

 

I'd stick to 32-bit. There's really  no use for 64-bit unless you need more then 2GB ram for your application, which is unlikely.

[ClobberXD]

3 minutes ago, Unimportant said:

I found the following in the JagPDF makefile:

 

# 64-bit check
if(CMAKE_SIZEOF_VOID_P EQUAL 8 )
  if (WIN32)
    message(FATAL_ERROR "\nJagPDF has not been ported to 64-bit Windows.")
  endif()
endif()

So there doe not seem to be a 64 bit port.

 

I'd stick to 32-bit. There's really  no use for 64-bit unless you need more then 2GB ram for your application, which is unlikely.

Isn't 64-bit applications twice as fast as 32-bit counter-parts? I thought that mattered...

[Unimportant]

No, there are only 2 benefits to 64 bit applications and even those benefits only apply in certain situations.

 

1) The maximum amount of memory available to a 32-bit windows application is 2GB. (32 bit can address max 4GB, but a single application only has access to half of it.). 64 bit applications can use all the memory available in a system. (64 bit can address a insanely high amount of memory, 2^64 bytes). This is only a benefit if you need more then 2GB RAM.

 

2) A 64-bit application can make use of a 64-bit CPU's 64-bit registers and thus can do calculations on 64-bit numbers in one go, without having to split things up in multiple 32-bit calculations. This is faster, but only if you need and use such large numbers, which is rare.

 

[trag1c]

16 hours ago, Anand_Geforce said:

Isn't 64-bit applications twice as fast as 32-bit counter-parts? I thought that mattered...

There are additional 64 bit registers available which may increase performance but in most cases there will be an insignificant or immeasurable performance increase.

 

As @Unimportant stated the primary advantage of 64 bit executable's is that its able to address more memory space than the 4GB range limit (assuming the application is large address aware). But this also causes an issue with increased memory usage because pointers take double the memory when compared to 32 bit pointers. It goes from 4 byte per pointer usage to 8 bytes.

[ClobberXD]

41 minutes ago, trag1c said:

There are additional 64 bit registers available which may increase performance but in most cases there will be an insignificant or immeasurable performance increase.

 

As @Unimportant stated the primary advantage of 64 bit executable's is that its able to address more memory space than the 4GB range limit (assuming the application is large address aware). But this also causes an issue with increased memory usage because pointers take double the memory when compared to 32 bit pointers. It goes from 4 byte per pointer usage to 8 bytes.

So 32-bit will not decrease performance too much?

[trag1c]

1 minute ago, Anand_Geforce said:

So 32-bit will not decrease performance too much?

99% of the time a change in performance is non existent. And for the love of everything programming don't worry about performance until it becomes a problem. Worry more about a well designed/structured program as that is far more important than performance. Wait until optimizations are needed than go at it with a profiler. There's the 80-20 rule which means that (in a programming performance context) 80% of the performance improvements will come from optimizing 20% of the code (this is not exaggerated at all, I've even seen 90-10).

[ClobberXD]

8 minutes ago, trag1c said:

99% of the time a change in performance is non existent. And for the love of everything programming don't worry about performance until it becomes a problem. Worry more about a well designed/structured program as that is far more important than performance. Wait until optimizations are needed than go at it with a profiler. There's the 80-20 rule which means that (in a programming performance context) 80% of the performance improvements will come from optimizing 20% of the code (this is not exaggerated at all, I've even seen 90-10).

I've configured a benchmarking utility as 64-bit - all it does is calculate the number of times a loop has been iterated in a minute... Will this (the results) change with 32-bit configuration? I hope not...

[trag1c]

10 minutes ago, Anand_Geforce said:

I've configured a benchmarking utility as 64-bit - all it does is calculate the number of times a loop has been iterated in a minute... Will this (the results) change with 32-bit configuration? I hope not...

Doesn't matter as long as long as all the clients are running the same build configuration. A big point of a benchmark is standardization between tests otherwise the results are skewed.