I would like to know how is that the .at() method works, like the one in the Vector class of the C++, a method that both ways returns and/or assign a value to the member of the array.
i don't know if with a macro i can do it, or declaring 2 method with same name... any help?
i have been trying to find and open the file of vector, to see how it was written, that specific method, but i have not found it.
(its for a different structure i am building, but i would like to access to them with only one method)
Example of what i mean.
vec.at(x) = value;
newValue = vec.at(x);
You have to return a reference to the value. So instead of
int at(int idx)
You just do
int& at(int idx)
References are very similar to pointers with the difference that you cannot and dont have to dereference them in order to manipulate the value they are referencing
There should be an easy way to open any source file within the IDE. I use this feature all of the time to review the Standard Library, especially when wanting to review the signature of the member functions of std::vector, std::map, std::list, etc., without having to open a browser window.
Hopefully the IDE used has something similar to "open file at cursor". Since the IDE is not known by the question content, a more generic procedure is presented.
1) Make sure the relevant header name is in a #include line. For example:
#include <vector>
2) Move the editor cursor so that the cursor is clearly shown under a section of the header file name (e.g. vector).
3) Within the IDE run the "open file at cursor" command.
4) The IDE should now show the file highlighted by the cursor in its own window / tab, and there is no need to manually navigate to the area where all header files are located on the development system.
5) Search the newly opened file as desired.
Related
I want to delete all the object that is not used now.
I used Visual Studio 2019.
When I search Object Browser, It gets to me some strange struct or class that I modified of name.
For example, first I define a structure as
typedef struct stOutput
{
double dDirtyPrice_CumInt;
double dDM;
//...
double dYield;
} stOutput
Later I changed this definition to
typedef struct stOutput_New
{
double dAI;
//...
long lObservStartDate;
} stOutput_New
However, the object browser shows to me just
stOutput.
There is no stOutput_New.
Also I put my cursor on 'stOutput_New' and push 'F12' then it locates my view some strange area.
There are even no 'stOutput_New'
Now, below picture is describing my real situation
This is 'Class View'
Actually I just use One stOutput, but there are so many stOutput that has same file path
Also below picture is my 'Object Browser'
As you can see the two stOutput have different member variables.
And I changed the name from stOutput to stOutput_new the latter.
But it seems my object browser didn't reflect it.
I tried
Project Unload and Reload it
Organize the code of Solution and Project
Re-Build Solution.
But everything doesn't work.
Please help me
In vs2019, I defined the structure exactly like yours according to your description, and then changed the structure according to your description. My object browser did not have the problem you described. If you are sure that your code does not repeat the definition of structure and other problems, I suggest you reinstall or repair VS.
enter image description here
Let me elaborate on the title:
I want to implement a system that would allow me to enable/disable/modify the general behavior of my program. Here are some examples:
I could switch off and on logging
I could change if my graphing program should use floating or pixel coordinates
I could change if my calculations should be based upon some method or some other method
I could enable/disable certain aspects like maybe a extension api
I could enable/disable some basic integrated profiler (if I had one)
These are some made-up examples.
Now I want to know what the most common solution for this sort of thing is.
I could imagine this working with some sort of singelton class that gets instanced globally or in some other globally available object. Another thing that would be possible would be just constexpr or other variables floating around in a namespace, again globally.
However doing something like that, globally, feels like bad practise.
second part of the question
This might sound like I cant decide what I want, but I want a way to modify all these switches/flags or whatever they are actually called in a single location, without tying any of my classes to it. I don't know if this is possible however.
Why don't I want to do that? Well I like to make my classes somewhat reusable and I don't like tying classes together, unless its required by the DRY principle and or inheritance. I basically couldn't get rid of the flags without modifying the possible hundreds of classes that used them.
What I have tried in the past
Having it all as compiler defines. This worked reasonably well, however I didnt like that I couldnt make it so if the flag file was gone there were some sort of default settings that would make the classes themselves still operational and changeable (through these default values)
Having it as a class and instancing it globally (system class). Worked ok, however I didnt like instancing anything globally. Also same problem as above
Instancing the system class locally and passing it to the classes on construction. This was kinda cool, since I could make multiple instruction sets. However at the same time that kinda ruined the point since it would lead to things that needed to have one flag set the same to have them set differently and therefore failing to properly work together. Also passing it on every construction was a pain.
A static class. This one worked ok for the longest time, however there is still the problem when there are missing dependencies.
Summary
Basically I am looking for a way to have a single "place" where I can mess with some values (bools, floats etc.) and that will change the behaviour of all classes using them for whatever, where said values either overwrite default values or get replaced by default values if said "place" isnt defined.
If a Singleton class does not work for you , maybe using a DI container may fit in your third approach? It may help with the construction and make the code more testable.
There are some DI frameworks for c++, like https://github.com/google/fruit/wiki or https://github.com/boost-experimental/di which you can use.
If you decide to use switch/flags, pay attention for "cyclometric complexity".
If you do not change the skeleton of your algorithm but only his behaviour according to the objets in parameter, have a look at "template design pattern". This method allow you to define a generic algorithm and specify particular step for a particular situation.
Here's an approach I found useful; I don't know if it's what you're looking for, but maybe it will give you some ideas.
First, I created a BehaviorFlags.h file that declares the following function:
// Returns true iff the given feature/behavior flag was specified for us to use
bool IsBehaviorFlagEnabled(const char * flagName);
The idea being that any code in any of your classes could call this function to find out if a particular behavior should be enabled or not. For example, you might put this code at the top of your ExtensionsAPI.cpp file:
#include "BehaviorFlags.h"
static const enableExtensionAPI = IsBehaviorFlagEnabled("enable_extensions_api");
[...]
void DoTheExtensionsAPIStuff()
{
if (enableExtensionsAPI == false) return;
[... otherwise do the extensions API stuff ...]
}
Note that the IsBehaviorFlagEnabled() call is only executed once at program startup, for best run-time efficiency; but you also have the option of calling IsBehaviorFlagEnabled() on every call to DoTheExtensionsAPIStuff(), if run-time efficiency is less important that being able to change your program's behavior without having to restart your program.
As far as how the IsBehaviorFlagEnabled() function itself is implemented, it looks something like this (simplified version for demonstration purposes):
bool IsBehaviorFlagEnabled(const char * fileName)
{
// Note: a real implementation would find the user's home directory
// using the proper API and not just rely on ~ to expand to the home-dir path
std::string filePath = "~/MyProgram_Settings/";
filePath += fileName;
FILE * fpIn = fopen(filePath.c_str(), "r"); // i.e. does the file exist?
bool ret = (fpIn != NULL);
fclose(fpIn);
return ret;
}
The idea being that if you want to change your program's behavior, you can do so by creating a file (or folder) in the ~/MyProgram_Settings directory with the appropriate name. E.g. if you want to enable your Extensions API, you could just do a
touch ~/MyProgram_Settings/enable_extensions_api
... and then re-start your program, and now IsBehaviorFlagEnabled("enable_extensions_api") returns true and so your Extensions API is enabled.
The benefits I see of doing it this way (as opposed to parsing a .ini file at startup or something like that) are:
There's no need to modify any "central header file" or "registry file" every time you add a new behavior-flag.
You don't have to put a ParseINIFile() function at the top of main() in order for your flags-functionality to work correctly.
You don't have to use a text editor or memorize a .ini syntax to change the program's behavior
In a pinch (e.g. no shell access) you can create/remove settings simply using the "New Folder" and "Delete" functionality of the desktop's window manager.
The settings are persistent across runs of the program (i.e. no need to specify the same command line arguments every time)
The settings are persistent across reboots of the computer
The flags can be easily modified by a script (via e.g. touch ~/MyProgram_Settings/blah or rm -f ~/MyProgram_Settings/blah) -- much easier than getting a shell script to correctly modify a .ini file
If you have code in multiple different .cpp files that needs to be controlled by the same flag-file, you can just call IsBehaviorFlagEnabled("that_file") from each of them; no need to have every call site refer to the same global boolean variable if you don't want them to.
Extra credit: If you're using a bug-tracker and therefore have bug/feature ticket numbers assigned to various issues, you can creep the elegance a little bit further by also adding a class like this one:
/** This class encapsulates a feature that can be selectively disabled/enabled by putting an
* "enable_behavior_xxxx" or "disable_behavior_xxxx" file into the ~/MyProgram_Settings folder.
*/
class ConditionalBehavior
{
public:
/** Constructor.
* #param bugNumber Bug-Tracker ID number associated with this bug/feature.
* #param defaultState If true, this beheavior will be enabled by default (i.e. if no corresponding
* file exists in ~/MyProgram_Settings). If false, it will be disabled by default.
* #param switchAtVersion If specified, this feature's default-enabled state will be inverted if
* GetMyProgramVersion() returns any version number greater than this.
*/
ConditionalBehavior(int bugNumber, bool defaultState, int switchAtVersion = -1)
{
if ((switchAtVersion >= 0)&&(GetMyProgramVersion() >= switchAtVersion)) _enabled = !_enabled;
std::string fn = defaultState ? "disable" : "enable";
fn += "_behavior_";
fn += to_string(bugNumber);
if ((IsBehaviorFlagEnabled(fn))
||(IsBehaviorFlagEnabled("enable_everything")))
{
_enabled = !_enabled;
printf("Note: %s Behavior #%i\n", _enabled?"Enabling":"Disabling", bugNumber);
}
}
/** Returns true iff this feature should be enabled. */
bool IsEnabled() const {return _enabled;}
private:
bool _enabled;
};
Then, in your ExtensionsAPI.cpp file, you might have something like this:
// Extensions API feature is tracker #4321; disabled by default for now
// but you can try it out via "touch ~/MyProgram_Settings/enable_feature_4321"
static const ConditionalBehavior _feature4321(4321, false);
// Also tracker #4222 is now enabled-by-default, but you can disable
// it manually via "touch ~/MyProgram_Settings/disable_feature_4222"
static const ConditionalBehavior _feature4222(4222, true);
[...]
void DoTheExtensionsAPIStuff()
{
if (_feature4321.IsEnabled() == false) return;
[... otherwise do the extensions API stuff ...]
}
... or if you know that you are planning to make your Extensions API enabled-by-default starting with version 4500 of your program, you can set it so that Extensions API will be enabled-by-default only if GetMyProgramVersion() returns 4500 or greater:
static ConditionalBehavior _feature4321(4321, false, 4500);
[...]
... also, if you wanted to get more elaborate, the API could be extended so that IsBehaviorFlagEnabled() can optionally return a string to the caller containing the contents of the file it found (if any), so that you could do shell commands like:
echo "opengl" > ~/MyProgram_Settings/graphics_renderer
... to tell your program to use OpenGL for its 3D graphics, or etc:
// In Renderer.cpp
std::string rendererType;
if (IsDebugFlagEnabled("graphics_renderer", &rendererType))
{
printf("The user wants me to use [%s] for rendering 3D graphics!\n", rendererType.c_str());
}
else printf("The user didn't specify what renderer to use.\n");
I ran into a problem with the Eclipse formatter. It won't format my code correctly when declaring methods within a class declaration. It puts a new line after the method's return type.
I already exported the style xml file and examined the settings in it, but none of the settings have any apparent connection to this problem, and the settings editor in Eclipse didn't show the same problem happening in it's sample code for method declarations.
Here is an example bit of code for what I want to have happen:
class MyClass
{
public:
MyClass();
void myMethod();
};
However, this is what I get:
class MyClass
{
public:
MyClass();
void
myMethod();
};
Again, in the styles editor, the code doesn't have this problem and looks just how I want it to, but in the actual code, the story is different.
I'm using version 3.8.0. Any help is appreciated.
Edit: I deleted those source files that were formatted incorrectly (after formatting the code several times to no avail) and replaced them with "identical" files with the same methods, same structure, etc. I formatted the code this time and it worked. This is probably a bug, but I'm leaving it up just in case anyone else encounters a similar problem or has a solution to avoiding this problem in the first place.
I hand edited two files under the main eclipse projects directory
.metadata\.plugins\org.eclipse.core.runtime\.settings
The two files:
file 1: org.eclipse.cdt.core.prefs, change this line from "insert" to "do not insert"
org.eclipse.cdt.core.formatter.insert_new_line_before_identifier_in_function_declaration=do not insert
file 2: org.eclipse.cdt.ui.prefs,
scan this file for "insert_new_line_before_identifier_in_function_declaration" and make a similar change from insert to do not insert next to it, should be obvious
Note I seen this problem on indigo and juno, the fix described above was in juno.
If you have a custom formatter config, export it first (settings>C/C++ General>Formatter>Edit>Export). Then change the following line to "do not insert". Save the XML.
<setting id="org.eclipse.cdt.core.formatter.insert_new_line_before_identifier_in_function_declaration" value="do not insert"/>
Delete the current config and import the one you changed.
There's a specific preference in the formatter options starting from cdt 9.8 included in Eclipse 2019-06.
I think this would increase the quality of life when devving, but google came up with nothing and I couldn't find anything specific inside inside Netbeans either.
What I want is to start with this header:
class bla
{
public:
static void gfg(somearg asd);
};
Then I open the blank bla.cpp and pressed 'autoimplement'. After that, it would look like this:
#include "bla.h"
static void bla::gfg(somearg asd)
{
//TODO: implement
throw unimplemented("void bla::gfg(somearg) is unimplemented");
}
Anyone know of a tool like this?
I found http://www.radwin.org/michael/projects/stubgen/
"stubgen is a C++ development tool that keeps code files in sync with their associated headers. When it finds a member function declaration in a header file that doesn't have a corresponding implementation, it creates an empty skeleton with descriptive comment headers."
This looks like it does exactly what you want it to do.
Some time has passed and in the meantime the requested feature seems to have been implemented in netbeans. Refer to https://netbeans.org/bugzilla/show_bug.cgi?id=213811 , which also gives a description on how to use it:
Note:
Implemented CTRL+SPACE.
IDE suggest implementing of class method if CTRL+SPACE was pressed:
- inside file that already has at least one method definition
- between method declarations
I'd like the user to be able to edit the number of recent files shown in the File menu of my MFC application. I've used two very good references:
http://www.codeproject.com/KB/menus/changemru.aspx
http://www.microsoft.com/msj/0899/c/c0899.aspx
It involves deleting and recreating the CRecentFileList object stored in CWinApp::m_pRecentFileList. Unfortunately, I find that the menu is not updated properly after replacing the CRecentFileList. See code snippet below:
void CMyWinApp::SetMRUListSize( int size )
{
// size guaranteed to be between 1 and 16
delete m_pRecentFileList ;
LoadStdProfileSettings( size ) ;
}
What can I do to ensure that what is drawn into the File menu is synchronized with m_pRecentFileList after I recreate the object?
My CApp derives from CWinApp. In initInstance, you have this line:
LoadStdProfileSettings(10);
At the end of InitInstance, add this code:
m_pmf->m_pRecentFileList = m_pRecentFileList;
Here m_pmf is my MainFrame class and I created a member CMainFrame::m_pRecentFileList of type CRecentFileList which is in the MFC source file filelist.cpp. m_pRecentFileList on the right is protected and CMainFrame doesn't have access to it from outside InitInstance, but you can make a functional copy here.
At the end of CMainFrame::OnClose, force a registry update by:
m_pRecentFileList->WriteList();
// Force registry update on exit. This doesn't work without forcing.
I don't even have to rebuild m_pRecentFileList, the MRU mechanism updates it correctly. Example: 5 MRU items, the first is moved to another directory and can no longer be found. Stepping through the code in the debugger shows that the bad entry is removed from the list. For some reason, the updated list isn't saved correctly unless I force it as explained above. I originally thought the problem might have something to do with privileges (64-bit Win7), but running the app as admin didn't help.
Some of Microsoft's documentation suggest you should call CWinApp::LoadStdProfileSettings from within InitInstance. This suggests to me that it's something done once during initialisation rather than at run time.
Have you tried fully implementing the second of the two links you provided? My guess is you need to add the second part instead of the call to CWinApp::LoadStdProfileSettings:
m_pRecentFileList = new CRecentFileList(0, strSection, strEntryFormat, nCount);
if(m_pRecentFileList)
{
bReturn = TRUE;
// Reload list of MRU files from registry
m_pRecentFileList->ReadList();
}
[Edit] Apparently m_pRecentFileList points to an CRecentFileList Class . Have you tried calling CRecentFileList::UpdateMenu?
There's another CodeProject example which might help too.