|
The $@ is one of the predefined make macros and refers to the target of the build; which should be the output file callapi. I looked at the man page for make on Ubuntu but it seems incomplete. There is (certainly used to be) a section somewhere that gives all the details on Makefile structures.
|
|
|
|
|
With your help I've cobbled this together ( and it works  ) thanks again
INCS = -I /home/pjk/C++/CallCommandsAPI/Headers/ \
-I /home/pjk/vcpkg/packages/rapidjson_x64-linux/include/ \
-I /home/pjk/vcpkg/packages/cpr_x64-linux/include/
LIBS = -L /home/pjk/vcpkg/packages/cpr_x64-linux/lib/ \
-lcpr -lcurl -lpthread -lssl -lcrypto
SOURCES = $(wildcard *.cpp */*.cpp)
TARGET: callapi
callapi: $(SOURCES)
g++ $(SOURCES) -o $@ $(INCS) $(LIBS)
clean:
rm callapi
Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
|
|
|
|
|
If you are interested in using the power of make to only compile modified sources that are newer than the target you should be able to do something like this
CPPFLAGS = -I /home/pjk/vcpkg/packages/cpr_x64-linux/include/cpr \
-I /home/pjk/C++/CallCommandsAPI/Headers/ \
-I /home/pjk/vcpkg/packages/rapidjson_x64-linux/include/ \
-I /home/pjk/vcpkg/packages/cpr_x64-linux/include/
LDFLAGS = -L /home/pjk/vcpkg/packages/cpr_x64-linux/lib/ \
-lcpr -lcurl -lpthread -lssl -lcrypto
SRCS = $(wildcard Source/*.cpp)
OBJS = $(SRCS:.cpp=.o)
ifdef DEBUG
CXXFLAGS += -ggdb
LDFLAGS += -ggdb
else
CXXFLAGS += -O2
LDFLAGS += -O2
endif
callapi: $(OBJS)
$(CXX) $(LDFLAGS) $^ -o $@
clean:
rm -f callapi $(OBJS)
I've added clean and debug options to help maintain your code. To make a debug version you do
make DEBUG=1 Note that $CPPFLAGS and $CXXFLAGS are standard make variables and will be expanded when trying to compile the individual object files, without us having to explicitly tell make to do so.
If you don't want the object files mixed in the source directory, look into using $(patsubst) [Text Functions (GNU make)](https://www.gnu.org/software/make/manual/html_node/Text-Functions.html#Text-Functions) and/or other make functions to manipulate targets. With some fancy footwork you could also get debug and production objects built at the same time, but I'll leave that as an exercise for the reader!
Keep Calm and Carry On
|
|
|
|
|
Thanks for this, one question, where is CXX defined ?
Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
|
|
|
|
|
CXX is defined in the bowels of make somewhere. It is the default variable for the C++ compiler, and is used in the rules for constructing default recipes. So for example, suppose you had an otherwise empty directory with only one file, hello.cpp, in it. Without needing to create a Makefile, you can build the hello executable just by saying "make hello". There's default rules for all kinds of things, C, Fortran, ranlib (.a) libraries, yacc, tex, and on and on. You can get a list of available recipes by saying "make -p", which for my version of make produces 1357 lines of output.
The CXX variable can be overridden by specifiying a shell variable of the same name at run time, so if for example you wanted to see what error messages clang++ spits out instead of g++ you can say
CXX=clang++ make target Similarly you have CXXFLAGS and CPPFLAGS which pass arguments to the C++ compiler and the CPreProcessor, respectively. So you could say
CXX=clang++ CPPFLAGS="-I /path/to/includs" CXXFLAGS="-O2 -Wall -Wextra" LDFLAGS="-L /path/to/lib" LDLIBS="-lmylib1 -lmylib2" make hello and make will apply the variables to the generated command line as expected, and produce:
clang++ -O2 -Wall -Wextra -I /path/to/includs -L /path/to/lib hello.cc -lmylib1 -lmylib2 -o hello
gnu make hack: You can rebuild everything from scratch, even if already compiled, without having to "make clean" by using the -B flag
It should also be noted that the Makefile I provided earlier uses GNU makeisms e.g. $(wildcard),$(patsubst). If you find yourself on a BSD or other unix like system that does not have GNU tools installed, the given make file will fail. But the variable substitutions mentioned here will still work.
Keep Calm and Carry On
|
|
|
|
|
vector<vector<int>> mark[5]
Is this array of 2D vectors? How can I traverse or insert any element from user in this data structure?
|
|
|
|
|
Try breaking it down into its constituent parts:
mark is an array of 5 elements.
Each element is a vector.
And each element of the vector is also a vector.
And each element of the inner vectors is an integer.
As it stands though, the array is null, so you need to initialise each of its elements with a new vector. You then need to decide what actual information you want to store in the vectors.
|
|
|
|
|
I have a C++ function that takes as argument an iterator and needs to increment it without passing the end of the container. I can write it as:
variant A:
bool func (std::string::iterator& ptr, std::string& container)
{
if (ptr != container.end())
}and call it as:
func (s.begin(), s);
or I could write it as
variant B:
bool func (std::string::interator& ptr, std::string::const_iterator& limit)
{
if (ptr != limit)
}and call it as:
func (s.begin(), s.end());
(the example assumes the container is a string but that's not important)
Which one would you favor?
Mircea
|
|
|
|
|
If the function modified the contents of the container I would probably pass it the container reference, otherwise I would prefer the iterators (or even a std::span).
|
|
|
|
|
Good points, thank you! However std::span is C++20 and I want to keep the code C++14.
Mircea
|
|
|
|
|
The second one: give to the function the strict necessary for its task.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Yep, my thoughts exactly. Thank you!
Mircea
|
|
|
|
|
"great minds..."
You are welcome.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
I have a more or less strict rule i.e. to wit in particular to be specific namely things that act like pointers are passed via copy constructor not via reference since raw pointers are fundamental type objects so take up little space and a reference is a pointer anyway. I agree w/ the chap who suggested passing only what the function requires i.e. first, last iterators. Further at point of call the code is easier to understand its purpose as it passes only what the function requires also it just looks better and is easier to understand as fewer ideas/concepts are involved namely the one idea/concept "iterator" rather than the two ideas/concepts "iterator and container". Was there not a recent article in a recent CP newsletter discussing this very thing i.e. minimizing the number of ideas/concepts needed to understand any code?
|
|
|
|
|
meagreProgrammer wrote: things that act like pointers are passed via copy constructor not via reference
Except that in my case the iterator needs to be changed by the function, hence I have to pass a reference.
Mircea
|
|
|
|
|
Would it be too lengthy or tedious an explanation to explain the need to modify the iterator. I find such a need quite unusual and do not recall ever having to perform same.
|
|
|
|
|
No problem: the iterator is a pointer in a UTF-8 encoded string and the function (called next) has to advance to the next code point (1, 2, 3 or 4 char). If iterator is at end of string it doesn't advance.
Although a very simple function, I had a number of design decisions to make:
- How should I deal with improperly encoded UTF-8 strings? I decided to return false if the string is not properly encoded.
- Should I just leave out the boundary check and just document it? I decided against as it would have been unsafe.
And the last one I was asking about: For limit check, should I just pass the string or the end iterator.
Mircea
|
|
|
|
|
I am NOT a C++ guy, so bear with me.
I am working on a C#/WPF app that references two C++ projects.
We just converted the solution from .Net Framework to .Net Core 6.0, and now the C++ projects won't compile while in the solution. If I open the C++ projects stand-alone, they compile file.
Primarily I'm getting the compile time error
'System': a namespace with this name does not exist
I've been Googling and 99% of the answers all say this. I've tried the answers and still get the same errors.
At this point I need help. I'm guessing it's some kind of configuration issue, but I really don't know.
Thanks
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
|
Richard MacCutchan wrote: What is the context
Not sure what you mean by "what is the context". Like I said, the project is in a solution with a C#/WPF project and the C++ project now doesn't compile.
Richard MacCutchan wrote: and are you sure this would not fit better in Managed C++/CLI Discussion Boards
I have no clue. But I could move it there.
Again, I have ZERO C++ experience, so I'm really in the dark with all this.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Kevin Marois wrote: Not sure what you mean by "what is the context"
All you have given us is an error message. We have no idea whether this is unmanaged or managed code, what the actual code that causes the error looks like &c.
|
|
|
|
|
OK, so here's the lines of code that are failing:
using namespace System;
using namespace System::Reflection;
using namespace System::Runtime::CompilerServices;
using namespace System::Runtime::InteropServices;
using namespace System::Security::Permissions;
This error occurs in the using statements in every C++ file in the project.
It's a .Net 6 project, so I'm assuming it Managed code.
I'm not trying to be difficult, but I just don't know what I'm looking at so it's hard for me to know what to post here.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
|
OK thanks. I'll take a look
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Hi
I have the following
struct tcbholder
{
char* tcb;
char programname[8];
struct stdecs stdecsx;
list <stdecs> strptr;
list <stdecs>::iterator stfirstptr;
list <stdecs>::iterator straverse;
};
struct stdecs
{
struct vsmdesc stordesc;
char* tcb;
struct blkdesc ablkdescx;
struct blkdesc fblkdescx;
list <blkdesc> ablkptr;
list<blkdesc>::iterator blktraverse;
list<blkdesc> fblkptr;
}
struct blkdesc
{
char type;
int blkaddr;
int blklen;
};
I declare a list class
list<tcbholder> tcbcollecter;
then a iterator
list <tcbholder>::iterator tcbitrate;
I am able to initialize the main iterator
tcbitrate = tcbcollecter.begin();
However when I try
tcbitrate->straverse = tcbitrate->strptr.begin();
I get the following
_STL_VERIFY(this->_Ptr != _Mycont->_Myhead, "cannot dereference end list iterator");
its in the list member line 151
Dont Understand
Thanks
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
