OStream

ostream

Welcome to other chapters of Let’s Understand Chrome V8 Dispatch is responsible for scheduling bytecode, which is equivalent to registering EIP++, and jumps to the next bytecode. Dispatch consists of two parts, one is a dispatch table and the other is the physical register. The table is an array that contains all bytecode addresses. V8 uses the physical register to dispatch bytecode for getting greater efficiency. 1. Dispatch Table The dispatch table is an array of pointers, which is used to store the address of the bytecode processing program. The array type is Code, and the Code Class is below: class Code: public HeapObject {
 public: NEVER_READ_ONLY_SPACE
 using Flags = uint32_t;
 #define CODE_KIND_LIST(V)\
 V(OPTIMIZED_FUNCTION)\
 V(BYTECODE_HANDLER)\
 V(STUB)\
 V(BUILTIN)\
 V(REGEXP)\
 V(WASM_FUNCTION)\
 V(WASM_TO_CAPI_FUNCTION)\
 V(WASM_TO_JS_FUNCTION)\
 V(JS_TO_WASM_FUNCTION)\
 V(JS_TO_JS_FUNCTION)\
 V(WASM_INTERPRETER_ENTRY)\
 V(C_WASM_ENTRY)
 enum Kind {
 #define DEFINE_CODE_KIND_ENUM(name) name,
 CODE_KIND_LIST(DEFINE_CODE_KIND_ENUM)
 #undef DEFINE_CODE_KIND_ENUM
 NUMBER_OF_KINDS
 };
 static
 const char * Kind2String(Kind kind);
 #ifdef ENABLE_DISASSEMBLER
 const char * GetName(Isolate * isolate) const;
 V8_EXPORT_PRIVATE void Disassemble(const char * name, std::ostream & os,
 Address current_pc = kNullAddress);
 #endif
 //................omit................
 }; : In the isolate, there is another pointer array that is the same type as the dispatch table. It holds all the Builtins addresses, which can confuse beginners easily. Note The dispatch table is maintained by BuildWithMacroAssembler, code is below: Code BuildWithMacroAssembler(Isolate * isolate, int32_t builtin_index,
 MacroAssemblerGenerator generator,
 const char * s_name) {
 HandleScope scope(isolate);
 // Canonicalize handles, so that we can share constant pool entries pointing
 // to code targets without dereferencing their handles.
 CanonicalHandleScope canonical(isolate);
 constexpr int kBufferSize = 32 * KB;
 byte buffer[kBufferSize];
 MacroAssembler masm(isolate, BuiltinAssemblerOptions(isolate, builtin_index),
 CodeObjectRequired::kYes,
 ExternalAssemblerBuffer(buffer, kBufferSize));
 masm.set_builtin_index(builtin_index);
 DCHECK(!masm.has_frame());
 generator( & masm);
 int handler_table_offset = 0;
 // JSEntry builtins are a special case and need to generate a handler table.
 DCHECK_EQ(Builtins::KindOf(Builtins::kJSEntry), Builtins::ASM);
 DCHECK_EQ(Builtins::KindOf(Builtins::kJSConstructEntry), Builtins::ASM);
 DCHECK_EQ(Builtins::KindOf(Builtins::kJSRunMicrotasksEntry), Builtins::ASM);
 if (Builtins::IsJSEntryVariant(builtin_index)) {
 handler_table_offset = HandlerTable::EmitReturnTableStart( & masm);
 HandlerTable::EmitReturnEntry( &
 masm, 0, isolate -> builtins() -> js_entry_handler_offset());
 }
 //.....................................................
 //................omit.............................
 } You can see regarding how to debug the BuildWithMacroAssembler. When the value of the parameter builtin_index is 65, the function pointer generator points to which is responsible for maintaining the Dispatch table, code is below: Chapter 9 Generate_InterpreterEnterBytecodeDispatch static void Generate_InterpreterEnterBytecode(MacroAssembler * masm) {
 // Set the return address to the correct point in the interpreter entry
 // trampoline.
 Label builtin_trampoline, trampoline_loaded;
 Smi interpreter_entry_return_pc_offset(
 masm -> isolate() -> heap() -> interpreter_entry_return_pc_offset());
 DCHECK_NE(interpreter_entry_return_pc_offset, Smi::kZero);
 // If the SFI function_data is an InterpreterData, the function will have a
 // custom copy of the interpreter entry trampoline for profiling. If so,
 // get the custom trampoline, otherwise grab the entry address of the global
 // trampoline.
 __ movq(rbx, Operand(rbp, StandardFrameConstants::kFunctionOffset));
 __ LoadTaggedPointerField(
 rbx, FieldOperand(rbx, JSFunction::kSharedFunctionInfoOffset));
 __ LoadTaggedPointerField(
 rbx, FieldOperand(rbx, SharedFunctionInfo::kFunctionDataOffset));
 __ CmpObjectType(rbx, INTERPRETER_DATA_TYPE, kScratchRegister);
 __ j(not_equal, & builtin_trampoline, Label::kNear);
 __ movq(rbx,
 FieldOperand(rbx, InterpreterData::kInterpreterTrampolineOffset));
 __ addq(rbx, Immediate(Code::kHeaderSize - kHeapObjectTag));
 __ jmp( & trampoline_loaded, Label::kNear);
 __ bind( & builtin_trampoline);
 // TODO(jgruber): Replace this by a lookup in the builtin entry table.
 __ movq(rbx,
 __ ExternalReferenceAsOperand(
 ExternalReference::
 address_of_interpreter_entry_trampoline_instruction_start(
 masm -> isolate()),
 kScratchRegister));
 __ bind( & trampoline_loaded);
 __ addq(rbx, Immediate(interpreter_entry_return_pc_offset.value()));
 __ Push(rbx);
 // Initialize dispatch table register.
 __ Move(
 kInterpreterDispatchTableRegister,
 ExternalReference::interpreter_dispatch_table_address(masm -> isolate()));
 // Get the bytecode array pointer from the frame.
 __ movq(kInterpreterBytecodeArrayRegister,
 Operand(rbp, InterpreterFrameConstants::kBytecodeArrayFromFp));
 if (FLAG_debug_code) {
 // Check function data field is actually a BytecodeArray object.
 __ AssertNotSmi(kInterpreterBytecodeArrayRegister);
 __ CmpObjectType(kInterpreterBytecodeArrayRegister, BYTECODE_ARRAY_TYPE,
 rbx);
 __ Assert(
 equal,
 AbortReason::kFunctionDataShouldBeBytecodeArrayOnInterpreterEntry);
 }
 // Get the target bytecode offset from the frame.
 __ movq(kInterpreterBytecodeOffsetRegister,
 Operand(rbp, InterpreterFrameConstants::kBytecodeOffsetFromFp));
 __ SmiUntag(kInterpreterBytecodeOffsetRegister,
 kInterpreterBytecodeOffsetRegister);
 // Dispatch to the target bytecode.
 __ movzxbq(r11, Operand(kInterpreterBytecodeArrayRegister,
 kInterpreterBytecodeOffsetRegister, times_1, 0));
 __ movq(kJavaScriptCallCodeStartRegister,
 Operand(kInterpreterDispatchTableRegister, r11,
 times_system_pointer_size, 0));
 __ jmp(kJavaScriptCallCodeStartRegister);
 }
 //================================separation=========================
 void Builtins::Generate_InterpreterEnterBytecodeDispatch(MacroAssembler * masm) {
 Generate_InterpreterEnterBytecode(masm);
 } In the above code, the is the entry point of bytecode dispatch, and the is the key code that implements the bytecode dispatch. Here are two important concepts: Generate_InterpreterEnterBytecodeDispatch Generate_InterpreterEnterBytecode The is a Builtin and its index is 65. (The index may be dissimilar in different V8 versions) Generate_InterpreterEnterBytecodeDispatch V8 uses a physical register to manage the dispatch table, the name of the register is . Using the physical register can avoid the push and pop of the dispatch table frequently, to improve efficiency. kInterpreterDispatchTableRegister Here are the key lines of code： Line 35, loads the dispatch table to the A register. Line 37 of code, take out the table address from the isolate. The implementation of A is in the below three functions. (1) ExternalReference ExternalReference::interpreter_dispatch_table_address(
 Isolate * isolate) {
 return ExternalReference(isolate -> interpreter() -> dispatch_table_address());
}
interpreter::Interpreter * interpreter() const {
 return interpreter_;
}
Address dispatch_table_address() {
 return reinterpret_cast < Address > ( & dispatch_table_[0]);
} Line 39 takes out the bytecode array from the stack. (2) Line 51 takes out the offset of the target bytecode from the bytecode array. (3) Lines 56 and 58 calculate the target bytecode address and store the address in kJavaScriptCallCodeStartRegister. (4) Line 61 jumps to register kJavaScriptCallCodeStartRegister and executes bytecode. Figure 1 is the call stack. (5) 2. TailCall The Dispatch() is the last step in a bytecode, so its alias is the tail call. Let’s look at a few bytecodes： IGNITION_HANDLER(StaGlobal, InterpreterAssembler) {
 TNode < Context > context = GetContext();
 //omit..............
 Goto( & end);
 Bind( & no_feedback);
 CallRuntime(Runtime::kStoreGlobalICNoFeedback_Miss, context, value, name);
 Goto( & end);
 Bind( & end);
 Dispatch(); // !!! this is the tail call.
 }
 IGNITION_HANDLER(LdaContextSlot, InterpreterAssembler) {
 TNode < Context > context = CAST(LoadRegisterAtOperandIndex(0));
 TNode < IntPtrT > slot_index = Signed(BytecodeOperandIdx(1));
 TNode < Uint32T > depth = BytecodeOperandUImm(2);
 TNode < Context > slot_context = GetContextAtDepth(context, depth);
 TNode < Object > result = LoadContextElement(slot_context, slot_index);
 SetAccumulator(result);
 Dispatch(); //!!! here also is.
 }
 IGNITION_HANDLER(LdaImmutableContextSlot, InterpreterAssembler) {
 TNode < Context > context = CAST(LoadRegisterAtOperandIndex(0));
 TNode < IntPtrT > slot_index = Signed(BytecodeOperandIdx(1));
 TNode < Uint32T > depth = BytecodeOperandUImm(2);
 TNode < Context > slot_context = GetContextAtDepth(context, depth);
 TNode < Object > result = LoadContextElement(slot_context, slot_index);
 SetAccumulator(result);
 Dispatch(); //!!! here 
 } The above three bytecodes all end with Dispatch(). Below is the code of Dispatch: void InterpreterAssembler::Dispatch() {
 Comment("========= Dispatch");
 DCHECK_IMPLIES(Bytecodes::MakesCallAlongCriticalPath(bytecode_), made_call_);
 TNode < IntPtrT > target_offset = Advance();
 TNode < WordT > target_bytecode = LoadBytecode(target_offset);
 if (Bytecodes::IsStarLookahead(bytecode_, operand_scale_)) {
 target_bytecode = StarDispatchLookahead(target_bytecode);
 }
 DispatchToBytecode(target_bytecode, BytecodeOffset());
 } The 2nd line is the comment function. When debugging, we can use its output information to locate the execution position. The 4th line takes out the offset of the target(next) bytecode. The 5th line loads the target bytecode. The 9th line calls which calls eventually. DspatchToBytecode() DispatchToBytecodeHandlerEntry() void InterpreterAssembler::DispatchToBytecodeHandlerEntry(
 TNode < RawPtrT > handler_entry, TNode < IntPtrT > bytecode_offset) {
 // Propagate speculation poisoning.
 TNode < RawPtrT > poisoned_handler_entry =
 UncheckedCast < RawPtrT > (WordPoisonOnSpeculation(handler_entry));
 TailCallBytecodeDispatch(InterpreterDispatchDescriptor {},
 poisoned_handler_entry, GetAccumulatorUnchecked(),
 bytecode_offset, BytecodeArrayTaggedPointer(),
 DispatchTablePointer());
} In , parameter 1 is the target bytecode and 2 is the offset of the bytecode. Parameter 1 is used to load the bytecode handler and 2 is used to load operands. Then call , which is below: DispatchToBytecodeHandlerEntry TailCallBytecodeDispatch template < class...TArgs >
 void CodeAssembler::TailCallBytecodeDispatch(
 const CallInterfaceDescriptor & descriptor, TNode < RawPtrT > target,
 TArgs...args) {
 DCHECK_EQ(descriptor.GetParameterCount(), sizeof...(args));
 auto call_descriptor = Linkage::GetBytecodeDispatchCallDescriptor(
 zone(), descriptor, descriptor.GetStackParameterCount());
 Node * nodes[] = {
 target,
 args...
 };
 CHECK_EQ(descriptor.GetParameterCount() + 1, arraysize(nodes));
 raw_assembler() -> TailCallN(call_descriptor, arraysize(nodes), nodes);
 } In the above code, the 5th line creates the descriptor, as below: CallDescriptor * Linkage::GetBytecodeDispatchCallDescriptor(
 Zone * zone,
 const CallInterfaceDescriptor & descriptor,
 int stack_parameter_count) {
 const int register_parameter_count = descriptor.GetRegisterParameterCount();
 const int parameter_count = register_parameter_count + stack_parameter_count;
 DCHECK_EQ(descriptor.GetReturnCount(), 1);
 LocationSignature::Builder locations(zone, 1, parameter_count);
 locations.AddReturn(regloc(kReturnRegister0, descriptor.GetReturnType(0)));
 for (int i = 0; i < parameter_count; i++) {
 if (i < register_parameter_count) {
 // The first parameters go in registers.
 Register reg = descriptor.GetRegisterParameter(i);
 MachineType type = descriptor.GetParameterType(i);
 locations.AddParam(regloc(reg, type));
 } else {
 int stack_slot = i - register_parameter_count - stack_parameter_count;
 locations.AddParam(LinkageLocation::ForCallerFrameSlot(
 stack_slot, MachineType::AnyTagged()));
 }
 }
 MachineType target_type = MachineType::Pointer();
 LinkageLocation target_loc = LinkageLocation::ForAnyRegister(target_type);
 const CallDescriptor::Flags kFlags =
 CallDescriptor::kCanUseRoots | CallDescriptor::kFixedTargetRegister;
 return new(zone) CallDescriptor( // --
 CallDescriptor::kCallAddress, // kind
 target_type, // target MachineType
 target_loc, // target location
 locations.Build(), // location_sig
 stack_parameter_count, // stack_parameter_count
 Operator::kNoProperties, // properties
 kNoCalleeSaved, // callee-saved registers
 kNoCalleeSaved, // callee-saved fp
 kFlags, // flags
 descriptor.DebugName());
 } In , parameter 2 is the target bytecode, and parameter 3 is the stack parameter count. This function is used to apply for register resources and create a . The gives what parameters to supply when executing a bytecode. The comments on lines 24 to 25 give its layout. GetBytecodeDispatchCallDescriptor CallDescriptor CallDescriptor In , the on the 9th line is below, we see that it’s parameter 1 is . TailCallBytecodeDispatch TailCallN() CallDescriptor void RawMachineAssembler::TailCallN(CallDescriptor * call_descriptor,
 int input_count, Node *
 const * inputs) {
 // +1 is for target.
 DCHECK_EQ(input_count, call_descriptor -> ParameterCount() + 1);
 Node * tail_call =
 MakeNode(common() -> TailCall(call_descriptor), input_count, inputs);
 schedule() -> AddTailCall(CurrentBlock(), tail_call);
 current_block_ = nullptr;
 } The 5th line generates a node. In the 7th line adds the node to the end of the current basic block. So far, the dispatch is completed and the next bytecode is started to execute. Figure 2 shows the function call stack. AddTailCall() Okay, that wraps it up for this share. I’ll see you guys next time, take care! Please reach out to me if you have any issues. : qq9123013 : v8blink@outlook.com WeChat Email Also published . here

Let's Understand Chrome V8 — Chapter 11: Bytecode Dispatch 

Prototype Design Pattern is a Creational Design Pattern that . You can consider the prototype as a of an object before the actual object is constructed. In this article of the Creational Design Patterns, we’re going to take a look at why we need a Prototype Design Pattern in C++ i.e. motivation, prototype factory & leveraging prototype design pattern to implement . helps in the prototyping(creating/copying cheaply) of an object using separate methods or polymorphic classes template virtual copy constructor By the way, If you haven’t check out my other articles on Creational Design Patterns, then here is the list: Factory Builder Prototype Singleton The code snippets you see throughout this series of articles are simplified not sophisticated. So you often see me not using keywords like override, final, public(while inheritance) just to make code compact & consumable(most of the time) in single standard screen size. I also prefer struct instead of class just to save line by not writing “public:” sometimes and also miss , constructor, , prefix std::, deleting dynamic memory, intentionally. I also consider myself a pragmatic person who wants to convey an idea in the simplest way possible rather than the standard way or using Jargons. virtual destructor copy constructor Note: If you stumbled here directly, then I would suggest you go through first, even if it is trivial. I believe it will encourage you to explore more on this topic. What is design pattern? All of this code you encounter in this series of articles are compiled using C++20(though I have used features up to C++17 in most cases). So if you don’t have access to the latest compiler you can use which has preinstalled boost library as well. Modern C++ https://wandbox.org/ Intent To create a new object cheaply with the help of an already constructed or pre-initialized stored object. The prototype provides flexibility to create complex object cheaply. The concept is to copy an existing object rather than creating a new instance from scratch, something that may include costly operations. The existing object then acts as a prototype & newly copied object may change the same properties only if required. This approach saves costly resources and time, especially when the object creation is a heavy process. So essentially the prototype is quite simply a partially or fully initialized object that you make a copy of. And then you subsequently use for your own benefit with variations. Motivation m_street; m_city; m_cubical;

 Office( s, c, n):m_street(s), m_city(c), m_cubical(n){}
}; m_name;
 Office m_office;

 Employee( n, Office o):m_name(n), m_office(o){}
}; {
 Employee john{ , Office{ , , } };
 Employee jane{ , Office{ , , } };
 Employee jack{ , Office{ , , } }; EXIT_SUCCESS;
} { struct Office string string int32_t string string int32_t { struct Employee string string int main () "John Doe" "123 East Dr" "London" 123 "Jane Doe" "123 East Dr" "London" 124 "jack Doe" "123 ORR" "Bangaluru" 300 return This is not the right approach as you have to write the main office address again & again for each employee detail. This is cumbersome & become more when you want to create an employee list. Moreover, consider the situation when your main office moved to another address. Prototype Design Pattern Examples in C++ A more pragmatic approach would be like this : m_name; Office* m_office; 
 
 Employee( n, Office *o):m_name(n), m_office(o){}
}; Office LondonOffice{ , , }; Office BangaluruOffice{ , , }; {
 Employee john{ , &LondonOffice };
 Employee jane{ , &LondonOffice };
 Employee jack{ , &BangaluruOffice }; EXIT_SUCCESS;
} { struct Employee string const string static "123 East Dr" "London" 123 static "RMZ Ecoworld ORR" "London" 123 int main () "John Doe" "Jane Doe" "jack Doe" return Above solution is suitable for our use case but sometimes we want to customize that office address. And when it comes to pointers & references and any sort of indirection, ordinary copying using operator equals quite simply does not work. A standard way to implement this is by implementing the copy constructor Prototype Factory So in the previous example of the Prototype Design Pattern, we basically had a global for office addresses and used their address for creating prototypes. object Now, this isn’t particularly convenient to the consumers of your API because you might want to give them a prototype to work with. And you should explicit enough in terms of letting people know there is the only a unified way by which they create instances from a prototype and so that they cannot make individual instances by themselves. And in this case, what you would build is off-course is a Prototype Factory: m_street; m_city; m_cubical;
}; m_name;
 Office* m_office; Employee( n, Office *o) : m_name(n), m_office(o) {} :
 Employee( Employee &rhs) : m_name{rhs.m_name}, m_office{ Office{*rhs.m_office}} 
 { }

 Employee& =( Employee &rhs) { ( == &rhs) * ;
 m_name = rhs.m_name;
 m_office = Office{*rhs.m_office}; * ;
 } ostream & <<(ostream &os, Employee &o) { os << o.m_name << << o.m_office->m_street << << o.m_office->m_city << << o.m_office->m_cubical;
 }
}; Employee main; Employee aux; <Employee> NewEmployee( n, c, Employee &proto) { e = make_unique<Employee>(proto);
 e->m_name = n;
 e->m_office->m_cubical = c; e;
 } : <Employee> NewMainOfficeEmployee( name, cubical) { NewEmployee(name, cubical, main);
 } <Employee> NewAuxOfficeEmployee( name, cubical) { NewEmployee(name, cubical, aux);
 }
}; Employee EmployeeFactory::main{ , Office{ , , }};
Employee EmployeeFactory::aux{ , Office{ , , }}; { jane = EmployeeFactory::NewMainOfficeEmployee( , ); jack = EmployeeFactory::NewAuxOfficeEmployee( , ); << *jane << << *jack << ; EXIT_SUCCESS;
} { struct Office string string int32_t { class Employee string // Private constructor, so direct instance can not be created except for `class EmployeeFactory` string friend ; class EmployeeFactory public const new operator const if this return this new return this friend operator const return " works at " " " " seats @" { class EmployeeFactory static static static unique_ptr string int32_t auto return public static unique_ptr string int32_t return static unique_ptr string int32_t return // Static Member Initialization "" new "123 East Dr" "London" 123 "" new "RMZ Ecoworld ORR" "London" 123 int main () auto "Jane Doe" 125 auto "jack Doe" 123 cout endl endl return /*
Jane Doe works at 123 East Dr London seats @125
jack Doe works at RMZ Ecoworld ORR London seats @123
*/ The subtle thing to note here is the private constructor of Employee & friend EmployeeFactory. This is how we enforce the client/API-user to create an instance of Employee only through EmployeeFactory. Leveraging Prototype Design Pattern to Implement Virtual Copy Constructor In C++, Prototype is also useful to create a copy of an object without knowing its concrete type. Hence, it is also known as Virtual Copy Constructor. Problem C++ has the support of polymorphic object destruction using it’s base class’s . Equivalent support for creation and copying of objects is missing as С++ doesn’t support virtual constructor & virtual . virtual destructor copy constructors Moreover, you can’t create an object unless you know its static type, because the compiler must know the amount of space it needs to allocate. For the same reason, copy of an object also requires its type to known at compile-time. Consider the following example as problem statement: ~animal(){ << ; }
}; animal {
 ~dog(){ << ; }
}; animal {
 ~cat(){ << ; }
}; { who; } { struct animal virtual cout "~animal\n" : struct dog cout "~dog\n" : struct cat cout "~cat\n" void who_am_i (animal *who) // not sure whether dog would be passed here or cat // How to `create` the object of same type i.e. pointed by who ? // How to `copy` object of same type i.e. pointed by who ? delete // you can delete appropriate object pointed by who, thanks to virtual destructor Just don’t think of , its code smell. dynamic_cast<> Solution The Virtual Constructor/Copy-Constructor technique allows polymorphic creation & copying of objects in C++ by delegating the act of creation & copying the object to the derived class through the use of virtual methods. Following code is not only implements virtual (i.e. clone()) but also implement virtual constructor(i.e. create()). copy constructor ~animal() = ; :: <animal> create() = ; :: <animal> clone() = ;
}; animal { :: <animal> create() { ::make_unique<dog>(); } :: <animal> clone() { ::make_unique<dog>(* ); }
}; animal { :: <animal> create() { ::make_unique<cat>(); } :: <animal> clone() { ::make_unique<cat>(* ); }
}; { new_who = who->create(); duplicate_who = who->clone(); who; 
} { struct animal virtual default virtual std unique_ptr 0 virtual std unique_ptr 0 : struct dog std unique_ptr return std std unique_ptr return std this : struct cat std unique_ptr return std std unique_ptr return std this void who_am_i (animal *who) auto // `create` the object of same type i.e. pointed by who ? auto // `copy` object of same type i.e. pointed by who ? delete Benefits of Prototype Design Pattern Prototypes are useful when the object instantiation is expensive, thus avoid expensive “creation from scratch”, and support cheap cloning of a pre-initialized prototype. The prototype provides the flexibility to create highly dynamic systems by defining new behaviour through object & specifying values for an object’s data members at the time of instantiation unlike defining new classes. composition You can simplify the system by producing complex objects more conveniently. Especially in C++, Prototype Design Pattern is helpful in creating copy of an object without even knowing its type. Summary by FAQs What’s the point of using the Prototype Design Pattern? To create an object rapidly based on cloning a pre-configured object. Useful to remove a bunch of boilerplate code. Handly while working with object without knowing its type. Prototype Design Pattern is an obvious choice while you are working with the . For example, in HTTP request most of the time header & footer content remains the same, what changes are data. In such a scenario, you should not create an object from scratch. Rather leverage Prototype Design Pattern. Command Design Pattern Is the Prototype Design Pattern Really Just Clone? It isn’t if you combine it with the . Factory Design Pattern Prototype design pattern to be used when creation is costly, but we do create in the clone. You must be wondering that in Prototype Factory we show above, we are creating instances in the copy constructor. Isn’t that expensive. Yes, it is. But just think about HTTP request, its header consist version, encoding type, content type, server-type, etc. Initially, you need a find out these parameters using respective function calls. But once you got these, these are not going to change until connection closed. So there is no point in doing function calls to extract these params over & over. What cost us here is not parameters but their functions to extract value. Previously published at http://www.vishalchovatiya.com/prototype-design-pattern-in-modern-cpp/

Design Patterns: Prototype Pattern in Modern C++

In software engineering, Creational Design Patterns deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic or ordinary form of object creation could result in design problems or added complexity to the design. Builder Design Pattern in C++ solves this specific problem by . separating the construction of a complex object from its representation By the way, If you haven’t check out my other articles on Creational Design Patterns, then here is the list: Factory Builder Prototype Singleton The code snippets you see throughout this series of articles are simplified not sophisticated. So you often see me not using keywords like override, final, public(while inheritance) just to make code compact & consumable(most of the time) in single standard screen size. I also prefer struct instead of class just to save line by not writing “public:” sometimes and also miss , constructor, , prefix std::, deleting dynamic memory, intentionally. virtual destructor copy constructor I also consider myself a pragmatic person who wants to convey an idea in the simplest way possible rather than the standard way or using Jargons. Note: If you stumbled here directly, then I would suggest you go through first, even if it is trivial. I believe it will encourage you to explore more on this topic. What is design pattern? All of this code you encounter in this series of articles are compiled using C++20(though I have used features up to C++17 in most cases). So if you don’t have access to the latest compiler you can use which has preinstalled boost library as well. Modern C++ https://wandbox.org/ Intent To create/instantiate complex & complicated object piecewise & succinctly by providing an API in a separate entity. Builder Design Pattern is used when we want to construct a complex object. However, we do not want to have a complex constructor member or one that would need many arguments. The Builder Design Pattern constructs a complex object step by step & the final step will return the object. The process of constructing an object should be generic so that it can be used to create different representations of the same object with the help of a variety of methods. Life Without Builders Suppose you have to create the HTML generator using C++ then very naïve way to do it is : text = ; output;
output += ;
output += text;
output += ; ( , text); words[] = { , }; oss;
oss << ; ( w : words)
 oss << << w << ;
oss << ; (oss.str().c_str()); // hello auto "hello" string "" "" printf "%s" // <ul><li>hello</li><li>world</li></ul> string "hello" "world" ostringstream "<ul>" for auto " <li>" "</li>" "</ul>" printf A sophisticated dev will create a class with a bunch of constructor argument & method to add a child node. This is a good approach though but it may complicate the object representation. In general, some objects are simple & can be created in a single constructor call while other objects require a lot of ceremonies to create. Having an object with 10 constructor arguments is not productive. Instead, we should opt for piecewise construction. Builder provides an API for constructing an object step-by-step without revealing actual object representation. Builder Design Pattern Example in Modern C++ m_name; m_text; <HtmlElement> m_childs; m_indent_size = ;

 HtmlElement() = ;
 HtmlElement( &name, &text) : m_name(name), m_text(text) {} : { oss;
 oss << (m_indent_size * indent, ) << << m_name << << ; (m_text.size()) oss << (m_indent_size * (indent + ), ) << m_text << ; ( &element : m_childs)
 oss << element.str(indent + );

 oss << (m_indent_size * indent, ) << << m_name << << ; oss.str();
 } <HtmlBuilder> build( root_name) { make_unique<HtmlBuilder>(root_name); }
}; HtmlElement m_root; :
 HtmlBuilder( root_name) { m_root.m_name = root_name; } {
 m_root.m_childs.emplace_back(HtmlElement{child_name, child_text}); ;
 } { m_root.str(); } { m_root; }
}; { builder = HtmlElement::build( );
 builder->add_child( , )->add_child( , ); << builder->str() << ; EXIT_SUCCESS;
} ; class HtmlBuilder { class HtmlElement string string vector constexpr static size_t 4 default const string const string friend ; class HtmlBuilder public string str ( indent = ) int32_t 0 ostringstream string ' ' "<" ">" endl if string 1 ' ' endl for auto 1 string ' ' "</" ">" endl return static unique_ptr string return { class HtmlBuilder public string HtmlBuilder * add_child ( child_name, child_text) string string return this string str () return operator HtmlElement () return int main () auto "ul" "li" "hello" "li" "world" cout endl return /*
<ul>
 <li>
 hello
 </li>
 <li>
 world
 </li>
</ul>
*/ We are forcing users here to use builder by making data members of HtmlElements private. As you can see, we have declared the HtmlBuilder & HtmlElement in the same file & to do so, we need forward declaration i.e. class HtmlBuilder; as it is an . And we can not create the object of incomplete type before compiler parses its actual declaration. The reason is simple, the compiler needs the size of an object to allocate memory for it. Hence pointer is only way around so we have taken <HtmlBuilder>. incomplete type unique_ptr Sophisticated & Fluent Builder Design Pattern Example Following is the more sophisticated example of the Builder Design Pattern in C++ organized in four different files (i.e. Person.h, Person.cpp, PersonBuilder.h PersonBuilder.cpp). Person.h ; :: m_name, m_street_address, m_post_code, m_city; :: m_company_name, m_position, m_annual_income; Person( :: name) : m_name(name) {} : ostream& <<(ostream& os, Person& obj); ;
}; # once pragma # include <iostream> using namespace std ; class PersonBuilder { class Person std string // Personal Detail std string // Employment Detail std string public friend ; class PersonBuilder friend operator const PersonBuilder static create ( :: name) std string Person.cpp PersonBuilder Person::create( name) { PersonBuilder{name}; }

ostream& <<(ostream& os, Person& obj)
{ os << obj.m_name
 << :: << << :: << << obj.m_street_address
 << << obj.m_post_code
 << << obj.m_city
 << :: << << :: << << obj.m_company_name
 << << obj.m_position
 << << obj.m_annual_income;
} # include <iostream> # include "Person.h" # include "PersonBuilder.h" string return operator const return std endl "lives : " std endl "at " " with postcode " " in " std endl "works : " std endl "with " " as a " " earning " As you can see from the above example Person may have many details like Personal & Professional. And so does the count of data members. In our case, there are 7 data members. Having a single class for all the actions needed to create a Person through constructor might make our class bloated & lose its original purpose. Moreover, the library user needs to take care of all those constructor parameters sequence. PersonBuilder.h Person person; :
 PersonBuilder( name) : person(name) {} { move(person); } ; ; ; ; ; ; ; ;
}; # once pragma # include "Person.h" { class PersonBuilder public string operator Person () const return PersonBuilder& lives () PersonBuilder& at ( :: street_address) std string PersonBuilder& with_postcode ( :: post_code) std string PersonBuilder& in ( :: city) std string PersonBuilder& works () PersonBuilder& with ( company_name) string PersonBuilder& as_a ( position) string PersonBuilder& earning ( annual_income) string PersonBuilder.cpp PersonBuilder& PersonBuilder::lives() { * ; }

PersonBuilder& PersonBuilder::works() { * ; }

PersonBuilder& PersonBuilder::with( company_name) {
 person.m_company_name = company_name; * ;
}

PersonBuilder& PersonBuilder::as_a( position) {
 person.m_position = position; * ;
}

PersonBuilder& PersonBuilder::earning( annual_income) {
 person.m_annual_income = annual_income; * ;
}

PersonBuilder& PersonBuilder::at( :: street_address) {
 person.m_street_address = street_address; * ;
}

PersonBuilder& PersonBuilder::with_postcode( :: post_code) {
 person.m_post_code = post_code; * ;
}

PersonBuilder& PersonBuilder::in( :: city) {
 person.m_city = city; * ;
} # include "PersonBuilder.h" return this return this string return this string return this string return this std string return this std string return this std string return this Rather stuffing all those construction related APIs into Person, we can delegate that task to separate entity i.e. PersonBuilder. Main.cpp ; {
 Person p = Person::create( )
 .lives()
 .at( )
 .with_postcode( )
 .in( )
 .works()
 .with( )
 .as_a( )
 .earning( ); < # include "Person.h" # include "PersonBuilder.h" using namespace std int main () "John" "123 London Road" "SW1 1GB" "London" "PragmaSoft" "Consultant" "10e6" cout endl return Isn’t the above construction looks more intuitive, natural & plain English? If you are concerned about blank methods like lives() & works(), then do not worry, it will be eliminated in optimization. You can also observe that we are forcing user’s to use builder rather than constructor by making the constructor private & exposing only create std::string name API. ( ) Do not over complicate things by designing an interface or abstract classes unless you need it. I have seen this in many Builder Design Pattern Examples on Web. Benefits of Builder Design Pattern The number of lines of code increases at least to double in builder pattern. But the effort pays off in terms of design flexibility, fewer or no parameters to the constructor and much more readable code. Builder Design Pattern also helps in minimizing the number of parameters in constructor & thus there is no need to pass in for optional parameters to the constructor. null Immutable objects can be built without much complex logic in the object building process. Segregating construction from makes the object representation slice & precise. Having a builder entity separate provides the flexibility of creating & instantiating different objects representations. object representation Summary by FAQs When should the Builder Design Pattern be used? Whenever creation of new object requires setting many parameters and some of them (or all of them) are optional. Why do we need a Builder class when implementing a Builder Design Pattern? It isn’t necessary but there are some benefits in doing so: The concern of building object should be in the separate entity as per . SRP The original object would not be bloated. Easy & maintainable code. Testing & understanding a constructor with many input arguments gets exponentially more complicated. Greatest Advantage of Builder Design Pattern! More expressive code. MyClass o = new MyClass(5, 5.5, 'A', var, 1000, obj9, "hello"); Instead MyClass o = MyClass.builder().a(5).b(5.5).c('A').d(var).e(1000).f(obj9).g("hello"); You can see which data member is being assigned by what & even change the order of assignment. What’s the difference between Abstract Factory and Builder Design Pattern? Factory produces the objects in wholesale that could be any object from inheritance hierarchy(like Point, Point2D, Point3D). While Builder deals with instantiation of an object that is limited to a single object(Although this statement is still debatable). You see Factory is all about wholesale object creation while the builder is piecewise object creation. In both the patterns, you can separate out the mechanism related to object creation in other classes. Previously published at http://www.vishalchovatiya.com/builder-design-pattern-in-modern-cpp/

Design Patterns: Builder Pattern in Modern C++

Patrones de diseño: patrón de constructor en C++ moderno

In software engineering, Creational Design Patterns deal with object creation mechanisms, i.e. try to create objects in a manner suitable to the situation. In addition to this basic or ordinary form of object creation could result in design problems or added complexity to the design. Factory Design Pattern in C++ helps to mitigate this issue by . creating objects using separate methods or polymorphic classes By the way, If you haven’t check out my other articles on Creational Design Patterns, then here is the list: Factory Builder Prototype Singleton The code snippets you see throughout this series of articles are simplified not sophisticated. So you often see me not using keywords like override, final, public(while inheritance) just to make code compact & consumable (most of the time) in single standard screen size. I also prefer struct instead of class just to save line by not writing “public:” sometimes and also miss , constructor, , prefix std::, deleting dynamic memory, intentionally. virtual destructor copy constructor I also consider myself a pragmatic person who wants to convey an idea in the simplest way possible rather than the standard way or using Jargons. Note: If you stumbled here directly, then I would suggest you go through first, even if it is trivial. I believe it will encourage you to explore more on this topic. What is design pattern? All of this code you encounter in this series of articles are compiled using C++20(though I have used features up to C++17 in most cases). So if you don’t have access to the latest compiler you can use which has preinstalled boost library as well. Modern C++ https://wandbox.org/ Intent For the creation of wholesale objects unlike builder(which creates piecewise). Motivation Let say you have a Point class having x & y as co-ordinates which can be Cartesian or Polar coordinate as below: Point( x, y){ } }; { struct Point float float /*...*/ // Cartesian co-ordinates // Not OK: Cannot overload with same type of arguments // Point(float a, float b){ /*...*/ } // Polar co-ordinates // ... Implementation This isn't possible as you might know you can not create two constructors with the same type of arguments. Other way around is: cartesian, polar }; Point( a, b, PointTypetype = PointType::cartesian) { (type == PointType::cartesian) {
 x = a; b = y;
 } {
 x = a * (b);
 y = a * (b);
 }
 }
}; enum { class PointType { class Point float float if else cos sin But this isn't a sophisticated way of doing this. Rather we should delegate separate instantiation to separate methods. Factory Design Pattern Examples in C++ So as you can guess. We are going to mitigating constructor limitation by moving the initialization process from constructor to other structure. And we gonna be using the Factory Method for that. And just as the name suggests it uses the method or member function to initialize the object. Factory Method cartesian, polar }; m_x; m_y;
 PointType m_type; Point( x, y, PointType t) : m_x{x}, m_y{y}, m_type{t} {} : ostream & <<(ostream &os, Point &obj) { os << << obj.m_x << << obj.m_y;
 } { {x, y, PointType::cartesian};
 } { {a * (b), a * (b), PointType::polar};
 }
}; { p = Point::NewPolar( , M_PI_4); << p << ; EXIT_SUCCESS;
} enum { class PointType { class Point float float // Private constructor, so that object can't be created directly const float const float public friend operator const return "x: " " y: " Point static NewCartesian ( x, y) float float return Point static NewPolar ( a, b) float float return cos sin int main () // Point p{ 1,2 }; // will not work auto 5 cout endl // x: 3.53553 y: 3.53553 return As you can observe from the implementation. It actually disallows the use of constructor & forcing users to use static methods instead. And this is the essence of the . Factory Method i.e. private constructor & static method Classical Factory Design Pattern If you have dedicated code for construction then while not we move it to a dedicated class. And Just to do separation of concerns i.e. from SOLID design principles. Single Responsibility Principle }; : { { x, y };
 } { { r* (theta), r* (theta) };
 }
}; { class Point // ... as it is from above friend ; class PointFactory { class PointFactory public Point static NewCartesian ( x, y) float float return Point static NewPolar ( r, theta) float float return cos sin Mind that this is not the abstract factory this is a concrete factory. Making the PointFactory friend class of Point we have violated the (OCP). As friend keyword itself contrary to OCP. Open-Closed Principle Inner Factory There is a critical thing we missed in our Factory that there is no strong link between PointFactory & Point which confuses user to use Point just by seeing everything is private. So rather than designing a factory outside the class. We can simply put it in the class which encourage users to use Factory. Thus, we also serve the second problem which is breaking the . And this will be somewhat more intuitive for the user to use Factory. Open-Closed Principle m_x; m_y;

 Point( x, y) : m_x(x), m_y(y) {} : { { x,y }; } { { r* (theta), r* (theta) }; }
 };
}; { p = Point::Factory::NewCartesian( , ); EXIT_SUCCESS;
} { class Point float float float float public { struct Factory Point static NewCartesian ( x, y) float float return Point static NewPolar ( r, theta) float float return cos sin int main () auto 2 3 return Abstract Factory do we need an Abstract Factory? Why C++ has the support of polymorphic object destruction using it’s base class’s . Similarly, equivalent support for creation & copying of objects is missing as С++ doesn’t support & . virtual destructor virtual constructor copy constructors Moreover, you can’t create an object unless you know its static type, because the compiler must know the amount of space it needs to allocate. For the same reason, copy of an object also requires its type to known at compile-time. ~Point(){ << ; }
}; Point {
 ~Point2D(){ << ; }
}; Point {
 ~Point3D(){ << ; }
}; { who; } { struct Point virtual cout "~Point\n" : struct Point2D cout "~Point2D\n" : struct Point3D cout "~Point3D\n" void who_am_i (Point *who) // Not sure whether Point2D would be passed here or Point3D // How to `create` the object of same type i.e. pointed by who ? // How to `copy` object of same type i.e. pointed by who ? delete // you can delete object pointed by who, thanks to virtual destructor Example of Abstract Factory Design Pattern The Abstract Factory is useful in a situation that requires the creation of many different types of objects, all derived from a common base type. The Abstract Factory defines a method for creating the objects, which can then override to specify the derived type that will be created. Thus, at run time, the appropriate Abstract Factory Method will be called depending upon the type of object referenced/pointed & return a base class pointer to a new instance of that object. subclasses ~Point() = ; <Point> create() = ; <Point> clone() = ;
}; Point { <Point> create() { make_unique<Point2D>(); } <Point> clone() { make_unique<Point2D>(* ); }
}; Point { <Point> create() { make_unique<Point3D>(); } <Point> clone() { make_unique<Point3D>(* ); }
}; { new_who = who->create(); duplicate_who = who->clone(); who;
} { struct Point virtual default virtual unique_ptr 0 virtual unique_ptr 0 : struct Point2D unique_ptr return unique_ptr return this : struct Point3D unique_ptr return unique_ptr return this void who_am_i (Point *who) auto // `create` the object of same type i.e. pointed by who ? auto // `copy` the object of same type i.e. pointed by who ? delete As shown above, we have leveraged polymorphic methods by delegating the act of creation & copying the object to the derived class through the use of pure virtual methods. Above code is not only implement (i.e. create()) but also implements (i.e. clone()). virtual constructor virtual copy constructor Make sure while using Abstract Factory you have ensured the . Liskov's Substitution Principle(LSP) Functional Approach to Factory Design Pattern using Modern C++ In our Abstract Factory example, we have followed the object-oriented approach but its equally possible nowadays to a more functional approach. So, let's build a similar kind of Factory without relying on polymorphic functionality as it might not suit some time-constrained application like an . Because the may troll system during critical functionality. embedded system virtual table & dynamic dispatch mechanism This is pretty straight forward as it uses functional & as follows: lambda functions }; Point { }; Point { }; <PointType, function< <Point>() >> m_factories; :
 PointFunctionalFactory() {
 m_factories[PointType::Point2D] = [] { make_unique<Point2D>(); };
 m_factories[PointType::Point3D] = [] { make_unique<Point3D>(); };
 } <Point> create(PointType type) { m_factories[type](); } 
}; {
 PointFunctionalFactory pf; p2D = pf.create(PointType::Point2D); EXIT_SUCCESS;
} { struct Point /* . . . */ : struct Point2D /* . . . */ : struct Point3D /* . . . */ { class PointFunctionalFactory map unique_ptr public return return unique_ptr return int main () auto return If you are thinking that we are over-engineering, then keep in mind that our object construction is simple here just to demonstrate the technique & so does our lambda function. When your object representation increases, it requires a lot of methods to call in order to instantiate object properly, in such case you just need to modify lambda expression of the factory or introduce . Builder Design Pattern Benefits of Factory Design Pattern Single point/class for different object creation. Thus easy to maintain & understand software. You can create the object without even knowing its type by using Abstract Factory. It provides great modularity. Imagine programming a video game, where you would like to add new types of enemies in the future, each of which has different AI functions and can update differently. By using a factory method, the controller of the program can call to the factory to create the enemies, without any dependency or knowledge of the actual types of enemies. Now, future developers can create new enemies, with new AI controls and new drawing member functions, add it to the factory, and create a level which calls the factory, asking for the enemies by name. Combine this method with an XML description of levels, and developers could create new levels without having to recompile their program. All this, thanks to the separation of creation of objects from the usage of objects. Allows you to change the design of your application more readily, this is known as loose coupling. Summary by FAQs Abstract Factory & Functional Factory is always a good choice. What is the correct way to implement the Factory Design Pattern in C++? Factory vs Abstract Factor vs Functional Factory? Factory: Create an object with varied instantiation. Abstract Factor: Create an object without knowing its type & refer using base class pointer & reference. Access using polymorphic methods. Functional Factory: When object creation is more complex. Abstract Factory + . Although I have not included Builder in Functional Factory example. Builder Design Pattern What's the difference between Abstract Factory and Builder Design Pattern? Factory produces the objects in wholesale that could be any object from inheritance hierarchy(like Point, Point2D, Point3D). While Builder deals with instantiation of an object that is limited to a single object(Although this statement is still debatable). You see Factory is all about wholesale object creation while the builder is piecewise object creation. In both the patterns, you can separate out the mechanism related to object creation in other classes. When to use the Factory Design Pattern? Employ Factory Design Pattern to create an object of required functionality(s) but type of object will remain undecided or it will be decided ob dynamic parameters being passed. Previously published at http://www.vishalchovatiya.com/factory-design-pattern-in-modern-cpp/

Design Patterns: Exploring Factory Method in Modern C++

Patrones de diseño: exploración del método de fábrica en C++ moderno

Imagine there is something wrong with the water pressure in your house. You have to call to the plumber service. They say that there is a guy, who is honest, and capable, and has a Ph. D. in plumbing, but… He doesn’t speak English well. He came from Tajikistan and only speaks fluent Tajik. But it just so happens that you studied Tajik in college, so you say that they send the guy immediately. When he arrives, you describe the problem (in Tajik), and he gets to work. Soon enough he finds the problem and tries to report it to you, apparently waiting for a reaction. But for some reason he doesn’t use Tajik to report it, he uses English. Which… He doesn’t really know. If you reply (in Tajik) that you don’t understand, he will not switch to Tajik; he will only repeat the same phrase louder. Which doesn’t help to build a dialog at all. Nobody knows why he consistently chooses to reply in the language he doesn’t speak well instead of his own. That you do. It is absurdly irritating, but that’s just how the things work. It’s how they always been. What he speaks in is basically a bad English mixed with professional jargonisms and Tajik obscenities. It looks something like this: In function ‘int main()’: 19:16: error: cannot bind ‘std::ostream {aka std::basic_ostream<char>}’ lvalue to ‘std::basic_ostream<char>&&’ In file included from /usr/include/c++/4.9/iostream:39:0, from 2: /usr/include/c++/4.9/ostream:602:5: note: initializing argument 1 of ‘std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&&, const _Tp&) [with _CharT = char; _Traits = std::char_traits<char>; _Tp = Element]’ operator<<(basic_ostream<_CharT, _Traits>&& __os, const _Tp& __x) Ok, it isn’t about plumbing anymore. In fact, It never was about plumbing. It’s about how we communicate with the machine. A programming language is something we use to tell it what to do, but the machine tries to speak back in English when something gets wrong. Computers don’t speak English well, although they are good at processing formal languages. And presumably, the one who writes in formal language should be able to read it back with no problem. Wouldn’t it be better, if the compiler or interpreter would respond in the same language it gets its commands in? Somehow the idea seems not all that agreeable without a Tajik plumber. So far the only language I know that reports errors in the same language you write code is Erlang. If you know more, please let me know in the comment section below. Here’s a simple example from “ ”: Programming Erlang 1> Point = {point, 10, 45}.
2> {point, C, C} = Point.
=ERROR REPORT==== 28-Oct-2006::17:17:00 ===
Error in process <0.32.0> with exit value:
{{badmatch,{point,10,45}},[{erl_eval,expr,3}]} The string in bold is the error message, the rest is just a preamble from the interpreter. Indeed, it isn’t entirely convenient for the casual reader. You have to know Erlang to read its errors. But since you still need to know Erlang to write the code that causes them, it’s fine. The alternatives are much worse. With informal and non-standardized error messaging you would have to know not only the programming language itself but its error messaging Pidgin as well. Every C++ practitioner can confirm that reading STL messages is an art by itself. It takes knowledge, patience, determination and, occasionally, a crystal ball to build a firm understanding of a reported problem. For instance, the error message from above reads as “sorry, I can’t print out an element for you, because its type doesn’t have a << operator.” Normally the language is something you can build a dialog in. Programming languages are an unlucky exemption. Historically it was more important to tell a computer what to do rather than the opposite. When you write a small single-threaded program you can hope that there will be no errors whatsoever, so you don’t really need a reporting at all. Error reporting was always viewed as an auxiliary feature. Erlang, however, aims at building highly complex distributed systems. Errors are not only most likely to happen, they are inherent to the nature of the domain. Everything that could go wrong eventually will. And you better have a decent reporting language for that. The very fact that you can have a dialog, meaning writing code and receiving errors in the same language, makes Erlang not only programming but a true computer language.

Why is Erlang the only true computer language

10 Best AI Music Generators for Streamlined Music Generation Process

Təkmilləşdirilmiş Musiqi Yaratma Prosesi üçün 10 Ən Yaxşı AI Musiqi Generatorları

10 nejlepších hudebních generátorů AI pro zjednodušený proces generování hudby

Οι 10 καλύτερες γεννήτριες μουσικής AI για βελτιωμένη διαδικασία δημιουργίας μουσικής

Los 10 mejores generadores de música con IA para un proceso de generación de música optimizado

Os 10 mellores xeradores de música AI para un proceso de xeración de música simplificado

10 pi bon jeneratè mizik AI pou pwosesis jenerasyon mizik rasyonalize

A 10 legjobb AI zenegenerátor az egyszerűsített zenegenerálási folyamathoz

合理化された音楽生成プロセスのための 10 のベスト AI 音楽ジェネレーター

Mpamorona Mozika AI 10 tsara indrindra ho an'ny fizotry ny famoronana mozika mirindra

Imashini 10 nziza yumuziki wa AI kubikorwa byogutunganya umuziki

10 Gjeneruesit më të mirë të muzikës me AI për procesin e gjenerimit të muzikës më të thjeshtë

10 Tijeneretara ta Vuyimbeleri bya AI letinene ta Endlelo ro Endla Vuyimbeleri lebyi Olovisiweke

Stream Processing - Windows

Stream Processing - Concepts

As a Product Evangelist, I regularly test and demo various APIs to better understand their capabilities. For a very long time, Postman has been my go-to tool. It’s straightforward, reliable, and does the job well. But recently, I discovered a game-changing feature that took my exploration to a whole new level and that’s the Postman’s pre-request scripts. Before now, I was running basic tests and manually inputting certain values even though I used variables for handling some auth, which worked fine but felt a little tedious over time. Yesterday, while playing around with Postman, I found a way to streamline my testing process using pre-request scripts, and the results were incredible. I started with a simple need by generating a unique transaction reference for an endpoint. Rather than manually entering a reference each time, I used Postman’s UUID function to automatically create a random 12-character transaction reference. function generateTransactionRef() {
 const characters = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789';
 let result = '';
 for (let i = 0; i < 12; i++) {
 const randomIndex = Math.floor(Math.random() * characters.length);
 result += characters[randomIndex];
 }
 return result;
}

var uniqueTransactionRef = generateTransactionRef();
pm.environment.set("transactionRef", uniqueTransactionRef);

console.log("Generated transactionRef:", uniqueTransactionRef); This random reference was then shared with other endpoints, making it easy for the APIs to access the same reference seamlessly. For example, one API requires a transactionref as part of the body to simulate transfer. With the script in place, I could automatically use the generated reference across multiple requests. This eliminated manual entry and potential errors. The value generated gets reused across any endpoint that needs it, keeping my testing smooth and consistent. Another API I work with requires a token to be refreshed every 30 minutes. This was something I used to manage manually, which felt like a waste of time having to copy-paste every time the token expires. But using pre-request scripts, I automated the entire process. Now, Postman grabs the newly generated token from the first request and automatically inserts it as the bearer token for subsequent requests in the same environment. var requestOptions = {
 url: 'URL to generate the token',
 method: 'POST',
 header: {
 'Content-Type': 'application/json'
 },
 body: {
 mode: 'raw',
 raw: JSON.stringify({
 "username": "user's email",
 "password": "user's password"
 })
 }
};

pm.sendRequest(requestOptions, function (err, res) {
 if (err) {
 console.error('Error fetching token:', err);
 return;
 }

 var jsonResponse = res.json();

 if (jsonResponse.statusCode === 90000 && jsonResponse.data && jsonResponse.data.token) {
 var token = jsonResponse.data.token;
 pm.environment.set('bearerToken', token);
 console.log('Token fetched and saved:', token);
 } else {
 console.error('Error: Token not found in the response. Response:', jsonResponse);
 }
});

pm.request.headers.add({
 key: 'Authorization',
 value: 'Bearer ' + pm.environment.get('bearerToken')
}); For all the other endpoints, the script picks up this token and adds it as the authorization header. This small tweak made my workflow far more efficient, as I no longer have to pause or copy-paste for manual token updates. This new approach has 10x’d the way I test, demo, and document APIs. The flexibility and power of Postman’s scripting features have opened up new possibilities for how I approach my work. I’m excited to keep exploring more features to make my API testing even more seamless. Next on my list is setting up API monitoring. I’ve done it in the past but can’t quite remember all the steps. Once I get that up and running again, it’ll be another big win for making sure everything stays up and running smoothly. Postman is more than just a tool for running API requests seeing that with a little scripting, it’s become a critical part of my workflow, allowing me to focus more on other important projects and less on repetitive tasks. If you haven’t started using pre-request scripts yet, I highly recommend giving them a try and they might just transform how you work. Let me know what you think about this short article and if I should be sharing more in this direction. As a Product Evangelist, I regularly test and demo various APIs to better understand their capabilities. For a very long time, Postman has been my go-to tool. It’s straightforward, reliable, and does the job well. But recently, I discovered a game-changing feature that took my exploration to a whole new level and that’s the Postman’s pre-request scripts. Before now, I was running basic tests and manually inputting certain values even though I used variables for handling some auth, which worked fine but felt a little tedious over time. Yesterday, while playing around with Postman, I found a way to streamline my testing process using pre-request scripts, and the results were incredible. I started with a simple need by generating a unique transaction reference for an endpoint. Rather than manually entering a reference each time, I used Postman’s UUID function to automatically create a random 12-character transaction reference. function generateTransactionRef() {
 const characters = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789';
 let result = '';
 for (let i = 0; i < 12; i++) {
 const randomIndex = Math.floor(Math.random() * characters.length);
 result += characters[randomIndex];
 }
 return result;
}

var uniqueTransactionRef = generateTransactionRef();
pm.environment.set("transactionRef", uniqueTransactionRef);

console.log("Generated transactionRef:", uniqueTransactionRef); function generateTransactionRef() {
 const characters = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789';
 let result = '';
 for (let i = 0; i < 12; i++) {
 const randomIndex = Math.floor(Math.random() * characters.length);
 result += characters[randomIndex];
 }
 return result;
}

var uniqueTransactionRef = generateTransactionRef();
pm.environment.set("transactionRef", uniqueTransactionRef);

console.log("Generated transactionRef:", uniqueTransactionRef); This random reference was then shared with other endpoints, making it easy for the APIs to access the same reference seamlessly. For example, one API requires a transactionref as part of the body to simulate transfer. With the script in place, I could automatically use the generated reference across multiple requests. This eliminated manual entry and potential errors. The value generated gets reused across any endpoint that needs it, keeping my testing smooth and consistent. Another API I work with requires a token to be refreshed every 30 minutes. This was something I used to manage manually, which felt like a waste of time having to copy-paste every time the token expires. But using pre-request scripts, I automated the entire process. Now, Postman grabs the newly generated token from the first request and automatically inserts it as the bearer token for subsequent requests in the same environment. var requestOptions = {
 url: 'URL to generate the token',
 method: 'POST',
 header: {
 'Content-Type': 'application/json'
 },
 body: {
 mode: 'raw',
 raw: JSON.stringify({
 "username": "user's email",
 "password": "user's password"
 })
 }
};

pm.sendRequest(requestOptions, function (err, res) {
 if (err) {
 console.error('Error fetching token:', err);
 return;
 }

 var jsonResponse = res.json();

 if (jsonResponse.statusCode === 90000 && jsonResponse.data && jsonResponse.data.token) {
 var token = jsonResponse.data.token;
 pm.environment.set('bearerToken', token);
 console.log('Token fetched and saved:', token);
 } else {
 console.error('Error: Token not found in the response. Response:', jsonResponse);
 }
});

pm.request.headers.add({
 key: 'Authorization',
 value: 'Bearer ' + pm.environment.get('bearerToken')
}); var requestOptions = {
 url: 'URL to generate the token',
 method: 'POST',
 header: {
 'Content-Type': 'application/json'
 },
 body: {
 mode: 'raw',
 raw: JSON.stringify({
 "username": "user's email",
 "password": "user's password"
 })
 }
};

pm.sendRequest(requestOptions, function (err, res) {
 if (err) {
 console.error('Error fetching token:', err);
 return;
 }

 var jsonResponse = res.json();

 if (jsonResponse.statusCode === 90000 && jsonResponse.data && jsonResponse.data.token) {
 var token = jsonResponse.data.token;
 pm.environment.set('bearerToken', token);
 console.log('Token fetched and saved:', token);
 } else {
 console.error('Error: Token not found in the response. Response:', jsonResponse);
 }
});

pm.request.headers.add({
 key: 'Authorization',
 value: 'Bearer ' + pm.environment.get('bearerToken')
}); For all the other endpoints, the script picks up this token and adds it as the authorization header. This small tweak made my workflow far more efficient, as I no longer have to pause or copy-paste for manual token updates. This new approach has 10x’d the way I test, demo, and document APIs. The flexibility and power of Postman’s scripting features have opened up new possibilities for how I approach my work. I’m excited to keep exploring more features to make my API testing even more seamless. Next on my list is setting up API monitoring. I’ve done it in the past but can’t quite remember all the steps. Once I get that up and running again, it’ll be another big win for making sure everything stays up and running smoothly. Postman is more than just a tool for running API requests seeing that with a little scripting, it’s become a critical part of my workflow, allowing me to focus more on other important projects and less on repetitive tasks. If you haven’t started using pre-request scripts yet, I highly recommend giving them a try and they might just transform how you work. Let me know what you think about this short article and if I should be sharing more in this direction.

Streamlining API Testing with Postman’s Pre-Request Scripts

EasyTdd 0.5.0: Streamlining Mocking with Incremental FluentMock and Other Updates

Stories, News & Mentions about OSTREAM

Ostream’s Stories on HackerNoon