C++Builder Developer's Journal

I have compiled the component and installed without issues but when I drop the component on a form I get lots of unresolved external errors, I have set all the paths for includes, libs etc. I don't know what to tell you. It has been many years since the last time I wrote a usable component in C++ i...

Ok, had a couple of errors but I got your code to compile, and installed the component but when I went to compile the test project with components on the form I get this error, tried to see what was going on but lost. All of those failing symbols are from the standard C++ library, which you were al...

the following are still global, all other vars have been moved to the class or made local to the method, hop this is ok. std::vector<TDBRecords*> qr; //for database table records std::vector<TDBRecords*> qp; //for field properties called by pragma std::vector<TDBRecords*> tn; //used to get table na...

If you have a moment, could you point to an area where this is an issue and suggest a fix so that I can learn a bit more, always willing.. Here we go (there are a LOT of them): TDBRecords* q; TBaseRecord* r; char *_ident; std::vector<TBaseRecord*> rc; std::vector<TDBRecords*> qr; //for database tab...

The following is th .h file for the other component You have a circular dependency problem. TSqliteAgent.h #include's TSqliteComponent.h, and TSqliteComponent.h #include's TSqliteAgent.h. So you end up in a situation where the TSQLite class has not actually been defined yet when the compiler tries ...

Not sure what you mean by this "is TSQLite a complete type before it is used in the" Do you know what a forward-declaration is? And the difference between a complete class type vs a forward-declared class type? OK, let me put it to you this way - preceding the offending __property declaration, does...

Pointers to TComponent-derived types are perfectly valid for __published properties, so you can link components to each other at design-time. I've written plenty of components with such properties, in both Delphi and C++. The code you have shown looks fine, so I have to think the error is related to...

Ahmed Sayed wrote: ↑Mon Mar 29, 2021 6:10 pm It always raises exception ... even this raises exception ... does creating TControls List always raises exception ... only in c++ it raises that exception

What is the ACTUAL exception that is being raised?

But there is no way for me like to favor Writes over reads. Right? No. for example if multiple read started before a write operation, is there a way to force it to execute the write first even if the reads threads where created first? This has nothing to do with the order in which the threads are c...

Now, I know that in a multithreaded app I must surround the static variable with Critical section like this, in order to prevent creating more than one users list. That example does not offer any multi-threaded protection whatsoever for the reading/writing of the list's entries, only for the creati...

But let's say that 50 are reading from the users list to validate the token at that same time a user is trying to login that means that this user will have to wait for the other 50 to finish. Right? Yes. Which should be fine, because when writing thread-safe data access, the sections you want to pr...

For now I use TCriticalSection only when add/remove a user to the map list. But when I read from the list I do it in the connection thread normally without using any critical sections. That is not thread-safe. A thread could be altering the map while other threads are trying to read from it. You mu...

As for your question, I was simply advised against when programming around wasapi, they have a considerable computational cost and slow everything down. Then use a spin lock, or a slim reader/writer, something that is lower overhead than a critical section (or, just use a critical section w/ a spin...

is solved by simply adding InterlockedIncrement () as in the code below? You would have to use the Interlocked API for both writes AND reads to ensure proper inter-thread access to the variable. For example, you can replace: *buffer++ = fileBytes[w]; InterlockedIncrement(&w); With: buffer[i] = file...

I see memory leaks and syntax errors in this pseudo-code. But, to address your actual question - the `w` variable is being shared across threads, so you MUST synchronize access to it. There is simply no getting around that. But, which synchronization method you use is entirely up to you. There are M...